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!