Scrumming the Scrum


... you are using Scrum as a process improvement. The Scrum Team must have effective Sprint Retrospectives and are Pop the Happy Bubble. The basic Scrum mechanisms are in place, and you want to leverage Scrum to fulfill its vision of kaizen:

kai-zen (カイゼン) n. a Japanese business philosophy of continuous improvement of working practices, personal efficiency, etc. <ORIGIN> Japanese, literally ‘improvement’. [1]

Also see Toyota Kata. [2]

✥      ✥      ✥

Only a small minority of Scrum teams achieve the hyperproductive state. This is because most teams fail to identify and remove impediments. Their work is not Done, their backlog is not Ready, and the team does not self-organize to improve performance.

Difficult impediments may require extremely focused efforts to remove. Working on many impediments at once often leads to a lot of work with little gain and can demoralize the team.

Therefore:

Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next Sprint. To remove the top priority impediment, put it in the Sprint Backlog as a task with acceptance tests (see Testable Improvements) that will determine when it is Done. Then evaluate the state of the task in the Sprint Review like any other task.

Focusing attention on the top priority impediment will have the side effect that the team will self-organize to remove other high priority impediments as well, without losing focus on the highest priority impediment.

✥      ✥      ✥

This pattern assures continuously increasing velocity or sustainable high-level velocity. If you are not continuously improving, your velocity will flatline or decrease over time. Lean expert Hugo Heitz [3] emphasized that Scrum teams do not put enough focus on process improvement: “They need to put the kaizen in the backlog. They need to Scrum the Scrum. They need to use Scrum to make Scrum better.”

While the ScrumMaster owns the process for creating and prioritizing the impediment list, the whole Scrum Team owns eliminating the impediments. Many impediments are resolvable by the team. In other cases, the team may need management help (see Involve the Managers).

Removing the top priority impediment should yield immediate velocity improvement. If not, the Scrum Team has not properly analyzed system dynamics and understood the root cause of the primary dysfunction.

When the team is successful in increasing its velocity the system will re-stabilize after impediment removal and the next most important impediment may be in an unexpected place. So it is likely wasteful for the team to work on multiple impediments or constraints at once. Focus on the top priority impediment.

Scrum is a framework for inspecting and adapting to achieve continuous improvement by removing impediments. Continuous improvement will increase velocity and produce a hyperproductive state (at least 400% improvement). Beedle et al. established the perspective early on (see “Scrum: A Pattern Language for Hyperproductive Software Development” in [4]) that Scrum is a pattern language for highly responsive and productive software development.

Past work in both highly disciplined companies [5] and dysfunctional companies has shown that every team can achieve a hyperproductive state by implementing specific practices using Scrum. For example, Systematic, a CMMI maturity level 5 company, demonstrated that all teams could double their velocity by having software tested at the feature level and bug free at the end of a Sprint. A second doubling of velocity was possible by assuring a high ready state of project backlog at the beginning of a Sprint.

Example:

A team uses the Happiness Metric as a way to identify and prioritize process improvements. On a scale of 1-5 they ask (1) how do they feel about their role in the company and (2) how do they feel about the company. Then they share what would make them feel better and the team uses planning poker to estimate the value of things that would make team members feel better. The team estimated the value (as opposed to effort) of backlog items as well. The team estimated the entire Product Backlog to sum up to 50 points of value.

“Better user stories” was the top priority improvement for the team. The team estimated that removing this impediment would yield over 60 points of value. The Chief Product Owner of the Product Owner Team wondered if removing that impediment might double velocity as the impediment value was higher than the entire Product Backlog value for the Sprint.

The Product Owner put “Improve User Stories” into the Product Backlog and the developers pulled it into the next Sprint with a Definition of Done. The team defined this Definition of Done as acceptance tests that had metrics that they calculated at the next Sprint Review. They included:

  1. How many stories got into the Sprint that did not meet the INVEST criteria (immediately actionable, negotiable, valuable, estimable, sized to fit, and testable)? — should be 0
  2. How many times did Developers have to go back to the Product Owner to clarify a story during a Sprint?
  3. How many times did dependencies force a story into a hold state during a Sprint?
  4. How many stories had process efficiency of over 50%? (process efficiency = actual work time/calendar time)
  5. How many stories were not clear to Developers? Measure by number of team members that complained about a story.
  6. How many stories implied technical implementation rather than clarifying desired user experience?
  7. For how many stories did Developers understand the linkage between the story, the theme that produced the story, the epic that generated the theme, and the business need that generated the epic? Measured by number of team members complaining that they did not understand why they were doing a story.

While improving the quality of user stories is never ending, the Sprint Review demonstrated significant improvement on this backlog item as measured by the acceptance tests. Significant improvement resulted in an increase in velocity after several sprints. After velocity had doubled this impediment fell off the top of the impediment list and another impediment took its place.

The graph below [6] shows the velocity of the team doing weekly sprints. In Sprint 86 (around 12/27/2010) the team doubled in size. By Sprint 89, “Improve User Stories” became a backlog item in each Sprint. Within three Sprints velocity more than doubled. The team realized an average 10% increase in velocity per Sprint in subsequent Sprints by Scrumming the Scrum.

Credits to Hugo Heitz for suggesting this pattern.


[1] Angus Stevenson, Christine A. Lindberg, Elizabeth J. Jewell, and Frank Abate. New Oxford American Dictionary, 3rd edition. Oxford University Press, 2017..

[2] Mike Rother. Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results. New York: McGraw-Hill, 2010.

[3] Hugo Heitz. “Scrumming the Scrum,” Personal Communication, Paris, 15 Dec 2010.

[4] Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, and Jeff Sutherland. “Scrum: A Pattern Language for Hyperproductive Software Development.” In Pattern Languages of Program Design 4, N. Harrison et al, ed. Boston: Addison-Wesley, 1999, pp. 637-651.

[5] Carsten Ruseng Jakobsen and Jeff Sutherland. “Scrum and CMMI — Going from Good to Great: are you ready-ready to be done-done?” In Agile 2009, Chicago, 2009.

[6] —. “The Scrum Guide: An interview with Jeff Sutherland.ˮ StickyMinds.com, https://www.stickyminds.com/interview/scrum-guide-interview-jeff-sutherland, 21 October 2014 (accessed 2 November 2017).


Picture credit: Josh Staiger, https://www.flickr.com/photos/44124323209@N01/273593601 (under CC BY 2.0 License)

Comments