Book Review: Shape Up
The second book for our #speakingsoftwarebookbridge project was Shape Up, by Ryan Singer. It’s a refreshing look at the Software Delivery Process that is sure to inspire, and hopefully accelerate your feature output!
Intro
I'm going to be 100% honest: I like this book. A lot.
Coming from a Software Leadership background, I welcome any-and-all advice and techniques for streamlining getting features into customer's hands. This book is chock-full of great lessons, learned from real-world experience. The lessons came from building Basecamp as it scaled from 4 to over 50 people, over the course of over 12 years (2003-2015+). Ryan used tight feedback loops to develop a fixed methodology to be able to consistently deliver to a high standard.
And the results speak for themselves! Basecamp and 37 Signals have become overwhelmingly successful. But what makes their unique process so damn good though?
Tell the nice man where it hurts
I come from a strong agile, 2-week-sprint background. As I've progressed to and through leadership, I feel like there's WAY too much time spent on managing the sprint and task flow, instead of focusing hardcore on delivery. And I know that I'm not the only one!
Indeed, Sprint Planning, Sprint Kick-offs, Mid-sprint check-ins, End-of-Sprint demos, etc. - all tied in lock-step with a 2-week release process, can be overwhelming. If the Release is delayed, and/or the sprint cadence is disturbed - things get real weird really quickly. And good luck managing features that take multiple sprints to complete!
Sprints come relentlessly (26 per year), with no breaks. There's a battle to get maintenance, refactoring and clean-up tasks in - with non-critical changes often being pushed out for multiple sprints. The general feeling with with this kind of flow is that it's a "feature-factory" - just shooting features off of a conveyor belt. The management around this leaves little time to get feedback from deliverables, perform progressive enhancements on features, or create/use agility to be able to pivot.
MANY Software Engineers that I know and have worked with have all expressed dissatisfaction with this approach, but generally any conversations around the delivery methodology devolve into AGILE WORKS and WATERFALL SO OUTDATED UGH. It's nice to see a 3rd option that makes sense.
This book aims to be not only that 3rd option, but also the better of the 3 - with no certification to purchase, no masters, nor tiring ceremonies required!
The 3-Step Rocket
The Shape Up! book educates the reader on it's unique strategy - divided into 3 parts to represent 37Signal's end-to-end process for feature delivery. Those 3 parts are:
Shaping
Betting
Building
Shaping is your scoping process. A 'pitch' is created - effectively a mixed functional and technical spec to explain how to institute a desired feature or change. Instead of estimates, these changes are dropped into 1 of 2 buckets. Small change (1-2 weeks) or big change (6 weeks).
Building is then implementing said features/changes, and leaving yourself some wiggle room to play with the scope as progress ebbs and flows. "Fixed time, variable scope" is the mantra! You'll also deploy/release at the end of the building process. A building round normally takes 6 weeks.
Sandwiched by Shaping and Building is the Betting Stage. Betting is deciding if the pitch is worth implementing in the next round of building. Owners argue their case, and all stakeholders review and decide.
If it wins - great, that's what will be built in the immediately following building round.
If not, well - not all pitches make it to production! Off to the bin! We'll touch on this later on...
Shaping and Building rounds are 6 weeks long, and there's a 2 week break to cool-down between each one. That means 6 cycles per year, with some spare-change days to account for end of year holidays. The 2 week break is used for maintenance, bugs, updates and of course: the betting meeting(s) to see what happens in the next building round.
The working premise is that small team(s) shape, as another team(s) build in those 6 week rounds. Shapers and builders are given time to focus and dedicate to their tasks. Unless there is a P1 incident they are not pulled away or interrupted from their task.
That's the jist of it! It's so mind-boggling simple and beautiful that you have to marvel for how it's not more widely known and adopted. It's very start-uppy, very fresh and plenty of wiggle room to:
Drive development at a sustainable, high-quality pace
Allow talent within the team to emerge
Account for mishaps, as scope is always variable.
Pitches be wild
Actually that heading is untrue. Pitch building has some nice rules to make sure that what's delivered bring value.
Each pitch should be focused and shaped around a problem or use-case. That use-case needs to be interrogated in order to REALLY understand the pain point behind it. The initial raw idea to solve that pain point may not be the final one, so it's important to understand the root cause so you're not just treating the symptoms.
There's also clear direction to stay away from redesigns, refactoring, 2.0s and other revision/misc items that are not driven by a single problem or use case. The definition of done can be very subjective in those cases, and you really want a clear end goal.
Side note: this directly links back to "Code that fits in your head", where a driver is what directs changes in the code base.
Another thing that I like about the pitch shaping approach is no wireframes. Instead of drowning in Figma revisions, shapers are encouraged to use "fat-marker" sketches to illustrate abstract UI ideas. Ideas need to be at a loose level of abstraction; let the builders wireframe it out later.
Put it all on red!
Betting is short and cut-throat. Ideas are either accepted or rejected. Rejected ideas are discarded. They don't go into a team backlog or archive. The teams are released from the burden and mental overhead of managing (or drowning in) a backlog.
You might panic reading that, but is that really such a bad thing? Instead of trotting out the same old horses to each track-meet, wouldn't it be better to always have a fresh conversation? Good ideas don't disappear, and they can be reshaped and re-contextualized to come back in another betting round. The betting round every six weeks will always be in-step with the current needs of the business.
Sub-teams (Product, Support, DevOps, etc.) can keep track of their own lists of things to do, and bring shaped pitches for those to the Betting Meetings. People from those departments can then advocate (or fight) for solutions to their current issues. There's no central list, and no one list is an input into the betting process. Every team brings their best ideas to the table each time.
The important thing to note about the betting process is that the team/dept is indeed BETTING. They're betting on:
the building team delivering most/all of the pitch
that the 6 committed, uninterrupted weeks of work will produce something stable and of business value
If the bet hasn't work out, then the 'loss' is 6 weeks. Which in reality isn't really that bad. There are many large enterprises that have projects scrapped after years.
Bets don't get extensions either. It's all or nothing. If while building it's discovered a pitch needs more than 6 weeks; that means something key was missed at the shaping stage, and the whole pitch needs to be reviewed and re-bet upon.
Build it and they will come
Winning pitches are handed-over to the building team, and after a brief kick off they take full ownership. They get the project - not a task list. It's up to the builders to self organize and spend some days figuring things out, discovering/imagining tasks and getting their figurative shit together.
From there it's a piece-by-piece implementation. Shape Up! advocates for building a slice at a time that works end-2-end. Build up working slices to end up with a perfect pizza / feature.
The benefits of working in this way is 2-fold:
Something immediately works, and you're not waiting for all threads to align at the 11th hour to be able to show everything working E2E.
As time passes and the release date draws nearer, slices can be selectively omitted so that a viable release can still happen. Fixed Time, Variable Scope.
Progress Reporting
If daily scrums are banned, teams self-organize, manage their own task lists and squirrel away for 6 weeks - how do leadership know how they are doing?
Task lists ebb-and-flow. Imagined tasks at the start of a round get replaced with discovered tasks as time goes on. Just getting a % of tasks done doesn't accurately reflect that actual % of work done of the implementation. There's never a 1:1 of tasks and code implementations. Enter the hill chart!
Hill charts are visual metaphors for where a feature is on the road to completion.
The uphill represents the discovery process. Figuring out what to do, what code will change, and what needs to be added
The downhill represents the execution - actually going and getting shit done.
With a hill-chart, you're effectively showing progress shifting from the unknown, to the known and finally to done. It's so simple that it needs no interpretation or analysis.
If you can take nothing else from this book, this is probably the one thing you can take and implement right away.
Pros:
Crystal clear examples. Real world feature use-cases are shown and explored, so you really understand how the process works at a macro and micro level.
Multiple options for how to implement and adjust this process in your team.
Deeper questions (where does this go? what do I do about X?) all get addressed in a timely fashion.
Hill Charts!
Very casual text - a fun read, and nothing stuffy or boring. Probably the most exciting and inspiring software delivery process book you'll ever read.
Free to read online and download
Summary
Even if you have no intention of moving away from your flavor of agile, lean, safe, waterfall, whatever - you still need to read this book. There's a lot of great insight and wisdom into why projects either sink or swim, as well as a worthy remedy.
This book will also cause you to think about your current process, and inspire you to take a harder look at the pain points and how to address them.
Highly recommended!