Last week Ryan Singer, Head of Product Strategy at Basecamp, released a web-book called Shape Up: Stop Running in Circles and Ship Work that Matters. In it, he outlines the unique process of product development they've developed over the past 15 years to ensure their small team is always shipping impactful product changes. Here are the 5 summary points I took away:
Source: Basecamp Shape Up web book
Unlike Agile processes where the team breaks a large body of work down into smaller sprint-sized chunks and starts to build them, Basecamp's process instead holds fixed the time to release a chunk of work to customers and focuses on "shaping" work into that time period. Big bodies of work take 6 weeks for a small team (1 designer and 2 engineers), while smaller ones take 2 weeks with the same size team (in that case, the team takes on 3-5 smaller bets to fill the 6-week cycle).
To me, the most interesting aspect of this is focus - teams are not asked to juggle multiple things simultaneously but instead are asked to swarm a project together and give it their undivided attention to see it through to completion. I saw the value of this first hand during "Innovation Sprints" we ran at HelloWallet / Morningstar - in a week, small teams of engineers and designers would do amazing things like build an entire mobile app from scratch. Yea, maybe it wasn't production-ready but I'm pretty sure the ability to focus on a single task for a week had something to do with their pace.
(Of note, there are no product managers at Basecamp - a few team leads / execs prioritize the work through shaping and betting, and individual project teams are held accountable for delivering during their build cycle.)
The pitch is a document that includes 5 ingredients:
Source: Basecamp Shape Up web book
Ryan kindly includes a couple of example pitches in the book.
Rather than work off an always-growing backlog, Basecamp cleans the slate every cycle and only considers a handful of pitches as candidates for the next build cycle. Each team keeps a list of the work they'd like to bet on themselves, and it's up to them to revive old ideas and bring them to the betting table / rationalize why they should be reconsidered.
Of note, none of the pitches are discussed with build teams unless it's decided the bet is going to be made. This way, you avoid distracting people with ideas that aren't prioritized.
Source: Basecamp Shape Up web book
Perhaps my favorite concept is how they communicate the status of a project mid-cycle. Ryan uses this hill analogy - when you're at the bottom of the hill, you have a lot of hard work ahead of you to get up the hill. But once you're at the top, coming down the other side is much easier. Similarly, the uphill tasks with software projects involve understanding the problem and shaped bet, then breaking up the work. The downhill tasks are to do the work identified.
Basecamp extends this analogy and visual into their product so stakeholders can get status reports without bothering the project team. The project team spends the first few days breaking the shaped bet into chunks of work, and updates the status in Basecamp to show where each chunk of work is on the hill:
Source: Basecamp Shape Up web book
In the example above, the project had 3 "scopes" (chunks of work), represented by the 3 dots on the hill. It's clear the team is still figuring out the Future-Applying Edits UX, the Global Recurring Events is almost done and Permas per Occurence is in-progress. The circle in the top left shows that the bet includes just these three chunks of work (that is, there's nothing left to do after these 3 are done).
Ryan makes a point of how most teams split work up by person / role, rather than how the work should be organized to make progress towards the final deliverable (shippable code, in this case). He has some great visuals to show why splitting the work up between front-end and back-end changes without coordinating efforts isn't helpful in reducing risk or making progress.
Source: Basecamp Shape Up web book
There are some key concepts I love about this process:
However, there are some parts of this process I could see existing product teams struggling with:
Ready to try the Shape Up process at your company? Get our tips on roadmap execution!