Better Standups by Ron Lichty

What makes a standup effective?

We know, from the Study of Product Team Performance, that the highest performing teams hold effective standups daily. Not every other day, not every third day, not occasionally. Daily.

But what constitutes an effective standup?

I’ve stepped into scores of software development organizations in the last seven years, between taking interim VP Engineering roles, advising business and product leaders on team effectiveness, and training and coaching teams and executives in agile. I’ve definitely seen highly ineffective standups: ones with no sense of urgency, no 15-minutes-or-less timebox (or no enforced timebox), no focus. Those are the egregious problems.

But there are several fundamental steps to high effectiveness I see all too few teams taking.

These days, while most teams have a notion of “the three questions” - answers to which each team member shares with the team each day - few teams address those questions effectively. And almost none have a sense of what underlies those questions - what the standup is actually for: How are we doing? Are we on track to successfully deliver the plan we set out at the beginning of our sprint? If not, how can we adjust?

Let’s start with the three questions: When the three questions are answered perfunctorily - as I’m sorry to say I mostly see - the standup is not a re-planning meeting. It’s just a status meeting. I’m even more sorry to occasionally find it relegated from face-to-face to Slack. I get it, when little more is happening than sharing status - but these teams are losing so much opportunity for it to be so much more.

Of the three questions, the one that is almost always dealt with effectively is the one about impediments: every day, every standup, sharing anything that’s standing in my way - with follow-ups by any and all who can help. Calling out impediments daily and responding to them actively will speed our team and our delivery.

But the other two of the three questions are too often answered with “What did I do yesterday?” and “What will I do today?” That’s not what I want to hear. What I want to hear is “What I accomplished yesterday” and “What I’m going to accomplish today.” “Did” and “doing” lend themselves to answers like “I worked on the subsystem yesterday” and “I’m going to keep working on the subsystem today” - which are wholly uninformative. They give our team much less insight than if we answer “What part of the subsystem did I accomplish yesterday?” and “What part will I accomplish by tomorrow?” 

The power of basing the two questions on “accomplish” is twofold:

1) It signals my team when I’m in trouble. If yesterday I told the team I intended to accomplish yy part of xxx, and I didn’t, that’s a heads-up that I’m not on track for my part of the sprint plan (and if anyone else on the team has time, maybe they might want to offer to help me).

2) By telling my team what I intend to accomplish, I’m exercising one of the core principles of time management: If I tell myself what I’ll accomplish a short time from now, I’m more likely to; if I tell teammates, I’m even more likely to.

The point of the standup - and the point of the two questions - is to see how we’re doing against our plan and to re-plan if necessary. Software can be wildly unpredictable - if we’ve hit a rough patch, we want our teammates to know that the work is more than we anticipated, that we’re likely now overcommitted, that maybe we could use help, or perhaps we need to re-think how we’ve divvied up the work, or to re-plan what we can reasonably finish by end-of-sprint.

Standups too easily devolve to be status meetings. Just this nuance begins to bring opportunity for teamwork back into the standup routine - opportunity for all of us to together consider how to keep our sprint plan on track.

But even with improved wording, just doing a go-round of the three questions can be all too status-ish and too me-ish, and not enough about us, about our plan, about how we’re doing as a team. To bring team and teamwork into focus, for the past few years I’ve been coaching a standup-closing practice I learned from Cathy Simpson, who learned it from Kalpesh Shah at the scrum gathering 2015: Cathy and I both got excited realizing that just by leveraging a simple fist-to-five, we could shift the conversation from “me” to “us” while getting a daily sense of the team’s confidence in its plan.

If you’ve never used fist-to-five, it’s a quick way to get the sense of a group of people in response to a question. On a given signal, each team member raises a hand and votes their answer with a number of fingers. In this case, the question is “How confident are we that we’ll make our sprint plan?” Five fingers signals total confidence we’ll make the plan. Four fingers signals high confidence. A fist is zero confidence - basically, I don’t think we have any chance of making our plan; one or two fingers not much better. 

If, in response to the question, there are any votes other than 4s and 5s, my practice is to ask the team to discuss what it would take to get all votes to 4s and 5s. Often it’s just one or two developers who are struggling - is there someone who can come to their aid, someone who is on or even ahead of schedule with the work they’ve taken on who can help. 

On the other hand, we may face the situation where there’s no recovery possible. How useful to know that at this point, as opposed to discovering end-of-sprint that we didn’t finish one or more stories. Knowing earlier in the sprint lets our product owner be intentional about which story or stories we should put back in the backlog. It won’t be a random story that’s not finished at the end of the sprint, but one that has the least value for the sprint, and for which our product owner now has time to reset expectations with stakeholders that it will not be completed in this sprint. 

Once we’ve adjusted our plan to get it back on track, a fist-to-five should give us 4s and 5s. And we’re back on our way.

The nuances I’ve called out are the kinds of things we might call “hacks,” but they really ought to be referred to as making our standups more effective - getting standups back to their intended purpose.

If you look up the definition of “scrum”, you’ll find, in its rugby definition, that it’s a way “to restart the game.” No surprise, then, that the daily standup is itself sometimes called a daily scrum. It lets us re-start our “game” every day. But the standup only works as a restarting and replanning meeting when we’re all engaged together working as a team, focused together on making our software development hum.