A blog.

Standing up against stand ups

In the first post following on from That’s not agile I want to look at a practice I find to be one of the most tricky and contentious issues I encounter when discussing Agile, especially with developers: the daily stand up. Many Agile people tell me that these daily sessions are a MUST and you’re not Agile if you’re not doing them. However, these sessions aren’t described in all agile methodologies and, in many cases, you can watch these meetings as if you were an anthropologist and see where the project is not actually agile at all.

Many agile teams use stand ups (or daily scrums) to ensure that the team is working through the backlog/tasks/stories effectively. Take a look at the list below and see if any/all of these match what you see/experience:

  1. The stand up goes for longer than 15–20 minutes
  2. The project manager/scrum master/loudest person does all the talking
  3. Most people are sitting down
  4. People have their laptops, tablets and mobiles out and are reading off them
  5. It’s rare that the whole team is there at every stand up
  6. Someone is pointing at a gantt chart

Most stand ups I’ve been involved in usually hit 3–4 of those items. In most situations I can tell that the team is needing (crying out for) better communication levels so Item 1 is most common. Of course, if the project team is communicating fluently throughout the day, these daily meetings may not be required at all. In fact, the somewhat artificial nature of the approach can lead to breaks in thought and communication that’s already going on within the team.

Some project managers have indicated to me that it’s a useful approach if the team is distributed and/or some members are working across projects. In both of these situations I wonder if the structure is actually debilitating and that, instead of stand ups, the project would be better served by bringing the team into the same room and ensuring team members are focussed on one project at a time. The context switching hits in numerous ways - it’s an attention break and sometimes a complete change in direction (especially for the project part-timer).

Another reason often cited is that developers don’t communicate very well. First up, it’s important to check that assertion before reacting to it as many developers will sit right next to each other and instant message throughout the day. If your criteria for communication is talking out loud perhaps you need to dig a bit deeper. Crystal Clear stresses the utility of osmotic communication and many of us will have seen projects that just hum - people talking, sharing, laughing. Team members are actively problem-solving with each other, grabbing a coffee and discussing a piece of the architecture or drawing all over the whiteboard. Those teams using XP are pair programming and those that aren’t XP’ers may pair program ad-hoc when a tricky problem has come up. Throughout the day there are waves of quiet as people focus and louder times when discussions need to happen.

My big question here is: when the team is humming, do you really need a stand-up?

If the team is in the same location and someone completes a story couldn’t they just call out “I’m done with Story X and reckon I’ll pick up Story Y” or if they have a problem is calling out “Story W is killing me - the message queue looks like it’s not <blah> - anyone able to help me for a bit?” not effective? Do they really need a stand up? Doesn’t the PM/scrum master/lead hear this because they’re in the same room anyway?

I believe the answer is that you don’t need these daily meeting but… in the early stage of a project or with a new team member it might be worth using stand ups to try and kick-start the communication. As always, monitor, reflect and respond to the situation - don’t just do something because you’ve been told “that’s agile”.