Shape Up at Searchspring: How we use it and what we changed

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 blog will give 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. They run simultaneously: Shaping and Implementing.

Put simply, Implementing is when the engineers build software and release it into production. Shaping 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. This allows the engineering team to focus on other tasks like 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.

Shaping

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. This differs significantly from typical methods of estimation planning. 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. They 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. 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 tasks crop up. Spikes create an unknown amount of additional work. 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.

Implementing

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. A task hill 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 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.

Shaping in Isolation

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. Input from multiple people across multiple departments is really important to us in order to shape something that’s useful to our customer.

Throwing Out Work

Basecamp 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.

Ignoring Anything Unrelated

Shape Up is 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.

Miro/Product Marketing Process

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.