24days until
ScrumPLoP!

Scrumming the Scrum

... you are using Scrum as a process improvement. The Scrum Team must have effective Sprint Retrospectives and have Popped 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’. The New Oxford American Dictionary. 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 software is not done, their backlog is not ready, and the team does not self-organize to improve performance.

Difficult impediments require extreme focus 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 user story with acceptance tests that will determine when it is Done. Then evaluate the state of the story 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 flat line or decrease over time. Lean expert Hugo Heitz [1] 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, management help will be needed.

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

When the team is successful in achieving velocity increase the system will re-stabilize after impediment removal and the next most important impediment may be in an unexpected place. So often unnecessary work (waste) will be generated by working on multiple 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. [3reported that Scrum is a pattern language for hyperproductive software development.

Recent work in both highly disciplined companies [4] and dysfunctional companies [5] 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 velocity by have 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 entire product backlog was estimated at 50 points of value.

“Better user stories” was the top priority improvement for the team. Removing this impediment was estimated at over 60 points of value. The Chief Product Owner wondered if removing that impediment might double velocity as the impediment value was higher than the entire product backlog value for the sprint.

"Improve User Stories" was put into the Product Backlog and pulled into the next sprint with a definition of DONE. This definition of done was implemented as acceptance tests that had metrics that were 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 teams 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 it’s place. 

The graph below shows the velocity of the team doing weekly sprints. In Sprint 86 the team was doubled in size. By sprint 89, “Improve User Stories” was put in the backlog of each sprint. Within three sprints velocity more than doubled. An average 10% increase in velocity per sprint was seen in subsequent sprints by Scrumming the Scrum.

 


Author: Jeff Sutherland (suggested by Hugo Heitz)

References:

[1] H. Heitz, "Scrumming the Scrum," Personal Communication, Paris 15 Dec 2010.


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


[3] M. Beedle, M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland, "Scrum: A Pattern Language for Hyperproductive Software Development," in Pattern Languages of Program Design. vol. 4, N. Harrison, Ed. Boston: Addison-Wesley, 1999, pp. 637-651.


[4] C. Jakobsen and J. Sutherland, "Scrum and CMMI  – Going from Good to Great:  are you ready-ready to be done-done?," in Agile 2009, Chicago, 2009.


[5] J. Sutherland, S. Downey, and B. Granvik, "Shock Therapy: A Bootstrap for a Hyper-Productive Scrum," in Agile 2009, Chicago, 2009.

Comments