Shape Up
Stop Running in Circles and Ship Work that Matters
By Ryan Singer
“Beware the simple question: ‘is this possible?’ In software everything is possible but nothing is free.”
What is this book?
Ryan Singer is a software developer and product designer who has worked at companies including Basecamp. The book is a guide on how Basecamp approaches product development.
Six-Week Cycles
Basecamp runs on cycles of 6 weeks vs shorter sprints.
Six weeks is long enough to build something meaningful start-to-fish and short enough that everyone can feel the deadline looming from the start…We don’t rethink our roadmap every two weeks. We say to ourselves ‘If this project shifts after six weeks, we’ll be really happy’. Then we commit this six weeks and leave the team along to get it done
Shaping the Work
Alongside the six week cycles, a small senior team is responsible to shape the work. This shaping involves the team defining the key elements of a solution with this being at level of abstraction which is “concrete enough that the teams know what to do, yet abstract enough that they have the room to work out the interesting details themselves”.
When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? … designing the outline of a solution that fits within the constraints of our appetite
Making the teams responsible
Ryan outlines how full responsibility is given to small integrated teams of designed and programmers. A high level outline is passed to the teams and they work together to build vertical slices. They do not have managers chop up the work and programmers take tickets. As a result, Ryan argues that managers spend less time managing tickets and more on shaping better future projects
How does shaping work at Basecamp?
Shaping has four main steps:
- Set boundaries – how much time is this idea worth and what is the problem being solves?
- Rough out the elements – a rough drawing solving the problem within the appetite but without the finer details
- Address risks and rabbit holes – take a hard look at the proposed solution and identify risks, cut things out or specify certain details
- Write the pitch – Finally, the person working on the shaping will right up a formal pitch. This pitch then goes to the betting table for consideration.
Always starting with an appetite
A recurring idea is present throughout the entire book which is to always start with an appetite for an idea before doing anything else as it dictates how you proceed on designing and developing the solution.
Fixed Time, Variable Scope
This principle called “fixed time, variable scope” is key to successfully defining and shipping projects…We apply this principle at each stage of the process, from shaping potential projects to building and shipping them. First the appetite constraints what kind of solution we design during the shaping process. Later, when we hand the work to a team, the fixed time box pushes them to make decisions about what is core to the project and what is peripheral or unnecessary.
“Good” is relative
There’s no absolute definite of “the best” solution. The best is relative to your constraints. Without a time limit, there’s always a better version….We can only judge what is a “good” solution in the context of how much time we want to spend and how important it is”
Bets, Not Backlogs
Basecamp doesn’t do backlogs viewing them as a big weight or work that never gets done giving people a feeling of always being behind. What do they do instead?
Before each six-week cycle, there is a better table where stakeholders decide what to do in the next cycle. Pitches from the last six weeks are reviewed and then decided upon with a cycle containing small bets and large ones.
Bets are commitments
When a bet has been made, the team is simply left to just focus on this bet and nothing else.
When people ask for “just a few hours” or “just one day,” don’t be fooled. Momentum and progress are second-order things, like growth or acceleration. You can’t describe them with one point. You need an uninterrupted curve of points.
Vertical Slices
Ryan makes to point to think about work vertically. Instead of teams working horizontally with the backend being made, separate from the front-end and then all coming together at the end, Ryan proposed to work vertically in order to get a true end to end view of whether the idea works.
So instead of working on the entire project separately, teams will pick off one slice of the project and integrate it completely vertically.
Stay debt-free
Ryan makes the point that the answer to all requires should be a gentle “no”. If you respond right away you having given enough time to shape the idea and really decide whether its worth placing a bet on.
Saying “no” doesn’t prevent your from continuing to contemplate them and maybe shape them up in future projects. Saying “yes” on the other hand, takes away your freedom on in the future. It’s like taking on debt.
Ryan treats bugs like any other work, they can be brought to the betting table and vie for time as per other projects.
Bugs
The question is posed about how you deal with bugs during a six week cycle. Ryan makes the point that there is nothing special about bugs that make them automatically more important than everything else. All software has bugs. If they are critical then they must be solved right away, otherwise they can wait.
Cool Down
After every six week cycle, there is a 2 week cool down period where people can clean up code, fix bugs, try new ideas out etc. before another cycle starts.
