Building with Shape Up

This is the sequel to my post Shape Up Your Agile, about the book Shape Up: Stop Running in Circles and Ship Work that Matters by Basecamp’s Ryan Singer.

This post incorporates a number of quotes and hand-drawn illustrations from Shape Up. All link to their source in the online book and are copyright ©1999-2020 Basecamp.

In my first post, we looked at Shape Up fundamentals like six-week cycles, appetite, work shaping, and the betting table. We left off at the handoff of shaped, de-risked work to the development teams. This post will focus on Shape Up’s approach to building. (And shipping!)

Hand it over, with autonomy

Before the dev team gets a project in Shape Up, two vital steps have already occurred:

• Work shaping – identifying what we want and what dev resources we’re willing to invest to get it
• Betting – firmly committing ourselves to this project versus others competing for the same resources

Because these two pre-steps are beautifully thought through, and thanks also to other fundamentals such as six-week cycles and the circuit breaker, Shape Up positions dev teams to enjoy a degree of autonomy far beyond that of the usual agile approach. In effect, we are saying:

“Here you go, dev team. This is what we want, and we’ll leave you alone for six weeks to build it. Implement the details as you see fit.

Good luck!”

Traditional agile, let’s say Scrum for example, looks a bit different:

“OK dev team! Here are your tasks! We managers, infinitely wise, have selected these for you to do these over the next two weeks! Dig right in!

And don’t worry, we’re right here if you need help or any kind of decision. In fact, let’s meet every morning to check in! Why don’t we stand up at that meeting, sound good?

See you soon!”

Autonomy (project) or code monkey (tasks), which do you think your dev teams will prefer?

Ramping up

What happens during the first two or three days after the project is kicked off? Lots of genuine work – orienting, exploring, understanding – but little of it visible.

Shape Up encourages patience during these early days of the build cycle:

Asking for visible progress will only push it underground. It’s better to empower the team to explicitly say “I’m still figuring out how to start” so they don’t have to hide or disguise this legitimate work.

Let there be tasks

Since the dev team wasn’t handed a list of tasks, they need to develop their own. Shape Up differentiates between imagined tasks – " tasks we think we need to do at the start of a project" – and discovered tasks – “tasks we discover we need to do in the course of doing real work.” There’s nothing wrong with imagined tasks, and during early ramp-up, a number will come to mind and be captured.

Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges.

This is why, once the team is oriented, it’s time to dig in and build something real. Only by starting to do real work are we going to discover the full set of to-dos that make up our project.

Slicing off a piece to build

Shape Up warns us against building front end and back end components independently, and waiting until late in the project to start integrating them. Instead, we are encouraged to deliver integrated, demoable, “really done” pieces of work throughout the project, even here in week 1.

For this to be possible, you need to slice out a piece of the project that includes the right set of front end elements, combined with the back end elements that support them. As nicely illustrated in the book, this gets you a slice that works:

In week 1, we aim to carve out, build, and demo our first slice, beginning a pattern that will continue throughout the cycle. But not just any slice – Shape Up encourages us to “start in the middle” for our first visible slice of work, building something that is central to the project, as opposed to a peripheral like the login screen. The identified slice needs to be small enough to execute in a few days, and if possible, something novel, new to us.

Further tips on building this first slice:

• Affordances before pixel-perfect screens – On the front end, start with rough, unstyled “affordances” rather than trying for pixel perfection.
• Program just enough for the next step – On the back end, you don’t need to build everything, implementing a couple of fields or a bit of routing logic is fine, just enough to allow the front end of the slice to function.
• Programmers don’t need to wait – The pitch we received starting the project gives programmers enough information to dig in. There’s no need to wait around for your front end developer to ask for something. Go ahead and dig in.

Integrated slice = “scope”

These things we’ve been calling “slices” or “pieces” are actually a vital element of successful building with Shape Up, and the have an official name: scopes.

We call these integrated slices of the project scopes. We break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other.

To be clear, scope as used in Shape Up means “integrated slice” — and definitely does not mean “estimate” or “level of effort.”

Scopes are fundamental in Shape Up because they are how work gets delivered, and therefore also how we organize tasks. They even help us define the language we use when talking about our project.

Scope mapping

Recall that when our team is handed a project in the form of shaped work represented in a pitch, tasks are intentionally not defined yet: our work is shaped but no tasks are defined:

In the early days of the project, we’ll immediately uncover and write down a number of tasks, but these won’t yet be organized in any meaningful or useful way:

When we identify and build our first slice of work, we start the process of identifying scopes and their associated tasks:

We complete our first scope …

… and then we’re ready to take a pass at fully mapping out all of the project’s scopes and their tasks:

Scopes evolve as we dig deeper and understand more:

We build our way through these scopes …

… until finally we’re done:

Getting the scopes right

You need to walk the territory before you can draw the map.

Scope mapping is literally a blank-sheet-of-paper problem – so how can the team know its scopes are right? This is largely a matter of feel, “does this feel right?” Shape Up identifies three signs that our scopes are well-mapped:

1. You feel like you can see the whole project and nothing important that worries you is hidden down in the details.
2. Conversations about the project become more flowing because the scopes give you the right language.
3. When new tasks come up, you know where to put them.

Shape Up likewise lists three warning signs that our scopes may need to be redrawn:

1. It’s hard to say how “done” a scope is. This can happen when unrelated concerns are mixed within a single scope, so that finishing tasks related to one concern don’t result in any perceived progress on the other.
2. The name isn’t unique to the project, like “front-end” or “bugs.” Shape Up terms this kind of scope a “grab bag” or “junk drawer” of tasks that instead should be filed under other scopes.
3. It’s too big to finish soon. A scope that’s overly large is effectively a project that hasn’t been scope-mapped, with a long, unorganized task list, difficult to show quick progress on.

Scope shapes

Shape Up warns us that not all scopes have the nice layer-cake shape with a layer of UI over a thin supporting layer of back-end code.

Some scopes look more like icebergs, with a tiny bit of UI riding over a huge hidden mass of back-end logic, or vice-versa. Icebergs need to be thought about and scope-mapped a bit differently.

And despite the warning above, Shape Up acknowledges that most projects need a “chowder” scope to hold tasks that don’t fit elsewhere. We are advised to both expect, and maintain a healthy skepticism about, chowder scopes.

Tracking progress and managing uncertainty

In the handover section above, we highlight the significant autonomy that Shape Up gives dev teams. That autonomy isn’t total, though; stakeholders and managers still need visibility into project status and risks. Providing useful visibility without adding friction isn’t easy.

We’ve already talked about “imagined” vs “discovered” tasks: some tasks can be anticipated and planned for, but the tasks that represent the majority of project work are unanticipated and can only be discovered during project work. One implication is that our task list actually grows as the project progresses:

This project is actually **pro**gressing in a natural way, but if you go by the length of the list or even the number of open tasks, it seems to be **retro**gressing. Clearly to-do list counting isn’t much of a metric to manage by.

Estimating task effort and tracking completion percentage seems like a smarter way to manage. The problem is that effort estimates are one-dimensional; they lack any measure of uncertainty:

Say you have two tasks, both estimated to take four hours. If one task is something the team has done ten times in the past, you can be confident in the estimate. Suppose the other task is something the team has never done before, or it has unclear interdependencies. It could take the four hours if all goes perfectly, but due to the unknowns in it, it could stretch out to two to three days. It’s not meaningful to write “4 hours, or maybe 3 days” as the estimate.

This “4 hours or maybe 3 days” brings back memories – that’s an answer I’ve gotten many times when, in my manager / stakeholder role, I’d ask the dev team, “well, how long will it take to build that?” This seemingly flip answer is actually a pretty healthy one – my team was responding honestly and trying to communicate “can’t know until we start building it” uncertainty that traditional estimates have no way to express.

We never did figure out a good system for managing uncertainty. But the Basecamp guys did.

The hill chart

The Basecamp team had a critical insight:

Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.

The uphill part is where uncertainty is high; once we reach the top of the hill, there’s still a lot of work to be done but it’s all known work and therefore predictable, low-risk, downhill. Here’s what that looks like in a picture:

Shape Up’s hill chart is simply this hill curve applied to project scopes. Each scope placed at the appropriate spot on the curve based on its completion and uncertainty status:

If you’re a manager or stakeholder, this one simple chart provides a complete birds-eye view of how the project is coming along – what Shape Up calls “status without asking.”

There’s actually a third dimension here, time. Since scopes move on the curve over time, we have a time series of hill charts showing how our scopes are progressing over time. Or in some cases, not progressing, or even retrogressing:

By looking at how hill charts change over time, managers and stakeholders get critical insight into “what’s in motion and what’s stuck.” In this example, the red dot looks like a “stuck scope.” Noticing this, the manager can initiate a friendly conversation with the team, and work out a course correction that gets the scope back on track. All this happens with the least possible friction. No probing phone conversations, “So, how are things going?” No status reports. No daily standups.

Basecamp’s hill charts implementation

As you might expect, Basecamp’s own hill chart implementation is excellent. You can simply drag a scope along the curve of the hill chart to update status:

For managers and stakeholders, Basecamp can easily pull up the hill-chart-over-time view:

How to build (and stay out of trouble)

Scope mapping gives us an effective way to organize and talk about the work to be done. Hill charts help the team track and communicate progress during the build cycle. But does Shape Up help us actually execute the work?

In my mind, the way scopes and hill charts train us to think and talk about the work, and for that matter everything else that Shape Up has laid out and walked us through, has all established the foundation for actually doing the work effectively. It’s an iceberg. Up here in the sunlight is the dev team, supported by their managers and stakeholders, kicking ass. Down below, hidden, is the deep Shape Up foundation that forms and supports that ready-to-kick-ass team.

That said, Shape Up does provide solid guidance on how to build effectively:

• Build your way uphill. Early Shape Up adopters often run into “backsliding,” where a scope seems to make it to the top of the hill, but then slides back down into the unknown zone. “Oh crap, it’s actually a lot more complicated than I thought.” Shape Up points out that this is often because “somebody did the uphill work with their head instead of their hands.” The solution – build your way up the hill, rather than trying to do it in your head.
• Solve in the right sequence. Some scopes have more uncertainty than others. When deciding which scope to work on first, Shape Up counsels us to think about being towards the end of the cycle and running low on time – which scope would you not want to build, late in the game, under time pressure? The answer is clear and leads the the guidance, “push the scariest work uphill first.”
• Stuck scope? Refactor. Sometimes a scope that appears stuck just needs to be redrawn. The most common scope slicing problem is an over-broad slice that encompasses several concerns. The team might be progressing just fine on several of the concerns, but because they are part of a larger grouping, the scope can’t move up the hill because some of the concerns are still unsolved. Shape Up tells us “The solution in a case like this is to break the scope apart into smaller scopes that can move independently.”

Stopping

That there is an entire chapter in the Shape Up book on deciding when to stop, complete with one more great tool called scope hammering, was a facepalm moment for me. It just never dawned on me that deciding when to stop is a really crucial part of the project. Now that Shape Up points it out – facepalm – of course. I should have realized this and approached it like Mark Watney in The Martian,

I’m going to have to science the shit out of this.

Alas, I did not, and therefore our projects normally ended with a good dose of chaos and regret.

As you might have noticed, Shape Up is all about sciencing the shit out of every aspect of software development, and they did it again here.

Compare to the baseline, not the ideal

Great people have a burning desire to do great work – and also a tendency to try for perfection. This is a valuable trait, but can trips us up when it’s time to finish and ship. We compare what we’ve built so far to the ideal solution we have in mind, and want to keep going to achieve that ideal. Shape Up tells us that

It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline—the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B?

Scope creep

Shape Up points out that scope grows naturally, like grass:

Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Projects are opaque at the macro scale. You can’t see all the little micro-details of a project until you get down into the work. Then you discover not only complexities you didn’t anticipate, but all kinds of things that could be fixed or made better than they are.

So why feel ashamed or angry about something that’s just a reality of software development (and in fact all project work)? Shape Up tells us:

This is how it is. Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.

Scope hammering

How does Shape Up keep the scope grass mowed? Let’s not forget one of the Shape Up fundamentals we covered in part one: the circuit breaker. “If the work doesn’t get done, the project doesn’t happen.” That hard limit underlies the subject of controlling scope and deciding when to stop.

This forces the team to make trade-offs. When somebody says “wouldn’t it be better if…” or finds another edge case, they should first ask themselves: Is there time for this? …. We expect our teams to actively make trade-offs and question the scope instead of cramming and pushing to finish tasks

Shape Up thought carefully about the name also:

People often talk about “cutting” scope. We use an even stronger word—hammering—to reflect the power and force it takes to repeatedly bang the scope so it fits in the time box.

Scope hammering is largely about carefully considering which scope changes are must haves and which are nice to haves. Finally, of course, you need to have the courage and power to make the hard decisions that lead to shipping on schedule, to say no. Courage and empowerment are a thread that runs throughout Shape Up.

Deploy and cool down

One final reminder that the title of the Shape Up book includes the phrase “Ship Work that Matters” – or to quote the book itself, “done means deployed.” Once you’ve taken care of that little detail, then comes cool down. We are cautioned to “move on,” keep the plate clean, and not get sucked into making immediate changes to what you just shipped based on early feedback .

If you want to try Shape Up

As I was putting finishing touches on this post, I noticed that the Shape Up book includes a handy appendix on how to give Shape Up a try, with tips, cautions, and three suggested approaches based on your situation.

Thank you!

If you made it here, through two parts and nigh on 7,000 words, thank you!

Special thanks to Basecamp and Ryan Singer for their generosity in writing up Shape Up and sharing it freely with us.

Finally, thanks to Ten Chu, who acted as a sounding board for me around aspects of Shape Up. I’m also grateful to a friend of Ten’s, Will Warren, who as CTO of Searchspring is an experienced Shape Up user, and shared many useful insights.

Speaking of which, I hope to do a follow-up post or two based on conversations with Shape Up practitioners. Stay tuned.