June 17, 2014

Are You Coming to Standup?

Many software companies follow the practice of “stand-up” meetings. The intended purpose of this daily ritual is for team members to:

communicate status updates to each other on work since the last meeting.
share the current day’s objectives.
raise any potential concerns, roadblocks, questions etc.

It boils down to one thing: communication. In a software project, each member has to know what’s going on. Otherwise (usually wrong) assumptions are made & effort is duplicated. Stand-up meetings promise to improve communication, but most teams fail at them.

Think back to your last stand-up. Was it a status update meeting for the sake of getting your designer/manager/Q.A. up to speed? Was it your boss presenting top-down updates to the team? Was it a bug scrub? Planning for the next release? If so, guess what: you’re not doing it right. The good news is, it probably doesn’t even matter if you did.

Let’s say your team executes stand-ups perfectly, every single day. This 5-15 minute huddle is only enough time for everyone to glance over what they did yesterday and are planning to do today. Sweet, just a 15 minute meeting for that slight sense of control. But what did this just cost the team? How long will it take everyone to mentally return to the state they were in before the interruption? Some groups try to mitigate this by doing stand-ups first thing in the morning. (note: many great devs are night owls and will absolutely hate that you did this to them). Rise and shine, welcome to stand-up. At this point have you had time to actually plan what you’re going to tackle that day? Or do you just hurry and think of something to say before it’s your turn? If during the day you stick with your answer, your planning is haphazard and sloppy. If you change what you’re working on, your team is out of date. The daily standup routine is a micro-managing solution, and should probably only be used if the team is composed of unmotivated people who need constant accountability checks. Otherwise, there are better tools.

Communication #

Daily status meetings are an attempt to formalize the healthy communication that occurs naturally in great teams. It’s like the Mimic Octopus warding off predators by changing shape and color to look like a poisonous snake (which is freaking awesome BTW).

But the real thing doesn’t happen every morning at 9AM. It happens at 10:26AM when Mark gets in to work and excitedly shows Sydney and Jared the sweet canvas feature he finished at 3 in the morning. It happens during lunch when Sam explains how he’s thinking of building the new command line tool. It happens automatically when people are enjoying what they’re working on and who they’re working with. If your team isn’t communicating, process is not the answer. You have to fix the real issues. It might be something as simple as not sitting near each other. The team might be bored out of their minds doing nothing but fixing bugs. Or it might not the right mix of people to begin with. Stand-up can’t help you here.

Tools #

Once the team is actually communicating, they can add tools into the mix to make things even better. But be very careful here. Just like with stand-up meetings, the purpose of these tools is not for reporting up the chain. It is for enhancing communication between members of the team. I’ve seen too many projects default to using Jira and set it up in a way that caters to the managers. Suddenly the teams find themselves buried alive in epics, sprints, fix versions, release versions, statuses, workflows, and a myriad of process that is completely foreign to the way the team actually works. Three sure signs that this has already happened to your team:

You have a “kanban” board but the columns have been locked down for better reporting.
You have a dozen custom fields.
You have to keep bugging the devs to use the blasted thing.

The team should pick a tool they love using, to help them keep each other up to date. My personal preference for this is Trello. It’s very simple, it updates real-time via web sockets, and people actually enjoy using it. At a single glance I know if Mike has finished writing that REST service I need to call. Lance knows everything he needs to take a look at because he’s subscribed to the “QA this” column. We all know what everyone’s status is because it’s right there; we can check it asynchronously when we want/need to. I’ve been on several teams now where teammates avoided using other solutions but fell in love with Trello. Use whatever works for your team, and use other tools for reporting up the chain (demos, release notes, macro status updates etc).

Focus #

After communication, the other benefit stand-ups try to provide is focus. Software projects can get crazy. Developers need a way to focus on the things that move the project forward. In my opinion scrum misses the mark - two or three week sprints are too long an interval for a single focus. Daily stand-ups are too short. What I’ve found works best for me is a weekly focus. Franklin Covey’s 5 Choices to Extraordinary Productivity calls these “big rocks” - the one or two most important things you can get done this week to progress the project. You get these big rocks done and your week is going to feel awesome. The little things will fall into place. If you spend all your time “sorting gravel” - email, other people’s priorities, meetings, debates, minor bug fixes, etc. both you and your project will be at risk.

I’ve been on teams where we would get together for a few minutes at the beginning of each new week - to decide the next big rock we each wanted to tackle that week. We then tracked these in Trello with cover images to make them stand out.