- Retrospective analyses are held after a project to determine what worked well and what did not. They are also conducted at the end of an iteration in Agile project management.
- Agile practitioners call these meetings retrospectives or retros. They are an effective way to check the pulse of a project team, reflect on the work performed to date, and reach a consensus on how to tackle the next sprint cycle.
- These are the five stages of a retrospective analysis for effective Agile project management: set the stage, gather the data, generate insights, decide on the next steps, and close the retrospective.
Understanding retrospective analyses
Retrospective studies were once the domain of the healthcare industry where existing data are studied to identify risk factors for certain diseases.
In more recent times, retrospective analyses have been adopted by project teams to uncover what is working well and what needs improvement.
Retrospective analyses are also a perfect match for Agile project management and, because they are held after each iteration, respect one of the philosophy’s core tenets of continuous improvement.
Agile practitioners call these meetings retrospectives or retros. But whatever the name, they are an effective way to check the pulse of a project team, reflect on the work performed to date, and reach a consensus on how to tackle the next sprint cycle.
Retrospectives also have a knack for allowing blockers to surface before they become problematic. Blockers are any factor that impacts the team’s ability to work.
They may describe a work environment that is too loud, slow user-story acceptance, or too many meetings that hinder progress.
How to run a retrospective analysis
David Horowitz is the co-founder and CEO of Retrium, a company that helps clients develop sprint retrospective analyses that are fun, interactive, and fuel continuous improvement.
In an interview with Forbes in March 2022, Horowitz posited that five phases described an effective retrospective.
Phase 1 – Set the stage
To foster an effective meeting, it is important to first check the temperature of the room and ensure that everyone is in a mood conducive to reflection.
Horowitz uses the example of a team of developers who are thrown from deep technical work to introspection in rapid time.
Since they have not had adequate time to adjust, their engagement in the retrospective analysis is low at best.
So how can the facilitator provide mental separation from the previous task and the task at hand?
One way is to move around the room and ask everyone to contribute a one-word emotion that describes how they feel. Collective deep breaths can also work well.
Phase 2 – Gather the data
Otherwise known as setting the terms of reference, gathering the data means clarity is provided on what is being reviewed.
Is it a process, procedure, or specific event? Whatever the case, it is vital there is consensus on the set of facts that will be discussed.
Teams that skip this phase end up failing because they try to fix a problem without a shared mental model of what the problem actually entails.
In Agile projects, this phase may encompass objective data such as the number of stories completed, average cycle time, or velocity.
There is also subjective (soft) data to consider which deals with team motivation, emotions, opinions, and feelings.
Phase 3 – Generate insights
The third phase is characterized by assessing the state of the issue. Note that it is not quite time for problem-solving. Instead, the team should discuss what changed and how the iteration came to be the way it is.
Root cause analyses such as the Fishbone diagram or 5 Whys can be useful to narrow down a list of factors to two or three the team can focus on.
Otherwise, the team can ask themselves if it sees any patterns or surprises in the data and if so, what they signify.
Before moving to the next phase, there must be consensus around the major factors at play.
Phase 4 – Decide on the next steps
In the fourth phase, the team takes what it has learned and incorporates them into a plan to move forward.
Most teams understand this process well because of a natural desire to come up with ideas that enable them to improve.
To a lesser extent, however, some other teams will use this phase as an opportunity to complain and thus fail to identify actions that will lead to beneficial change.
These teams tend to see little value in retrospectives and may cease performing them entirely.
Frameworks such as Stop Start Continue can be used to brainstorm a list of potential actions.
These are subsequently analyzed in the Force Field Analysis to identify the strongest supporting and inhibiting factors for a change item.
Once a list has been assembled, the team can vote on a way forward with impact, effort, and energy mapping.
Phase 5 – Close the retrospective
The fifth and final phase should only last a few minutes. Consider this phase to be a retrospective of the retrospective. What worked? What didn’t? How could the team do better next time? Is there any constructive feedback for the facilitator?
Individual contributions should also be recognized and celebrated at this point.
Main Free Guides:
- Business Models
- Business Strategy
- Business Development
- Digital Business Models
- Distribution Channels
- Marketing Strategy
- Platform Business Models
- Tech Business Model
Connected Analysis Frameworks
Related Strategy Concepts: Go-To-Market Strategy, Marketing Strategy, Business Models, Tech Business Models, Jobs-To-Be Done, Design Thinking, Lean Startup Canvas, Value Chain, Value Proposition Canvas, Balanced Scorecard, Business Model Canvas, SWOT Analysis, Growth Hacking, Bundling, Unbundling, Bootstrapping, Venture Capital, Porter’s Five Forces, Porter’s Generic Strategies, Porter’s Five Forces, PESTEL Analysis, SWOT, Porter’s Diamond Model, Ansoff, Technology Adoption Curve, TOWS, SOAR, Balanced Scorecard, OKR, Agile Methodology, Value Proposition, VTDF Framework, BCG Matrix, GE McKinsey Matrix, Kotter’s 8-Step Change Model.