Stand-ups – We can do better

Every development team I have worked on since about 2009 has had a daily stand-up meeting. Along with sprint planning and retrospectives, stand-up meetings are one of the holy trinity of SCRUM meetings whose existence and necessity are seldom challenged. But what are stand-ups really for?

  • Reporting of task status. This should be handled by some sort of task board that your team keeps updated. If management or another interested party wants a progress report of the state of a project, a stand-up meeting is probably the worst way for them to get that information. They would need a full rundown of what is done and what yet needs to be done, which really shouldn’t be happening every day with all of your developers standing there.
  • Reporting roadblocks to scrum master and team. Why wait until the stand-up to tell people you’re stuck? Do it as soon as your stuck!
  • Communication among team members. This is the true aim of the stand-up, and the reason I say that stand-ups aren’t totally useless. You can do a quick check to make sure that someone else doesn’t already have a solution to the problem you are facing. You can also make sure that you and another developer aren’t planning on working on the same thing. However, you really don’t get any benefit beyond that. I think there is a more advanced tactic out there that you can use for better results. Which leads us to…

Pair programming

Isn’t that only 50% efficiency you say? Pair programming is a lot more effective than it appears on the surface. You get stuck on a problem less often. You have another person there to come up with ideas and keep you focused. Most development time isn’t spent typing, it is spent thinking about hard problems. Talking to another smart person can really kick your thinking into overdrive.

The less-obvious but extremely powerful benefit to pair programming is its effect on team communication. In my experience, the biggest hurdle to fluid intra-team communication is trust. When a developer can go off and solve a problem without any team interaction, they do not have to expose the messy discovery process that led to the solution. The stand-up communication cycle gives each team member 24 hours to go off on their own and work on something in complete isolation before reporting back to the team. That cycle isn’t that long, and it does keep the rest of the team updated along the way, but it doesn’t build trust.

In order to build trust, you will need something that exposes each developer’s discovery process to the other team members. Once each team member realizes that nobody else knows exactly what they are doing either, then they can start feeling more comfortable seeking help and guidance as issues come up in real time. Developers will be able to improve their process by watching and understanding the process of others instead of just hearing about the results at the end. It will be much more effective than a 15 minute (if you are lucky) meeting every morning.

The other major benefit to working with someone else in real time is that there is another person that intimately understands the problem you are working on. They can more easily swap into your problem context to help you out at a later date, or potentially even pick up the work if you are needed elsewhere. Those are communication benefits that you just don’t get when you are only half listening to your teammate spend 60 seconds telling you what they did yesterday, what they are going to do today and what roadblocks they currently have.

How do we start?

I am not going to propose that developers should work in pairs all day. Firstly, pair programming is intense and exhausting. Secondly, the developers on the team will probably be feel a bit vulnerable and reluctant to embrace the idea. I think of it as a small tool to kick-start communication.  I once worked on a team that had a loose rule/guideline that we pair with another developer for an hour a day. On a team of four or five developers, it wasn’t difficult or intrusive to find someone to pair with at some point during the day. I found that even at that short duration, trust and knowledge quickly spread throughout the team. It was easily the most communicative development group I have ever been a part of.

Have your team read this post, and then propose at your next sprint retrospective that the team try having one short pair programming session a day. If you elect to keep the stand-up meeting in place, watch it become pointless when everyone in the circle already knows what everyone else is going to say.