Reductionist Retrospectives
We can recognize software scope creep, but do we notice the slow creep of extra process on our workflow?
Retrospectives often outputs a list of tasks or additional processes that your team needs to implement. The tasks vary, maybe they will open a new way of working or doing this additional task would have caught the failure before finding it in production.
Let’s be honest though, most actions on a long list are often not done. This can be down to a couple of reasons but is likely because action was neither urgent or important. The team meets next retro, we sit down and either talk about how we forgot to fully implement a new idea or (possibly even worse) just don’t talk about previous actions.
One solution is to keep in mind the reductionist attitude, where you try to remove process if it’s not working. This allows people to not do something.
Suppose you’re a city road planner. Your city is having lots of 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, that throws away estimating tickets and just counts the number of tickets.
Reductionism at it’s heart is just about making things as simple as possible, but it can be mighty hard to throw away the complexity.