ShapeUp! Shaping, Betting, and Building
The summary starts with the second step in the method, the story flows better this way,
Betting on a six-week release
Key concepts:
Product and engineering commit to share and mitigate delivery risk (Fix time/effort and vary scope.)
Cross-functional, autonomous teams align to independent technology components, e.g., services, and have end-to-end accountability for feature design, delivery, and production operations.
Phase Overview:
A 6-week release effort is a “bet” matching an “appetite”
An “appetite” is not an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. The appetite is a creative constraint on the design process - to keep it in check, balanced to value.
Language connotes a business risk worth taking - clear customer value at a reasonable price
Needs mutual commitment from tech and product to vary scope and approach to win the bet.
Caps the downside: short enough time to limit the damage if it will cost more than its worth
Provides pressure: long enough time to get something meaningful done and short enough to feel the date pressure
Product shapes the next idea as they support the build process of the current idea.
Shaping
Key concepts:
Shape an idea for a customer outcome to design and build in one release.
Set boundaries, identify risks, and layout a high-level model, not a design, to be elaborated during the build
Pitch the idea to place a bet, i.e., to be chosen to attempt delivery
Start with a raw idea - What problem does it solve? And what outcome gives it customer value? How will we verify they get it?
Shape the idea to fit an appetite, apply design thinking, i.e., it may need to be decomposed, list the constraints.
Set boundaries - how much is enough?
Rough out the elements of the idea at a high level, low-fi, but clear on the outcome. Breadth, not depth — explore options. Leave room for designers, e.g., not a UI spec.
Address risks, and rabbit holes by looking for unintended consequences, unanswered questions, etc. Specify the tricky details.
Get technical review and determine what is out of bounds.
Write the pitch:
The problem to solve, along with the expected customer outcome and verifier.
Our Appetite - how much time is it worth and what constraints does that imply?
The core elements of the solution - not the “answer.”
The Rabbit holes to avoid and risks to deal with.
No-gos - what should the team exclude, things we are choosing not to cover to fit the appetite or make the problem workable.
Building
Key concepts:
Apply design thinking to balance feature design, technical risk, and time to market.
Organize work in the team by application structures (“scopes”) not people. Scopes are independently buildable and testable and may depend on each other.
Do the hardest/riskiest thing early
Product assigns projects, not tasks, and done = deployed
Hand delivery over to the team to build a feature that gets the outcome given the technology and the time available.
Discover and map the scopes, the independently testable and buildable, end-to-end slices that together make up the feature. Use these scopes, e.g., edit, save, send, to show progress.
Get one piece done, a small end-to-end slice to gain momentum within a few days
Start in the middle, with the most novel, risky element. If time runs short, simplify or remove nice to haves or should-haves.
Substance before style - build and verify basic interactions work before focusing on UI styling
Unexpected tasks and opportunities will appear as you go, so know when to stop.
Compare completed work to a baseline, e.g. the customer experience now, not a future ideal.
Use the mutual commitment of 6 weeks to an all-or-nothing release as a circuit breaker to limit the scope.
Commentary
Top takeaways:
- Scopes with automated tests speed development and enable the long run product and organizational flexibility that is central to Amazon, Google, Spotify, etc.
- The “circuit breaker” motivates frequent releases and shared accountability between engineering and product, but may trade-off completeness in the near term.
- ShapeUp is lightweight and has obvious limits. Say you’ve got 48 people across 8 teams and two years of budget to scale up your software. How do you define and coordinate all of that work? Carefully, I assume.
- Shape Up heroically assumes autonomous, cross-functional teams. Which I support wholeheartedly, but you may not have.
The summary leaves a lot out, e.g., large project how-to guidance. Some of it seemed silly, e.g., visualizing status as scopes rolling up and down hills. But, the content is free; you find it here, and I’m not complaining. The scopes concept is central to software development. In fact, outside of the hill thing, there is little to dislike.
ShapeUp is lightweight and has obvious limits. Say you’ve got 48 people across 8 teams and two years of budget to scale up your software. How do you define and coordinate all of that work? Carefully, I assume. It heroically assumes autonomous, cross-functional teams. Which I support wholeheartedly, but you may not have.
A small consultancy doing web development projects for clients created the method, and it fits that like a glove. It can be a great fit for small tech startups until they scale past two or three teams. After that, keep the concepts and solve the next set of problems. Lots of good toolsets out there, LeSS, Scrum, etc.
