Andrew on Agile

During my ScrumMaster certification, Mike Cohn recommended that the size of a cross functional scrum team should be between 5 and 9.  In a recent exercise, we tried splitting a scrum team three ways – 5-6 people in each team - for the next release.

At the end of last year I counted 16 people in a scrum.  For most of the release the team size averaged 12, consisting of a mix of product managers, QA, front-end engineers, software engineers and the ScrumMaster.  16?  It never meant to get that big, but with an addition here and an addition there, it did.  It was too big.

The scrums were starting to take too long, there were too many stories in the sprint for one team to truly keep track and impediments were flying around everywhere.  Risk was starting to creep into each sprint and eventually the release.

I put it to the team that they should split in half for the next release and while some members were ok, others really objected to the idea.  They felt it would generate unnecessary tension between a team that had grown strong together.

Due to the type of work within the first sprint in that next release the team worked as one again, but agreed tentatively to an unequal split (1/3 to 2/3) for the following two (and final) sprints.  It was ok, both teams had a couple of issues mainly down to the fact that they were building three applications which all needed to communicate with one another, but the smaller team certainly preferred being small.

So now they’ve split into 3.

It’s brilliant.  The teams are made up of 1-2 QA, 2-3 Engineers and a Product Manager.  The teams were encouraged to go through the agile scrum motions how they saw fit.  The smaller size enabled intense collaboration during a short planning phase, resulting comprehensive stories.  Poker and sprint planning was a breeze, less big personalities to get in the way of proceedings, and it was so much easier to keep on top of the progress during the sprint.  The software’s of high quality.  It’s done.  It contains a good level of tests and the quality of the code is great.

Now that risk is greatly reduced.  In the sprints before if something started to go wrong it could have affected the whole team.  All members would get distracted by the issue and if it didn’t get resolved and the goal compromised, the team would be left demoralised by all the drama such failed sprints bring.  Oh yeah, and the team members love it.

So if it was going good, then the team gets bigger and you start to have problems, or if you’re trying things for the first time and some members aren’t engaging, break it down.

Change is good.  That’s what we always say right?  On this occasion it really was.  Recently a new member of an engineering team brought with them from their previous organisation some great alternative ideas for agile approaches.  One in particular was the format of their retrospective.

It goes like this:

The scrum team are all present.

There are two sets of post-it notes, each of a different colour, it’s agreed what colour is for good and what colour is for bad.

The team collectively set about writing one point per post-it what they feel was good and/or bad about the iteration they’ve just completed.

Each team member then gets a chance to stand up in front of the team and read out their notes, elaborating when either prompted or just when they feel like it, and stick them on a board.

When everyone has had their turn, the post-its are categorised into topics and grouped together.

It’s very easy to see what was good about the iteration, but also what was bad.

Then team members each have three votes for improvement which they can add to whatever post-it, or its, they choose.

The votes are tallied and the two topics (either grouped or individual) with the highest amount of votes are turned into backlog items for the next iteration.  Of course if there are other negatives that can be easily addressed they are not excluded.

We’ve found this format to be very successful.  The structured approach means we easily fit into the time box for the meeting.  Every team member gets their chance to praise what they liked, or vent their frustration over what they didn’t; it’s actually quite a good bonding session.  The focus on the big negatives means they never fester and are addressed promptly, so the team is continually improving.