Introducing Shape Up

In the previous article, Scrum has had its day! What’s next?, I explained why, although Scrum was a significant leap forward as a software development methodology, it also brought with it a number of challenges, and that it was time to move on.

Let’s introduce Shape Up, a methodology created by 37 Signals, the makers of the Basecamp and Hey apps, the Ruby on Rails framework, and half a dozen books on software development like Rework and Remote.

Over the last few years, 37 signals says there’s been a heightened curiosity about how they work. People often ask them how they get so much done so quickly at such a high level of quality with such a small team. And how they keep their teams together for years and years.

It has a lot to do with Shape Up, a methodology they developed in isolation over nearly 15 years of constant trial and error, iterating and polishing up. And they have recently released it to the public. As they say on their website: “We’re here to share it with all those curious enough to listen to a new way of doing things. Explorers, pioneers, those who don’t care what everyone else is doing. Those who want to work better than the rest.”.

This article, the second in the series, will focus on the big picture of Shape Up and how it’s different from Scrum.

Six-week cycles

First, they work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.

They don’t count hours or question how induvidual days are spent. They don’t have daily meetings. They don’t rethink their roadmap every two weeks. Their focus is at a higher level. They say to themselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then they commit the six weeks and leave the team alone to get it done.

Shaping the work

Second, they shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before they consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

When shaping, they focus less on estimates and more on their appetite. Instead of asking how much time it will take to do some work, they ask: How much time do we want to spend? How much is this idea worth?

Making teams responsible

Third, they give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.

Together, these concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.

Targeting risk

At every step of the process they target a specific risk: the risk of not shipping on time.

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

If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that they don’t invest multiples of the original appetite on a concept that needs rethinking first.

And lastly they reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, they build one meaningful piece of the work end-to-end early on and then repeat.

The 3 parts of the process

• Part One is all about Shaping — the pre-work to do on projects before to consider them ready to schedule. From setting the appetite on a raw idea, to sketching out a solution, to writing a pitch that presents the potential project.
• Part Two is about Betting — how to choose among the pitched projects and decide what to do six weeks at a time.
• Part Three is about Building — the expectations to place on the teams and the special practices to use to discover what to do. Teams figure out what to do, how they integrate design and programming, how they track what’s known versus unknown, and finally they make the hard calls to finish the project on time.

Conclusion

As you can see, Shape Up is quite different from other traditional methodologies and challenges many of their aspects. Personally, it just feels right and it's about time something like this was needed.

Indeed, during our many consulting missions, we have found that traditional methodologies such as Scrum can have serious negative effects and are convinced that Shape Up, or at least the adoption of some of its principles, can make a major contribution to project success.

This concludes the second article in the Shape Up series. In the next article, we’ll take a closer look at the first part: Shaping.

Stay tuned!