Within the Agile community retrospectives are widely seen as the mechanism for promoting learning and change. But many teams fail to hold retrospectives, or fail to act on the findings, thus they fail to learn and improve. If we are going to fix this we need to change our approach to retrospectives, and find new ways to learn and create change.
On the face of it the idea is simple: periodically take some time to reflect on and discuss recent work, then agree improvements. With so much agreement over a relatively simple idea why do so few retrospectives happen?
An Advanced Technique
In reality retrospectives are one of the more advanced techniques in the Agile toolbox. One we can only use when we have some experience and success with other techniques, and when our organizations are mature.
The most common reason given for not doing a retrospective is lack of time. True, we are all busy people, but if we really value retrospectives the way we say we do, surely can we make time? Finding the time is really a question of prioritization, deciding that the retrospective is more important than other things.
The ‘I don't have the time' excuse is hides deeper reasons. It is a convenient explanation for something most individuals and organizations just don't want to do. The underlying problems are a fear of what might be found and a lack of trust between colleagues.
As individuals, we fear retrospectives for what might be uncovered, or what might be whitewashed. We intuitively have a good idea of what worked and what didn't work but we fear exposing these problems. Perhaps we skimped on testing, perhaps someone wasn't pulling their weight, or perhaps the business never really knew what it wanted. Facing up to problems requires courage.
Our companies fear retrospectives too, largely for the same reason: they fear what might be exposed. The business may well know it had an ill-defined idea when work started, but once the project had been approved nobody wanted to point out the Emperor had no clothes. Admitting a problem exists implies it should be fixed, which means finding time, energy and money - in other words more work.
All too often trust is missing. Individuals don't trust the corporation, the corporation doesn't trust the teams and managers are stuck in the middle being pulled in all directions. Without trust it is hard to be open and face up to problems.
Perhaps the only thing worse than not having a retrospective is having one and not being able to follow through to implement the suggestions. Teams that are brave enough to hold a retrospective and face up to problems quickly become frustrated and disillusioned when they are blocked from fixing the problems identified.
Which brings us to the second big problem with retrospectives: they don't bring about change. Organizations that have tried retrospectives feel good, the exercise is cathartic. Once we have exposed the problem and think we know how to solve it, we have renewed hope and energy. But if nothing happens frustration results, and the next time someone suggests a retrospective we think ‘Not again!'
One team at a London based software company used to conducted regular retrospectives but the team was not improving. When asked the team manager said: ‘I've stopped going. They find the same things every time and nothing happens.'
Making change happen is difficult. There may be technical problems, time problems, or the need for support from outside the team. Perhaps we need money for training, an extra person to fix a specific problem, or some other expenditure that is unlikely to get approved.
Tackling these problems requires a two-pronged approach. Firstly we need to find new ways of learning and improving apart from retrospectives. Secondly we need to adjust our approach to retrospectives.
Change starts with managers who are responsible for improving things. They are given a little authority to help