As the Shape Up method gains popularity, I see more and more blog posts written by teams who made the transition from other methodologies to Shape Up.

While these “Shape Up vs Scrum” articles are useful, they tend to only cover the mechanical differences between Basecamp's Shape Up and Scrum. In other words, “the how”.

In this post, I want to explore “the why” that makes “the how” really click.

If you want successful Shape Up adoption, you need to know this part.

When I first read the Shape Up e-book I couldn’t help but notice how familiar it was. It was like our team’s philosophy had been put down in writing by a thorough and eloquent writer.

Shape Up resembled the method we had developed independently at our workplace.

For example, we felt that the traditional two-week sprints got in the way too much. Having to repeat planning and ceremonies every two weeks was too expensive for us.

We also found that estimate-driven project management, as opposed to appetite-driven, caused a lot of friction.

I want to share with you the thought process that led us to the same conclusions as Basecamp, in the hope that it will help you adopt Shape Up successfully.

I know it helped us tremendously.

Understanding healthy team habits that support Shape Up will ensure successful implementation

Ryan Singer, the author of the Shape Up book, opens his Shaping in a Nutshell course by listing three reasons for adopting Shape Up:

Anticipation of future team growth (want to run parallel product teams)
Dissatisfaction with stalling teams (want to correct this problem)
Wanting to learn new skills

“Cultivating a high-performing culture” was what motivated us to come up with our Shape Up-like process. I guess that makes it four reasons.

To help with readability, from this point on I’m going to use the term Shape Up to refer to the development process we used, even though it’s not technically accurate. We started with our own homegrown Shape Up-like process before switching to Basecamp’s version.

For us, being a high-performing team was closely intertwined with the Shape Up philosophy. Shape Up benefited from, and embodied, the values that made our team click.

In order to show you why the Shape Up methodology was a natural fit for us, first I need to explain some of the concepts that underpinned our team.

If you want to practice Shape Up on Jira, please check out our Shape Up Board app (plugin) for Jira. It’s free for up to 10 users.

Purpose

Have you ever been in a workplace where individuals bring in a new piece of tech for no reason other than to pad their CV with buzzwords?

I have. This behavior kills motivation, stifles innovation, and ultimately destroys a lot of business value.

This happens because people don’t have a purpose to get behind. And when there is a gap in leadership.

When building our team, we were very conscious about this problem, so we addressed it right away.

Before an employee joined us, while they were still going through our interview process, they heard us talk at length about delivering user value.

In meetings and workshops, we frequently tied our discussion back to user success and business growth.

We created a team of software engineers and UXers who had a strong product mindset.

Another thing we did to bolster purpose was “meet in the middle” decision-making.

As you are no doubt aware, top-down decision making is flawed due to low-level blind spots. Bottom-up decision making also suffers from blind spots (in the opposite direction).

So we made the call to always involve representatives from both ends whenever we needed to make major decisions.

Obviously the goal was to combine perspectives and minimize blind spots. But an equally important objective was to create a strong sense of purpose.

Having a voice and influence over important matters kept people engaged and aligned.

Mastery

High-achieving individuals always strive to excel in what they do.

This trait can easily (and often does) backfire, if a leader doesn’t know how to harness it skillfully.

In the absence of guidance from their leader, software engineers will likely default to endless pursuit of technical excellence.

They’ll get extremely good at technologies whose further mastery will have a diminishing impact on end users.

To address this, we directed our team’s desire for mastery at the product itself instead of the underlying technology.

(Don’t get me wrong, we still had good code and architecture. We just didn’t gold plate things.)

We honed our ability to unearth the most impactful user value, and to use our technical knowhow for making the right quality-scope-speed tradeoffs.

As it turned out, our engineers actually enjoyed this.

Thinking about user impact made them feel good.

A metric lift that was directly credited to their work made them feel even better. So did positive user feedback.

Some individuals in our team took it further and became attuned to the commercial aspects of the business.

Tip: Collecting some user feedback is better that none at all. Don’t overthink it and start simple. I recommend Qualli.

Parkinson’s Law

Parkinson’s Law states that “Work expands to fill the time available.”

Take this very post you’re reading for example. I could give myself one hour, four hours, or four days to publish it. In each scenario two things are certain:

I’d complete it successfully, and
It would happen at the last minute

Sure, the four-day option would allow me to cover more depth, but I’d likely let myself be interrupted by admin tasks and other distractions.

I find allocating too much time to a project to be equally as problematic as allocating too little.

Shape Up Myths

You may have come across Shape Up’s pros and cons while researching it.

Some of its criticisms are probably fair on a micro level, but in the broader context of a healthy team, they don’t hold up.

Below I will list common criticisms directed at the Shape Up method and examine them one by one. This format will guide our discussion of Shape Up's “why”.

Shape Up’s rigid time box is unfair to engineers. It forces them to rush and write bad code.

Does Shape Up cause engineers to work long hours? — *Is it true that Shape Up causes engineers to rush and accrue tech debt?*

Our worst projects were ones for which we allocated time generously. These projects always ran over time.

In retro, everyone said they didn’t like the projects. Not the CTO. Not the stakeholders. Not even the designers and engineers involved.

You’d think that the engineers would appreciate the time afforded to them. But no. They found the projects too sluggish and heavy for their liking.

Parkinson’s Law was clearly at play here. Because we gave the projects ample time, work swelled up to fit this time allocation.

Subconsciously the engineers found it acceptable to over-engineer things. Or future proof stuff prematurely. All of this compounded to cause a deadline overrun.

The generous deadline was detrimental.

Our designers and engineers responded by asking for tighter sprints. They wanted an imminent finish line that forced them to cut out all the noise.

So we switched to three-week cycles. Smaller pieces of work would be afforded one cycle, while larger ones two.

With a more aggressive deadline the delivery teams no longer felt sluggish. They genuinely enjoyed racing towards a finish line.

Unfortunately we only traded one problem for another.

The engineers found themselves accruing larger-than-acceptable tech debt, because their estimates were too optimistic.

If you’ve read the Shape Up book, you can see where this is going.

Estimate-driven project management didn’t work for us and likely doesn’t for most tech businesses.

When a deadline is about to be missed, everyone expects the engineers to be the ones cutting back (on code quality), because the time frame came from them in the first place.

By asking engineers for an estimate, you’re implicitly holding them responsible for the deadline. This is the first problem with estimates.

Estimates also cause incompatibility.

A project is a business investment. How much to spend on a project is a business decision. Engineers should not be making that call.

Why, then, do tech businesses make engineers estimate and take it as gospel?

Tech debt happens because we ask technical people to make a commercial decision. Incompatibility breeds complexity.

Basecamp understands this, so they ask their “business people” for an appetite. “How much time are we willing to spend to build how much stuff?”

This simple change in questioning has such an outsized impact on a project’s success. It massively derisks the project as a whole.

It shifts the strategy from engineers having to cut back on code quality at the last minute, to shapers cutting back on scope upfront during shaping.

It’s easy to assume that Shape Up’s inflexible time box will lead to bad code and stressed out engineers. But in practice that couldn’t be further from the truth.

Shape Up’s rabbit holes and no goes spread the burden of meeting deadlines. The shapers are just as responsible as the delivery team, if not more.

Whenever a deadline was under threat, our shaper would be the first one to react. They would revisit the boundary and find ways to reduce it.

To be clear, I’m not advocating for ignoring engineers’ input during the shaping phase.

You should definitely get engineers to sanity-check pitches. In fact, you should get them to touch the code and spike unknowns.

You should also discuss time frames with engineers, but only as a rough guide, not gospel.

The betting table is a form of top-down decision making, aka HiPPO (Highest Paid Person’s Opinion), taking away people’s autonomy

In the Shape Up book, this is what Ryan Singer says about Basecamp’s betting process:

Our betting table at Basecamp consists of the CEO (who in our case is the last word on product), CTO, a senior programmer, and a product strategist (myself).
[...]
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.

As you can see, Basecamp has the highest people at the betting table for efficiency reasons, not privilege. It removes multiple layers of authorization.

There’s no reason why your betting table can’t be done by “lower ranked” people, as long as one of them has the authority to give projects the final go ahead.

Remember the concept of “meet in the middle” decision making that I explained earlier?

In keeping with that principle, we kept our betting table less top-heavy than Basecamp’s.

Not only was ours more balanced rank-wise, but it also involved different people on a rotating basis (with a few permanent members).

This was important to us because we wanted our team to develop the right mastery and purpose.

In order to minimize blind spots, we made sure that the following elements were covered between the people who attended:

Mid-long term vision
User needs
Technology needs
Commercial considerations

Thanks to our various “meet in the middle” workshops, enough people had been exposed to the big picture, resulting in little reliance on our CEO for betting. In fact, the CEO was not at the betting table half of the time.

In short, betting didn’t take away our team’s autonomy. It was empowering.

Shape Up requires experienced people and an unconventional way of working

I agree with the critics on this one.

It’s true. Shape Up requires unconventional culture and personnel. In a good way.

In traditional software development methodologies, product owners are often reduced to being ticket admins and product work becomes neglected.

And engineers are similarly reduced to ticket takers. Not only that, but the weight of deadlines falls squarely on their shoulders, leading to feelings of unfairness and burnout.

These are serious issues. If Shape Up helps you fix them, does it matter if it’s a little unusual?

The part about Shape Up requiring senior devs isn’t entirely true, though.

What will benefit Shape Up is not seniority in terms of the number of years, but a balanced mindset.

Remember, one of the goals of Shape Up is to enable parallel teams by eliminating reliance on a single individual. A well-rounded team makes this possible.

Let’s take Shape Up’s scope hammering for example. As you can see in Ryan Singer’s post, delineating scope boundaries requires serious skills.

You need to understand the users, product, tech, and sometimes even commercial context.

Which is why only very few people can pull off scope hammering flawlessly, thus creating a bottleneck.

This is where cultivating a well-rounded mindset in our team (see Mastery above) really paid off.

Most of our engineers weren’t so obsessed with technology that they were incapable of helping out with scope hammering, betting, or shaping.

Because our designers and engineers had product and user-centric thinking, we were able to distribute and parallelize product management work, thus solving the product bottleneck issue.

To me, this “special team culture” that Shape Up is said to require bears the hallmark of high performance. You’ll benefit from it anyway, regardless of Shape Up.

In case you need further convincing, Atlassian publicly talks about promoting this product mindset among their software engineers.

Shape Up leads to people shipping low-quality, unpolished features

This is very similar to a previous criticism, but it deserves its own discussion.

For us, not defining a clear and tight boundary was the single biggest cause of time blowout, by far.

It led to engineers uncovering more and more dependencies that had to be touched, leading to the scope spiralling out of control.

On the other hand, whenever our shaper took the time to shape properly, we didn’t find ourselves having to sacrifice quality all that often.

Shape Up’s strict time box worked better for us because it forced our shapers into good habits.

Shipping unrefined features has nothing to do with Shape Up, but everything to do with unclear boundaries.

Incomplete planning will always cause issues, whether you use Agile (Scrum, Kanban, XP) or Shape Up.

As I explained in the first half of this post, we all value mastery. We want to deliver high-quality stuff.

Having spoken with a lot of end users, I can safely say that our definition quality is very different from theirs..

Our users told us on many occasions that they would rather have an unrefined feature in six weeks, than a super polished version in six months.

From their point of view, going from no feature at all to an unrefined one would already be life changing.

They don’t care all that much about the icing on the cake, as long as they can get the cake quickly.

If you equate quality with polished features, then yes, Shape Up’s deadline (or any kind of deadline for that matter) will make you uncomfortable.

However, if you switch your perspective and equate quality with solving customer pains quickly through smart tradeoffs, then you’ll enjoy having a deadline. You might even prefer it!

After all, constraints give rise to creativity.

Shape Up is chaotic because it does not have a product backlog

Shape Up couldn’t be more different than Scrum in this regard. While product backlog is mandatory in Scrum, Shape Up advises against it.

As a knowledge worker you may squirm at the idea of throwing away the product backlog. What happens to all that information?

Well, Shape Up only frowns upon public backlogs.

It acknowledges that individuals may keep a private list.

If an idea or a bug is important enough, someone will take note of it. If no one does, it can’t be that important.

So no, Shape Up does not make you throw away important information, nor does it cause work to be shaped and pitched arbitrarily.

In our case, the team readily embraced Shape Up’s “bets, no backlogs” concept.

People were indeed tired of backlog grooming. Having to track months-old tickets with questionable relevance felt tedious.

Many tickets were added to the backlog for no reason other than recency bias. Recent issues always seemed important, so a ticket was always created.

In the grand scheme of things many of them didn’t matter at all.

With Shape Up you risk throwing away six weeks instead of two

You may be concerned about going all the way to the end of a project only to find that it’s going to fail.

I can see the logic behind this concern, but it’s an unlikely scenario if you execute the delivery phase correctly.

Shape Up’s hard deadline is supposed to change your delivery teams’ approach to be like that of Basecamp’s.

First, your engineers are meant to identify as many unknowns as possible and tackle the riskiest bits upfront.

Then, the engineers move on to integrate end-to-end as early as possible. This is what makes the last-minute failure scenario unlikely.

In our experience, by week two or three we’d have a super rough but fully integrated solution coded up, good enough for a rough demo.

At this stage, every layer has been explored and understood by the delivery team.

If you ever need to make the call to drop a project, it will be at this point.

A potential wastage of two to three weeks does not make Shape Up costlier than traditional methodologies.

Integrating end-to-end early is hugely underrated, so I’ll say a few words about it.

I’m sure you know that releasing incrementally (as opposed to big bang) is the right thing to do.

But you can release incrementally the right way, and the wrong way.

Let’s say an engineer is tasked to build a four-page sign up flow (terrible idea by the way - too much friction).

Wanting to do the right thing, the engineer plans to push to prod incrementally behind a feature flag and will only open it up once everything is completed.

So the engineer starts working on page 1.

Illustration of starting to build component 1 — *Making progress on page 1*

So far so good.

In order to have the first “pushable bundle”, the engineer continues to build out page 1. Once it’s fully built, the engineer puts it behind a feature flag and pushes to prod. (I’m leaving out QA to simplify the story.)

Illustration of completing component 1 — *Incremental release #1*

Increment 2 follows the same pattern: fully build page 2, put it behind the feature flag, and push.

Illustration of completing component 2 — *Incremental release #2*

Rinse and repeat for the rest.

Illustration of completing component 3 — *Incremental release #3*

This is doing incremental release the wrong way.

If the engineer fails to complete page 4 by the end of the cycle, the entire feature is unusable. The whole six weeks are wasted.

Illustration of failing to complete component 4 — *When incremental development is done incorrectly, one missing element causes the whole thing to be unusable.*

I’ve seen a case where a junior engineer, unaware of Ryan Singer’s advice on early end-to-end integration, failed pretty much in the manner that I described above.

His entire 4-step feature was unusable on deadline day despite releasing incrementally, because he sliced it wrong.

The Shape Up book explains that increment 1 should be horizontally-shaped instead: build a very rough implementation of pages 1-4, put them behind a feature flag, and push to prod.

Illustration of integrating components 1 to 4 — *Shape Up advocates integrating end-to-end as early as possible*

Further increments are for polishing code, functionality, UI, etc.

If the engineer runs out of time, the entire feature is usable. Perhaps with rough edges, but usable. No waste.

To be fair, this concept of delivering usable chunks also exists in Agile. It’s just more apparent in Shape Up due to its unforgiving deadline.

Shape Up uses unfamiliar terminology

This is undeniably true.

The Basecamp folks like to come up with their own stuff and do things differently. (See side note below.)

It’s not just limited to Shape Up. You can see their unique take in everything they make, like Rails, Hey, the Basecamp.com product, etc.

Take the instant messaging feature on Basecamp.com for example. You and I would probably name it “Instant Messaging”. But not Basecamp. They call it Campfire.

That’s why you won’t find Scrum terms in Shape Up.

No sprints, PRD (Product Requirements Document), product owners, or backlogs. Instead you’ll find cycles, pitch, shapers, or betting table.

These words and phrases were chosen deliberately. Betting implies that there’s a pay off. Scope hammering is meant to convey force.

The terms are different for a reason. They’re not different for the sake of being different.

Having said that, I’m not a big fan of the term scope in Shape Up, as it has two different interpretations:

A slice of work
Size or extent

Side note: When it comes to software architecture, Basecamp is once again different from everyone else.

They buck the trend of SPA by not splitting front-end and back-end, which leads to slightly jumpy UI in Basecamp.com and Hey.

I understand that they made this choice for development speed reasons but in all honesty I was questioning whether their approach was too extreme.

In light of the recent tech downturn, this proves to be a smart move.

Forgoing the front-end and back-end split cuts down a lot of work, allowing Basecamp to weather the storm better than many tech businesses that got too fat.

Being different has its advantages!

Closing

Shape Up is a different way of working. It doesn’t work well with top-down decision making or micro management. But then again, what does?

To get the most out of Shape Up, your team needs a healthy user- and product-centric mindset.

And your designers, engineers, product managers, and “business folks” need to have a highly collaborative working relationship.

If you can provide that, Shape Up will make your team ship like clockwork.

What do you like and not like about Basecamp’s Shape Up? Please leave a comment below.

If you want to practice Shape Up on Jira, please check out our Shape Up Board app (plugin) for Jira. It’s free for up to 10 users.

Last update: May 2024