Ryan Singer has documented Basecamp product development and delivery methodology in the ebook Shape Up – Stop Running in Circles and Ship Work that Matters. Shape Up describes Basecamps process of taking raw ideas, working through a shaping process to narrow to a core problem, remove any unknowns / risks / deep rabbit holes, add project boundaries, prefer appetite over estimates, create a pitch, bet on the work with a six week build cycle, and handover the work to a small, empowered build team to discover the work through doing, building scopes of work, communicating progress through Hill Charts, use scope hammering and working in small vertical slices in a continuous delivery mindset, attacking the most unknown / riskiest work early in the six week product development cycle.
Key Messages:
- Use a shaping process to define & validate a problem, to address any unknowns or risks
- Focusing on appetite instead of estimates
- Prefer bets, not backlogs
- Bet on a six week cycle with a circuit breaker at the end
- Small empowered teams owning cycle outcomes
- Deliver small vertical slices of the problem space
- Build has two distinct phases – discover and validate (uphill), and known / execute (downhill)
- Scope will grow as the delivery team learns more about the space, continuously hammer scope to deliver on six week commitment / cycle.
Please see below my notes / snippets (copied from Shape Up ebook without permission), you can download a free copy of Shape Up from basecamp: https://basecamp.com/shapeup/shape-up.pdf.
Notes
Six week cycles
- Strict time box, acts as a circuit breaker, by default no extension.
Shaping the work
- Senior group works in parallel to cycle team – focused on appetite (how much time do we want to spend)
Team fully responsible
- Making hard calls to finish the project (cycle) on time
Targeting risk
- The risk of not shipping on time. Solving open questions before we commit to a cycle. Build vertical deliverables, integrate early & continuously, sequence most unknown work first.
Part 1 Shaping
Wireframes are too concrete (give designers no room / creativity – design anchored)
Words are too abstract (solving a problem with no context, hard to understand scope & make tradeoffs)
Good Shaping:
- Its rough
- Its solved
- Its bounded
Shaping is kept private (closed door) until commitment to a cycle is made
Two work tracks (cycles)
- -> One for shaping
- -> One for building
6 week cycles, shaping leads into building:
Shaping 1 | Shaping 2
————-> Building 1 | Shaping 3
————————–>Building 2 | Shaping 4
—————————————> | Building 3
—————————————————-> | Building 4
Appetite
- Small batch (one designer, one or two programmers for one or two weeks)
- Big batch (same team size, 6 weeks)
Fixed time, variable scope: An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design
Analyse a customer problem – we asked when she wanted a calendar. What was she doing when the thought occurred to ask for it?
Breadboarding
Use words, or fat-marker visuals to achieve.
Iterate on original idea
Fat marker visuals
- Avoid getting into a high level of fidelity, or into the weeds
Do stress-testing and de-risking (find deep holes and challenges which could hinder)
The Pitch
Prefer pitches to be asynchronous communication – i.e. give people time to review offline in their own time, only escalate to real-time when necessary (i.e. meeting with key stakeholders) and give notice in advance
People review pitch and add comments (i.e to poke holes / ask questions – not to say no to the pitch, that’s for the betting table)
Part 2 Betting
Bets, not backlogs – big backlogs are a big weight we don’t need to carry. Backlogs are big time wasters – constantly reviewing, grooming and organising.Each 6 week cycle, a betting table is held where stakeholders decide what to do in the next cycle – containing a few well shaped, risk reduced options; the pitches are potential bets
- If a pitch was great, but the time wasn’t right (there is no backlog), individuals can track the pitch independently and lobby for it again six weeks later
Its easy to overvalue ideas – in truth ideas are cheap – don’t stockpile or backlog. Really important ideas will come back to you.
6 Week Cycle
Cool Down
After every 6 week cycle, we schedule two weeks for cool down. This gives leaders enough time to breath, meet and consider what to do next and programmers and designers are free to work on whatever they want (i.e. fix bugs, explore new ideas, try out new technical possibilities).
Project teams consist of one designer & two programmers or one designer & one programmer (normally). A team spending an entire 6 week cycle is called the big batch team, and the team working on small projects (1-2 weeks) is called the small batch team.
The output of the betting meeting is called a cycle plan.
The cycle plan is a bet with a potential payout at the end of the cycle.
Cycles are dedicated commitments – uninterrupted time for the team to focus. The team cant be pulled away to work on something else. When you make a bet, you honour it.
- “When you pull someone away for one day to fix a big or help a different team, you dont just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong. Hour can kill a day. Losing a day can kill a week.”
We only plan one cycle ahead, and can always introduce critical work in the next cycle. If it’s a real crisis, we can always hit the breaks – by true crises are very rare.
Having a fixed 6 week cycle without any potential for increased time acts as a circuit breaker, preventing runaway projects and projects which overload the system. If a project doesn’t finish in the six weeks, normally means a problem occurred in the shaping phase – perhaps time to reframe the problem. “A hard deadline and the chance of not shipping motivates the team to regularly question how their designs and implementation decisions are affecting scope”
What about bugs: Unless its a P1/P2 (i.e. a crises) they don’t naturally get priority over existing planned work, they can wait. This is how we address bugs:
- Use cool-down period
- Bring it to the betting table
- Schedule a bug smash (once a year, usually around holidays – a whole dedicated cycle to fixing bugs)
For projects larger than a 6 week cycle, we shape them (break them down) into 6 week cycle and only bet 6 weeks at a time.
Place Your Bets
- Depending on whether we’re improving an existing product or building a new product, were going to set different expectations about what happens during the six week cycle.
- Existing Products – Shape the work, bet on it, build.
- New Products – broken into three phases:
- 1. R&D mode: Learn what we want by building it (time boxed spikes, learn by doing), no expectation of shipping anything.
- 2. Production mode: Shape the work, bet on it, build. Shipping is the goal (merging to main codebase), however not necessarily to end customers yet so we maintain the option to remove features from the final cut before launch
- 3. Cleanup mode: A free for all, reserved capacity to finish things, or address things forgotten, bugs etc, no shaping, no clear team boundaries with work shipped continuously in as small bites as possible. Leadership make “final cut” decisions with cleanup not lasting longer than two cycles.
Examples
Betting table questions & debates
- Does the problem matter?
- Weighing up problems (options) against each other
- Can we narrow down the problem (Pareto – 80% of the benefit from 20% of the change)
- Is the appetite right (do we want to spend $xxx / weeks / cycles on this problem)?
- Is the solution attractive?
- Is it the right time?
- Are the right people available?
After the betting table has finished, a kick-off message is posted on which projects we’re betting for the next cycle and who will be working on them
Part 3 Building
Assign projects, not tasks. Nobody plays the role of “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.
Team defines their own tasks and work within the boundaries of the pitch.
Team have full autonomy and can use their judgement to execute.
Done means deployed. All QA needs to happen within the cycle.
A Basecamp project is created, chat channel and kickoff call.
First two – three days is radio silence from the team as they dive deep into the details and get aquatinted with the problem.
Team starts of with an imagined tasks, and through discovery learn about the real tasks to complete. Teams discover by doing the real work.
Integrate one slice
Pick a small slice of the project (ie design, backend & front end coding) to deliver end to end to show progress and gain feedback
Start in the middle
Start at the core of the problem (ie core screen and adding data to a database) and stub everything else out, rather than at the entry point (i.e. logging in). When choosing what to build first:
- It should be core
- It should be small
- It should be novel (things you’ve never done before, address risk / uncertainty)
Organise by structure, not by person
Allow teams to self organise around a problem, understand the scope, form a mental image, breaking down into parts that are no longer than 1-2 days effort – a series of mini scopes.
Scopes become the natural language of the project at the macro level. It will help communicate status and progress.
Scoping happens over time as the team learns (not necessarily all up front); You need to walk the territory before you can draw the map. Scopes need to be discovered by doing the real work; identifying imagined vs discovered tasks and seeing how things connect (and don’t connect).
How do you know if you have scoped right?
Usually takes a few weeks to get a clear understanding of scope
A typical software project is split into cake layers (front end & backend work, thin slices). Watch out for icebergs, which can see a lot more back end or a lot more front-end work; look to simplify, reduce the problem and/or split these into seperate projects.
There will always be things that don’t fit into specific scope buckets, we refer to these tasks a chowder.
Mark tasks which are nice to have with a leading ~ to identify nice-to-haves (to sort out from must-haves).
Show Progress
We have to be cautious if big up front plans – imagined tasks (in theory) vs. real tasks (in practice).
As the project progress, to-do lists actually grows as the team makes progress (making it very hard to report progress of an imagined up front plan).
The problem with estimates is they don’t show uncertainty (or confidence level).
- If you have two tasks, both estimated to take four hours:
- the team has done task 1 many times and you can be confident in the estimate
- The team has never done task 2 or it has unclear interdependencies (lots of unknowns) is uncertain and a low confidence estimate
We came up with a way to see the status of a project without counting tasks and without numerical estimates – by shifting the focus from what’s done or not done to what’s unknown and what’s solved. We use the metaphor of the hill.
The uphill phase is full of uncertainty, unknowns and problem solving (ie discovery). The downhill phase is marked by certainty, confidence, seeing everything and knowing what to do.
A dot that doesn’t move over time is a red-flag, someone might be stuck and need help (the Hill Chart identifies this without someone needing to say “I dont know / I need help”). Changes languages and enables managers to help by asking “what can we solve to get that over the hill?”. A non-moving dot can also indicate work is progressing well, but scope is significantly increasing with discovery, the team can break scope apart into smaller scope or redefine / reshape the problem.
Sometimes tasks backslide, which often happens when someone did the uphill work (i.e. discovery) with their head (i.e. imagined) instead of their hands (practice). Uphill can be broken into three tasks:
- “I’ve thought about this”
- “Ive validated my approach”
- “I’m far enough with what I’ve build that I don’t believe there are other unknowns”
Teams should attack the scariest / riskiest scope first within the cycle (given more time to unknown tasks and less time to known tasks).
Journalists have a concept called the inverted pyramid, their articles start with the most essential information at the top and add details and background information in decreasing order of importance. Teams should plan their work this way too.
Deciding when to stop
There’s always more work than time. Shipping on time means shipping something that’s imperfect.
Pride in work is important for quality and morale, but we need to direct it at the right target. If we aim for perfect design we’l never get there, at the same time we dont want to lower our standard.
Instead of comparing up to an ideal, compare down to a baseline – seeing work as being better than what customers have today – “its not perfect, but it works and is an improvement”.
Limits motivate trade-offs, with a hard six week circuit breaker forces teams to make trade-offs.
Cutting scope isn’t lowering quality. Makes choices makes the product better, it differentiates the product (better at some things).
Scope Hammering
Quality Assurance
Base camp (for millions of customers), have one QA person. The designers and programmers take responsibility for the basic quality of their work and the QA person comes in towards the end of the cycle and hunts for edge cases outside the core functionality. Programmers write their own tests and team works together to ensure the project does what it should according to what was shaped.
We think of QA as a level up, not as a gate or check point.
The team can ship without waiting for a code-review, there’s no formal checkpoint. But code review makes things better, so if there’s time, it make sense.
When to extend a project
In rare cases we’ll allow a project to run past its deadline / cycle and use the following criteria:
- The outstanding tasks must be “must haves”
- The outstanding tasks must be all “down hill” – no unsolved problems, no open questions.
The cool down period can be used to finish a project, however team needs to be disciplined and this shouldn’t become a habit (points to a problem with shaping or team performance).
Move On
Shipping and going live can generate new work – through customer feedback, defects and new feature requests.
With customer feedback, treat as new raw ideas which need to go through the shaping process.
- Use a gentle no (push back) with customers until ideas are shaped and problem verified. If you say yes to customer requests, it can take away your freedom in the future (like taking on debt).
Feedback needs to be shaped.
Summary
As base camp has scaled to 50 people, we’ve been able to specialise roles:
- Product team (12)
- Specialised roles of designers and programmers
- Dedicated Security, Infrastructure & Performance (SIP) handles technical work, lower in stack and more structural
- Ops team (keep the lights on)
- Support team
With this structure, we don’t need to interrupt the designers and programmers on our core product team working on shaped projects within cycles.
