Basecamp is a project management and communication platform, widely known for its innovative software development practices and novel ways of working. Ryan Singer, Basecamp’s Head of Strategy, recently captured Basecamp’s approach in Shape Up, which is freely available online and as a PDF. The product development process at Basecamp consists of three distinct stages: shaping, betting and building.

Basecamp typically work in six-week cycles, building and releasing new features within that timeframe. The work is shaped first before it’s given to a team to work on. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before considering a project ready to bet on. Interestingly, shaping is less about traditional estimation of development work, and much more about appetite. Instead of asking how much time it will take to do some work, people at Basecamp will consider how much time they want to spend on a specific piece of work; how much is this idea worth?

Shaping

When shaping a solution, the aim is to strike the right balance between ‘too vague’ and ‘too detailed’. Wireframes are deemed too concrete, whilst words are often too abstract. The reason why this balance is important is that the scope of a project needs to be flexible enough for the team to come up with appropriate design solutions whilst not running the risk of growing out of control due to a lack of boundaries.

These are the main steps to shaping:

Set boundaries – First figure out how much time the raw idea is worth and how to define the problem. This provides the basic boundaries to shape into.

Rough out the elements – Then comes the creative work of sketching a solution. At Basecamp, they do this at a higher level of abstraction compared to wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.

Address risks and rabbit holes – Once there is the feeling that a solution has been found, the goal is to find holes or unanswered questions that could trip up a team. The solution gets amended accordingly, tricky things removed from it, or specified details at tricky spots to ensure that a team doesn’t waste time or gets stuck.

Write the pitch –  When the solution is shaped enough to bet on, things are packaged up formally in a pitch. The pitch summarises the problem, constraints, solution, rabbit holes, and limitations. The pitch then goes to Basecamp’s betting table for consideration.

Ryan Singer writes about how Basecamp uses the technique of breadboarding, a concept borrowed from electrical engineering. When breadboarding, three things are drawn:

Places – These are things you can navigate to, like screens, dialogs, or menus that pop up.

Affordances – These are things the user can act on, like buttons and fields. Interface copy is considered to be an affordance too, as reading it is an act that gives the user information for subsequent actions.

Connection lines – These show how the affordances take the user from place to place.

I like how words are used instead of pictures, focusing on the solution’s components and the connections between them and allowing you to figure out an idea. Importantly, this technique allows you to judge if the sequence of actions serves the use case you’re trying to solve.

If the idea being considered is a visual one. In this case, breadboarding would be insufficient because the visual representation is the fundamental problem. At Basecamp, wireframes wouldn’t be created in this circumstance, but fat marker sketches would be created instead. A fat marker sketch is a sketch made with such broad strokes that adding detail is difficult or impossible.

Bets, Not Backlogs

Singer explains how at Basecamp backlogs are viewed as time wasters; the time spent constantly reviewing, grooming and organising ‘tickets’, working on a list of items that might or might not get done. By contrast, Singer talks about holding a betting table before each six-week cycle. At the betting table, stakeholders evaluate pitches from the last six weeks, or any pitches that somebody purposefully revived and lobbied for again.

Taken from: The betting table at Basecamp consists of the CEO, the CTO, a senior developer and product strategist (Ryan Singer himself). The main reason why Basecamp use bets instead of plans, is the difference in expectations set when talking about bets:

Bets have a payout – Solutions are deliberately shaped into six-week projects so that there’s something meaningful that’s finished at the end. The pitch defines a specific payout that makes the bet worth making.

Bets are commitments – If a bet is made for six weeks, then the relevant people will get six weeks to work exclusively on that thing for six weeks, without distractions.

Bets have a cap on the downside – When a bet is made to work on something specific for six weeks, the most that you can lose is six weeks and thus avoiding a situation where you’re spending multiples of the original six-week commitment on a solution.

 

Build your way uphill

This section of “Shape Up” starts with a great and very true point about the unpredictability of development work: “This goes back to the notion of imagined versus discovered tasks. In our naive notion of a list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.” Also, numeric estimates of pieces of work often don’t take into account the level of uncertainty involved in different tasks. Basecamp have recognised this and instead use the metaphor of the hill, which concentrates on what’s unknown and what’s solved:

The idea behind this hill is that anyone in the company can see at a glance where things are at. If a task been ‘uphill’ for while, why is that? What unknown is holding it up? Or perhaps the item on ten hill consists of a number of smaller items. The hill helps to see what is stuck and what has been done, or getting close to being completed.

Main learning point: I found “Shape Up” a very helpful and insightful book. Not only does it provide a great insight into Basecamp’s approach to developing products, it also made me reflect on my own ways of working – and the teams that I’m part of. Highly recommend reading “Shape Up” if you’re interested in learning about alternative ways of developing software products or collaborating during the product development lifecycle.