How can a Scrum daily not be a status pull?

Question

There's a widespread saying

The Scrum daily is not a status pull; if it is - you are not doing Scrum.

By "status pull" is meant everyone from the development team reporting they have done some work in the last 24 hours, reporting to a manager. And the notion of a manager is another one falling outside the Scrum framework.

But the canonical 3 topics advised to be talked about are "done; current; blockers". How are these topics different from "I've done work; I am working right now; I am not waiting on anyone"? Where is the collaboration part?

Answer 1

Collaboration at the Daily Scrum

Where is the collaboration part?

The collaboration is based on the assumption that the Developers are not working in silos, and that they have interdependencies. The purpose of the Daily Scrum is to plan the upcoming daily work cycle. The 2020 Scrum Guide says:

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

In other words, the reliance on the "three questions" is no longer prescribed or recommended, but you can still use them in the unlikely event that the Developers actually find them useful. However, they were dropped primarily because they shifted the focus away from collaboration and towards status reporting, especially about individual progress or specific Sprint Backlog items. That's why it's now considered an anti-pattern: the focus of the meeting should be on collaborative progress towards the Sprint Goal.

Instead, the Developers should be discussing the current day's work (or possibly the next day's, if the Scrum is held at the end of the day). Assuming the Daily Scrum is held closer to the start of the day, there are some core things the Developers need to collaborate on, such as:

• What do they need from each other today?
• Are there things they need help from the rest of the team with today?
• Are they waiting on something from someone else today?
• Does the team need to set up a meeting to discuss something today?
• Et cetera, so forth, and so on.

The point here is that it's just-in-time coordination and planning between Developers, not a status report. The content of the coordination and planning is really up to the Developers, so long as it meets the objectives of building the Increment and advancing towards the Sprint Goal.

Planning Additional Meetings

Note that the Scrum Guide also says:

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

So, the Daily Scrum is ultimately about just-in-time planning and coordination between Developers. This goes beyond just the current day's work, although that's the primary focus; it's also about coordinating whatever else is needed to make progress towards the Sprint Goal, including setting up additional meetings or discussions. The Daily Scrum itself is time-limited and scoped to things that need to be planned or coordinated short-term (including additional meetings) rather than trying to boil the ocean within a fifteen-minute time box.

Answer 2

The 3 canonical topics are no longer part of the Scrum Guide itself, they were removed in the November 2020 update, because they did indeed allow teams to treat the Daily like a status call. Especially with a manager present (who, by the rules, should not be there or should be an observer only, so if a manager is getting involved, someone should explain the rules to them again)

While you can still use these 3 topics as originally intended, the Daily really should revolve entirely around the blockers. The team probably already knows what you did, and what you'll be doing today, because that's visible on the backlog. What's important to discuss is what's not going as planned.

Things you could bring up include

• new functional requirements or discoveries(hey, we mentioned not needing to thread the thing, but there's this case that does require it)
• intersections with another's work (since you're working on the Gizmo, we need to coordinate a bit because I'm also going to make a modification to it)
• things stopping you from being effective (so I'm fixing the Foobar, but I'm not sure how it interacts with the Baz, can anyone give me some pointers?)
• things that are taking longer than planned (we planned for this to take just one day, but it turns out the refactor hits more things that we thought, I'm going to need another day)
• things that are going better than planned (we planned for this to take 3 more days, but I just found a library method that does all of the work already, so I'll be done by lunch and continue work on the Whirlygig next)

Essentially, anything that's either going to change the plan, or that needs to be done in order to make sure the plan can be kept.

The original 3 questions ended up displacing the original, real important Daily Scrum question: "Are we still on track to complete the goal?"

Questions like above are related to that one, and help collaboration through identifying things that are a risk to the goal as well as spare time and resources that can contribute to the goal (or make it better).

None of them are directly to the status of any specific task.

Also, sometimes there is nothing deviating from the plan, everything's going according to plan and schedule. That's fine (great even), and it means the Daily Scrum probably shouldn't take more than 30 seconds. That's not an issue at all, and what you'd expect. Only if you realize later in the day that important things were not said does anything need to change.

Answer 3

Who, at the Daily Scrum, without changing the attendees, would be receiving the status updates, if it were to be a status meeting?

The only required attendees of the Daily Scrum are the Developers on the Scrum Team. Personally, I do find it helpful if the Scrum Master and Product Owner are also there, but that may not be possible in all situations, such as scaled situations where the Scrum Master and Product Owner are shared across multiple teams.

Since the only required attendees are the Developers and the Scrum Team is self-organizing, self-managing, and collaborative, the Developers should always be aware of the status of the work that they need to do. In some cases, though, it can be useful to synchronize on the status of work, since things may have changed more recently.

The ultimate purpose is to replan, though. The Scrum Team - primarily the Developers, since they are the ones who do the work needed to create usable Increments - is working toward a Sprint Goal. The root issue to address at the Daily Scrum is what the Developers can do between now and the next Daily Scrum to get closer to the Sprint Goal. If the Developers find that the Sprint Goal is at risk, they should be working with the Scrum Master and/or Product Owner to resolve impediments and make sure that what they can deliver is the most valuable thing.

Answer 4

Scrum's view on the Daily and on Management

The 2020 version of the Scrum Guide says this about the Daily Scrum artifact:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

[...]

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

[...]

Nowhere does it say anything about how to achieve those goals, whether it's push or pull or whatever other dialog structure, nor does it forbid any particular technique.

Nor does the Guide say that the main purposes of the Daily is collaboration! Collaboration is of course a tool to solve problems and to work on things where collaboration makes sense, and also inevitable given that all members of the Daily are on the same power level, and an inherent part of everybody informing everybody else. But as written in the Guide, the purpose of the Daily clearly is inspecting progress (and fixing problems that come to light during this inspection).

It says the following regarding management:

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

This means that aside from the devs, only the PO or SM are there, and only if they have an active role in the sprint backlog, so they are there in the role of a developer, not SM or PO. So this clears up one part of your question: the role of management is clearly not here. There can be no "status pull" if there's no management to pull, unless you are of the utmost pessimistic opinion that the team informing itself about its own status is already a negative thing.

Fixed dialog structure

The three topics "what have I done, what will I do, and what are my impediments" do not need to be so utterly destructive as written in many of the other answers.

They are a guideline, a framework, especially if working in a team where the dailies are not yet the grandest event ever. There are still worse kinds of dailies than this (for example, by the PO taking the time to babble on and on about whatever they need right now...).

Also, they solve the "blank paper" issue. Not every developer is a great rhetorician, and in my experience it is noticeably freeing in such meetings to give a common structure, so everybody can remember. This is similar as in other dialog formats (for example a "round table" where each person is explicitly called up to say his opinion on a topic by a neutral moderator). Sure, many people scoff at structuring dialog, and every kind of structure is viewed as oppressive, but there is a reason they exist, and when one gets a bit over the weird situation, it can be very productive.

In fresh teams, where everybody is already used to Scrum in general, having such a common ritualistic structure makes the process of getting to run well together very smooth. Even the most fresh dev, who maybe does not even know that he has a problem, yet, can say what they are doing and what they are going to do; and if there is the common problem that they simply do not have enough information to pick a new story (or how to do the current one in a good way) the team can immediately chime in and offer help, pairing sessions etc.

Also, nobody said that this must take long, be boring, or that there should be a lot of focus on the "what have I done" or "what will I do". Of course most time should be spent with the impediments, and often collaboration is the cure. These three formulaic questions are just the triggers to get the discussion started.

Finally, not in every team every person is checking the sprint backlog or board religiously for individual changes. Sometimes it's just nice for the team to update itself on who does what, especially in a remote setting. Some answer said "it's useless because everybody knows what everybody is doing anyway", but my response to that would be - if they knew already, they spent time on finding that out. They can save that time because they will be told in the standup. Zero net change.

The time wasted can be absolutely minimal if nothing of import happens. In my dailies, on good days (i.e. no impediments) it's over in a few seconds per dev. "What have I done" and "what will I do" can literally be a half-sentence each. We even allow for "I have just finished on XYZ and will pick one of the open stories next"; this (the second part) is valuable because at this point a team member can chime in, ask for help, seeing as the dev is free currently, or point out ideas about which next story would be most important etc.. But I would be worried if someone said "I have worked on my last story and will work on my next story" - that is a clear sign that something is going wrong - that dev is simply skipping his part; and if they can't even tell us what they have been doing up to right now, there is a high likelihood that they also would not tell us what their current impediments are.

Answer 5

How are these topics different than "I've done work; I am working right now; I am not waiting for anyone"? Where is the collaboration part?

You are absolutely right. I have seen enough daily standup where every developer, one after another, answers those three questions. And that, indeed, has nothing to do with collaboration. That is just cargo cult daily standup. Someone said that's how it's done and people do it. It's obviously stupid. If everybody does it one after another, there is no collaboration, or collaboration comes in as something that destroys a previously communicated plan.

Listening to X developers answering those three questions, one developer after another is the most boring status update I know. Because it is just that: a status update. Ironically even without the boss present, so it's not only a useless status update, it's not even useful for the one person that could profit from it.

The point of the standup is collaboration. If Alice needs help, that is the time where she can ask and Bob can step up and help today. But if Bob already said what he did yesterday, what his plan is for today and that he has no blockers, that's kinda stupid. It#s not agile at all, it's mini-waterfall. Bob made a plan before he even knew Alice needed help. Which is the whole point of this meeting, to find out who can do what to reach the sprint goal.

So are the three questions bad? No. They are great. But they weren't meant as a checklist for mindless drones.

So what you should do is the following: you take the three questions and actually use them in an order that is meaningful:

First round: everybody reports on changes in their works status and what new work that means for today (aka "what did I do" and "am I blocked"). Alice might say "I have a problem furbicating the widget, I could use help". Noted. Open task. Bob might say "I finished coding the story, my code now needs a code review". Noted. Open task. Charlie might say "I finished a code review for Dave, the story is deployed and can be tested by someone who didn't code it now.". Noted. Open task. Dave might say "I tested that story, I found something that I think is a bug, maybe we can talk with the PO and Alice who originally coded it". Noted. Open task.

So now, with all the open tasks for today on the table, now we can meaningfully go into round two and answer the second question for everybody: what will they do today? Someone will help Alice. Someone will review Bobs code. Someone will test. Someone will figure out whether it's really a bug.

And then we had communication, collaboration and consensus what the team will do today to reach the sprint goal.

So yes, the three questions are good, but please don't treat them as a mandatory checklist for everybody to just drone on about. They do not make sense that way, they hinder collaboration. Use them in the right order and you will have great collaboration.

Answer 6

I think the point about the daily scrum not being a status meeting is that the team shouldn't feel like they are reporting back to the PO, SM, management or other stakeholders at the meeting. It is up to the team to decide how to run their daily scrum. This is the team's time to make sure everyone is properly engaged and the team is productive.

The three-questions format is not the only way to do it and in many cases is not the best way. Lots of teams drive the scrum from the board, where they can discuss stories being worked on and pending. I like to encourage teams not to talk about yesterday but to focus instead on what remains to be done.

Answer 7

Nothing wrong with those 3. The collaboration part is in other things though:

• I want to talk with you this morning about the alignment

• What/where is that resource that I could use for ...

• Is there anyone who can help/explain/give me ...

• I will leave early today, at ....

etc. etc.

Answer 8

According to the Scrum Guide, the purpose of the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. In a status meeting, individuals give updates on the tasks or items they have each worked on, and there is likely not focus on achieving a valuable business outcome. an effective Daily Scrum is essential to achieving the benefits of Scrum. The Daily Scrum is a quick collaborative planning session. It is by the Developers, for the Developers