Making Agile Sausage and the 40% Rule

I recently stumbled across an article about Agile standup meetings told through references to the Chicken and the Pig project fable. The article is a conversation re-cap from the Yahoo Scrum Development group. The theme is chicken participation in standup meetings--how many chickens are too many?

Note: Throughout this blog post I will make references to chickens and pigs. My only meaning in this context is through the project fable mentioned above. I do not intend to convey any additional connotations associated with chickens or pigs. They are simply representations of the different roles in and around a software project.

My answer is 40%. When the number of chickens approaches and exceeds 40% of the total number of attendees in the standup, strange things begin to occur.

On a previous software project, my team’s standup meetings started taking on a presentation-like quality. Team member updates became terse. Real impediments were occasionally muted or missed completely. In general, the standup meetings became less about team collaboration and communication and more about project status updates. So, for a week, I counted and figured the percentage. 40% of the attendees were chickens.

It is not hard to imagine why the intent of a meeting can change over time in such an environment. On this particular project, the team members were actually asked to stand in front of the board and physically point to the story or task on which they were reporting. This was done so attendees could tell which index cards were currently being discussed. So not only was the standup meeting degrading to a forum for status updates, it also was being choreographed!

I understand the pragmatic-minded readers are probably questioning my 40% rule by now. Is there really something significant about 40%? No. It just makes better blog entry titles. My point is that standup meetings are similar to tools in a mechanic’s toolbox. The best tools are the ones that have a specific and narrow purpose. The all-in-one screwdrivers are usually flawed in some major way. They try to do too much, so they do not perform any one function particularly well. In my experience, standup meetings are similar. They do not serve multiple purposes very well.

So how do we know when our standup meetings are not serving their original purpose? Some simple observations will probably suffice. Here is my list:

1. Team members sound like they are reporting rather than sharing.
2. A significant number of team members are visibly nervous before their update.
3. The team starts to dread the daily standup meeting, whether stated or observed.
4. The standup meeting is directed (choreographed) by someone.
5. The project manager has stopped sending regular status reports to management and instead invites them to attend the standup meeting so they can get updates directly from the team members.

Is the answer to the standup problem to un-invite chickens? That does not seem to be a good long term solution. Agile projects are supposed to be transparent. I think it is important for management to feel they are welcome to observe the software development process first hand. Agile teams need to be transparent and open to be successful. But openness requires a level of trust; and trust only grows when parties observe common boundaries.

My advice for managers and product owners: If someone invites you to watch sausage being made, don’t complain that it is gross. Up close, software development can be messy and a bit erratic. If you value transparency, then find a way to build trust with the team. If you need a status update, talk to your project manager.