Explore/Expand/Extract cheatsheet
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 first heard about Kent’s idea in 2017. His original Facebook posts on the topic are still available [1, 2] and there a few other references scattered across the web [1, 2].
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.
The cheatsheet
| Phase | Mindset | Focus | Metrics | Process | Craft |
|---|---|---|---|---|---|
| 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.