Shape Up is a product development process that helps engineering teams to ship high quality products efficiently. Created by Basecamp, it’s an alternative to Scrum that focuses on how a team works together. We follow much of the Shape Up methodology at Searchspring, with some slight adjustments to accommodate our specific requirements. If you’re thinking about joining our engineering team, this should give you an insight into how we work, and what Shape Up looks like to us.
What is Shape Up?
Shape Up follows eight week cycles, comprising six weeks of building product (the Bet Cycle), and two weeks of engineering-only work (the Gap Cycle). As shown in the graph, there are two phases in the six week bet cycle that run simultaneously: Shaping and Implementing.
Put simply, Implementing is when the engineers build software and release it into production. Shaping, meanwhile, involves the architects and team leads of those systems getting together with the product team and stakeholders to figure out what to build and how long it will take to develop the next new product.
In between those two phases is the Gap Cycle, which allows the engineering team to focus on other tasks – learning, cleaning code, maintaining production systems, and so on. It’s also the period when most meetings take place, as developers are protected completely from interruptions during the Implementing phase. No meetings, from 9am – 5pm for six entire weeks.
Towards the end of the Gap Cycle, we have the Betting Table meeting. This is when the ideas for new products (or bets) are presented, evaluated, and chosen. Following that, resources are allocated, developers are assigned, and the next phase begins.
The Shaping phase seeks to strike a balance between work estimations that are too concrete or too abstract. There’s an important concept called “appetite” in Shape Up, which differs significantly from typical methods of estimation planning.
You’re probably familiar with the concept of scope, which defines the boundaries of a new product and requires engineers to make an educated guess as to how long development of that product would take. If you turn that on its head, appetite asks the question: how long do you want to spend developing an idea? If it’s going to take longer than six weeks to build, do you still want to proceed?
During the Shaping process, the product team presents an idea, and they also come prepared with the maximum amount of time they are willing to spend on developing this feature. Instead of immediately eliminating ideas that don’t fit the desired appetite, the engineer can suggest cuts that would allow completion within the specified timeframe. Ultimately, the product team can then make a decision on whether to proceed with an idea, or throw it out and pursue an alternative.
Shape Up emphasizes the need to give engineering teams full autonomy while building. Entire projects are assigned, as opposed to disparate individual tasks. If you’re familiar with Scrum, you’re used to chopping work up into small blocks as part of backlog and sprint grooming. Those tasks then get put into a sprint with an estimate of how much your team can get done in a week, and based on how much work you completed in previous sprints, you estimate how much you can get done in this sprint. But it never really works out as surprise work crops up, spikes create an unknown amount of additional work, and the developer who picked up a task can vary wildly in their ability to complete it in the time estimated. All of this variability risk is captured in the shaping phase and mitigated by your most senior team members.
In the implementation phase, slices are chunks of work that can be released into production. Slices should be vertically sliced all the way through the stack, from the UI to the database, to avoid a mismatch at the end. A vertical slice through the product will unearth all of the risks and issues with scope early on.
A critical tool for visualizing risk in Shape Up is the task hill, which allows product owners to identify risk in real time, without having to distract the engineers. Uninterrupted work is a core principle of Shape Up, and the task hill has also allowed us to get rid of our daily engineering standup. Now, if an engineer is blocked, they raise it on Slack immediately.
Some of the things we changed
We’ve adopted most of what Basecamp does at Searchspring, but not all of it.
Basecamp talks about shaping in isolation: putting a product owner alone for a long period of time to come up with ideas. We wanted to involve more stakeholders. The product that we build is very complicated, and most people involved in building it have never been a merchandiser – the person we are building the product for. Input from multiple people across multiple departments is really important to us in order to shape something that’s useful to our customer.
Basecamp also has a very hard line about throwing out work if a bet goes over time. We currently don’t do that. If it looks like we’re going over scope, we get together as a product and engineering team to de-scope, so that we can still release something usable in the six week timeframe. Right now at Searchspring, we are confident that the bets we’re producing are relevant for our customers. If we slightly miss the timeline early on, it’s okay. In the future, we might adopt this policy.
Shape Up is also fairly militant about ignoring anything unrelated to the current bets for six weeks. We recognized that this wouldn’t work for us as we have customers to support on a daily basis. However, uninterrupted time for developers is incredibly important if you want to produce a lot of high quality software, quickly. So, we created a brand new team called the Bug Hero team, as a defence mechanism for dealing with those distractions – deprecation notices, bugs, fires, and any other unexpected work that needs to be done during that time. Developers are rotated on and off this team so they’re not doing Bug Hero work all the time.
We also introduced Miro, an online whiteboard tool that allows us to collaborate in a distributed environment. And, we added a product marketing process. Once a bet has been chosen, we immediately spin up the marketing process so that when we hit our six week deadline, we have already built our go-to-market strategy.
Shape Up at Searchspring
There’s a lot more to Shape Up than I’ve outlined here, and I highly recommend Basecamp’s ebook if you’d like to learn about it in more detail. It’s proven to be a highly effective methodology for us at Searchspring, and adapting it to our requirements has enhanced our output even further. If having six weeks of pure, uninterrupted time to build software appeals to you, we’re always on the lookout for engineers to join the team. You’ll find our current open positions here.