Building a product using Shape Up methodology.

What is Shape Up?

Shape Up was created by the founders of Basecamp and is broadly based around three phases of work that happen within a “cycle” — typically 6 weeks in duration:

1. Shaping: product owners and designers, with the help of engineers, come together to define a specific problem, propose a solution and decide what the appetite is (we’ll go into this later). The key here is getting the design to the right level of abstraction i.e. concrete enough that the team knows what to do, yet abstract enough that they have room to work out the interesting details themselves.

2. Betting: shaped projects of work are brought to the “betting table” where the team decides which projects to work on this cycle. Any projects that don’t get selected are not kept in any structured way (i.e. no backlogs!).

3. Building: a team of designers and engineers work on delivering the project, and are given full responsibility for figuring out the tasks and details required to do so. Projects are either completed within the 6-week cycle, or they are killed using a “circuit breaker”— there are no arbitrary extensions on delivery time (or at least very rarely).

The cycle is followed by a two-week “cool-down” where shapers can focus on preparing the next projects to pitch, and builders can work on bug fixes, improvements and even their own ideas for adding functionality and value to the product.

You can read more about Shape Up in detail here: https://basecamp.com/shapeup

Why we like Shape Up at rebank

Two parallel tracks: Shaping and Building

Often when working in agile teams, it can be difficult to find enough time to properly “plan” work as you’re working on a perpetual two-week sprint cycle. Shape Up involves working on shaping and building separately in parallel. So while the builders are working on delivering the projects that were successfully pitched for the cycle, the shapers are speaking to customers and deciding what work to pitch and then bet on for the next cycle.‍

Assign projects, not tasks‍

Assigning “tasks” to engineers reduces them to grunts or “code monkeys” and can be horribly demoralising as a consequence.

Instead, the shaping process allocates sufficient time to properly understand and de-risk a body of work — which is then given to engineers to work on uninterrupted for up to six weeks (depending on the “appetite” — we’ll get to this shortly). Engineers use their creativity to find and build a solution and have a complete feature to deploy at the end. High fives all round!

Slice projects vertically, not horizontally

Typically in scrum, tasks are sliced “horizontally” and assigned to engineers depending on the discipline: backend, frontend, database etc. However, this creates a disconnect between the goal of the project and the actual work. Shape Up slices work vertically (by default) into user functionality e.g add user, edit user, delete user which gives the build team distinct, releasable features to work on and maintains a focus on customer impact first and foremost.

Focus on appetite, not effort

The seemingly default behaviour when evaluating a task in a sprint cycle is “how long will this take?” (i.e. effort). Instead, Shape Up focusses on “how much time is this project worth to us and/or our customers?” (i.e. appetite) and is grouped into two “batch” sizes — small batch (1–2 weeks) and big batch (3–6 weeks).

Fixed time, variable scope

In a typical sprint cycle, a task you thought was going to take two weeks but is actually going to take four weeks just gets shifted into the next sprint.

There are a few problems with this:

1. You’re diluting the value of your time — the value this task provides is static while the time you spend on it increases.

2. Tasks that continue with arbitrary timelines create morale problems for both product teams and the wider company. You need regular wins!

3. Having tasks that “just take as long as they take” can erode the sense of urgency in product development which can be fatal for startups.

Having a hard deadline on a project means that you’re forced to focus on the highest impact tasks, hammer the scope accordingly and deliver the project according to the agreed appetite.

No backlogs

Backlogs are terrible for morale as they create a perpetual sense of falling behind even though you’re not, and they can be a time sink to maintain.

“But we’ll forget what we need to work on?!” you say…

Any project that is important enough will keep being brought to the betting table. If you need a backlog to remember it, then it’s not important.

Communicating progress with hill charts

Communicating progress shouldn’t require people constantly asking questions like “where are we up to with x”. It can be very difficult for those outside of the people directly building something to know exactly how far along we are on a project.

Shape Up uses hill charts to communicate progress on a given “scope”. “Every piece of work has two phases. First, there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then once we can see all the work involved there’s the downhill phase of execution.”