Shape Up
Notes and Quotes
Stop Running in Circles and
Ship Work that Matters
by Ryan Singer
An agile approach to product development, from the creators of Basecamp, that seems easy to understand and follow, mostly oriented to build certain types of products: Medium sized products / medium sized teams, able to manage continuous customer feedback.
Overview of Main Ideas
Six week cycles
Each team should find this, but for medium sized teams, six weeks seems good enough to build something you can show and test, also it helps building a sense of urgency on the deadline.
Shaping the work
There is a “shape” time, done by a small group, this shaping process happens in parallel with the actual building (coding) process. People involved in shaping it’s not involved in coding (in the same cycle).
Shaping means defining the work to be done with the right level of abstraction:
… the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.
Make teams responsible
A team owns a slice of the product.
…work together to build vertical slices of the product one at a time.
Targeting risk
Risk gets reduced in 2 ways:
-
During Shaping process (addressing open questions).
-
Capping the bet to a six weeks cycle (this is the “circuit breaker”), if a project needs more time, it does not get the extension, instead it is considered to be “rethink”.
Principles of Shaping
Wireframes are too concrete.Words are too abstract.
Properties of Shaped Work
-
It’s rough: Not many details
-
it’s solved: All elements of the solution are visible, including their connections.
-
It’s bounded: Shaped work shows what to do, and also what not to do.
Who shapes? Someone that knows about the business, has tech skills and knows how to build interfaces.
Two tracks on the same cycle
One part of the team is building some previously shaped work, and the other part is shaping what’s next. Both tracks are separated, and happening at the same cycle.
Steps to shaping
-
Set boundaries: Sets appetite and define what is (and what is not)part of the solution.
-
Sketch a (rough) solution: Breadboard, showing elements and their connections.
-
Address risks and rabbit holes: Look for any assumption that may not be clear enough and may need some investigation. Cut back not necessary parts. Check with technical experts.
-
Write the pitch
The pitch summarises the problem, constraints, solution, rabbit holes, and limitations.
Made with https://mural.co/
Setting the Appetite
Define “how much time this deserves”, assuming fixed time but variable scope. This is a different take on estimates. Appetite usually comes to 2 sizes:
-
Small Batch: Part of the team/part of the cycle
-
Big Batch: All team / the whole cycle
We can only judge what is “good” solution in the context of how much time we want to spend and how important it is.
To narrow down the problem we should stop asking “What could we build?” and start asking “What is really going wrong?”. Appetite will also tell how much research is worthwhile.
What is included in the Pitch
-
Problem
-
Appetite
-
Solution
-
Rabbit holes
-
No-gos
Bets (no backlogs) and the Betting Table
Once the Pitch is ready, it goes to the Bet. Before each cycle, there is a Betting Table where a set of pitches is discussed by a small group. This group decides what pitch must be addressed in this new cycle. This bet is then honored by bringing team uninterrupted time, starting whit a clean slate (not carrying stuff from the previous cycle).
Decentralised lists: … Support can keep a list of requests … Product track a list of ideas … Programmers maintain a list of bugs … There is no one backlog or central list and none of these lists are direct input to the betting process.
Questions to ask during the Betting Table:
-
Does the problem matter?
-
Is the appetite right?
-
Is the solution attractive?
-
Is this the right time?
-
Do we have the right/skilled people available?
Cool-down
Happens after a six-week cycle. Can be used to fix bugs, or try new tech ideas. It is also used to run the Betting Table.
What happens after shaping/betting?
Assign projects, not tasks
Nobody plays the role of the “taskmaster” or “the architect” who splits the project up into pieces for other people to execute. … The team is going to do their own tasks and their own approach to the work. They will have full autonomy and use their judgment to execute the pitch as best as they can.
DONE?
Done means deployed
QA?
The project needs to be done within the time budgeted; otherwise, our appetite and budget don’t mean anything. That also means any testing and QA needs to happen within the cycle.
This process assumes developers take responsibility for the basic quality of their work. And QA can limit to edge cases.
We don’t depend on QA to ship quality features that work as they should. QA generates discovered tasks that are all nice-to-haves by default.
Discovering scopes down the road
The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time — a few days or less. They are bigger than tasks but much smaller than the overall project. Three signs indicate when the scopes are right:
- You feel like you can see the whole project and nothing important is hidden.
- Conversations about the project become more owing because the scopes give you the right language.
- When new tasks come up you know where to put them.
Beware of Icebergs
When there is much more frontend work than backend work (or vice versa) we have an Iceberg.
For both backend and frontend, we always question them before accepting them as a fact. Is the complexity really necessary and irreducible? Do we need that fancy UI? Is there a different way to build that backend process so it has fewer interdependencies with the rest of the system?
Showing progress
Estimates don’t show uncertainties.
Showing status with the hill chart
The hill chart is a tool to show “where we are”. Uphill is about the unknown, so we are investigating here. Downhill is about the known, so we are implementing the solution here.
For a given project, comparing the current hill chart with the previous one will give a concrete and clear status. Uphill (unknown) may not be easy to estimate, but Downhill (known) should be.
When is it good enough?
- Compare to baseline instead of an ideal.
How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? … It’s the difference between “never good enough” and “better than what we have now.”
Cutting scope
Making choices makes the product better.
Scope Hammering
This separates must-haves from nice-to-haves.
Is this a “must-have”? Could we ship without this? What happens if we don’t do this? Is this a new problem or a preexistent one? How likely is this case or condition to occur? When this case occurs, which customers see it? Is it a core or an edge case?
The overall process and how the concepts fit
The following charts show the main concepts, their connections, and where they are placed.
How the two tracks work together
Made with https://mural.co/
The Build Track
Made with https://mural.co/
The Shape Track
Made with https://mural.co/