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:

  1. What signals should we look for to know which phase we’re in?
  2. How should our team’s approach change at each phase?
  3. 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.

  1. 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.
  2. 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.