[First, previous, next in series]
This is the fourth of nine articles in a series exploring the matrix below (introduced here):
We’ve now reached the middle column, and we’re starting from the bottom with Hypothesis-driven change.
Back in the day, we had Plan-Do-Check-Act (PDCA) – effectively the grandaddy of all experiment-based improvement cycles. This decade, Lean Startup has made the idea sexy once again, and there’s a really nice correspondence between the kind of hypothesis-driven approaches described by (say) Ash Maurya’s Running Lean (focussed on evolving a product) and Jeff Anderson’s Lean Change Method (focussed on evolving an organisation). Learn one, and you’re halfway there with the other! It hasn’t escaped the attention of the Agile community either – see for example this 2011 Dr Dobb’s article on Hypothesis-Driven Development.
Framing
Spend any time researching “hypothesis-driven development” now, and you’ll soon find this template familiar:
We believe that <change>
will result in <outcome>.
We’ll know when that we have succeeded when <measures>.
I appreciate the humility of it; in contrast to the way change is often framed, we’re prepared to admit that we don’t yet know for sure yet how well (or even whether) we’ll succeed. It really is an experiment, and not just because of the formalism. For all but the most obvious of quick fixes the truth is that you don’t know yet, so you might as well be honest about it!
As taught in my workshop , this 21st century framing helps lead the way to some questioning:
- How well could it turn out, and what would be required for the best case scenarios to play out? This line of questioning gets us into assumptions and dependencies, and sometimes to a whole cascade of preliminary experimentation.
- What unintended consequences (good as well as bad) might arise? How might we nurture the potential upsides as well as prevent or mitigate the downsides?
- Who would need to be involved?
Organising
For each individual change, Ash and Jeff have this kind of workflow in common:
- Prioritisation: choosing what to next, holding back changes that we shouldn’t commit to yet (there’s only so much we should do at once), and having the discipline to reject any that are unlikely to make it to the front of the queue in the foreseeable future
- Negotiating the nitty-gritty details (which in some cases may need to happen in parallel with prioritisation)
- Proving that it is as feasible, workable and usable as we thought
- Verifying that we’re getting the results we expected, capturing insights
- Either making the change permanent or reverting it
Processes such as these lend are very suited to being managed in a kanban system. There’s a nice symmetry here – your MVPs and your changes to organisation or process could easily be managed together using tools that many Agile teams would find quite familiar.
Joining the dots
To quote one recent workshop participant, this is “practical teaching which will be easily implemented in my business”. It stands very well on its own as a set of techniques, but as we further explore values-driven change we’ll see how it connects to values-based delivery (the service orientation part especially) and values-based change too.
Blog: Monthly roundups | Classic posts
Links: Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Agendashift 