Driving your team forward with Hypothesis-Driven Development
It was a Monday afternoon, and our team retrospective. Every two weeks we’d sit down and discuss what happened since the previous one, but this time it was different. This time we were focused entirely on one epic. For this epic we’d decided to experiment in splitting the work differently, and we wanted to know how people thought it went. The typical deluge of post-its went up on the wall, we voted on the most interesting, and we got down to discussing them. The conversation that followed wasn’t any sort of critical analysis, but rather an argument about ideals, and what we should be doing. By the end of it, we knew no more than when we started.
The problem? Nobody remembered why we’d split it differently in the first place.
Those who cannot remember the past are condemned to repeat it
In the time between deciding to experiment and measuring the results, we’d lost context. It wasn’t anybody’s fault. It had taken over a month to deliver on the work. We just didn’t invest in maintaining any log of why things were done.
Attempts at maintaining a shared context always seem to focus on what has been done, rather than why it was done. You join a team and you’re given access to a huge wiki explaining each component in the system, typically accompanied with a huge architecture diagram explaining how everything fits together. Maybe a decision log which explains why technical decisions were made. Attempts to improve a team are, however, usually buried in some sort of retrospective log, with no real explanation of what drove the actions, or ceremonies, that the team now take for granted. I think there’s a better way to structure improvement within a team, and that is by embracing hypothesis-driven development.
Hypothesis-driven development (HDD) is a practice which brings the scientific method to developing software. Instead of stories, which are about delivering specific pieces of value, you perform experiments. These experiments test hypotheses; which are expected to achieve a certain outcome. We can take this concept and apply it to a team, creating team experiments.
I imagine a world where teams maintain a wall of experiments, which they use to assess changes to the way they work. Retrospectives become about assessing experiments are already running, talking through the current state of the team, and deciding which new experiments to run.
Building and improving effective teams is about learning what works for you, and the best way to do that is through trying new things and seeing what sticks. HDD is a great opportunity to test your ideas and also provide a lasting log of your team’s growth.
Originally published at jimmythompson.co.uk.
