Option A: One six-week experiment
You don’t need to change everything all at once. If the whole product team isn’t ready to make a big change, just start off with a single six-week experiment. These are the steps to take:
- Shape one significant project that can be comfortably finished within six weeks. Be conservative and allow extra time on your first run.
- Carve out one designer and two programmers’ time for the entire six weeks. Guarantee that nobody will interrupt them for the length of the experiment.
- Instead of a proper betting table, simply plan for the team to do the work you shaped for this one experiment.
- Kick off by presenting your shaped work to the team, with all the ingredients of a pitch. Set the expectation that they will discover and track their own tasks. (Hand Over Responsibility)
- Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
- Encourage them to Get One Piece Done by wiring UI and code together early in the project.
You don’t need to worry about Mapping the Scopes or Showing Progress right away. You should see a big leap in progress just by dedicating uninterrupted time, shaping the work in advance, and letting the team work out the details.
Once the team gets used to Getting One Piece Done, the stage will be set for properly mapping scopes down the road. It’s the same idea, just repeated. Later still, when they are good at defining scopes, you can use the hill chart to Show Progress on those scopes.
This approach lets you demonstrate success with one team and a single six-week commitment. With credibility gained from a good outcome, it’ll be easier to lobby for a bigger change and convert the wider team to working this way.
Option B: Start with shaping
Sometimes it’s not possible to get a team together to work for six weeks because somebody else, a CTO perhaps, controls the programmers’ time. In that case, you can start by shaping a compelling project with clearer boundaries than past projects. Present the project and put it through your company’s existing scheduling process (even if it’s a paper shredder). Better-shaped work can shine a light on the engineering team and help them open up to things like longer cycles or a more deliberate betting process.
Option C: Start with cycles
Another approach is to start by working in six week cycles. For teams that formerly used two-week sprints, this removes the overhead of constant planning meetings and gives programmers more time to build momentum and hit their stride. Once the team has more room to breathe, it’ll be natural to think more about how to shape the work to take advantage of this new capacity.
Fix shipping first
Build your shipping muscles before you worry too much about improving your research or discovery process. You can have the best customer insight in the world, but if you can’t turn it into a project and ship, it won’t matter. First get the team into a rhythm of finishing things. Once you have the capability to ship, then you can start improving the inputs to your shaping process.
Focus on the end result
Sometimes it can be scary to give the teams more free rein to set their own tasks and schedule. You might wonder: What if they don’t use up all the time we dedicate for the cycle? What if one of the programmers or designers sits idle at some point in the cycle?
To overcome these worries, shift the mindset from the micro to the macro. Ask yourself: How will we feel if we ship this project after six weeks? Will we feel good about what we accomplished? When projects ship on time and everyone feels they made progress, that’s the success. It doesn’t matter what exactly happened down at the scale of hours or days along the way. It’s the outcome that matters.