Retrospective

Description

A Retrospective, also known as “Inspect & Adapt”, is a kind of Kaizen by looking back and assessing to set a better course for what will come next [Derby 2006]. This is a workshop meeting that usually runs within the intimacy of the Team to create some confidence, so that issues met can be freely discussed [Medinilla 2014].

Retrospectives aim at improving notably [Derby 2006]

• Productivity
• Capability
• Quality
• Capacity

and of course working conditions and feelings because, when people avoid emotional content, issues don't go away [Derby 2006]:

• they go underground and saps energy and motivation
• the emotion may come out in a flare of anger, and a flame war won’t help your retrospective

This requires having structured activities to deal with this feeling question.

‍

There are a lot of predefined activities that can notably be found in:

• https://retromat.org/ 
• [Derby 2006]: pages 42 to 126
• [Medinilla 2014]: pages 159 to 190
• [Moustier 2019-1]: pages 51 to 62

On the Internet, you may find some other gamified retrospective to help you run workshops with some fun to add some spice in your workshop activities.

The typical retrospective dynamic is [Medinilla 2014]:

• Opening of the Retrospective
• Telling the iteration story to remember the main events
• Identifying impediments
• Adding impediments to the backlog

The idea is to engage Team Members in a safe environment to 

• let them express themselves, 
• spot relevant improvement opportunities 
• and provide support to successfully deploy some of those improvements.

The approach can be more formal to maximize the meeting efficiency with a structure such as [Derby 2006]:

• 1. Set the stage: helps people focus on the workshop, its charter and activities. It contributes to creating an atmosphere where people feel comfortable discussing issues
• 2. Gather data: creates a shared picture of what happened and expands everyone’s perspective.
• 3. Generate insights: the team considers the data to identify strengths and issues from the previous iteration and examine the conditions, interactions, and patterns that contributed to their success or failures
• 4. Decide what to do: plan experiments and actions from some candidate improvements
• 5. Close the retrospective: the Team must decide what they’ve learned from the retrospective and how they’ll retain it notably with action plans.

‍

Whatever your approach is, since retrospectives create an environment for learning, as a Facilitator you must pay attention to factors such as [Derby 2006]:

• Attention to avoid topic drifting,
• Relevance,
• Confidence / Competence,
• Satisfaction

‍

A retrospective can be as simple as a workshop with sticky notes given to participants. They all have to provide notes with “what went good” / “what went bad” / “Improvement ideas” [Kniberg 2015] from events or facts they experienced. Each item should be written on an individual note to ease processing.

Unfortunately, after a while, people will lose their attention or will not see things; therefore, you must vary activities to keep your team engaged; otherwise, after a while, the same old activities “lose their zest” [Derby 2006] [Medinilla 2014].

There are several other ways a Retrospective can go wrong [Medinilla 2014]:

• Strong practices and weak spots are identified but there is no actual analysis, no plan to enforce practices or reduce weak spots, no follow-up mechanism.
• All retrospectives seem all the same: the same problems are identified and reported over and over, and nothing really changes.
• The team uses retrospective time for playing team-building exercises, Agile games, and so on but there is no real improvement effort
• No action plan is provided because team members claim that the problems are not their fault and that blaming is cultural
• Action plans are defined too vaguely or with too much high-level content and wishful thinking
• The action plan is defined by the Leader but the Team does not feel empowered - Kaizen is limited to what the leader is able to achieve on his own.
• Few people participate
• Team’s fear of conflict makes them hide real problems
• Only bad feeling emerge from the workshop
• Not enough time to perform a proper retrospective, so results are weak, people think retrospectives are a waste of time and then, they don’t spend too much time on retrospectives - Agile coaches recommend a minimum of 30 min to 1 hr per iteration week (2 weeks equals 1h-2h) [Derby 2006] [Medinilla 2014]

Impact on the testing maturity

Every lean and agile process has a feedback loop. Without feedback there is no kaizen. If management is calling itself agile but refusing to let the team “waste time” on retrospectives, we risk losing the kaizen benefits of the agile feedback loop [Freedman 2015]. Therefore, Management should play a role in retrospectives, at least by providing space and time to let improvement happen. Manager should also take it as an opportunity to do Gemba. They should also let others talk first, acknowledge the contributions others make, and be careful how they disagree. They must preserve participation [Derby 2006].

In such workshops, whoever speaks, fact-based discussion and assertiveness, in a blameless and egoless state of mind, should be the rule to limit non constructive emotional responses [Derby 2006]. In a nutshell, communication and good facilitation are key [Medinilla 2014].

‍

Project retrospective after each release or when the project is being decommissioned, it may be useful to spot systemic issues. Be prepared for a full day series of workshops for big projects in order to explore multiple perspectives [Derby 2006]. For such workshops, you will need to 

• invite project stakeholders and teams
• find a room big enough to welcome everyone
• prepare management participation
• gather key questions before the workshop
• plan breakout sessions and breaks every ~2hrs
• set working agreements to set the stage  - you may ask people to monitor working agreements during the retrospective (eg. raising a high hand to make silence for all people [Li 2016]). When people take responsibility for their interactions, you can focus on facilitating [Derby 2006]

‍

When there are many Teams with strong interactions, a retrospective at group level may be useful to address systemic issues. Here are 2 examples:  

• LeSS proposes a “Joint Sprint Retrospective” [Larman 2010]: once the Team retrospective is over; people are gathered in a single room and a workshop can take place, notably with some Liberating Structure workshops such as OST. This ensures cross-team discussions on system wide issues. Product Owner, Scrum Masters, 1-2 Representative of each Team, and managers will participate [Larman 2017] to
    (1) discuss and learn about some aspects of the system,
    (2) create only one systemic improvement experiment to follow for the next Sprint
    (3) reflect on the results of the last retrospective experiment and use that to learn and adapt.
• SAFe proposes an “Inspect & Adapt” workshop with the agenda [SAFe 2021-49]
    (1) Agree on the problem to solve
    (2) Apply root-cause analysis
    (3) Identify the biggest root-cause
    (4) Restate the new problem for the biggest root-cause
    (5) Brainstorm solutions
    (6) Identify Improvement Backlog Items

‍

However, looking back on a long period or at scale is difficult. To do so, you may use Causal loop diagrams to model the system and spot improvement opportunities [CLExchange 2016]. This model will lead to conversations; the output is a shared understanding, not the model [Larman 2017]. The shared understanding facilitates the emergence of a common vision on improvement actions to experiment.

Once the retrospective is over, you should not think improvements are achieved. You still need to

• support changes through reinforcements, empathy, learning and practice opportunities, and reminders [Derby 2006]
• share responsibilities, and eventually build Teams, for making changes [Derby 2006]
• build “impediment boards” [Kniberg 2014] to ease visual management
• apply 5S on backlogged improvement because ideas may change or become outdated
• spread lessons learned between teams [Kniberg 2015]

‍

Agilitest’s standpoint on this practice

Click here to ask for the standpoint of Agilitest.

‍