Shape Up Part 2: Betting

In the previous article, Shape Up Part 1: Shaping, we discussed how Shaping, a parallel track to Building, allows teams to benefit from clear directions while retaining a high degree of autonomy.

In this article, we’ll give an overview of the principles of the second part of the Shape Up methodology: Betting.

Bets, not Backlogs

• At this stage, the pitch is written
• But it doesn’t go to a backlog, to avoid the situation where hundreds of tasks typically pile up, that we know we’ll never have time for and giving us a feeling like we’re always behind even though we’re not.
• This also prevents the time-wasting process of constantly reviewing, grooming and organizing old ideas, which prevents moving forward on projects that really matter now
• A few potential bets
  • Before each six-week cycle, a betting table is held where stakeholders decide what to do next
  • Nothing else is on the table – no giant list of ideas to review
  • With just a few options and a six-week long cycle, meetings are infrequent, short and intensely productive
  • If it is decided to bet on a pitch, it goes into the next cycle to build. If not, we let it go.
• Decentralized lists
  • Everyone tracks pitches, bugs, requests or things they want to do independently
  • It spreads out the responsibility of prioritizing. People from different departments can advocate for what they think is important.
  • The conversation is always fresh. Everythink is relevant, timely and of the moment.
• The betting table
  • Time to make decisions about which projects to schedule
  • Some companies use two-week cycles (aka “sprints”). But it’s too short to get anything meaningful done. Even worse, it’s extremely costly due to the planning overhead.
  • At Basecamp, a betting table consists of the CEO, CTO, a senior programmer and a product strategist. The highest people in the company are there, so there’s immediate buy-in and no need for a “step two” to get approval.
  • Meeting output: cycle plan
• Cool down
  • If it was always six-week cycles back to back, there wouldn't be any time to breathe and think about what's next
  • Period with no scheduled work of two weeks
  • During cool down, programmers and designers are freee to work on whatever they want, to fix bugs, explore new ideas, or try out new technical possibilities
• Uninterrupted time
  • When you make a bet, you honor it. You must not allow the team to be interrupted or pulled away to do other things.
  • The maximum you have to wait is 6 weeks before acting on a new problem or idea. Of course, when real crises occur, you can always hit the brakes. But these are very rare.
• What about bugs?
  • Use cool-down: gives programmers time to fix bugs in their lists
  • Bring it to the betting table: if the bug is too big to fix during cool-down
  • Schedule a bug smash: once a year – usually around the holidays – Basecamp dedicates a whole cycle to fixing bugs. It’s a good time for this because it’s hard to get a normal project done when people are off.
• Keep the slate clean
  • One betting cycle at a time
  • Never carry scraps of old work over
  • Every six weeks, learn what’s working and what isn’t, what’s important and what’s not

Place Your Bets

Look where you are. Wheter you’re improving an existing product or building a new one, you’re going to set different expectations for the next six-week cycle.

Existing Products

Follow the standard Shape Up process:

1. Shape the work
2. Bet on it
3. Give it to a team to build

It’s like buying a couch for a room with fixed dimensions.

New Product

It’s like figuring out where the walls are and where the foundation should go so the building will stand.

3 phases with different expectations:

1. R&D mode

• The idea is just a theory and technical decisions aren’t clear
• We can’t reliably shape in advance and say “This is what we want. We expect to ship it after six weeks”.
• Instead of betting on a well-shaped pitch, you mainly bet the time on spiking some key pieces
• Rather than delegating to a separate build team, senior people make the team for the architectural decisions and determine what’s possible in the product’s future
• Lastly, don’t expect to ship anything at the end of the R&D cycle. The aim is to spike and learn what works so you can commit to some load-bearing structure.

2. Production mode

• Point where the most important architectural decisions are settled
• The product does a few essential things and the foundation is laid
• Can bring in other people to contribute

3. Cleanup mode

• Bug smash, leadership makes those “final cut” decisions
• No more than two cycles to avoid delaying launch

Questions to Ask

Here are some common questions people ask when debating which bets to place at the betting table.

• Does the problem matter? Is this problem more important than that problem right now?
• Is the appetite right? We might still debate whether it’s worth the time.
• Is the solution attractive? A solution that works now may hinder some future work, for example.
• Is this the right time? Maybe it’s been too long since there’s been a splash of news with a feature. Or if the teams spent the last couple cycles in the same area of the app, their morale may dip.
• Are the right people available? Consider the types of expertise, holiays, …

Post the Kick-Off Message

After the bets have been placed, someone from the betting table writes a message telling everyone which projects are being bet on for the next cycle and who will be working on them.

Conclusion

In this article, we have seen an overview of the Betting process and the main steps. In the next article, we'll take a similar look at the third and last part of the Shape Up methodology: Building.

See you soon!