Heads up! This page uses features your browser doesn't support. Try a modern browser like Firefox or Chrome for the best experience.

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:

  1. Shape up one significant project or a few meaningful small batch projects that can be comfortably finished within the six weeks. Be conservative and allow extra time on your first run.
  2. 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.
  3. Instead of a proper betting table, simply plan for the team to do the work you shaped for this experiment.
  4. Kick off by presenting your shaped work to the team, with all the ingredients of a pitch. Set the expectation that they will create their own tasks. (Hand Over Responsibility)
  5. Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
  6. Encourage them to Get One Piece Done by wiring UI and code together early on 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.

Shaping first

Sometimes it’s not possible to get a team together to work for six weeks because somebody else, a CTO perhaps, controls programmer time. In that case, you can start just by shaping a compelling six-week project. When the work is better defined and there’s no confusing discovery phase in the cycle, any problems that come up will shine a light on engineering and open them to considering changing how they work.

Cycles first

Another approach is to start by lengthening cycles to six weeks. This will remove the overhead of constant planning meetings and give programmers longer stretches of time to build momentum and hit a stride. Then once you have more room to breathe, it’ll be natural to think about how to shape the work in order to better take advantage of this new capacity.

Build your muscle

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 doesn’t matter. First get the team into a rhythm of finishing things. Once you have the capability to ship, then you can start fine tuning the inputs to your shaping process.

Focus on the macro

Sometimes it can be scary to give the teams more free rein to set their own tasks and schedule. You might wonder: What if we bet on some small batch projects and they don’t use up the whole cycle? What if one of the programmers or designers has to wait on someone else for a day here or there?

To overcome these worries, shift the mindset from the micro to the macro. Ask yourself: If after six weeks we’ve shipped these projects, how will we feel? Will we feel good about what we accomplished? When projects ship and everyone feels they made progress, that’s the success. It doesn’t matter what happened down at the scale of hours or days along the way.

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.