In 1994 I had the privilege of working on the channel tunnel between the UK and France. We never did one retrospective. The best practice at that time was to consider a “lessons learned”, delivered at the end of the project. Think about it: When would such a project ever be done again?
Needless to say, we never improved how we worked on that project – during the project.
Then from 1997 to 2001 I worked on a project building a trading system for a bank. Again, we never once retrospected how we worked. We did not even collect lessons learned.
In 2011, some 10 years after the term “Agile” had been crowned, I heard about a story at an investment bank in the city of London. The management team wanted a “lessons learned” report. They went on to learn on the day that the project was delivered, that they had allowed the project manager to leave and they also “moved-on” other key members of the project team. Why? To save money, to reduce costs.
There was simply no one left to write the lessons learned. Ironically, they never learned from that mistake either.
And we leave the best example till last. In 2013, a medtech company wanted a project to roll-out “SAP in China”. Now, just how many times are you going to do that? How much sense does it make to wait until the end, before you have your lessons learned captured? When will you ever have the chance to implement SAP in China a second time – to do it better the next time?
Also note, it is often the project manager that completes the lessons learned. Rarely the people who are actively involved in daily delivery. I.e. The people doing the work.
Clearly then, the flawed “lessons learned” report was for many years the standard practice with projects, in order to get better. In itself, it’s not such a bad idea. However, as you can imagine from above, the execution is the challenge, and let’s face it, it’s often wasted effort.
This is where the retrospective comes into play.
Instead of waiting until the end of the project, we have to take time to frequently review how the project is being done, with a special view on constantly getting better in small manageable steps.
The Novelty Wears Off
The importance of the retrospective is without doubt. However many teams struggle with retrospectives after the initial excitement or interest: The novelty wears off.
And it is at this point that we need to re-inject energy, to take retrospectives to the next level of success. If we don’t, continuous improvement will die.
There are three main challenges that seem to always appear, regardless of team size, location, market segment or Agile method.
- Let’s improve Everything, Now!
Make sure that things happen afterwards. If this is not ensured why have retrospective at all? There are two issues here that lead to this.
A. The team will often have a long list of improvements to make. The retrospective must prioritise these. One technique is to use MoSCoW.
B. Even if the team selects a group of improvements, they are often in the form of projects or accountabilities. I.e. the counter-measures are big. So the team needs to avoid projects or accountabilities but rather identify one to three concrete tasks that can be done by the end of the next sprint – that move the team in the right direction.
- My Most Important Impediment
Individuals will push their own agenda, leading to measures that improve their own situation not that of the group, so work and time and money is potentially wasted.
One example was a business analyst with quite a powerful personality. She constantly pestered the developers to address her issue. She had not recognised that her issue was not the key issue for the entire team. Getting her to recognise this was key for the team to make progress.
- Cast The Net
Teams will often group their impediments and give them titles such as “Planning”, “Communication”, “Agile”, “Requirements”, “The Customer” etc and when faced with eight or nine of these general titles the group may get paralysed in terms of focusing on one. How do we break down that paralysed feeling?
The team simply needs to understand that when one thing starts to improve, the others will come with it. It is like casting a net, and pulling on one location, the rest will come too.
When we address those common challenges, and others, we begin to recognise that retrospectives are actually mostly about building trust.
One great line of questioning, is to ask this: “Who recently helped you, what did they do and what was the impact?”
It allows people to give gratitude, publicly.
It is clearly about getting better at what we are doing: About feeling pride in our work.
Retrospectives will give the team freedom to decide what to improve as they know what affects them primarily as a group, not as individuals.
If we then understand which measures have the greatest impact, we will understand the purpose of the improvements that were proposing to make. They will improve our working lives.
All of which raises our motivation to work.
The Personal Retrospective
Let’s consider the ability to retrospect on a personal level, not just in the team, and being able to reflect on how you as an individual can get better, on a regular basis. When this happens we start to have some very powerful changes.
For example, every day we find ways to do something that could have been better. We need to take a note of that and reflect on it personally. If we do that 5 times a week, for one year, we will have identified 200 things that could have been better – journaling is a brilliant way to do this.
And that is progress and it starts with you.