Reductionist Retrospectives
We can recognize software scope creep, but do we notice the slow creep of extra process on our workflow?
Retrospectives often output a list of tasks or additional processes that your team needs to implement. The tasks vary, perhaps they will open a new way of working, or implementing this additional task would have caught the failure before it reached production.
Let’s be honest though: most actions on a long list are often left undone. This can be down to a couple of reasons, but most likely because the action was neither urgent nor important. The team meets at the next retro, we sit down and either discuss how we failed to fully implement a new idea or (possibly even worse) don’t revisit previous actions at all.
One solution is to maintain a reductionist mindset, where you try to remove processes that aren’t working. This allows teams to eliminate unnecessary work.
Suppose you’re a city road planner. Your city experiences frequent car crashes at particular junctions. Obviously, the solution is to introduce more signage and install more traffic lights. Wait. Put on your reductionist hat. What happens if we remove signs, traffic lights, and road markings? This idea is called shared space and has been effective in reducing crashes in some places[1].
The shared space idea shows the power of the reductionist attitude. I’m not saying that standing up and claiming “look we had a bug in production, let’s throw away the Quality Assurance process” is a good idea. Sometimes you may replace a large process with a smaller one, such as the #NoEstimates movement, which throws away estimating tickets and just counts the number of tickets.
Reductionism at its heart is just about making things as simple as possible, but it can be difficult to throw away complexity.