The value stream

The retrospective and continuous improvement

The Sprint Retrospective is the event in which the Scrum Team examines its own way of working. Many teams hold one, and few draw lasting changes from it. Four patterns from A Scrum Book propose a discipline: choose a single improvement, the one the team is keen on, treat it as work in its own right and allow time to measure its effect.

Fourteen ideas and no change

The French department of a collège (a French lower secondary school, for students aged 11 to 15) has four teachers. They prepare their shared teaching units and assessments in three-week cycles and meet for an hour at the end of each cycle to take stock. This Thursday, the board fills up with fourteen ideas: harmonize the grading rubrics, tidy the shared folder, give earlier notice of absences, rework the grammar progression for the second-year classes (students aged 12 to 13). Five are kept, and each teacher writes them down in her notebook.

Three cycles later, the five ideas are still on the list. "We say this every time," remarks one of the teachers. The ideas were good. But none had an owner, a date or a place in the schedule, and none was precise enough for anyone to know one day whether it had been carried out.

Sprint Retrospective: stopping to look at how we work

The Sprint Retrospective pattern states its problem as follows: without explicit attention, processes and discipline decay over time. Changing piecemeal, without thinking it through, adds to the disorder, and changing nothing misses opportunities to improve.

The authors explain why the other events are not suited to this examination. The Daily Scrum has too short a horizon. From one day to the next, performance varies naturally, and reacting to these variations makes no sense. In the thick of the action, you only have one or two points of view on a problem. The Sprint Review deals with the product and takes place in front of stakeholders, which is not the setting for analyzing how the team works internally.

Other forces push toward examining nothing at all. Sprints follow one another, and people rush into the next one repeating the same mistakes. A team that has already made progress persuades itself that there is nothing left to find and that the "real work" is pressing. Finally, examining yourself exposes you to criticism and brings out defensive behavior, which the authors describe following Chris Argyris (1991).

The solution is to hold, at the end of each Sprint, an event in which the Scrum Team evaluates the way it has worked. The timing is chosen because finished work gives an overall view and memories are still fresh. The proposed changes may concern people, their relationships, the process, the environment or the tools. The authors link this practice to Toyota's hansei, the self-reflection that follows a failure. It also matches the last principle of the Agile Manifesto:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Manifesto for Agile Software Development (2001), twelfth principle

The book gives several pieces of advice. The whole Scrum Team takes part, Product Owner included, for three hours at most for a one-month Sprint. The retrospective is not dropped in order to finish the Sprint's work. It relies on facts, such as the share of the Sprint Backlog completed and the velocity, and it also notes what went well. To keep the session from turning into a round of complaints, the authors recommend the "Prime Directive" formulated by Norman Kerth in Project Retrospectives (2001): whatever is discovered, everyone is assumed to have done the best job they could, given what they knew, their skills, the resources available and the situation.

Finally, they acknowledge two limits. Holding retrospectives guarantees neither improvement nor even a stable process. And two or three hours are not enough to reach the root causes, which lie in the structure of the organization or in its values. For that, Kerth proposed three-day retrospectives held off site.

Scrumming the Scrum: a single improvement, put on the backlog

The Scrumming the Scrum pattern starts from a claim by the authors: only a small minority of Scrum teams reach a radically higher level of performance, because most fail to identify and remove their impediments. Two forces explain this. A difficult impediment calls for concentrated effort. And tackling several impediments at once costs a lot of work for little result, which discourages the team.

The solution is to identify, during the retrospective, the most important impediment and that one alone, then to remove it before the end of the next Sprint. To do so, it is put in the Sprint Backlog like any other work, with acceptance criteria that will say when it is Done, and its state is examined at the Sprint Review. Some teams put it at the top of the Product Backlog, to signal that improvement is real work whose cost and value the Product Owner has weighed. The Scrum Master keeps the list of impediments, and the whole Scrum Team is responsible for removing them. The book credits the idea to Hugo Heitz, a Lean specialist, who summed it up by saying that kaizen must be put in the backlog. This Japanese word refers to continuous improvement in small steps (see Kaizen in the Lean corpus, in French).

The late test papers. The French department goes back to its list of fourteen ideas with a different question: which one hinders their shared work the most? They agree on the common test papers, which arrive the day before the test and which nobody has time to proofread. They put this in the plan for the next cycle, with a criterion: "The test paper and the grading rubric are filed in the shared folder five working days before the test." One teacher takes it on, and two hours of department meeting time are set aside for this work.

At the end of the cycle, the point is checked like everything else. The paper was filed six days ahead. Two colleagues had time to adapt their last lesson, and a numbering error was corrected before printing. The other thirteen ideas wait, and the team chooses a new one.

Happiness Metric: choosing what the team is keen on

That leaves the question of how to choose. The Happiness Metric pattern observes that a retrospective produces many ideas and that nobody knows in advance which ones will pay off. Long lists also have a demotivating effect, which the authors support with the work of the psychologist Barry Schwartz (2004) on excessive choice. So you need to work on the right improvement, and the team has to want to carry it out.

The solution is to drive improvement through a single small change at a time, chosen by consensus. The team is asked a question that helps it sense which of the available options most arouses its commitment, for example: what would we most like to do together, in the next Sprint, to improve the way we work? Many teams use a subjective scale from 1 to 5. The book insists on consensus. A majority vote or a decision by the Scrum Master are forms of control, whereas what drives the pattern is the team's feeling that it is deciding. Enthusiasm does not excuse a lack of realism: the acceptance criteria are spelled out and the work is estimated.

This pattern is markedly longer than the others, because its authors discuss their own doubts in it. They write that happiness is not the key to the Happiness Metric. According to the research they review, a team's happiness is linked to its future performance, but the arguments for a cause-and-effect relationship are scarce. Henrik Kniberg, whose company Crisp introduced this metric into the agile world, told them that the average obtained there remained very stable and taught almost nothing in itself. What makes the difference would rather be autonomy: a team that chooses what it improves finds that it has a grip on its work.

They also report an unfavorable case. A team that measured its happiness for its own sake, without linking it to a shared goal, won the right to work from home, each person on their own. Reported happiness went up for good, but velocity, after a brief rise, returned to its previous level. The authors conclude that the question asked must bear both on the team and on the product.

Kaizen Pulse: alternating change and stability

The Kaizen Pulse pattern is aimed at a team whose results have become steady and which wants to move up a level. Its problem is one of measurement. To know whether a change improves things, you need a baseline for comparison, and establishing one takes several Sprints. If velocity varies widely from one Sprint to the next, no effect can be told apart from the noise. If you change several things at once, you do not know which one had the effect. There is also a human factor: a group needs time to absorb a new practice until it becomes a habit.

The solution is to alternate periods of controlled velocity with pulses of improvement. The team first stabilizes its velocity, the book giving as a benchmark a variation kept within a 20% band. It then introduces a single change and practices it until it becomes routine. It goes back if experience shows the change does harm. The authors prefer to speak of "continual" rather than "continuous" improvement, and credit this scheme to a book on Toyota by Hirotaka Takeuchi and his colleagues (2008).

They add a warning. Velocity is used for forecasting; it does not measure value. A change can increase it while degrading what the product brings, and you will not notice if you look only at velocity. Other indicators must therefore be tracked as well, such as defects or the value delivered.

One change at a time. A team of six developers works in two-week Sprints. Its velocity over the last six Sprints is 21, 19, 22, 20, 18 and 20 points, an average of 20. All the values lie between 18 and 22, within 10% of the average, which gives a stable baseline.

At the retrospective, the team chooses one improvement: each item will be reviewed by a second developer before being declared Done. The next five Sprints give 17, 21, 24, 23 and 25 points. The first Sprint is lower, while people learn. The last three average 24, since 24 + 23 + 25 = 72. The team takes 24 as its new baseline, 20% more than before. At the same time, it checks that the number of defects reported after delivery has not gone up.

Because it changed only one thing, it can reasonably attribute this result to it. Had it also changed the length of its Sprints and the make-up of the team, the same figures would have taught it nothing.

What the 2020 Scrum Guide says

The Guide gives the Sprint Retrospective the purpose of planning ways to increase quality and effectiveness. The Scrum Team inspects the last Sprint with regard to individuals, interactions, processes, tools and its Definition of Done.
The maximum length is three hours for a one-month Sprint, as in the book. The retrospective concludes the Sprint.
The 2017 edition required the Sprint Backlog to include at least one high-priority process improvement identified in the previous retrospective, which amounted to making the Scrumming the Scrum pattern compulsory. The 2020 edition is more flexible: the most helpful improvements are addressed as soon as possible and may be added to the next Sprint Backlog.
The Guide has the whole Scrum Team take part. The book envisages, as an exception, the Developers asking the Product Owner not to attend a session, and sees this as the sign of a more serious problem.
The Happiness Metric, velocity and the impediment list do not appear in the Guide.

Limits and pitfalls

A retrospective with no follow-up produces the opposite of the intended effect, because it teaches the team that talking changes nothing. The Scrumming the Scrum pattern targets this flaw, provided the time for the improvement is really taken out of the Sprint.

Many impediments do not depend on the team. An imposed tool, a purchasing rule or a team that is constantly reshuffled cannot be fixed among colleagues. The book then provides for enlisting the managers, as the article on protecting the Sprint explains.

The session can also be hijacked. When a manager comes to tell the team how to improve, it becomes an instrument of pressure, which Ron Jeffries described under the name "Dark Scrum" (2016). Kerth's directive assumes a trust that cannot be decreed.

Finally, the book's figures should be read with care. The Scrumming the Scrum pattern asserts that removing the main impediment must produce an immediate improvement and that, if it does not, the team has misanalyzed the situation. Reasoning built this way can never be caught out. The example of doubled velocity that the pattern gives is taken from an interview given by Jeff Sutherland, and the case of the Danish company Systematic, which it also cites, from a 2009 conference paper co-authored by Sutherland. Neither comes from independent observers. The worked example above is fragile for another reason: eleven two-week Sprints add up to more than five months, during which many other things may have changed. The corpus's critical article returns to the value of these claims.