Kent Beck's ‘Explore/Expand/Extract’ is a framework of sorts for helping teams navigate their way through major phases of growth and maturity. This is a cheatsheet I made for myself.
I’ve found it particularly useful for focussing teams, by creating alignment about which phase we’re at. Getting aligned on this early can prevent a lot of trouble down the road.
Why a cheatsheet?
Even after becoming familiar with the framework, I had open questions about how to really put it into practice:
- What signals should we look for to know which phase we’re in?
- How should our team’s approach change at each phase?
- How do we know when we’ve transitioned between phases?
I made the cheatsheet to act as a shorthand reference to help answer these questions.
|Explore||Move fast and break things||Experiment. The 10x/100x idea that gains traction will be a diamond in the rough. Expect lots of failures. That's fine – you have nothing to lose.||Don't stress about defining your own yet, you're still looking for them.||Forget about estimates, just time-box your work and pay attention. Be Agile if that's your thing.||Not a priority. Time spent fine-tuning code / design / scontent is time you could be spending exploring (starting new experiments).|
|Expand||Focus on impact||Remove scaling bottlenecks by solving the difficult technical problems. Focus on future impact because the work is unlikely to produce immediate payoffs.||Define what you need to measure the success of the technical problems being solved.||Use estimates as a way to ruthlessly prioritise and sequence the most important work. Celebrate each win no matter how small each may feel.||Iterate but don't refactoring too heavily yet. The public results of code / design / content changes are still more important than their internal states.|
|Extract||Slow down and fix your shit||Few experiments. Minimise the possibility of failure. Upside is that every fix is multipled because of the work done in Expand.||They drive everything. Now is about picking which of those metric levers to pull on at different times.||Forget about Agile. Forget about XP. This is not a game of courage like Explore. There's a lot to lose.||Make everything the best it can be. Refactor, refine, polish.|
Notes on transitioning between phases
Each phase is a totally different game requiring a different mindset and set of processes. You can’t have an Explore mindset when you’re in Extract and expect successful outcomes.
The key challenge is for a team to simultaneously manage multiple projects at different stages across Explore/expand/extract.
- Transitioning from Explore to Expand isn’t a choice. It just happens. Your users/customers will tell you when you’re heading into Expand because your product/experience isn’t meeting their expectations. This is a good problem to have, because it shows that they give a shit.
- When transitioning from Expand to Extract you do have a choice: bank on your idea being the Big One and commit to playing a totaly new game (Extract) or choose to keep exploring.