There was a glorious moment in 2014 where I worked on a team that really started pushing the boundaries of agile and lean software development. We wrote about it in a book titled Cranked: a lean and agile software development method. The team achieved this by throwing out the worn-out retrospective routine that is so common in agile teams.
Worn Out Retrospective
See if you recognise this from a typical retrospective…
Sticky Note Group:
- Programmers and testers not working closely enough
- Feels like mini-waterfall
- Test under pressure at end of iteration
- “Programmers and Testers need to work more closely”
Yeah right! This is equivalent to fixing a “broken power cable” by stating that the “power cable should be less broken“.
If this is how your retrospectives work, they are well and truly worn out.
The retrospective was actually the first thing that we changed. We weren’t “doing Cranked” at the time, we were doing Scrum. It was a typical Scrum implementation (and I say this with confidence, having conducted a survey that found a majority of Scrum teams are finding the same kinds of problem).
So we did a very different retrospective.
The scope of the retrospective was everything under the control of the team. The process, the tools, the roles. Everything. We generated a whole list of things that were broken and then dug down on each to find the root cause.
Once we had our collection of problems and causes, we grouped them together.
Then we talked about solving them.
For example, the issue of hand-offs between different specialisms came up. We could have suggested the banal and ineffective resolution of “do better hand-offs“, but instead we talked about how we could eliminate hand-offs altogether. If transferring work between people causes failures, could we reduce or eliminate these failures by ditching hand-offs?
This is one of the lines of thinking that lead to us removing all roles and titles from the technical team. One day we were “Testers”, “Graduate Developers”, “Developers”, “Leads” and all sorts; the next day we were all “Technical Team Members”.
We were surprised about how controversial this was. We didn’t think it was controversial. We found a deep-rooted problem in the way we were working and we fixed it. Our contracts might still have narrow job titles on them, but we were no longer constrained by this broken organisational thinking.
And we repeated this unconstrained retrospective method on each of the fundamental issues in the process until we had eliminated them.
We worked on two projects as a team using Cranked. During this time there were no software defects. We had eliminated the primary causes of defects in our organisation, which were mainly communication problems. We also went a long way to reducing the variability that made planning difficult.
Retrospectives have a habit of becoming tired and ineffective. It may even be tempting to ditch them entirely because they have become so worthless. Working on the Cranked team taught me that retrospectives can be brought back to life by expanding the scope of what can be discussed and ensuring the team has a remit to change what they find is broken – even dramatically so.
So if your retrospectives are starting to fail you, remember these points:
- The team must have power to change things.
- The scope should be wide (otherwise the software development process is constantly being optimised while waste and inefficiency elsewhere is ignored).
- Techniques should be used to dig deeper to find the root cause of a problem (for example n-whys).
- Dramatic changes should be encouraged. No part of the system or the process should be sacred or unchangeable.
The specific changes we implemented aren’t even that important. They worked incredibly well in our context, but every team should be given the freedom to do what we did (design our own jobs in order to benefit the organisation). Even if people don’t try out Cranked, we would hope that they make their retrospectives braver, more dramatic and more relevant.