...you’ve started calibrating your velocity (see Notes on Velocity) by using Running Average Velocity, but find that it is still difficult to achieve good Sprint production forecasts.

✥       ✥       ✥ 

An average of recent past velocities isn’t necessarily a predictable velocity.

You want the velocity to reflect the team’s current abilities, yet it takes time to know whether process improvements actually worked. Yesterday’s Weather works in a system that has settled into the rhythms of a given season, but the early days of an agile team are very much like the transition from winter to summer in Chicago, where the weather changes from hour to hour.

Good teams experience plateaus of normative stability between rockier episodes of change (see Kaizen Pulse). A running average takes no account of variance, so it is a particularly dubious predictor of system behavior in a Development Team’s early Sprints. One can’t extrapolate the historic velocity of a system into the future until the system has normative behavior.

Further, good Scrum teams should have kaizen mind (see Kaizen and Kaikaku). Teams that have longstanding low variance in their velocity are dead teams: they are not growing in their practice and are likely not improving. So while Running Average Velocity works for these teams, it does not work for teams undergoing regular kaizen: the average of the past three Sprints is, by definition, a non-normative predictor of values in a monotonically increasing series.

Therefore:

Recognize an updated velocity only if the team sustains a new level for three Sprints in a row.

✥       ✥       ✥ 

Now the team is more likely to meet delivery expectations in the upcoming Production Episode. The velocity hopefully exhibits a long-term trend of improvement, but there is no law of nature preventing velocity from decreasing over time, either.

A great Scrum team runs in two modes: calibration mode and kaizen transition. During calibration mode, the team strives to normalize its velocity by reducing its variance. There are, in fact, good kaizens to this end: ensuring that the whole Development Team is involved in estimation; making sure that the Product Owner is not; making sure that all developer work comes from the Product Backlog; and so forth. Once the team establishes a new stable velocity, it can affect a kaizen with the aspiration of achieving a new plateau.

This pattern is an example of the Satir cycle of organizational change. The Satir cycle describes how outside changes (“foreign elements”) temporarily disorient an individual or organization ([1], Chapter 5, “The Process of Change”). A kaizen is tantamount to a “foreign element” that invalidates the formerly invariant assumptions on which the old status quo depended. The organization must latch onto a transforming idea that brings it out of chaos into new normative work patterns. Good organizations wait out the inevitable chaotic stage and wait for a new normalcy to prevail before pronouncing a new velocity.

Perhaps the most important factor contributing to normalcy is to stabilize team membership. See Stable Teams.

Toyota, in fact, works in this way ([2], pp. 84–5). After a kaizen, the teams stay the course with Mary Poppendieck’s notion of Deliberate Practice, described by Jon Jagger in [3] (pp. 44–45), to make sure the team integrates the kaizen into routine practice and that the improvement holds.

[1] Virginia Satir, et al. “The Process of Change.” In The Satir Model: Family Therapy and Beyond. Palo Alto CA: Science and Behavior Books, 1991, Chapter 5.

[2] Hirotaka Takeuchi, et al. Extreme Toyota: Radical Contradictions That Drive Success at the World’s Best Manufacturer. Chichester, UK: Wiley, 2008, Chapter 4, pp. 84–5.

[3] Jon Jagger. “Do Lots of Deliberate Practice.” In Kevlin Henney, ed. 97 Things Every Programmer Should Know. Sebastopol, CA: O’Reilly, 2010, pp. 44–45.

Picture credits: https://pixabay.com/en/shift-gear-knob-vehicle-parts-1838138/. (under CC0 license).