An alternative to "yesterday, today, blockages" reporting in an Agile stand-up

The standard reporting technique for an Agile stand-up is to run around the team and get everyone to quickly report on three things:

1. What I did yesterday
2. What I am going to do today
3. Blockages

This works really, really well in teams of about 5-8 people, but I have noticed that it can become unwieldy if the team gets much larger. Leaving aside the obvious solution of breaking the team up into smaller units (which might not always be possible, as I found out today on a project that I am working on), I was wondering if there was anything that I could do to make the run-around work a little more smoothly.

One thing that we've tried that can improve the stand-up is to reduce the standard three questions down to just two:

1. Achievements
2. Blockages

Because not everyone will have daily achievements, nor will everyone have daily blockages, you can skip some of the team as necessary, which can speed things up. In a large group, it can give you some extra time to celebrate or congratulate those people that do have an achievement to report, even if it is only small. Or equally, to flag a blockage that needs some more attention. I've noticed that the group recognition is (generally) enough to spur others to participate when they have something worth telling the team.

I know this might sound a little like heresy, but it does actually work, as long as you are very diligent to watch out for two specific pitfalls. These are:

1. "My tasks are 95% complete"
2. "I have nothing to report"

If you find that someone on the team is falling into the "95% complete" rut, then you need to help them out by engaging them directly in the stand-up, and if necessary, go back to the standard three questions to help them out. Equally, if someone has nothing to report for more than 2 or 3 days, its a good sign that something is wrong, or at least, it's enough of a flag to the scrum master to pay a little more attention to that person.

I don't think that this is a substitute for the normal 3-point reporting style, but some stand-ups just get a little larger than you would like, and often this can be out of your control.

I'll see how this new technique goes over the next couple of weeks, and then follow-up with my findings.

M@

Murals and Skyscrapers

I think that everyone knows that the "like building a skyscraper" metaphor is thoroughly wrong for describing the process of building software. However, it doesn't seem to stop it being used again and again (and often clueless project managers are the worst offenders). I have a hunch that attachment to this metaphor might have something to do with why the same project managers have such a love affair with Microsoft Project. But that's another story altogether.

However, today I heard a thoroughly great metaphor for software, one that I haven't heard before, and it really resonated with my experiences building software. I really wish I could claim credit for coming up with this, but sadly, it was a colleague at my current consulting engagement. Tip o' the hat to Andrew. Nice work.

Anyway, the metaphor is a simple one and it goes like this: Software is like a bunch a people painting a mural. You all stand around for a while, maybe pencil out a rough outline, maybe mix some colours and sample how they look on the wall. Then you split up, and some of the team works on one part, and some on others, perhaps individually or in small teams. You come together regularly to assess progress and decide where to go next. There's generally someone in charge, in some form or other (or maybe not), and they might work on their own section, perhaps one of the most challenging bits. Every now and again, you take a step back, and there are some parts that you have to rub out, paint over and redo. It's collaborative and non-linear. Sure, you need an outline and some sort of plan to start, but the way it ends up is very much influenced by the process.

Not only is this a good metaphor for software in general, I think it's an espescially good metaphor for agile software development because it emphasises collaboration and iteration. I will be sure to use it next time I am trying to explain to someone why traditional project management tools are such crap for managing software development.

M@