As a SAFe® Program Consultant Trainer, I have launched many Agile Release Trains (ARTs) over the last two years in a variety of industries and countries. Every time, I look to try something new (an experiment) to see whether there is a better way of doing things.
So, through a series of blogs I am going to share some of those experiments that I have found really useful. Perhaps try them out for yourself and let me know how you get on.
Let’s start by looking at the Inspect and Adapt workshop which, after the PI Planning, is probably the most important event; it is where we remember Principle #12 from the Agile Manifesto:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
This principle is re-emphasised by SAFe by including “relentless improvement” as one of the four pillars of the SAFe House of Lean.
The Inspect and Adapt (I&A) workshop is held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.
The I&A workshop consists of three parts:
- PI System Demo
- Quantitative measurement
- Retrospective and problem-solving workshop.
“The teams then run a brief (30 minutes or less) retrospective, the goal of which is to identify whatever issues they would like to address. “
The Scaled Agile Framework® (SAFe®) doesn’t give any specific guidance on how to run the retrospective but references the great book by Esther Derby and Diana Larsen, called “Agile Retrospectives: Making Good Teams Great”.
My issue is that running a retrospective can take longer than 30 minutes, especially for a large train, AND people generally have short-term memory. So, whilst they might remember the challenges from last week or the week before, they will forget about those from the first few weeks of the PI.
So, my approach has been to mine the Team Retrospectives with the Scrum Master and pull out all the challenges and issues that are more systemic, organisational or should be solved at the Program Level.
SAFe Big Picture 4.5
I then get them framed as Problem Statements using the anatomy of a well-defined problem: What, When, Where, Frequency AND Impact. As a consequence, the Retrospective actually starts with me sharing the problems and asking if there is anything we have missed, in which case we can frame another problem statement.
The Problem Statements are posted on the wall around the room and once people have had chance to consider each one, I ask them as individuals (not teams) to stand by the problem they want to work on.
Here we have to impose some parameters - no more than 6 people working on the same problem. If you have more than 6 people, then they need to break into small group(s) to work on the same problem, just independently of the other team(s).
Tip: Make sure you have multiple copies of the Problem Statement available in case you have more than one team working on the same problem.
I find the above approach is more expedient that running a retrospective, and draws out the challenges that the teams have experienced over the course of the PI.
I then run through the Root-Cause Analysis, re-state the Problem Statement and Impact and then brainstorm solutions.
I get each team to present their problem and solutions to the assembled audience, and once presented, post these back on the wall.
Once all problems and solutions have been presented, I then run a line voting (not dot voting) session. Everyone has three votes, and they vote on which problem and solution they would like to see tackled.
Tip: When doing the line voting, I recommend gating every five because it makes it so much easier to count up the votes!!!
There you have it - how to make the short retrospective actually short. Let me know how you get on - write to us or leave a comment on this blog article.
If you want to explore more on SAFe or further your knowledge, why not check out our Training courses?