Scrum is toxic; agile is dead. Is Shape Up the answer to how we develop software products?

“I’d like to try Shape Up with my team,” said David, a tech lead manager that I work with. David is a big fan of 37signals, and Shape Up is how they develop their products, such as Basecamp. The methodology is introduced to the world by Ryan Singer in the book Shape Up: Stop Running in Circles and Ship Work that Matters.

Shape Up had been on my reading list for years, and David’s comment finally spurred me to read it.

In the Shape Up methodology, potential work is shaped into six-week packages. The prospective projects are pitched against each other and senior leadership decide what work goes ahead. These are called “bets” to acknowledge that these projects are not guaranteed to succeed.

Once the bets are placed, they are worked on by implementation teams. The teams are small, generally a designer and one or two software engineers. The team has autonomy to deliver the work as they see fit, and progress is monitored from afar using hill graphs (more on these later). If the work can’t be completed in the six-week window, it is considered a bust (in order to avoid throwing good money after bad).

Smaller pieces of work are shaped into one or two-week packages, and combined together into six-week units.

How operational issues and bugs are dealt with is mostly glossed over, though there is a mention of a dedicated Ops team handling them. Shape Up makes the argument that, really, “most bugs can wait.” This perspective might be hard medicine to take, but it is a strong stance on how ruthless prioritization should be. If all things are equally important, then nothing is important. Prioritisation is making a choice of what you will work on and what you won’t.

Shaping comes at the expense of making

“We reduce risk in the shaping process by solving open questions before we commit the project to a time box. We don’t give a project to a team that still has rabbit holes or tangled interdependencies.”

Given that the shaping is done outside of implementation teams (who at any given time are busy implementing), I asked David what he saw himself doing: shaping or implementing? If he was shaping, he shouldn’t be disturbing his team to advise on the design decisions. If he was implementing, he wouldn’t have any say in the shaping of work. And would his team be happy to not be involved in the shaping of the work?

This is my main qualm with Shape Up the methodology: the people who shape the work are not the ones who do the work. By definition, shaping is done by a small senior group, who work outside of the six-week cycles.

Shape Up talks about giving the team freedom and independence, but divorcing discovery and high-level technical design (necessary to shape those six-week packages) from implementation surely robs the executing team of autonomy.

Shape Up says it focuses on appetite over estimation. I love Shape Up’s concept of appetite, which emphasizes the value that solving a problem will bring (more on appetite later)! But you can’t avoid all estimation and still have confidence that the problem is solvable within six weeks.

The central tenet of Shape Up is that you have a shadowy cabal of masters of product development whose job it is to identify a problem, eliminate the rabbit holes in the solution, estimate what can be done in six weeks, and then hand it over to be implemented to someone else. (Remember who the solution implementers are?)

To be fair, Shape Up is explicit about being a methodology for avoiding the “risk of getting stuck” and not one of discovery. But the setup sure is a far cry from Marty Cagan’s idea of empowered product teams.

As it’s impossible to avoid never doing any work when validating or scoping a project, I find that the best results are achieved when the people who scope a project are the ones who deliver it. You can never anticipate all the questions that will arise in a project. So rather than trying to do this upfront, we should empower a team to be able to find answers as they go along.

As an industry we’ve worked to get away from the waterfall methodology, where decisions flow from one stage to another, making anything done upstream incredibly hard to change. While Shape Up does leave many of the details for the implementation team to work out, its whole premise is to eliminate risks and rabbit holes by making the big technical design decisions upfront. This feels like a step backwards from the vision of empowering teams to own the whole problem and solution.

Despite my qualms of organizing work this way, there is plenty to like about Shape Up.

How to avoid the trap of perfectionism

I’ve always loved the Lean Startup adage that “if you aren’t embarrassed with your first release, you worked on it too long.” Only once you get it in front of users can you learn what works and what doesn’t. It’s a shame that first releases are so rare — and that releasing buggy features in a mature product isn’t quite as viable a strategy.

Yet while we don’t want to release unfinished work, we do need to curb the inner perfectionist in us as product developers. How can we tell what’s good enough? How can we be okay even if it isn’t the all-singing-all-dancing version we can imagine?

Shape Up solves this by shifting the point of comparison: rather than comparing your work to the ideal, compare it to the baseline, the current reality for customers. Is this better than what they have currently?

This shifts the emphasis from us and our work to the value the work brings to customers.

Even more powerful is Shape Up’s “ship in six weeks or the project gets scrapped” ultimatum:

“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? Without a deadline, they could easily delay the project for changes that don’t actually deserve the extra time.”

While I don’t believe in using arbitrary deadlines to squeeze work out of development teams, having no deadlines or constraints actually makes it harder for teams. Progress requires decisions, and clear constraints help in making these decisions.

Shape Up’s six weeks is an arbitrary deadline, but only the time is fixed, the scope is variable.

People can get behind deadlines that they understand. But if there is no purpose or value in achieving the deliverables that were committed to in a sprint, this just becomes a way to burn out your team. Maintaining a high velocity might be rewarding in a gamified kind of way, but this confuses the metric for what’s being measured.

Saying that a piece of work is worth an investment of six weeks is a nice way to put it, but this fixed time period still feels awkward. What if some feature is worth four weeks of investment? Or ten weeks? While I’m sure there are ways to get around this (bundle multiple smaller projects, cut scope), what Shape Up is really saying is that it values predictable cadences and ways of working over considering the nature of the work at hand or the team doing it. It would rather shape the work to fit the process than shape the process to fit the work.

In Scrum, teams plan for and attempt to deliver an agreed amount of work in a sprint (the length of which can vary). In Shape Up, the team is tasked with delivering an agreed piece of functionality in six weeks. I’m not sure there’s much difference between the two.

Shape Up as a critical response to Scrum

Shape Up and Scrum were both created to solve problems inherent in developing software. For this reason, it’s no surprise that they have similarities. But, as Shape Up came after Scrum, it’s also possible to see Shape Up as a critical response to Scrum and its perceived shortcomings.

Too many organizations separate development teams (often ensconced within the “IT” department) from the rest of the business. In this setup, the development teams treat the rest of the business as clients (though instead of calling them clients, they’re called stakeholders).

If the business wants something from a development team, it is expected to do so by specifying a list of “requirements”. The fact that there is always more to develop than there are developers, and that different parts of the business want different things, inevitably leads to different parts of the business competing over whose requests get worked on first.

The stakeholders, who know from experience that any work that they fail to get through now will have to wait until the next window of work orders, are naturally inclined to push for the inclusion of anything and everything they can think of.

This leads to a laundry list of hodgepodge requirements.

This “a little bit for everyone” approach leads to “not much for anyone.” But no matter: once these requirements have been estimated and packaged up into a project, the project plan, complete with a schedule of deliverables (created, naturally, by simply totting up the individual estimates), is treated as a contract between the development team and the business.

In this approach the plan becomes more important than the outcome. Any new information that turns up along the way is better off ignored, as nobody wants the hassle of changing the plan, as this would be tantamount to renegotiating a contract.

In these low-trust environments Scrum can help make things better. It offers a way to curtail risks and cut down on big planning upfront.

Unfortunately, Scrum has a tendency to mutate into a process in which teams are constantly sprinting from one arbitrary deadline to another. Too often Scrum ends up being a way to micromanage people’s work.

Frequent planning sessions, especially if they include people not on the team, invites close scrutiny into the whats and hows of the work. These ceremonies not only take up time, but they also disrupt the team and all too easily devolve into tools of surveillance and coercion. This is a major criticism of what Scrum and agile has become.

Shape Up tries to fix these by allowing the team to work independently for six weeks at a time. With hill charts, Shape Up even invented a way for leadership to observe progress without having to speak with the team!

Where Shape Up goes beyond Scrum

We used to use Scrum-y ceremonies at LloydsDirect: refining backlogs, estimating tickets, planning out two weeks of work, retrospecting after each sprint. This worked okay, but we started feeling like the structure wasn’t really doing much for us. We were shipping as and when, sometimes multiple times a day, so planning for releasable pieces of work per sprint wasn’t useful. The business rarely needed precise deliverables on given dates, so there was little need to try to predict when we’d finish a piece of work and then scramble to meet this deadline. It became clear to us that setting arbitrary sprint goals based on imperfect estimates was a waste of time and effort. So we abandoned these rituals.

My point is that it’s the circumstances of your organization that dictate what constraints your team should optimize for. Scrum tries to avoid big upfront planning by constraining the planning horizon and involving the business (as represented by the product owner) in the process. Shape Up also seeks to avoid detailed requirements gathering, but it also aims to abolish the frequent planning and reporting associated with Scrum.

However, Shape Up is not a drop-in replacement for Scrum. Unlike Scrum or other agile methodologies, Shape Up dictates how projects are estimated, selected and executed. It also prescribes specific organizational structures.

Scrum’s view of the world is that there is the development team and then there’s everyone else. This is effectively a client–contractor relationship.

Where Scrum tries to overcome uncertainty by cutting down upfront planning and providing the business optionality in the work in progress, Shape Up tries to give teams implementation-level autonomy and interruption-free focus time at the cost of genuine agency to explore the opportunity space.

If Scrum teams de-risk their work by constantly demonstrating their progress and consulting with the business on what’s next, Shape Up trusts its teams — up to a (six-week) point. In neither is the team actually empowered to work with the business to figure out how to best deliver business goals.

Appetite is a tool to accompany estimation

I’m a big fan of Shape Up’s concept of “appetite” — how much a feature or project is worth to the business. “Estimates start with a design and end with a number. Appetites start with a number and end with a design.”

Most projects have their return on investment (value) weighed up against their cost (effort), so in this sense Shape Up’s appetite isn’t a novel concept. But the concept of appetite is a useful addition to any discussion that involves estimation. It helps ensure that when estimating we keep in mind the desired value, not just the cost of the proposed solution.

Too often the “funding process” for a project goes like this: the business asks the developer how long will it take to build “x”? The developer asks some clarifying questions about requirements and then gives an estimate. If the estimated effort is under the projected value, the project gets approved, if not, it is rejected.

Notice how at no point in this example did the business share what the desired outcome of building “x” is or how valuable it would be to the business. Nor did the developer ask for this.

Without considering desired outcomes, project definitions and estimates become static and immutable, and leave development teams little agency to make trade-offs or respond to new information.

Consider this example. The business asks the developer: “How much effort would it be to add a ‘Contact Us’ form to our website?”

To answer this, the developer needs to consider what languages the web server runs, if there is any existing similar functionality, how to deal with spam, security testing, where the responses are stored, how they will be read, etc.

The estimate for this feature might be several weeks of effort!

Whatever the estimate ends up being, responding with a figure-as-a-fact is a conversational dead-end; there isn’t much the business can do with it apart from accept it or reject it. If it happens to exceed the business’s appetite, they might ask if it can be done for less, which is a clue for the developer to rethink their approach. But wouldn’t it be easier if the developer immediately countered the estimate request with: “What’s your appetite?”

In the “Contact Us” form example, an appetite below the estimate might lead to exploring what the underlying need is — allowing customers to get in touch — which in turn might be satisfied more simply, for example, by adding an email and phone number to the website.

My point is that this should be a conversation: we want this outcome and we think it’s worth this much, what will it take to deliver that? Matching estimate to appetite allows the right trade-offs to be made. (This is why I hope I will never have to participate in an agency-style competitive pitching process again — there is no conversation about what actually is needed.)

While appetite is only a proxy — how much we’re willing to invest in something — it acts as a reminder to consider what the desired outcome or value is that the project seeks to unlock.

Appetite, estimate and outcome should all be variables within a dynamic equation

A mistake that I’ve seen organizations make time and time again is to treat funding decisions as static end products rather than formulas where the viability decision can be recalculated at any time. In this “fund-and-forget model” the cost-benefit analysis is done once and the factors that led to this decision are cast aside or, at best, insufficiently documented.

Once a project has been given the go-ahead, it enters the backlog to be scheduled for commencement at a later date. By the time it comes to a team to work on to figure out how to actually implement it, the project definition is treated as gospel, as an immutable objective that can’t be altered. The goal becomes to complete the project, not to achieve the originally desired outcome.

This risk is especially prevalent when projects cross organizational boundaries, either within a business from one department to another, or when engaging external partners, such as contractors or agencies.

Even — or maybe especially — the outcome needs to be checked from time to time. The world around us is changing all the time, occasionally these changes will invalidate the original outcome.

Keeping the appetite, estimate and desired outcome in mind allows the team to make trade-offs and re-plan over time.

Hill graphs, scope maps and tackling the biggest risks first

I’d love to try using hill graphs. Hill graphs are little Gaussian curves with an indicator to show how far along a feature is in development. The left half is uphill, meaning there are still unknowns to figure out. Only once you’ve broken the back of the feature, where the rest is predictable work, do you enter into the right side of the graph — from here on out, it’s smooth sailing, all downhill.

I particularly like the diagnosis of what causes “sliding back down” the hill:

“… because somebody did the uphill work with their head instead of their hands. Coming up with an approach in your head is just the first step uphill. We often have a theory of how we’ll solve something — ‘I’ll just use that API’ — and then the reality turns out to be more complicated. It’s good to think of the first third uphill as ‘I’ve thought about this,’ the second third as ‘I’ve validated my approach,’ and the final third to the top as ‘I’m far enough with what I’ve built that I don’t believe there are other unknowns.’”

Equally compelling is the point made about tackling the biggest risks first and leaving the “screw tightening” until later. If a team starts with building email templates, they could spend weeks fine tuning the copy and design — time they might later wish to have spent on figuring out the more unknown challenges.

I’ve seen this happen with teams, and it’s a sticky situation to get out of. You find that you’ve chosen a less-valuable piece of work to start on but it can easily take more and more tinkering and polishing to finish.

This approach is the opposite of the “quick wins” strategy, in which the team starts with some relatively easy piece of work to get points on the board early and to demonstrate how the process works. The quick wins strategy can really pay off when working in a low-trust environment (like for new clients).

While this can be a great way for a team to build momentum and reinforce a shipping mentality, it can backfire if the quick win doesn’t end up being quick. If this happens, you’ve invested a lot of time in a less-valuable piece of work.

To work, the quick wins need to actually be quick: this is what wins trust.

Another great concept from Shape Up that I’d love to try is scope maps. It springs from the ideas that work should be organized by structure, not who’s doing it, and that “you need to walk the territory before you can draw the map”.

I’ve often used mind maps to explore complexity and scope. Scope maps feel like inverse mind maps, where instead of creating new branches outward, you are progressively slicing an area into smaller, more granular parts.

So, should you Shape Up?

Would this approach work for your team? This depends on how you want to organize your team.

Do you want to centralize decisions to a select few whose job it is to break down the work into well-defined specifications (or six-week cycles) for “lesser staff” to then implement? Do you want to free your implementation teams from intrusive scrutiny and trust that they will deliver the best possible implementation given their brief? If so, Shape Up is a great methodology to try.

I can see how this would work well at 37signals, where (it seems that) the shaping team has personally been involved in designing and building the product from the ground up. It probably also works better when operating on a known product (as opposed to totally greenfield projects without known conventions or constraints).

As a methodology, Shape Up demands quite a specific way of organizing your business, and presupposes that the work can be defined upfront by people who aren’t actually implementing it. It’s geared towards cutting down on fine-detail specification and estimation (except the estimation done by the big-wigs), cross-team collaboration and oversight. As such, it requires a certain level of trust of both the shaping and implementation teams.

Scrum, as a comparison, fits a much more traditional client–contractor model (i.e. low-trust environments).

By my reading, Shape Up still requires more upfront design and gives the team a lot less remit than Marty Cagan’s empowered product team model. In this light, Shape Up seems to be somewhat of a halfway house between Scrum and empowered product teams.

But don’t just take my word on this: Shape Up, the book, is engaging, very well written, and well worth a read. Plus, it’s free!

As for my tech lead David, he never did try Shape Up. “My idea for pushing Shape Up was as a way to force people to work collaboratively. Moving people to separate tracks isn’t how I want to see a team running. I want everyone along for the ride.”