Why you need retrospectives for your project and how to use them

Retrospectives are the Desert Island Disc of Agile and Lean-Agile techniques. Ask any Agile or Lean-Agile expert to pick a single project technique: they would pick retrospectives each time. Not stand ups. Not user stories. Not burn downs. Every single time they’d pick retrospectives to get them off that desert island of projects gone awry.

Why? Retrospectives are right there in the Agile Manifesto  as the final principle underpinning everything Agile:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its [behaviour] accordingly.”

Agile is good at bringing the problems to the surface. The success of an Agile team depends on the team’s ability to effectively deal with these problems. Retrospectives are a way of identifying and further examining these with teams and stakeholders and considering how to act. But they also give people the opportunity to see and acknowledge success.

If this sounds a bit weird to you, we’ll hazard a guess that maybe you’re coming from a more traditional project management approach.

The not-so-Agile approach to project problems a.k.a. not seeing the elephant in the room a.k.a. no retrospectives

Say a project isn’t going well—the metrics aren’t right. The project is taking too much time, and it’s costing too much money.

One by one, the team members are called in for performance management reviews.

“If you hit this part in the schedule in X time and step up your output…” says the project manager reviewing a team member. We’ll call the manager: Sam.

Sam manages to gain some insights from these reviews, but it’s like feeling out an elephant’s bulk while blindfolded. Sam manages to get parts of the elephant, like an ear here and a tusk there, they wonder what the smell is, but still never sees the whole. And if we were to stretch this metaphor a little further:

Because Sam never talks to the team in groups or even the team and stakeholders at the same time, they never hear the elephant trumpet.

Sam never realises they’re dealing with an elephant.

And because Sam is just dealing with the elephant in pieces and with the same tools all the time, they never come to understand how an elephant ended up standing in the middle of their office.

And boy, if that elephant decides to stampede, there’s no hope for that project. Goodbye KPIs.

To people who practise Agile and Lean-Agile forms of project management and delivery, that’s what traditional approaches to project management look like. A world where people can’t say to Sam, “Sam, there’s an elephant in the room,” because they’re not empowered to speak honestly with them.

The right culture is where mistakes are held as valuable sources of learning and everyone can talk about the elephant in the room.

Retrospectives reveal the elephant before it can build up momentum

Through constant and frequent use of retrospectives, it’s possible to identify the elephant. Find out what it wants and take it to a safe location.

The rest of this blog post looks at how retrospectives work and three techniques you could start using today in your projects.

Retrospectives v reviews

Before we go any further, it’s essential to understand that retrospectives are not the same thing as reviews.

A review is about delivered features and what features you might want to achieve in the next sprint.

A retrospective is where you reflect on the processes used in a sprint.

Reviews look at what you delivered.

Retrospectives look at how you delivered.

(And a sprint in Lean-Agile is a period where work is carried out on a product or service (Bluefruit’s sprints are two weeks long).)

Continuous improvement from the start

Having retrospectives right from the start enables continuous improvement from the get-go. This is the opposite of models like traditional software maturity models, such as the Capability Maturity Model Integration (CMMI). In CMMI, the final maturity level you can reach (Level 5) is the one where you’re frequently reflecting and optimising processes. You don’t start in that position.

Agile flips this and says you do this from the start. You do it at the same time as the rest of its core principles. That way, you discover what your processes are and then act.

You start by reflecting on how you do the things you do, and you discover all the other processes that may be involved. Through the process of a retrospective, you will have a better understanding of what each member of the team is doing.

Through retrospectives, you might find that you want to make your customer more aware of your team’s progress. So, you start doing reviews and start sharing. And you keep holding retrospectives. You keep learning and improving, working together to find questions that need answering.

We can’t understate how vital retrospectives are to the Agile process.

How to run retrospectives

You can run retrospectives using different techniques. There’s no single technique that you should always stick to. But there are three guidelines you need for successful retrospectives:

• Mix it up—different formats and different stakeholders as often as you can
• Keep it open, keep it safe
• Record and review actions

No one wants a zombie retrospective where you have the same people, potentially unable to talk, shuffling along and never knowing what actions already came up.

You capture actions from retrospectives, and you track those actions. In subsequent retrospectives, you reflect on those actions and what you’ve achieved from the previous retrospective, as well as looking at what you want to change this time.

Mix up whom you include in your retrospectives—ensuring that you have a chance to learn from everyone involved over the course of a project. That includes your stakeholders, not just your team. But that also means making sure people in retrospectives can speak freely. You need to empower them to be as open as possible about mistakes and their thoughts on those mistakes.

Why? Mistakes are the primary source of learning in a project.

Remember: the point of a retrospective is to gain insights into how you could work better.

Retrospective formats

There are numerous formats that you can run a retrospective in. Three we frequently use at Bluefruit are:

• Start, More, Keep, Stop, Less, Puzzle
• Value Stream Mapping
• Five Whys

Start, More, Keep, Stop, Less, Puzzle

This format goes a few steps further than a regular “Start, Stop and Continue Meeting”.

What does Start, More, Keep, Stop, Less, Puzzle mean? Generally:

• Start: processes/actions you think should be started.
• More: processes/actions you think need to be done more frequently or in more depth.
• Keep: processes/actions you think are fine the way they are.
• Stop: processes/actions you think the team should stop doing.
• Less: processes/actions you think the team can do less of.
• Puzzle: processes/actions or issues that you’re not sure about, but need to be addressed.

Running Start, More, Keep, Stop, Less, Puzzle

Doing a retrospective using this format, you eventually end up with a whiteboard like so:

Click on image for a larger view.

How did do you get to this point? First draw sections for Start, More, Keep, Stop, Less, Puzzle and add them as headers. Then you and your retrospective attendees spend a timeboxed amount of time (5 to 10 minutes) writing on Post-Its points that fit under the headings of Start, More, Keep, Stop, Less, Puzzle. As you write down your thoughts on the Post-Its, you add them to those headings.

Once the time is up, you take people through the Post-Its, taking time to discuss what they mean, grouping similar ones together when they’re in the same header. You note down actions that come from these.

(Basic) Value Stream Mapping

Borrowed from Lean manufacturing, Value Stream Mapping can help teams to see the bigger picture when an issue arises.

How? Once upon a time at Bluefruit, we had a client who was concerned with how long it had taken to fix critical defects through writing code. Fixes sometimes take a couple of days, but this client noted that it was taking 12 weeks to get a fix. That wasn’t normal.

A standard retrospective is usually too zoomed in to see all factors that might be affecting a project and looking at the time it takes to fix a bug.

To help us puzzle out what was going on, we did a Value Stream Map of the project. We mapped out how time was spent on value adding activities versus activities that added waste. Waste came in the form of wait times that could be a week long, or two weeks long, which here at Bluefruit means it’s added into the backlog for the next sprint. Looking at the Value Stream Map, the 12 weeks wait time for fixes was clear to see.

What was needed wasn’t us thinking faster or doing things more quickly. What was needed was the application of some simple queuing theory, which meant we could reduce the time activities were sat in inboxes or waiting in queues to be addressed.

The time to fix critical defects went down from 12 to 2 weeks, all without any extra effort from the development team.

Running a basic Value Stream Mapping session

Get some Post-It notes, a whiteboard, pens and whiteboard pens to hand and gather people involved in working on the product. Remind everyone that value adding activities are:

• Done right first time
• What your customer wants you to do
• When you’re processing or creating

To create a basic Value Stream Map try following these steps:

1. Scope out the whole process, checking when it all starts and when it stops. At the start your customer won’t be happy and is trying to achieve a goal and at the end they’ve achieved their goal and are happy.
2. Generate ideas of what your value steps are and what your waste steps are.
3. Analyse these steps to see how much time is spent adding value and how much time is spent adding waste. Put these underneath the steps, with waste on one level and value on the level below.
4. To find out the ratio of value added versus waste, make sure everything is in a similar time format, then divide the time spent on value added activities by waste time and multiply by 100.
5. Reflect on what you’ve found and decide actions you can take to remedy any steps where waste is created.

Once you’ve mapped out a draft of your Value Stream Map, it might look something like this:

Click on image for a larger view.

This is a Value Stream Map of for an average Bluefruit blog post. Altogether, 3.4% of the time for the post is spent on value adding activities.

What you need to keep in mind when analysing your Value Stream Map

The time spent adding value is rarely a place where you can further optimise what’s happening. Instead, look to where waste time is happening.

Use something like queuing theory to help reduce times something is sitting around, waiting for action to happen to it. If you have a huge backlog of tasks, consider ways they can be prioritised.

In the case of our sample blog post map, we could use paid promotion methods to reduce the time spent waiting to see a result. We could also introduce a prioritisation system for blog post ideas to reduce the two week gap earlier on.

Five Whys

Five Whys came from manufacturing and was developed at Toyota. This retrospective method is the one that if you only had retrospectives at your disposal and one format, it would be Five Whys.

In Five Whys, you find answers to the hard questions.

Here, you ask a question about a problem and from there, you suggest causes and then ask why of these causes. Using Five Whys helps you to gain a deep level of understanding on how to solve a problem and the problems that led to it. It’s a highly effective form of root cause analysis.

Running Five Whys

This method ensures as many critical angles as possible are covered.

Find a whiteboard or wall or similar large surface you can stick stuff like Post-Its to. Then:

1. Write your starting question at one end of your whiteboard—this is your main problem.
2. Then you and your team add causes that led to that question, on Post-Its, branching off from the starting question.
3. When you put down a cause, you check to see if this generates further questions and therefore causes, noting them/these down on more Post-Its as you go.
4. Stop when you reach the root causes of each of these issues.

You’ll end up with an analysis that looks like this:

Click on image for a larger view.

How to make actions from your Five Whys

Discuss your root causes and possible actions. When the analysis has gone deep, you’ll likely have many actions. These actions will represent changes for the short, mid and long-term of a project.

For the benefit of your customer, you should look to find some wins that can happen in the short term from those actions. You should roll in these changes as a natural part of your ongoing project process.

And then when it comes to your next retrospective, you should examine the progress of these actions.

A common theme in root causes

When you go through Five Whys, many of the root causes you’ll uncover have the same core to them:

People.

It could be that one small misstep early on has caused a snowball like effect through a project. Or it might be that teams and clients have not been communicating enough or in a transparent way that leads to a project from becoming blocked. Maybe an earlier issue was identified, but there wasn’t a process in place to deal with it.

Perhaps a vital detail got lost in an email chain.

But this isn’t about blaming people; it’s about finding the actions necessary to move beyond those mistakes.

Other retrospective formats are available

Bluefruit teams do use the above three formats a great deal, but here are a few more that you might want to try out:

• Sailboat
• The 4Ls
• Ishikawa (fishbone) diagram
• Appreciative Inquiry

These are just some alternatives. Both Lean and Agile have many that are suited to different product lifecycle stages.

Continuous improvement and learning from mistakes

We mentioned earlier that the defining element of Agile is that:

Mistakes are the primary source of learning in a project.

Learning and continuously improving is at the core of Agile and Lean-Agile practices. Carrying out frequent retrospectives will enable you to:

• Openly discuss emerging problems
• Record meaningful insights and actions
• Ensure projects are on track

Get the right balance

You might find after your first retrospective that there are a whole host of actions and you have no idea how you’ll fit them all into a sprint. But it won’t be like this for each retrospective, and certainly not when you make a point of using different formats and speaking to different people.

If your sprints are two weeks long like ours, have a recurring meeting at the end of those two weeks to go through a retrospective.

Retrospectives are like any skill, physical or mental: the more often you do it, the easier they become. And because you’re doing them so often, the earlier problems will bubble to the surface, because you’re tackling issues head-on and early, before they can grow and suddenly there’s an elephant in the middle of your office.

If you’d like to learn more about Lean-Agile software development practices, check out the posts below.