Basecamp’s Shape Up: how different is it really from Scrum?
A summary of how Shape Up works and compares to Scrum
Basecamp is famous for having their own, often counter-intuitive way of doing things which delivers impressive results for them. Over the years, small nuggets of Basecamp’s way of working have been released to the public. Now there is a Shape Up guide publicly available that can teach you how to do Product Development like Basecamp.
In Dublin, I listened to Ryan Singer speak at INDUSTRY about Basecamp’s way of working, and unknown to me at the time, there he presented some of the tools that are part of Shape Up.
I’ve read the guide and decided to view the Shape Up approach through the lens of Scrum for two reasons:
To make it easier to understand for the large group of people who already are familiar with Scrum.
To find out how different it really is from Scrum.
I can tell you already that Shape Up and Scrum have a lot in common, but there are also significant differences.
How does Shape Up work in a nutshell?
Delivering a project with Shape Up consists of three distinct phases:
Shaping. Senior team members, who ultimately will not execute the project, define the problem and solution with the right amount of detail. Shaping needs to happen at the appropriate level of abstraction: concrete enough, so the team knows what to do, but not so prescriptive that it restricts the team from figuring out interesting details themselves. It is a delicate balancing act.
Betting. Shaped projects are pitched to the management team with some senior members present, and together they decide which projects to green light, and which to drop. Shaped projects that don’t make the cut are not systematically stored.
Building. The team delivers the shaped project with all necessary skills present in the team and have full responsibility for scope in a cycle of six weeks. At the end of the six weeks, either the project is finished or the project is killed. Extensions can happen but are extremely rare and discouraged.
Is Shape Up a process framework?
No. It is a toolbox full of techniques that you can apply as you see fit in your own process. Shape Up will not help you discover your own better working process. It provides tools you can use in your working process.
Shape Up cannot be combined with Scrum for three reasons:
Shape Up prescribes not using a Product Backlog. The Product Backlog is a mandatory artifact in Scrum.
Shape Up works in cycles of six weeks. Scrum does not allow a Sprint length of 6 weeks. Technically you could work around this by breaking down a Shape Up cycle in a few Sprints, but that would conflict with the Shape Up approach.
Refinement (shaping) of the work happens outside the team, following a dual-track process of Discovery and Delivery.
Even though the second reason can easily be debunked, because Shape Up also claims you should do the following when running a six-week cycle:
“Instead they should aim to make something tangible and demoable early — in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.” — Shape Up Guide v1.7, 2019 edition
This is the same result you get if you run a Sprint of 1 or 2 weeks. You don’t call it a Sprint, but you need to achieve the same result as what you’d do during a Sprint.
Is Shaping the same as refinement?
Shaping and refinement are pretty similar, but there are some key differences:
Shaping, preparing the work, so it’s ready to be planned as part of a six-week cycle, is done by senior members outside of the team. In Scrum, the Development Team refines their own work to make it ready to be worked on.
Shaping results in big blobs of work that presumably fit in a six-week cycle. Refinement splits features up in smaller, sprint-sized chunks.
Work does not get estimated, but the appetite gets set. How much time will we spend on this? The two options available are Small Batch (two weeks) or Big Batch (six weeks).
Shaping does not affect the Product Backlog in any way, as there is no Product Backlog.
Shape Up claims the following key difference of Shaping with other methodologies:
“This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.” — Shape Up Guide v1.7, 2019 edition
When you do Scrum, the Development Team chops up their own work. So completely different is quite a stretch. But hey, I can’t blame them for trying to sell their approach.
How does Shape Up work without a Product Backlog?
Shape Up works without a Product Backlog. If anyone wants to keep track of an idea, he or she should take care of this on their own and bring it up in the betting phase (again).
The reasoning behind this approach is that important ideas will come back. It ensures you focus on doing what is the most important now, instead of just honoring commitments or working on the next thing on the list. It is expressed the following way in the Shape Up guide:
“It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles. 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 50 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.” — Shape Up Guide v1.7, 2019 edition
What is betting in Shape Up?
Betting means deciding which projects get a team to work on for a cycle of 6 weeks. A group of important stakeholders comes together to determine what the teams will work on. It basically is a committee making decisions about what the teams will build. After a project gets green light in the Betting cycle, the following happens:
6 weeks of uninterrupted time will be dedicated to the project.
A small new team gets hand-picked specifically for realizing this project with a size of 3–4 people and all skills necessary to perform the work: programmers, designer, and a QA.
A key difference to Scrum is that in Shape Up, people get selected to work on a specific project. When you work with Scrum, work comes to the team, and the team composition does not change based on the needs of the projects (usually at least).
How do you build products with Shape Up?
In Shape Up, a small team commits to achieving a Bet in a cycle of six weeks. The scope and how they do the work is entirely up to the team, as long as it falls within the boundaries of the Bet. This is highly similar to the Sprint Goal approach, followed by Scrum. The team has flexibility on Scope but commits to meeting a specific goal during a time-box.
Shape Up describes various techniques to help managing uncertainty, risk, slicing of work, showing progress, and controlling the scope. All of these techniques are described in the book and can be perfectly used together with Scrum, as complementary practices.
Just like with Scrum, part of the plan and work to be done emerges during build phase:
As the team gets oriented, they start to discover and track the tasks they need to do to build the project. It’s important at this early phase that they don’t create a master plan of parts that should come together in the 11th hour. — Shape Up Guide v1.7, 2019 edition
Even though Shape Up works in cycles of 6 weeks, it is recommended to deliver something already working in the first week.
The Shape Up guide presents various techniques that are employed for the Betting, Shaping, and Building process. I won’t go into detail about those techniques, as they can be employed in any approach and are not what makes Shape Up unique.
At the end of every six-week cycle, there is a two-week cool-down cycle. During this period team members are free to work on whatever they want.
During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities. — Shape Up Guide v1.7, 2019 edition
Scrum vs. Shape Up Summary
What do they have in common?
Time-boxed approach to delivering software.
The scope is flexible during the time-box. However, there are limits to this flexibility. As long as it meets the intended objective of the Bet or the Sprint, flexibility is permitted.
Refinement is necessary to make work-ready.
The team has full control on how to split up work in tasks and how the work is performed.
What are the differences?
Shape Up has no Product Backlog.
Shape Up follows a Dual Track Agile process of Discovery and Delivery.
Shape Up refinement (Shaping) is done by senior members outside of the team and gets handed over to the team that will execute it. In Scrum, refinement is done by the team that will perform the work.
Shape Up is a toolbox, Scrum is a process framework. Shape Up will not help you discover better ways of working or delivering value. Shape Up mainly contains best-practices that work for Basecamp. It is not well-described and structured like Scrum (yet).
Shape Up offers no prescriptive approach to scale with many teams. Scrum neither, but at least there are many Scrum scaling frameworks available. How you make Shape Up work on complicated products with many teams is unclear.
What is my personal opinion of Shape Up?
I want to stress I never worked with Shape Up. All my arguments are entirely theoretical in nature and could be wrong. This is just my initial impression, based on my personal expertise with building products.
The things I like:
The Development Team has full control over the scope of the six-week cycle. It takes self-organisation to another level.
No Product Backlog. Maybe having no Product Backlog is a bit extreme, but I do think it’s good to keep your Product Backlog short and relevant for what you will be working on soon. Otherwise, your Product Backlog will become stale and come back to haunt you.
Teams are tiny, which means there is less overhead, and collaboration becomes easier. Might also be a problem for products that are more complicated to have such small teams.
The techniques described in Shape Up are pretty nice and can be combined with other development methodologies or process frameworks. It is far more prescriptive in areas where Scrum simply provides nothing.
Cool-down cycles at the end of six-weeks. Scrum can be relentless and give little breathing space. It also gives the opportunity to team members to do spend time on the things they’d like to work on and reward them for their efforts. It provides a space for learning, experimentation, reflection and divergent thinking.
The things I don’t like:
Shaping is done by senior members outside of the team, possibly introducing waste and inefficient hand-overs.
Teams get assigned to the work. I believe stable teams perform better than short-lived, temporary teams.
How do you ensure teams have knowledge of the technical component they will be working on? Or is this taken into account when assigning team members?
Totally unclear how Shape Up will work with bigger teams or scale with many teams. My initial impression is that it does not seem extremely scalable.
No moment of reflection built-in where people can chime in to improve the process. This is a missed opportunity.
Shape Up does not cover validation of what you’ve delivered, just discovery and delivery.
The voice of people who will perform the work in the betting process seems small, apart from key senior people. It would be nice to include the team more in the decisions on what will be worked on, so there is more buy-in.
In short, I’d not try out Shape Up as the risk of potentially throwing away six weeks is too big. And if you do it in a two-week cycle, I don’t think it’s very different from Scrum. With Scrum, you get a result at the end of every Sprint. Shape Up is less transparent about what you deliver, yet it is just as important to deliver something in the first week. If you need to achieve the same goal of delivering something that works early, I’d rather have that it is explicit, like with the Sprint approach of Scrum.
The main upside of Shape Up is the techniques that are presented in the guide, but those can be readily applied and adopted by any Scrum Team. I don’t see a need to restructure a Scrum Team that is performing well, just to deliver valuable things later, with more risk and less transparency than you have when you use Scrum.