Back to Basics: Daily Scrum

16 April 2012

Ovidiu Pitic
Cognizant

More than a decade ago I was programming as part of enterprise software teams, fairly well protected from everything not related to our planned deliverables. I had a lot of fun.

But then I moved up to become an architect and team manager, and I got more visibility into the demand side. The fun didn't stop, but something seemed to be missing. Our process lacked substance, and I could see that from the new position. We needed to be more aligned, more agile. We had to get a common understanding of where we stood and how to deliver on our stakeholders' needs. If only we'd known Scrum back then.

Scrum does one thing extremely well, something I believe to be crucial for its fantastic adoption: It defines a vocabulary that's simple to understand and pick up.

Much of my work these days consists of coaching Scrum product development teams, and every day I'm faced with situations in which this basic vocabulary prevents misunderstandings. But what if the definition itself varies? How about semantics and their impact on your team?

As an example, let's look into a variation of how the daily Scrum (or daily stand-up) might be understood by teams and individuals. Take this example of a conversation held by a fictive enterprise team during a daily Scrum:

Mark: Yesterday I worked with David on the updated requirements coming from Department X. We analyzed them and also involved Anna so that she can prepare the test scripts. Today I'll work on User Story 7 for the end-to-end implementation (UI-logic-DB). No impediments.

David: Like Mark said, yesterday I processed the new requirements, and I helped on User Stories 4, 5, and 6. From Anna I understood that User Story 7 needs more clarification, so today I'll have a chat with the PO and improve it. No impediments.

You could say that we get a decent view of the work done and to be done. It definitively adheres to the standard definition of the daily Scrum: " . . . inspecting the work since the last daily Scrum and forecasting the work that could be done before the next one. . . . What has been accomplished since the last meeting? What will be done before the next meeting? What obstacles are in the way?" (The Scrum Guide, Ken Schwaber and Jeff Sutherland)

However, there's something fundamentally wrong here: All we get in the conversation are activities, not results. And this happens more often than we'd like to believe.

A better (but still not ideal) conversation would be:

Mark: Yesterday I worked with David on the updated requirements coming from Department X. Most of my planned grooming effort is gone, but they're ready for planning now and I still have time to work with Anna on the test scripts. Today I'll work on User Story 7 for the end-to-end implementation (UI-logic-DB), which I expect to finish around lunch. Depends on Anna a bit but will finish today, anyway. No impediments.

David: Like Mark said, yesterday I processed the new requirements, and I finished clarifying User Stories 4, 5, and 6. From Anna I understood that User Story 7 needs more clarification, so today I've planned a chat with the PO. I think we can finish by the end of the day, with a little time available for other tasks. No impediments.

Note how results are communicated and a feel of the workload is also passed to the team. This helps sprint progress assessment, improved collaboration, and self-organization, and it avoids lack of transparency, poor involvement or, in general, fallback to "the old way of doing things."

If you recognize that your team is discussing activities more often than results, you (as the ScrumMaster or Coach, typically) should immediately start helping your team transition from an activity-based to a results-based daily Scrum meeting. You could try some of the actions below for a seamless but effective change:

  • Point out the keywords helping the discussions: delivery dates (today, tomorrow, before lunch, etc.), estimates versus actuals (almost double what we thought it would take, spot-on, etc.), workload/feelings (quick solution, a burden, need help, free enough to pick up something else, etc.).
  • Take turns updating the burn-down chart — each day another team member can do it. This means that everybody needs to share measurable progress, not for a certain individual but for the team. If you do this after the daily Scrum, the one updating the chart should discuss stories that show no clear progress with the people working on them.
  • Make sure you're mentoring. Talk, outside the meeting, with people you feel are lacking in ability to clearly articulate their progress. Help them prepare a concise, activity-based message for the next daily Scrum.
  • Be an example.

In my Coach role, I'm painfully aware that, in certain organizations, I need to change thinking patterns to encourage people to be more open, organized, or efficient, while at the same time keeping the morale high. And sometimes I get loads of information about the organization from daily stand-ups like the ones above.

I hope I've started a discussion on Scrum improvement patterns. I'm sure there are many more "improvement gems" in our Scrum community, so please — comment on this article and share your own experiences!


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Juan Banda, CST,CSP,CSM,CSD,CSPO, 4/19/2012 7:37:20 AM
Nice article Ovidiu. I agree with you that focus should not be on activities but on results, after all Scrum is a pragmatical and highly results-oriented framework.

My best guest is that culture has a lot to do in how team members report on the Daily Scrum Meetings, for instance is very common that in a control culture these meetings tend to be more like and status or "report to the manager" meeting. Again, the control culture focus in activities and adherence to the plan created by some boss.

I like to think in Scrum teams like small cells that create their own subculture inside the bigger company/division culture. Team culture is more easy to influence and to focus/refocus to what is really valuable in that meetings.
Ovidiu Pitic, CSP,CSM, 4/23/2012 12:41:04 PM
Thanks for the comment, Juan! I completely agree on the culture/mentality being essential to a well-functioning team. It is also our role (as Scrum experts) to show the way towards increased engagement and fun... btw: cool reference to the cell structure, BSO is known to have used that for growth (http://www.extent.nl/articles/entry/the-evolution-of-bso-and-its-offspring)
Khemchand Sachdeva, CSM, 5/8/2012 5:00:26 AM
One thing that works like an acid test is that, a scrum master should watch who the team members are looking at while sharing their status in the stand up meeting. If all the team members are looking at the Project Manager or Scrum master then it is a not a good sign. The status is for everybody to know and not for certain individuals.

You must Login or Signup to comment.