Effective Stand-ups - the art of the huddle
Some of the most effective stand-ups I’ve ever been a part of were at the end of very long waterfall projects that have gone horribly, horribly wrong.
These projects were either late and at the point where the testing was uncovering hideous bugs while people were struggling to rush out the final features, or they had gone live with lots of bugs in that soul-destroying state where customers are trying to use a website with more going wrong than right.
Every day the team tasked with turning the situation around stood together and had a conversation along these lines of “What is our biggest problem right now?” or “What is the place where we can make the most impact TODAY?”.
With that agreed, the team members would add in what they know or think about the problem. Tasks were assigned or volunteered and a plan for the day agreed on. Then people got to work and tried to meet that commitment so that everybody was in a better place by the end of the day.
While those projects were in a horrible situation, I found them the most exhilarating to work on. The teams those projects have been some of the most effective, most cohesive groups of people I’ve worked with.
In contrast, most “agile” project teams I’ve witnessed have daily stand-ups which are the most mind numbingly boring ceremonies you can imagine. To the point where I’ve often heard statements like “We don’t see any value from our stand-up, so we should stop them”.
You know what these look like.
Everybody standing in a circle looking half asleep while each person stares at their shoes and rambles something like:
“Yesterday I worked on the user account feature and I didn’t get that finished because I found that I didn’t know xyz so I sent an email to the team and I haven’t heard back so I’m blocked on that one so I picked up the reset password feature and I’ll work on that today but I have a meeting today so I don’t know how much I’ll get done on that but if I hear back from my email and that gets resolved I’ll pick that up again and maybe get that finished…..oh yeah, no impediments”
And so it goes around the team and nobody really cares.
It’s horrible, usually a total waste of time, and nobody wants to go to those meetings. So people look to either blame agile itself or the individual team members who are trying to follow “the rules” and answer the three questions.
Meanwhile any information that’s actually worth sharing about problems and solutions usually gets shut down and “taken offline”. I’ve seen developers come up with “creative” solutions like throwing stress balls at people who talk too much in the stand-up.
I see this as attacking the symptoms of a problem rather than looking for the cause.
If your team doesn’t have a collective goal, then having a daily stand-up is just about status reporting rather than a coordination point.
Too many teams see their goal as getting as many story cards moved on a wall as possible in the space of two weeks. This is a problem with the planning of a iteration (if you have them) and the leadership of the team, which usually reflects a wider organisational dysfunction.
If we spend more time thinking and talking about our goals as a team, then it’s much easier to focus a daily stand-up to information that is useful to share.
The standard three questions in an stand-up are a good template and starting point, but I’ve found it better to focus the team by posing the question of what we can do to get us closer to some shared goal. This goal might be a release, the end of a sprint or iteration or just a particular feature. The closer we are to this goal the more real the conversation is (which is why we do short iterations and/or limit Work in Progress).
In a situation with less clarity such as a new team, new project, or a chaotic situation like the ones I started with it might be “what could we achieve today that will leave us in a better place?”.
Once we’re all thinking about the same end goal the discussion becomes a lot more practical and relevant and you start to find the teamwork and interactions that an agile team is meant to have.
In his talk “Pimp My Architecture”, Dan North has a great metaphor which I’ve been using for years as an agile coach and leader. He talks about a Gridiron team in a huddle. They have a very short term goal.
“How many yards can we get towards the goal line before the next time we stop. What can we do to make the next 20 seconds the best we can. Plays are called, the team agrees, everybody does their part in the play and if they do it right, they regroup again in a very short time and do it again”.
This is what a stand-up should be.
Some tips if you’re struggling
Look at the work you’re doing as a team. Try to look at your planning and prioritisation so people can work more on related items. If your planning can talk through a roadmap to get from where you are to where you need to be the dependencies should drive more team collaboration.
If it’s a maintenance type team we’re you’re working on possibly unrelated enhancements, look at a more frequent release cadence so that getting into the release becomes a more real goal.
Look at reducing your Work in Progress. If the team is working on fewer things at once it’s easier to focus on getting things finished. You’ll find this is likely to impact your release cadence by bringing about smaller, more frequent releases.
And smaller, more frequent releases is of course the key to becoming more agile as an organisation.
So next time you find a stand-up dragging on, don’t look at the person doing the talking as the problem. Look at the wider project, prioritisation, and organisation and try to address the problems at a larger scale.
comments powered by Disqus