Basecamp published an online book describing their product development approach, called Shape Up.
My initial thoughts:
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.
They also have “small batch bets” with 2 week cycles. Unclear whether these small batch bets are themselves batched into the larger bet cycle or are more on-demand.
This also highlights the difference between a “project” or “bet” (something that produces a larger outcome) and an “iteration” (a delivery construct to iterate and increment toward that larger outcome). Scrum Sprints used to be equivalent to “project” or “bet” which meant they tended to be longer (4 weeks) but these days, there’s a greater tendency for them to be more the delivery construct.
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.
Shape Up seems to take a similar perspective to Scrum, that is, a manager and design leader perspective, not a team member perspective.
“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.
I reflexively don’t like these kinds of thinker vs doer splits. However, I also recognise being practical with context and skill gaps. I’d feel better if they were more explicit about laddering up capability so that anyone can be a shaper.
I wonder how much of this shaper/builder split was influenced by, or influences, their emphasis on remote work.
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:
- Small batch: 2 weeks
- 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.
Overall the work breakdown approach feels very similar to Extreme Programming with a designer playing the role of Customer.
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.
My preference is a maps and sketches approach. The techniques I’m used to are slightly different but Basecamp’s breadboarding and fat marker sketching feel very familiar.
Standard pitch structure for bets
- Problem: raw idea or use case
- Appetite: how much time we’re willing to spend on this (i.e., 2 weeks or 6 weeks)
- Solution: core elements
- Rabbit holes: risks
- 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.
In XP, the mindset is more “how do I approach work such that interruptions aren’t as disruptive?”
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.
In the imbalanced scenarios, they scope the front-end and back-end work separately rather than together.
“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.
