The standard reporting technique for an Agile stand-up is to run around the team and get everyone to quickly report on three things:
- What I did yesterday
- What I am going to do today
- 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:
- Achievements
- 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:
- "My tasks are 95% complete"
- "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@
1 comment:
i was in a very large project group with 30+ people at standup. by the end no one could remember what most others had said.
since it was primarily devs in the group, and we are pair all the time, we tried to split into two groups with one member from each pair attending each group.
had some success with this but the biggest problem was with the attendees who we're pairing; ba's, project managers etc.
Post a Comment