Executive Summary of Shape Up

Shape Up! Shaping, Betting, and Building

Shape Up is a lightweight software delivery method targeting start-ups and smaller software organizations. It has some powerful concepts that work, is free, and is supported by a product called Basecamp. This article summarizes the method, adds a bit to it here and there, and provides commentary. I hope you enjoy it. 

Shaping

Key concepts:

• Shape an idea for a customer outcome to design and build in one six-week 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.
• This pitch is like the one- and six-page narrative format Amazon uses for almost all internal efforts.

Phase Overview:

1. Start with a raw idea - What problem does it solve? And what outcome gives it customer value? How will we verify they get that customer value?
2. Shape the idea to fit an appetite, apply design thinking, i.e., it may need to be decomposed, list the constraints.
3. Set boundaries - how much is enough?
4. 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.
5. Address risks, and rabbit holes by looking for unintended consequences, unanswered questions, etc. Specify the tricky details.
6. Get technical review and determine what is out of bounds.
7. 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-go's - what should the team exclude, things we are choosing not to cover to fit the appetite or make the problem workable.

Betting on a six-week release

Key concepts:

• Product and engineering commit to share and mitigate delivery risk (fix time/effort, vary scope, and focus on fast business feedback)
• 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.
• These concepts/principles underly many successful software organizations including Spotify, Amazon, and Google.

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 and balanced to value.

1. Language connotes a business risk worth taking - clear customer value at a reasonable price
2. Needs mutual commitment from tech and product to vary scope and approach to win the bet.
3. Caps the downside: short enough time to limit the damage if it will cost more than it's worth
4. 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.

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
• These concepts draw heavily on Extreme Programming, XP principles

Phase Overview:

1. Product assigns projects, not tasks, and done = deployed
2. Hand delivery over to the team to build a feature that gets the outcome given the technology and the time available.
3. 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.
4. Get one piece done, a small end-to-end slice to gain momentum within a few days
5. Start in the middle, with the most novel, risky element. If time runs short, simplify or remove nice to haves or should-haves.
6. Substance before style - build and verify basic interactions work before focusing on UI styling
7. 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:

1. Scopes with automated tests speed development and enable the long run product and organizational flexibility that is central to Amazon, Google, Spotify, etc.
2. The “circuit breaker” motivates frequent releases and shared accountability between engineering and product but may trade-off completeness in the near term.
3. 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.
4. Shape Up heroically assumes autonomous, cross-functional teams. Which I support wholeheartedly, but you may not have.

More generally, the concepts are excellent and apply outside this lightweight method. I’m guessing most who use it would also sprinkle in some Scrum. This approach begs for XP practices. Scopes are natural outcomes of TDD and BDD.

This executive summary leaves a lot out, e.g., large project how-to guidance. Some of the guidance 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.

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 that help you and solve the next set of problems. Lots of good toolsets out there, LeSS, Scrum, etc.