Your Daily Scrum is Killing Your Team

Your Daily Scrum is almost certainly killing your team, and probably not for the reasons you think.

I can guess some of the problems that you’ve encountered with your Daily Scrum.

• Some people show up late, if at all.
• Some people don’t say much.
• Other people don’t know when to shut up.
• Everyone talks to the Scrum Master (especially if that’s also the manager), instead of to each other.
• Some people prattle on endlessly about how pointless the Daily Scrum is.
• Some people whisper about how the Daily Scrum is just another form of micromanagement.
• If the Scrum Master (or manager or team lead or some other Really Important Person) can’t attend, then they cancel the meeting.

If you find yourself in this situation, then your Daily Scrum probably is pointless, and you should consider shutting it down, because it’s probably doing more harm than good.

Since the books tell you to have a Daily Scrum, whether you need it or not, when you encounter these problems, you’ll probably have the impulse to search for ways to change your Daily Scrum to make it more effective. In the process, you’ll probably encounter some fairly dubious advice… something like this. What idiot wrote that?!

This idiot. (I’m sorry.)

In 2006 I wrote an article entitled “Stand-up/Daily Scrum: focus on achievement and commitment” which revolved around the notion that we were asking the wrong questions in our Daily Scrum. We were asking ineffective, wimpy questions, and as a result, we weren’t getting to the good stuff that the Daily Scrum is meant to uncover. It seemed plausible when I wrote it. I did the best I could at the time. I was thinking as a project micromanager instead of as a team member. I’m sorry.

How Not To Rescue Your Daily Scrum

I wrote that we shouldn’t merely ask What did you do yesterday?, but rather the much stronger question What did you achieve yesterday? I reasoned that just the word achieve should focus the mind on what each of us accomplished, since the rest of the group probably doesn’t care that much for a play-by-play account of how we did it. I felt very proud of this insight: I love linguistic tricks that encourage better behavior.

Similarly, I argued that we shouldn’t ask the wishy-washy What do you plan to do today?, but rather the much more professional-sounding What you do commit to achieving today? Here we have the words achieve and commit right next to each other. I decided that this focus on commitment and achievement would encourage everyone to think hard about what task they’re working on and how to make demonstrable, tangible progress towards completion… by committing to achieving something. If I can’t commit to achieving something today, then maybe I’ve bitten off more than I can chew, and maybe I need to break the work down or ask for help…. It all sounded so good!

Unfortunately, I continue to see and hear stories about groups that, in spite of trying to implement this obvious improvement, never see the benefits that they so obviously convey. On the contrary, this drives people in a handful of dysfunctional directions:

• Some people, desperate to show commitment to achievement, begin overselling what they do each day. They sound like used-car salespeople: annoying, loud, larger than life. If we used to have project management theater before, this people raise it to the level of Broadway.
• Some people, desperate to deflect from their own lack of achievement, waste their precious energy poking holes in other people’s stories. They sound like your annoying little brother or sister, trying to catch you in a lie, prepared to tell Mom or Dad, by which I mean the Scrum Master or project manager.
• Some people, desperate to get back to work and finish something before anyone notices, keep even more quiet than they did before.

I’m sure there’s more, but this will do for now. In trying to focus the group on sensible-sounding things like achievement and commitment, we’ve made our Daily Scrum problems worse. Well done!

That’s why you should never listen to consultants like me. (Well… to consultants like me from 10 years ago. I make much more sense now.)

A Missing Ingredient That You Didn’t See Coming

Of course, as a consultant of the kind you should never listen to, I have the answer, so you should listen to me now. Forget what I wrote in 2006; I was drunk or something. (Maybe I was desperate to market my own skills, so I hastily wrote a superficially insightful-sounding article without really thinking through the ramifications of my own advice, hoping that you wouldn’t notice. See how easy it is to go down this road?)

Over the last few years I’ve been telling audiences about the dangers of an ineffective Daily Scrum. I’ve been telling them that the missing ingredient in their Daily Scrum was discussing risks. More than that, I believe that unless we use it as an opportunity to surface and address risks, the Daily Scrum will remain an exercise in project management theater. If we go back to the so-called “three questions”, you can see the intent behind them to facilitate discussions about risk.

1. What did you do yesterday?
2. What do you plan to do today?
3. What’s in your way?

If we can’t clearly articulate what we did, then that points to having unclear goals, which constitutes a serious risk in most projects. Even if we can clearly articulate what we did, if the other people in the group don’t find it compelling, then that points to having clear-but-misaligned goals, another serious risk in most projects. If we say straight out that we got nothing useful done yesterday, then that points to obstacles in our path—we’re no longer talking about risks, but actual problems.¹

If we can’t clearly articulate a plan for what we’ll do today, then perhaps we have unclear goals or obstacles in our path. If other people in the group don’t find our plan compelling, then perhaps we have misaligned goals or work is falling through the cracks. It would help occasionally for someone to say “I have no idea what to do today”, but few people seem to feel comfortable saying something like that. (There’s a clue in this sentence. Read on.)

What’s in your way? seems like the question that ought to bring risks to the surface, but programmers notoriously have problems asking for help. By forcing them to answer this question every single day in front of others, you’re mostly forcing people to admit that they’re stupid every day in front of their peers, the people whose respect they likely crave intensely. (Another clue. We’re getting warmer.)

Any good textbook on project management will emphasize the importance of managing risks. The Daily Scrum’s three questions appear to have been designed to help us manage risks on a daily basis. My “refinement” of these questions—sprinkling in magic words like achieve and commit—appears designed to amplify the risk management power of the Daily Scrum questions. So why the hell isn’t all this working?

I Think By Now You Can See This Coming…

If you relate to a lot of this, then your Daily Scrum is going to continue to be a pointless exercise in project management theater until you deal with a fundamental, underlying problem.

Trust.

Welcome to what I call the Fundamental Irony of Agile Software Development.

Among all the agile practices that one could adopt, advisers very commonly recommend “The Daily Scrum” and “Retrospectives” as places to start. They reason that these tools lead directly to more improvement sooner than any of the other practices. They also reason that since these practices do not require any technical infrastructure, everyone can start doing them right away. Unfortunately, both The Daily Scrum and Retrospectives shine a massive spotlight on a group’s trust issues. People in high-trust environments find them very effective at directing their focus towards managing risks; however, people in low-trust environments don’t have the tools nor feel the safety to deal with their lack of trust, and shining a spotlight on this problem often makes the situation worse.

Your Daily Scrum fails precisely because it worsens a problem that it’s intended to solve. Your Daily Scrum scares away the very people it most needs to help. Even if you can rebuild their trust, many of them will view the Daily Scrum with suspicion, even contempt, for the rest of their careers. Woo!

So What Now?

If you suspect that the Daily Scrum is killing your team because of underlying trust issues, then I offer you so time-honored, folksy advice:

When you finding yourself sinking down deeper into a hole, stop digging.

Cancel today’s Daily Scrum. Don’t just cancel it, but tell people why you’re canceling it. Everyone, I think our Daily Scrum is doing more harm than good. I propose that we stop holding Daily Scrums until we’ve had a chance to talk about what went wrong. Of course, now you’ll have the impulse to call a meeting to discuss your problems with the Daily Scrum. Not yet.

Give everyone a week or two to feel like they can get some “real work” done. Remember that many of them view meetings as mostly pointless obstacles to getting things done, so get out of their way. I’m guessing that many of them want a greater feeling of accomplishment—a sense of completion. Let them have some time to pursue that on their own. What makes this tactic so effective? It gives you a chance to gain some of their trust—especially the ones who have thought of the Daily Scrum as an exercise in micromanagement.

So stop micromanaging. Stop shining a spotlight on an uncomfortable situation. Let everyone “get back to work” for a while. While everyone is “cooling off”, look for signs of the kinds of risks that the Daily Scrum is meant to bring to the surface.

• Are people getting stuck and not asking for help?
• Do people know which tasks to work on?
• Do people routine choose urgent or significant tasks to work on?
• Are tasks being completed and not just started?
• Are people duplicating one another’s work?

There are more, but this will do for now. Look for evidence of these problems.

While you’re noticing these problems, also look for signs that your group is addressing these problems on their own.

• Are people talking to each other in informal groups more often?
• Are people asking each other for advice on what to work on next?
• Are some people offering (often unsolicited) advice on what to work on next?

If your group is handing these problems effectively, then forget about the Daily Scrum for now and look for some other agile-related tools to help solve an even more pressing problem. (I’m pretty sure you have one.) If, however, your group is not handling these problems effectively, and especially if people are getting into arguments about how to handle these problems, now you have an opportunity to invite the group to talk about the problem.

Don’t Just Reinstate the Daily Scrum

Now that the team has had a break from daily meetings, perhaps they feel ready to discuss issues related to getting daily work done. (I assume that they haven’t, in the interim, spontaneously become a powerhouse of effectiveness.) Invite everyone to meeting and make it very clearly optional—we don’t want to make it seem like the beginning of reintroducing something they just got rid of. Ask them what problems they notice. Among the issues they mention, you might find these:

• Too many urgent tasks are sneaking up on us.
• Too many significant tasks are falling through the cracks.
• Too many people find themselves having to redo work that others thought was completed.
• We’re starting a lot of tasks, but not completing them.
• We’re fighting about what do next and not coming to a useful resolution.
• We’re letting ourselves remain stuck and not asking for help.

These are exactly the kinds of problems that the Daily Scrum is meant to solve, so now is a perfect time to recommend the Daily Scrum as a way to solve these problems, right? (Ignore the other issues they raised, of course, because you know that they need to bring the Daily Scrum back, and you’ve found your opening….)

Wrong. Do not jump at the first opportunity to reinstitute the Daily Scrum. Just because your group has had a week or two to get the bad taste out of their mouths doesn’t mean that they’ve forgot how awful it was.

Which Problems Will They Solve?

We can get much better results by figuring out what the group thinks and how it feels about the problems they’ve just raised. If you try to solve those problems for the group, then group will never feel invested in the solution, and nothing will stick. I get amazing results when I take the time to find out both what they think and how they feel about the their problems. I love these two questions:

1. How urgently do we need to address this problem? (Scale of 1 to 5. 5 means “If we don’t deal with this now, we’ll all die.” and 1 means “I really don’t think this ‘problem’ is a problem.”.)
2. How much energy do you have to address this problem? (Scale of 1 to 5. 5 means “I’m going to fix this problem even if I have to drag all you people with me.” and 1 means “This company doesn’t have enough money to motivate me to do anything about it.”.)

The answers to these questions tells us a lot about what we’re likely to do next. (Not what we should do next, because if we don’t have energy to do it, then we’re not going to do it. Simple as that.)

If urgency is generally high and energy is generally high, then the group will probably figure out how to solve the problem, and you don’t need to direct what they do. Offer them support, but not advice. Congratulations! You’ve helped cultivate some of that self-organisation that the Scrum books keep yammering on about. It’s a Good Thing.

If urgency is generally low and energy is generally low, then there’s probably nothing you can do to cajole the group into addressing the problem. Congratulations! You’ve avoided a protracted, pointless battle that would probably have taken on a decidedly dysfunctional parent-child dynamic. You dodged a bullet. You’ll have to manage this risk on your own, so do the usual things: evaluate the potential cost of the risk, and if it’s significant, look for transition indicators and come up with some mitigation tactics.²

If urgency is generally low, but energy is generally high, then maybe the group is starving for a sense of completion. Maybe they’re drowning in problems and are looking for a “win”—any win. Resist the urge to step in and tell them that they have to solve a more urgent problem. Let them go with their energy. Even if they end up solving a less-urgent problem, they will have the chance to let their energy drive them towards completing something. This can help them gain confidence, work more as a team, and thereby prepare themselves to take on even more significant, urgent problems. I often go after a “quick win” in order to “warm up” or gain the confidence I need to take on a bigger, deeper, more significant problem. You’ll have to manage the urgent risks on your own for now, while you wait for the group to show signs of being ready to take those on.

If urgency is generally high, but energy is generally low, then it sounds like the group doesn’t know how to solve the problem. Now is your chance to step in with a suggestion. If you believe that the Daily Scrum will help solve that problem, then you need to pitch your idea to the team, but let them decide whether they want to try to solve their problem your way. If they decline, then you need to respect that; but at the same time, you can feel perfectly justified in challenging them to come up with an alternative to your suggestion. If they can’t think of one, then I think it’s perfectly reasonable to say something like this:

I feel confident that the Daily Scrum will solve this problem. If nobody has a better suggestion by Friday, then we’re going to start Daily Scrums on Monday. We will focus on using the Daily Scrum to solve [our urgent problem], which we’ve agreed is urgent, but that we don’t have a better way to solve yet. If, after two weeks, we feel that the Daily Scrum is not helping solve [our urgent problem], then the experiment will probably give us another idea for a solution, and we’ll try that. If, on the other hand, it seems to be helping, then I say we continue. Who’s with me?

This might actually work. Your Daily Scrum could actually stop killing your team, but only if they know what problem it’s trying to solve, and only if they don’t have a better solution in mind. Then, it could actually help. Who knows? They might even grow to like it.

Related

If someone would cancel the calendar invite for your daily standup, would it still happen? Dare to find out?

— David Tanzer (@dtanzer) April 26, 2017

David Tanzer, “Stop the Daily Standup Meeting”. In some companies, one person’s absence means canceling the Daily Scrum/Standup Meeting. In that case, why do you need the meeting at all? This article also reminds you that you have the option to cancel these meetings altogether, as long as you listen to the signals telling you that you need to reinstate it. (Don’t forget that part.)

References

Tom DeMarco and Tim Lister, Waltzing with Bears. For me, the textbook on managing risk in software development projects. I make a point of re-reading this book every few years.

Patrick Lencioni, Overcoming The Five Dysfunctions of a Team: a Field Guide for Leaders, Managers and Facilitators. I recommend the field guide in particular because it offers some techniques for building trust within the team, and when trust is particularly low, people will be suspicious of artless, overt attempts at building trust. You might need help.

Patrick Lencioni, Death by Meeting. What is the purpose of meetings? Which meetings do you need? Which meetings do you not need? If you’d like an overview of the topic, then I recommend this one.

Diana Larsen taught me the “urgency/energy” tactic and I have found it especially useful in developing a plan for dealing with problems, even in “meetings” in my own mind.