Why aren't you supposed to report status in standups?

Question

My team has a new scrum master. The old SM always said that standups were about coordination between the team members and not a report to him. Urging us to help each other if one of us ran into difficulties, to break work items up into smaller pieces, check in and merge frequently, to look out for functionality that could be turned into reusable components.

New SM wants to know how fast we will be done with our items and urges us to review work items quickly. The retrospective is cancelled so we can finish our work.

The old SM always said the standup shouldn't be what he called a status pull and that the team needed to take ownership the work and self organize. I feel that the changes the new SM has made have not been an improvement, but I am unsure how to argue against it.

Is it true that you aren't supposed to report status in standups in scrum? If so why?

Answer 1

It's not that you aren't supposed to report status in the Daily Scrum. Instead, the purpose of the Daily Scrum is to enable the Developers on a Scrum Team to understand the current state of progress toward the Sprint Goal and adjust their plan to maximize the chance of the team achieving the Sprint Goal before the end of the Sprint.

What the Daily Scrum looks like depends on the team. A team where the Developers tend to work individually and sometimes in pairs would likely have a different structure for a Daily Scrum than a team that regularly mobs. If people are working individually, there may be more emphasis on the current state of work and what people need from each other to get to Done. If the team tends to work as a single entity, there may be more emphasis on planning. Regardless, though, the objective is to assess progress and adapt the plan.

The emphasis on knowing how fast the work will be done seems suspect. When I'm asked to facilitate Daily Scrums, I tend to focus on the age of the item with respect to the team's history. Depending on the tool you are using, you may be able to get information about work item aging and cycle time. Focusing on reviewing items may be a reasonable thing to ask - if you use a Kanban board to visualize the workflow, there's a common practice of walking the board right-to-left and making sure the right-most items progress before taking on new work.

As an aside, canceling the retrospective raises more questions about the ability of the Scrum Master. Retrospectives are not only an important part of Scrum but are the only practice mentioned in the Manifesto for Agile Software Development. If work isn't getting done within the Sprint timebox, the retrospective is the perfect opportunity to understand why and make adjustments for the future. Together, with the changes to the Daily Scrum, I'd question if the Scrum Master truly understands the Scrum framework and the Agile methods.

Answer 2

TLDR: You don't have a Scrum Master

Repeat after me: The Daily Scrum is not an update-to-management meeting!

Your Scrum Master(SM) is acting not as a SM, but as a manager.

The problem is, the SM is not supposed to be a manager. Take a look at the described duties of the SM. Notice the complete lack of anything along the lines of 'track the progress of the project and react accordingly'.

---

To answer your actual question

Is it true that you aren't suppose to report status in standups in scrum? If so why?

It depends. Again from the Scrum Guide (emphasis mine):

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 Daily Scrum is a 15-minute event for the Developers of the Scrum Team.

So... is the Daily Scrum intended to reveal progress? Sure. But it is supposed to be a peer-driven meeting to get the Team on the same page. You are not supposed to be reporting to anyone (see link above)!

---

By far, the absolute most alarming point in your post is

The retrospective is cancelled so we can finish our work

Problems that jump out to me:

1. The Retrospective is, in my opinion, the single most important meeting in Scrum.
2. Part of the Scrum Master's job is to ensure all Scrum meetings are held properly.
3. The Scrum Master's job does not include determining how the Team gets work done. That responsibility is held by the Team.

You do not have a Scrum Master. You have a manager.

---

As for what to do...

Is s/he your actual manager (or has the support of such)? If no, the solution is simple - ignore him/her. You need a Scrum Master - so consider stepping up. You take on the role of Scrum Master. You conduct the Retrospective and Daily Scrum. Bring this up in the Retrospective first (ideally not while the not-SM is there, because unless the the not-SM is also a developer, s/he is not actually part of your Team) and discuss this. Then, when questioned, simply instruct the not-SM that "during our Retrospective, we determined that the current biggest blocker was the lack of a Scrum Master. So I stepped up, and we are now enacting Scrum as the organization requires."

If s/he is your actual manager, things get thornier. But it's your job to make him/her aware of the pitfalls of not having a Scrum Master and having a boss, claiming to be a Scrum Master, telling you to not do Scrum. The Scrum Guide will be your friend during this conversation - it is the only actual, de-facto authority on Scrum. The not-SM's actions are having an impact on the business, and as an employee, when you're unable to fix a problem yourself, it's your job to make your boss aware of it (even when your boss is causing the problem). After that, though, you need to either abide by your boss's instructions, go higher up the chain of command (be careful with this), or vote with your feet.

Answer 3

The SM's job is to make sure that the ceremonies happen, not to tell the developers how to conduct their meetings. Daily stand-ups are supposed to be run by and for the development team.

While there are no absolute rights or wrongs in stand-ups, I do think it's a waste to use a whole-team meeting to report status. Status can be read from a Kanban board or collaboration software at any time. Using the time to talk about what comes next surely makes more sense than talking about what is past because people can then react, offer assistance, advice or just be reassured by knowing something is being addressed.

Cancelling the retro surely is not likely to encourage collective ownership and self-organisation. Skipping the retro in order to complete planned items might make sense sometimes but you could take account of that at the next sprint planning meeting and try to make room for the retro in the following sprint.

Answer 4

Slightly different statement of the above - I agree with the other answers, but will share a different perspective.

If you are reporting status in a meeting of N people, then that status is of no value to N-2 people. most of the people in that meeting are being paid to stand around and act like mannequins. A close friend of mine uses his daily standup meeting to do his daily workout because he is required to be (virtually) present, but his participation in the meeting is less than 2 minutes. So while everyone else is doing status reports, he is doing pushups and situps and other exercises.

And at least in my experience, there is a strong incentive to obfuscate status. My current manager's status meeting is absolutely useless because everyone uses as many acronyms and allusions as possible. Psychologically/bureaucratically, if anyone other than the manager understands the status, then there is a risk that they will engage with it and drag you into a turf war/empire building contest. On the other hand, if your update is intelligible only to the manager, then you are clearly elite. The third dysfynction (anti-pattern) is that status meetings lead to people trying to solve problems - which is a horrible antipattern that always results in half informed people offering half informed advice, generally confusing issues and wasting more people's time. A 30s status update can be transformed into a 10 minute exploration of a non-solution by a group of people who aren't responsible stakeholders.

While managers are required to maintain situational awareness of all the efforts under their purview, the only excuse for a mass status update is to stroke the manager's ego. In every other sense, it is more effective to approach each task lead and discuss the status of the task/product/deliverable, and if there are interconnections to explore, schedule an ad hoc meeting with an agenda focused on the problem.

I don't like scrum; I've made that clear across PM.SE. But if your team has the commitment to actually do scrum - to identify actions, blockers and dependencies, then the scrum meeting serves as a locus for self-organization. But the mindset is different; status meetings are

"Behold oh powerful Lord the valuable services that I provide and recognize me among all these lesser vassals"

Scrum meetings are:

This is what I'm doing to advance our cause; I'm proceeding slowly because someone borrowed my lawnmower - if anyone could loan me one for 3 hours, I could get back on track. I'd also like anyone's advice on how to X, but contact me outside the meeting...

Note the focus on us, on our goal and on coordinating resources to find solutions. Nobody's ego gets stroked.

Which is why Scrum is doomed; scrum is self-organizing, and organizations are organized to promote egos first and produce products and services as a secondary effect.

Answer 5

Other answers cover why the Daily Standup shouldn't be a status report to the Scrum Master, but there's a detail missing: If you need a Daily Standup for the team to know the status, then your information radiators (specifically your board that shows in-progress issues) are either not always up to date, not trusted by all team members to always be up to date, or not visible enough.

You shouldn't need a teammate to tell you every day what they're working on, you should be able to see that clearly on the board. Then why does the Daily Standup exist? To have a talk around those issues, not to read the board out loud.

Answer 6

Career-oriented advice: It just doesn't matter. I would conform to the SM's request. I would de-escalate as much as possible. I would report it only as normal job duties require, and with a goal of just being truthful, nothing more. Concentrate on getting your part of the work done. If there is a 'roadblock' to your work outside your control, notify the appropriate people. De-escalation is the key from a career perspective. "Vote with your feet" is then always a backup plan, depending on how strongly you feel about it. The theory behind scrum groups is of interest, but from a practical POV, retaining your job is much more important. "Been there, done that"....

Answer 7

To me it sounds like a lazy Manager updating his team's status, rather than a scrum meeting. It also sounds like Team Meetings at some companies I have been at.

But you have to wonder what would happen if the term Scrum Master was retired, and replaced with something like team coordinator?

On the other hand, remember the Golden Rule. He who has the gold, makes the rules.

Agile is a framework and Scrum is a tool to increase productivity. If Scrum and Agile do not work at a company, then Management will bring in the next game for managing people.