Shape Up Your Agile

The Basecamp guys have been busy lately. I follow DHH and Jason Fried on Twitter and generally find myself agreeing with their often-contrarian points of view. I love their Guide to Internal Communication, their pushback against insane 80-hour workweeks in It Doesn’t Have to be Crazy at Work … REWORK … REMOTE … Getting Real. This is a seriously impressive body of work.

Shape Up: Stop Running in Circles and Ship Work that Matters, written by Basecamp’s Ryan Singer, hit my radar last summer, and I’ve been trying to write about it ever since.

Before I dig in, let me say that this post includes a number of quotes and several hand-drawn illustrations from Shape Up. All are linked back to their source in the online book and are copyright ©1999-2020 Basecamp.

My problem has been, it’s a big subject, and the deeper I dug, the bigger it got. Big as in a 143 page PDF. Bigger – it speaks to every aspect of the software development process. Biggest – it represents an alternative to All Those Other Agile Methodologies That Everybody Uses.

In the event that the Basecamp guys happen to read this, they might be shrieking and gibbering right now, because they do not, never ever, in any way or sense, describe Shape Up as an “agile methodology.” A case in point: if you search the Shape Up ebook for “agile,” you get one lonely match (in Jason Fried’s Foreword):

Likewise, just one match if you search for “scrum” and “methodology.” In all cases, the point being made is, “Shape Up isn’t one of those!”

So what is Shape Up?

Shape Up is the Basecamp team’s distillation of how they themselves develop software, superbly written and illustrated, freely contributed to the world as an online and downloadable e-book. Shape Up occupies the same territory, serves the same function, as Those Various Agile Methodologies.

Given that almost everybody is doing some kind of agile – formal, informal, sorta-kinda, whatever – it’s worth establish a baseline by taking a quick look at where agile started and what it has become today.

Where agile began

I was managing software development projects at Viant in February 2001 when the Manifesto for Agile Software Development was published. In those days, most software development happened using the lumbering, ultra-heavyweight waterfall methodology. The Manifesto outlined the principles of a radically different approach – far lighter weight, with a far greater emphasis on people and collaboration. The Manifest didn’t invent agile, but rather reconciled a number of existing “light” or “lightweight” methodologies that came into being as a backlash against waterfall.

The Manifesto got our attention, and led to a broad, radical rethinking of the entire software development process, cutting away process overhead and improving the quality of delivery. Agile became a serious, lightweight alternative to the heavyweight incumbent that was waterfall. (If you’re interested in more history and perspective on the Manifesto, I enjoyed this podcast interview of Scott Duncan.)

What agile has become

20 years have passed, and agile has gone from upstart to incumbent. At its worst, “bad agile” has become grotesque, bloated like Dune’s Baron Vladimir Harkonnen, accreting process overhead, cargo cult rituals, pricey certifications, and legions of gurus to help you Do Agile Right$$. One anecdote I heard recently: an agile expert convinced a company to pay him $2K per head to train every single employee in their technology organization in Scrum. The tech organization had over 50 people, but only a third of those were actually developers. Total cost, well over $100K. Result: a couple of limp two-week sprints followed by total regression to the old process.

We had a pretty solid dev process at the music app maker I co-founded, Agile Partners. I guess we fell in the informally agile or influenced-by-agile camp, but it worked – tight, efficient, effective. In recent years when I’ve gone out seeking a fresh answer to, “What’s the best way to do agile these days?” it was like I was on a different planet, nothing even vaguely resembled either the Manifesto or the nimble approach we had applied so successfully at Agile Partners. Going by what I found, modern agile seemed to have been hijacked by expert$ and transformed into a monstrosity with many of the same drawbacks of the old waterfall process that early agile was created to overcome.

Not all agile is bad agile. My friends at the Chicago CTO Group are very smart people, and everyone I’ve spent time with is practicing some form of agile effectively. I wonder, though, whether agile’s accumulated bloat and baggage is forcing these good folks to swim upstream.

Shape Up: a breath of fresh air

When I caught wind of Shape Up and started to read through the book, I had a flood of reactions – “This makes sense!” “Wow, this is a lot like our process at Agile Partners …” “Man, they’ve really thought this through …” “Whoa, what an interesting approach to that problem …”

The Basecamp guys aren’t afraid to take a different path than the herd, and many aspects of Shape Up directly confront (or more accurately, ignore) consensus agile practices. If you practice some form of agile software development today, I’m convinced that it’s very worth putting aside your methodology and process beliefs and read the Shape Up book, cover to cover, with a deeply open mind. When Shape Up follows the road less traveled, there’s a smart reason for it. When Shape Up diverges, that’s an opportunity to reexamine your current processes, ask yourself, why are we doing it the way we are today?

Six-week dev cycle, two-week cool-down

So let’s get right in your face, shall we? Those two-week sprints you’re running today? Forgetaboutit. Shape Up uses six-week cycles instead, with a two-week cool down between cycles. They make the point that two weeks is not enough time to get anything meaningful done, and that the overhead of planning sprints every two weeks just isn’t worth it. I’ve done both, and I side with Shape Up on this one.

In Shape Up, six weeks means six weeks of “leave them alone and let them work” uninterrupted time. When the cycle team (typically one designer and one or two programmers) is handed a piece of work, it comes with that commitment from management. No daily standups, no counting hours, no parcelling out bite-sized tasks, no questioning how time is spent.

Cool-down is used, well, to cool down, to breathe, like after a hard workout. But also for planning the next cycle, fixing some bugs, experimenting, whatever.

The circuit breaker

Dev teams are given a carefully-shaped, de-risked project, and six weeks to build it. In return, the team is expected finish and release the project in that six-week window. This expectation is baked into Shape Up through the circuit breaker: when the six weeks are up, if the project hasn’t finished and released, the breaker pops, work stops, and this project is over. If there’s an appetite for finishing the work, that becomes a new project, and it goes back through same up-front process that any other project does – work-shaping, de-risking, and betting, which we’ll look at shortly. Allowing a project to overrun its deadline is almost unheard of.

Work shaping

Shape Up takes its name from work shaping, and I wouldn’t be surprised if the Basecamp guys put more effort into getting this part of the process right than any other. In work shaping, a small, experienced team defines the key elements of the project, at exactly the right level of abstraction, with enough detail that the dev team knows what to build, but not so much that the team is can’t exercise its skill and imagination in crafting the solution.

Nailing the right level of abstraction

I love Shape Up’s level-of-abstraction principles:

• Wireframes are too concrete
• Words are too abstract

I’m a word guy personally, perhaps because I’m too short of design genes to even do a decent wireframe. But I’ve been burned over and over by trying to define a piece of work using just words; the team just can’t visualize it. And I’ve certainly experienced too concrete as well, when wireframes were part of the project spec, pre-defining the solution and excluding all the great ideas the team might have come up with if they hadn’t been over-constrained. I never did figure out a good system for creating specs with the right abstraction level; kudos to the Basecamp guys for pulling this off.

Nailing the right level of abstraction in the project definition reinforces an idea we introduced earlier: Shape Up dev teams are autonomous, fully responsible for creating the solution, and the project spec supports this.

Properties of shaped work

Besides the right level of abstraction, shaped work has a few other key characteristics:

1. It’s rough. When you look at a shaped project spec (or “pitch”), it’s obvious that it’s unfinished. “Work that’s too fine, too early commits everyone to the wrong details.”
2. It’s solved. The shaping team, a small and very senior group, has put a lot of thought into how this thing works. All the pieces are there, and they connect properly.
3. It’s bounded. Shapers have likewise thought carefully about where not to go, “there be monsters” regions likely to trip up the dev team and derail the cycle.

Note that the shaping team is separate from the dev team(s), and that shaping happens in a completely separate, parallel track from the dev teams’ building track.

Estimating vs. appetite

I’ve talked to lots of CTOs and engineering leads in the past year, and estimating is a sore spot, often turned into an open wound by an overly-rapid sprint cycle. A lot of bandwidth gets poured into agile estimating, with many people using Story Points as opposed to trying to estimate effort directly. Anecdotally Story Points seems to work better, if not very well. Personally, Story Points set off my Voodoo Science alarm.

Shape Up’s approach to the estimating problem is jujitsu – turn the problem on its head – through the idea of appetites.

Every piece of work starts with a raw idea, and with a raw idea in hand, our first step here is to “set the appetite”: how much of an investment is this idea worth? Is it worth a couple of team weeks (what Shape Up calls a Small Batch)? A whole six-week cycle (a Big Batch)? As the book says,

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.

So where an estimate is fixed scope, variable time, an appetite is fixed time, variable scope. Thus appetite (scope) becomes the key constraint that we have to work against as we create our design for this work. It empowers us to make smart trade-offs, both during the shaping process and when building. And unlike Story Points, which to some degree just kick the estimate can down the road to be dealt with later, appetite means we are dealing the scope vs time tension from the very beginning.

What is this thing? Sketching the elements

So, we have a raw idea that we like enough to spend more time shaping; and we’ve established our appetite or scope, say a Big Batch. Now it’s time to circle back to having the right level of abstraction, more abstract and less defined than wireframes, but less abstract than naked words. Here Shape Up introduces two tools that help us spec elements at the right level.

Breadboarding is something electrical engineers do when they want to wire together an early circuit prototype, without the extra work of laying out a PCB or even soldering.

Shape Up breadboards are the same idea applied to software, giving us a fast way to “wire up” affordances, actionable elements like buttons and fields, with places, like screens or dialogs. Here’s an example breadboard diagram from the Shape Up book for an invoice autopay feature – note how nicely this fits between overly-abstract words and over-detailed wireframes:

Fat marker sketches fit the bill when we need to get visual but need to make sure we don’t go overboard and overconstrain by creating a wireframe or high-res mockup. Shape Up defines these as “a sketch made with such broad strokes that adding detail is difficult or impossible.” Here’s a grouped-list example from the book:

Shape Up sketches were originally drawn with Sharpies, but these days are often created on iPads equipped with Apple Pencils.

De-risking

As mentioned earlier, shaped worked is bounded. Once we’ve sketched out the elements of the solution, it’s time to look for trouble, for things that could derail the cycle and cause “failure to ship.” The Basecamp guys again bring a lot of discipline to this part of the process, identifying four tools for de-risking:

1. Looking for rabbit holes, where we slow way down and look carefully for what we might gave missed in what we’ve sketched out, and the patch the hole.
2. Declaring out of bounds, where we identify any parts of the solution that are ripe for an overly-complex implementation, and make clear such an implemntation is out of bounds.
3. Cutting back, a general philosophy of Shape Up: look for parts of our solution that we got excited about during sketching but which really aren’t necessary. Cut them, perhaps mentioning them as “nice to haves.”
4. Presenting to technical experts, if there are areas the shaping team aren’t 100% comfortable with, making it clear that “we’re really hunting for time bombs that might blow up the project.”

Package up a pitch

At this point, our work shaping team has picked up a worthy raw idea, determined what appetite we have for it, sketched it out at the right level of abstraction, and addressed potential risks. If the idea was bad or if there wasn’t an acceptable solution given our appetite, the idea would have been dropped.

So if the idea has survived to this point, we have a winner, right? Not yet. What we have is a viable idea: one with a solution that’s doable within the constraints of our appetite. What we don’t know yet is how this idea compares with the other ideas competing for development resources. That’s where our next topic, betting, comes into play.

So far, our work has stayed mostly internal to the shaping team, and the idea exists mainly in the minds of this team, supported by a few rough sketches and notes. We need something better when we go outside the team, what Shape Up calls a pitch. The pitch needs to help the outside person, who lacks the deep shared context of the shaping team, to understand what this thing is: “help them see it.” Don’t worry, though, pitches aren’t overly elaborate or time-consuming to create; as with all things Shape Up, a pitch is “as simple as it can be, but not simpler.”

Betting instead of backlogs

It’s time again for Shape Up to drive a stake into the heart of another fundamental agile concept, the centralized backlog.

Here’s why:

“Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up …. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.”

“Backlogs are big time wasters …. time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.”

What does Shape Up do instead? A betting table, held during the cool-down period between six-week cycles, where a small list of the pitches we just described are presented as possible bets for the upcoming cycle. Most of the pitches will have been developed by the shaping team during the previous six-week cycle, but a few of the pitches might be ones that had been passed over at past betting tables, and revived for another shot this time.

But … but … but … my lists!

At this point, you may be freaking out … what about my lists? Don’t I need lists? Won’t we lose things? Shape Up isn’t trying to kill lists and tracking things, just the centralized backlog that has to be continually groomed and managed. Decentralized lists are great, keep whatever you need:

“We don’t have to choose between a burdensome backlog and not remembering anything from the past. Everyone can still track pitches, bugs, requests, or things they want to do independently without a central backlog. Support can keep a list of requests or issues that come up more often than others. Product tracks ideas they hope to be able to shape in a future cycle. Programmers maintain a list of bugs they’d like to fix when they have some time. There’s no one backlog or central list and none of these lists are direct inputs to the betting process.”

Still, you might say, if we don’t have our centralized master backlog, don’t we risk losing some really important ideas? No, says Shape Up, important ideas will keep reemerging:

“Really important ideas will come back to you. When’s the last time you forgot a really great, inspiring idea? And if it’s not that interesting—maybe a bug that customers are running into from time to time—it’ll come back to your attention when a customer complains again or a new customer hits it. If you hear it once and never again, maybe it wasn’t really a problem. And if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it in the next cycle.”

The betting table

The betting table is actually a relatively short meeting, likely one or two hours, not necessarily in-person, where a small group of stakeholders choose what gets worked on during the next six-week development cycle. In a smaller company, stakeholders might include the CEO, CTO, and product leadership; in larger companies, whatever level of senior management has 100% decision-making responsibility – it won’t work if the person or persons with final say aren’t at the table. As the book says,

“The highest people in the company are there. There’s no “step two” to validate the plan or get approval. And nobody else can jump in afterward to interfere or interrupt the scheduled work. This buy-in from the very top is essential to making the cycles turn properly.”

All the work shaping team’s efforts – shaping at the right level of abstraction, carefully de-risking, crafting the pitch – pays off at the betting table, putting exactly the right information in the hands of exactly the right decision-makers.

“The meeting is short, the options well-shaped, and the headcount low. When these criteria are met, the betting table becomes a place to exercise control over the direction of the product instead of a battle for resources or a plead for prioritization.”

The betting table is thus a big win for management too:

“With cycles long enough to make meaningful progress and shaped work that will realistically ship, the betting table gives the C-suite a “hands on the wheel” feeling they haven’t had since the early days.”

For more information on the how the betting table meeting works, check out the “Questions to ask” section in the book.

Why the emphasis on “bet”?

Shape Up uses the word “bet” intentionally because the word’s implications fit:

• Bet implies a hoped-for payoff or reward, like an investment. In our case, thinking of green-lighting a project as a bet helps us stay focused on the fact that we are seeking a return on our development investment, as opposed to just filling out schedules with things to do.
• A bet represent a commitment. When you lay down your bet at a casino, there are no do-overs. Likewise, when the betting table green-lights a project, that’s a commitment that the dev team assigned gets six uninterrupted weeks to create the solution.

Bets placed, time to build …

The output of the betting table meeting is assignments for each dev team for the next cycle.

The build phase comes next, and Shape Up serves up an approach to building that’s just as counter-consensus and worthy of your suspended-belief consideration as what you’ve just read. I especially love scope mapping and hill charts.

I plan a Part 2 to cover the build process in Shape Up, stay tuned. Update: here is Part 2: Building with Shape Up.

– Jack Ivers