A Different Kind of Daily Scrum

Scrum teams often find that daily stand-up meetings take longer than expected. We’ve all heard the advice that the meeting is called a “stand-up” because we’re meant to stand on our feet for it, which gives people an incentive to keep their updates short. And yet I’ve been on several teams where the meeting filled a 45 minute time slot every morning, whether people were standing or not.

It is my experience that stand-up meetings (the Daily Scrum) typically run long because they adhere to the format where each team member answers The Three Questions:

• What did you work on yesterday?
• What are you planning to work on today?
• Is anything blocking you?

I argue that this format is broken for two reasons: it encourages people to talk for much longer than is productive, and it even saps team members of their motivation to work. Instead, consider structuring the Daily Scrum around the tickets that are in progress, rather than what each team member is working on.

Noisy Updates

Talking about work fills software developers with pride. Have you ever been cornered by a programmer at a party who was keen to talk shop? We love to talk about our work, and once the train of thought leaves the station it can be difficult to stop. Asking developers to talk about their recent work encourages some of us to ramble.

People are also competitive to varying degrees, and it’s not uncommon for team members to want to have the most impressive update at the Daily Scrum. Some team members may strive for a short, punchy update about solving a difficult problem, but an “impressive” update may also take the form of a long, tedious account of approaches tried and tasks completed. Nobody wants to sound like they’re idle, even if the honest update is that there is not much new to report.

Team members may also feel insecure or even fear for their job security at the Daily Scrum. Being uncertain about what work to do or not having anything important to say may be honest, but it can also be politically dangerous. A bad manager may take it as a sign of laziness, and a toxic team member may even hold it against somebody who is insufficiently enthusiastic.

All of this activity during the Daily Scrum detracts from the issues that matter: can the team complete all of the work committed to for the sprint, and what risks or problems are in the way? Of the Three Questions, the one that is actually important is whether any tickets are blocked.

Motivation and Drive

The Three Questions apply pressure on team members to stay productive. This is a bit of classic “the carrot and the stick” style motivation, and I argue that it harms more than it helps. Professional programmers are typically hungry for excellence and do not need a daily, public reminder to plan their work and stay on top of tasks.

Daniel Pink’s book Drive: The Surprising Truth About What Motivates Us explores how broken workplace incentives have become. Software development is both creative work and collaborative work, so keeping people motivated requires respecting their autonomy and building a high trust environment. Asking people to make their work sound impressive in a daily sound bite is not conducive to building trust. If that description fits your team’s Daily Scrum, strongly consider making changes.

Google’s Project Aristotle / re:Work reached a similar conclusion: that the single factor which predicts software development team effectiveness is Psychological Safety. The ideal Daily Scrum is a safe environment for team members to raise concerns and draw attention to problems without fear of being made to feel foolish. Asking for individual updates may put people on the defensive instead.

Maximizing Individual Contributor Utilization

Scrum is often used as a process to divide work among team members and keep each person busy. Teams track the number of story points completed per sprint with the goal of continually improving, but when story points are a proxy for effort, that just means pressuring people to work harder and harder each sprint.

The Theory of Constraints described by Eliyahu Goldratt and popularized in his book The Goal (which is the template for Gene Kim’s popular DevOps book, The Phoenix Project) claims that maximizing the output of individual work stations does not maximize the output of an entire system. There are bottlenecks that limit the productive output of the system, and only by widening the bottleneck can total throughput be improved. It is not a given that keeping each individual team member busy will optimize throughput; instead, the team will get stuck in a sub-optimal local maximum.

This idea was expanded on in the Toyota Production System and adapted to software development in the book Lean Software Development by Mary & Tom Poppendieck. Doing the right work matters much more than the total amount of work done. When you buy software, do you care how hard the developers worked on it, or are you more concerned with the features it provides and how much it costs? To maximize efficiency, software development teams must shorten the cycle of design, development, and delivery as much as possible to form a feedback loop that keeps efforts focused on what matters most to customers.

The goal of Scrum, then, is not to keep each individual team member busy, but to deliver incremental improvements to the product as quickly as possible. It is important to keep team members included and provide opportunities to meaningfully contribute to the team effort every day. However, keeping team members focused on closing tickets faster than they pile up distracts from the more important work of ensuring that the right tickets are being created.

Stop Starting, Start Finishing

Instead of going through each team member and asking the Three Questions, consider going through the tickets in the current sprint and asking what the status is. Start from the tickets closest to completion and work backward to the tickets furthest from completion. Focus the discussion on who is working on each ticket, whether there are any blockers, and what the risks are.

This format works because it emphasizes completing work in progress and being able to create follow-up tickets sooner. Once a change is visible in the QA environment, a product owner can evaluate it and plan new tickets. The follow-up work may even be higher priority than what is already planned.

The magic of this process is a lot like the value proposition of the Tableau product itself: Tableau allows users to answer the next question quickly, and a well-run Agile process lets the team get to the next top priority ticket quickly. Just as a Tableau user doesn’t know what their next question will be until they have an answer to their current question, a Scrum team does not know what the next most valuable thing to work on will be until they deliver the work that is currently in progress.

Caveats and References

Only a few of the Scrum teams that I’ve been part of have structured their Daily Scrum process in the way that I describe. I have found that these teams tend to have shorter Daily Scrum meetings, that team members are more likely to unblock each other promptly, and that their sprints are more likely to finish with every ticket completed. Your mileage may vary.

Agile teams are meant to experiment and continuously improve their process. Rather than taking the ideas above as a prescription for fixing Scrum teams, consider them suggestions to be discussed, iterated on, and applied or discarded as needed. No two teams are alike.

In the process of making up your mind, I do recommend the books that I have mentioned above along with a couple of others: The Psychology of Computer Programming by Gerald Weinberg, and Kanban in Action by Marcus Hammarberg and Joakim Sundén. I found them to be enjoyable reads and great sources of inspiration. All of these books are listed below in roughly priority order.

• Lean Software Development by Mary & Tom Poppendieck, 2003
• The Psychology of Computer Programming by Gerald Weinberg, 1971
• Drive by Daniel Pink, 2009
• Kanban in Action by Marcus Hammarberg and Joakim Sundén, 2014
• The Phoenix Project by Gene Kim, 2013
• The Goal by Eliyahu Goldratt, 1984

As a tiny post-script, I recognize that The Psychology of Computer Programming is now a 50 year-old book and mentions long forgotten technologies like JOVIAL, the IBM 704, and OS/360 Job Control Language, but it has amazed me for its depth of insight and enduring relevance to modern software development. One could easily be fooled into thinking that Mr. Weinberg had written this book about the current decade, and he tells numerous stories that I recognize myself in even though my career didn’t start until after the year 2000.