4 ways to keep the daily scrum from becoming a status meeting

Ah, the daily scrum, so often misused as an instrument of status (see https://youtu.be/i7_RPceEIYE for a discussion).  Often the way the daily scrum is conducted lends itself to a report of status.  The team answers 3 questions in a round robin fashion.  It often sounds like this:

·      What did you do yesterday?

I went to meet with Joe and had to fill out an HR form.  I also wrote 13 emails and filled out my timesheet.  Oh, yeah, I also wrote a little code.

·      What will you do today?

Well, I’m going over to the other building to talk to the stakeholders about next month’s sprint.  I’m also going to three meetings about the user interface. On top of that I’m going to Yorka’s Greek for a gyro with Felice.

·      Are there any blockers?

No blockers.

Not a fruitful exchange, is it? 


The heart of the daily scrum is to use it as a micro planning and coordination session for the next 24 hours, not so everyone can share their status.  Status can be gleaned from a simple task board, a burndown, a burnup, or other information radiators. 


Here’s some ways to promote focus on the sprint goal and coordination during the daily scrum:

1.     Recast the questions to focus on a consumer/producer conversation like so:

What did you complete yesterday that we can consume?

What will you complete today that we need to consume or coordinate?

Is there anything out of your control that will prevent you from reaching your objective for the day?

2.     Recast the questions to focus on the sprint goal like so:

What did you do yesterday to contribute to the sprint goal?

What will you do today to contribute to the sprint goal?

Is there anything out of your control that will prevent you from contributing to the sprint goal?

3.     Abandon the questions and focus on 3 questions and focus explicitly on coordinating like so:

In order to make progress toward the sprint goal, what do we need to coordinate today (e.g. technology, people, process)?   Make sure this question says “what do we need” as opposed to “do we need”.  The former infers something needs to be coordinated.

4.     Focus on the tasks and PBIs that are in progress. Rather than a round robin by person, the daily scrum becomes round robin by PBI:

For PBI xyz, do we need to coordinate anything for today’s progress? 


One more thing.  The it’s the daily scrum, not the standup.  You don’t have to stand up.


As you can imagine, there are a lot of other ways to keep the daily scrum focused appropriately.  Try your own experiments and inspect and adapt.  Just keep the heart of the daily scrum in mind.

Spitting stories not sprints

Splitting stories through vertical slicing is something you’ve probably heard and are practicing.  Now you’re probably thinking “I’ve done that before, this is simple.”  If that were the case, many of the agile consultants would be out of the job.  It’s harder than you think to have the discipline to slice features up.  It’s also tough to be disciplined and make sure that ever iteration has multiple features in the iteration. 


Often times iterations become boxes of features – when planning the sprint the question asked is “what can you deliver in 2 weeks” as opposed to “what can you grow in 2 weeks”.  Creating two week feature boxes is encouraged by a lot of authors that talk about release themes – people misunderstand that to mean that sprints should be themed.  When push comes to shove the sprint is extended to meet the completion of the theme.  Sound familiar? 


Thinking in terms of a pull system rather than ‘pushing’ work into a sprint will go a long way.  I’ve had students that said their software is extremely complex and nothing can be produced for weeks on end.  Consider this – do you compile and check out what the code is doing only after the end of weeks – I hope not.


A 2 week sprint is 2 weeks of time, not an estimate of what the team thinks can be completed in 2 weeks which is then extended to accommodate the estimated features.  You’ve got to think backwards, that will help quite a bit. 

Coach yourself out of the job


I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 


When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.


When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.


I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.


Agile maturity of organizations

I recently had a thought that I'd like to share with others regarding agile thinking.  


I believe that agile maturity can be thought of in three levels:

1) Level 1 is where agile is thought of as a way to allow change through adaption and inspection.

2) Level 2 sees agile as proactive in it's ability to change:  it not only allows change, but proactively positions the organization to expect and anticipate changes, in part by actively deferring constraining commitments.

3) The most mature agile organizations must seek out change, not just passively await it.  The example is organizations that foster change through techniques such as hack-a-thons or innovation days.


I've come to see these levels by watching multiple companies introduce Scrum and the supporting agile mindset without seeing product innovation.  They simply wander to the same general destination as they always have, minimizing risk and reducing waste, the only innovation being in the minor details. That’s a pity, but often the best you can hope for until the organization matures.


These levels are not meant to relate to Shu-Ha-Ri nor the Dreyfus model of skill acquisition.  It’s just way of progressing a company to higher levels of empirical processes based on their attitudes of change.  It works for me.


Have you experienced the same?