Is Scrum a status report meeting or a developer meeting?

Question

I'm a developer and we started using Agile last year (October 2011). And, it has been rough to say the least. I was always taught Scrum was to discuss the following:

1. What you did yesterday
2. What you are going to do today
3. Any issues, challenges or roadblocks that might be in the way (at the moment)

My understanding is that this meeting is for the developers, but product owners should be there to answer any questions that may be directed toward them. Otherwise, this is a meeting to go over developer needs & issues in a manner that is relaxed and for the developers (no one else).

Now here's my issue...
In our version, each developer is required give what is tantamount to some kind of Regimented Status Report. We stand-up and report in the following format:

(a) The Story Number and Name
- Each Task Number in the story that we worked-on
- The Original Time Estimate for the currently discussed task
- The Actual Time Estimate for the currently discussed task
- An explanation of why we were over or under

...and so on.

My Question is:
Is this Scrum? Heck, is this Agile?

Answer 1

Dissecting a Status Pull

No, what is happening in your meetings is not a Scrum stand-up meeting, it's a status pull. In fact, it's probably worth dissecting this particular status pull to see why your "Scrum" process is failing.

The first two elements that your project manager (not Scrum Master, evidently) is asking are:

• The Original Time Estimate for the currently discussed task
• The Actual Time Estimate for the currently discussed task

The only practical utility for this information is to determine whether estimates were on-target or not, or whether there are hidden process impediments that were not planned for in the original estimate. However, gathering this information in this particular way is not very agile because:

1. This information should already be transparent through the use of a Kanban board or other framework process. Having to ask for it explicitly is a "project smell" that indicates a fundamentally broken project process or an undocumented objective.
2. Estimates are estimates, not commitments. As long as all stories that the team has voluntarily committed to perform during the Sprint are completed by the end of the Sprint, the individual story estimates (as opposed to the aggregate estimate) are not intrinsically useful except as part of a retrospective.
3. If your process is based on 100% utilization, rather than a throughput-based pull queue, then it's neither Scrum nor agile. All agile frameworks require slack in the process; asking for daily deltas at such a granular level certainly implies an intolerance for the slack required by agile frameworks.

Now, the last item is particularly telling. Your PM wants:

• An explanation of why we were over or under

Getting better at estimating is a useful goal for any agile framework. However, one goal of Scrum is to ensure that the team does not over-commit; if there is extra capacity within the Sprint once all stories are completed, then the team can and should pull additional stories into the Sprint from the Product Backlog.

The question, as described, sounds a lot like stories are being assigned to the team for each Sprint, which is an epic fail from a Scrum stand-point. Even if that's not actually the case, it's another "project smell" that indicates that individuals are being "held accountable" (presumably by the PM) for the accuracy of individual story estimates, rather than for the team's overall progress in meeting the Sprint Goal for that iteration.

Mis-estimating is an issue that should always be communicated clearly during Sprint Reviews, and used as a learning process during the Sprint Retrospective. However, the tone of the question above implies that accountability for estimates is more important than anything else, and diverts focus from feature delivery to C.Y.A. delivery.

Using the Stand-Up to Coordinate Status

The following is incorrect:

[The stand-up] is a meeting to go over developer needs & issues in a manner that is relaxed and for the developers (no one else).

The daily stand-up is a commitment and coordination meeting for the entire team. It is designed to ensure that the entire team is aware of impediments, what stories are done or not-done, and what tasks are ready to be pulled from one team member's to-do list into someone else's.

None of the above means that a Scrum Master or Product Owner doesn't gain value from the meeting. A well-run daily stand-up will give the Scrum Master a clear picture of any process issues and whether individual stories are done or not-done. The Product Owner gains a sense of whether there are risks to the current Sprint Goal, timely insight into backlog grooming tasks for the next iteration, and provides advance notice of when a Sprint might need to be terminated early.

It is important that the Scrum Master and the Product Owner be active participants in the stand-up, but if the team is reporting to either of them, then the team is neither self-organized nor empowered to efficiently deliver value.

Your Process Might Be Broken If...

Here is a short list of "project smells" that seem related to your issue. It's part of a longer list I came up with for reference when I'm doing Scrum training for teams or when I'm coaching other practitioners. If any of them seem applicable to your situation, then your team may want to take the issues on-board during a retrospective.

1. If the team has so many stories on the board at once that a verbal report needs to identify the story by number, then the process is broken.
2. If the team has so many stories that a glance at the board doesn't make it clear that things are moving from not-done to done in a timely manner, then the process is broken.
3. If the team is so large that a glance at the board doesn't indicate who is working on what--or worse yet, requires cross-referencing with a separate spreadsheet--then the process is broken.
4. If the PM's only communication about the project or with the team is at the daily stand-up, then the process is broken.
5. If the PM can't construct a burn-down chart from some combination of the story board, the daily stand-up, and ongoing communication with team members, then the process is broken.
6. If the daily stand-up is not serving the needs of the team, then the process is broken.
7. If estimates encourage excuses or justifications, rather than refinement over time, then the process is broken.
8. If the team is reporting to any one individual during the stand-up meeting, rather than cooperatively coordinating with one another, then the process is broken.
9. If your process is broken, but team members don't feel free to directly address the broken process during a retrospective, then your organizational culture is broken.
10. If your organizational culture is broken, and figuring out Who do we blame for breaking it? is more important than figuring out How do we collectively fix it? then it's time to dust off your resume.

Answer 2

The meeting you're describing (well, the meeting you should be having, see below) is a Scrum, sometimes called a stand-up.

Scrum - the methodology - is a set of practices, of which the Scrum meeting is core. You can think of Agile methodologies as different toolboxes, where the tools can be used together very effectively.

Agile is the term we give to the conglomerate of practices, the body of knowledge and the community built around similar methodologies and practices, including Scrum but also XP, DSDM and others.

So, the practice of holding Scrum meetings is part of Scrum, as well as part of just about every other Agile methodology (perhaps by another name), and Scrum is an Agile methodology, but Agile itself is bigger than individual methodologies or practices.

I should also address your other question: no, what you're doing is not the practice commonly called a Scrum. It's the practice commonly called micro-management.

Answer 3

The daily stand-up meeting (called daily scrum in Scrum) "is not a status update meeting in which a boss is collecting information about who is behind schedule".

In my opinion this is tempting to transform a stand-up into a status reporting meeting, where everybody in the team reports to the Scrum Master, PM or whatever. And this is a mistake. In a recent article (Daily Scrum: Not Just for ScrumMasters) Mike Cohn called it a "synchronization meeting", a moment when each team member gets to know what everyone else is doing and how the project is behaving.

This is also the moment where issues, impediments, are raised (but not a big problem-solving meeting).

So no, the meeting you describe does not look like a genuine daily scrum meeting. In short, if everybody leaves the meeting thinking that they just gave report to the PM, and not that they synced with the rest of the team, this is not a actual stand-up meeting.

That said, you should know that the problem is not that the meeting is held story-by-story instead of person-by-person, although this is the standard form. Kanban teams often use this kind of stand-up meeting, but the philosophy is not exactly the same as the focus is more on the flow of items. Anyway you might want to read this other article (Should the Daily Standup Be Person-by-Person or Story-by-Story?) by Mike Cohn.

Answer 4

No, it is not Scrum and neither Agile. I would say that all the information he needs must be available on the board. It would nice to find out what he does with the gathered information. The "An explanation of why we were over or under" is an interesting part, because what can your team or he do about it?

If you would like to improve the situation, find out:

• what does he do with the information?
• how can you make the work more transparent (with the board etc)?

A bonus:

• what did you expect when you started doing agile? Has anything changed/improved?

If the answer is no to the last question, you should really do a retrospective on different levels (business, development etc) separately and then together (share the information and generate discussions between the parties) to find out where are you heading and what are the expectations and set your ways of working accordingly.

Answer 5

From your description above it appears the focus of the meeting is tracking actuals against estimates. This is not my understanding of the purpose and value of the Scrum daily standup meeting.

Rather it is as you have described to use the structure of the three questions to get an idea of the current state of play. The value of those questions is what you do with the answers. Do they just provide a status report or are helping you with communication and co-ordination?

I have only worked on one Scrum project, developing an application for a German Telco. In this project I took on the role of 'Product Owner', I was based in London, UK, with the 'Scrum Master' and development team working in Dublin Ireland.

The value to me of the Scrum stand up, which we held as a conference call every day at 2pm, was to get daily feedback of what things were blocking the development team or needed clarification.

That was my one and only Scrum project. Once that project was in production the increased complexity tested the constraints of Scrum and I have since found Kanban to be a better fit for the work I do.

As an aside I would recommend taking a look at the debate on the value of estimation in software development. This David Anderson post on the subject is an interesting place to start.