Initial thoughts on Basecamp’s Shape Up

6 week “bet” cycle + 2 week cooling off

They use a 6 week “bet” cycle with a 2 week cooling off period. This is really a 8 week cycle which means average lead time from raw idea to deployed solution for “big batch bets” will be 4 weeks. Unclear whether there is incremental deployment within the 6 week bet.

Target audience seems to be managers and design leaders

One of the key differences between Scrum and Extreme Programming (XP) is that in Scrum, most of what happens in a Sprint besides some basic process and and roles is deliberately treated as a black box. In contrast, XP has a lot more about detailed practices and tactics. This is because Scrum is expressed from a manager perspective while XP is expressed from a programmer perspective (the hint is in the name). It’s not that someone is micro-managing you but more that you are micro-managing yourself.

“Shapers” vs “Builders”

They have small senior groups that “shape” bets which are then selected in a “betting table” process which are then allocated to “builder” teams.

Separate Shaping vs Building tracks

This is essentially Discovery (shaping) vs Delivery (building) or “dual-track”. From what I understand, Basecamp has these as separate teams? I generally prefer treating this as separate activities, not separate teams.

Focus less on estimates and more on “appetite”

Essentially “what are we willing to allocate to this effort?” over “how long will this effort take?” Fixed time (and cost), flexible scope. I’m assuming they also fix quality but this wasn’t explicit.

Small batch — 2 weeks; big batch — 6 weeks

They have two sizes for bets:

  1. Small batch: 2 weeks
  2. Big batch: 6 weeks

“Tasks”, “slices”, “scopes”

Tasks, slices, and scopes seems to be equivalent to tasks, user stories, epics/features. Scopes are extracted from slices rather than determined up front.

Risk-first sequencing of “slices”

They advocate a risk-first sequencing which is closer to Barry Boehm’s spiral model than the value-first sequencing typical with Agile methods. Granted, it was always a back-and-forth discussion in the Agile community.

“Breadboarding” seems like a simpler version of User Story Mapping

I’d like to experiment with this.

Standard pitch structure for bets

  1. Problem: raw idea or use case
  2. Appetite: how much time we’re willing to spend on this (i.e., 2 weeks or 6 weeks)
  3. Solution: core elements
  4. Rabbit holes: risks
  5. No gos: what’s out of scope

Avoid interruption within the 6 week bet

This reminds me of no interruption within the Sprint from Scrum.

Fairly small teams

“Shaper” teams seem to be 1–2 people. “Builder” teams are 1 designer, 1–2 programmers, 1 “QA” integration tester used later in cycle.

Layer cakes, icebergs, inverted icebergs

I like this metaphor they used to highlight how vertical slicing isn’t always so straight forward.

  • Balanced distribution of front-end and back-end work is a layer cake.
  • Significantly more back-end versus front-end work is an iceberg.
  • Significantly more front-end work versus back-end work is a reverse iceberg.

“Chowder” list for miscellaneous work

I think the idea behind the name is that if the “chowder” list is longer than 3–5 items, then it’s “fishy” and a “scope” should be created instead.

The hill chart is an interesting way to indicate progress

It’s different. I’ve never seen this in practice and I’m curious how it works in reality.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Yip

Jason Yip

Staff Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl