What is Shape Up, or giving shape to ideas

Shape Up is a term coined by Basecamp, a company that has been building software for more than 15 years. It started with a team of just 3 people and today is a point of reference, including in terms of product strategy. The concept of shaping comes from a book, also available online, written by Ryan Singer, describing how the company works. You might think the book is only valuable for organizations that want to adopt similar work cycles — in fact, it offers broad, valuable insights for any company that does development and design and struggles with the usual problems: not shipping regularly, never managing to stop and think strategically about what to build and how, or getting so caught up in plans and estimates that they lose sight of the actual work.

Some working methods and processes emerge naturally in every company, especially among people who have worked together for a while — but when onboarding new people, or simply when explaining to the outside world "how we do things when we do them well", the need arises to put all these concepts down in writing. That is why Shape Up was born, and it is the same reason why at Cantiere we write and maintain internal guidelines for everyone.

Shaping is a process we include in sprint planning, the phase that comes before actual development and that starts from a specific business or strategic need. In other words, it is one of those moments when we take in a stakeholder need and try to understand it better on every level — technical, production and strategic — before we are confident we can hand it to the production team with the lowest possible risk. If we wanted a dictionary definition, we could say that shaping is all the preliminary work of setting boundaries and reducing risk that is done before a project is assigned to the team.

We can break shaping down into these distinct phases:

• Identify problems and goals at a high level;
• set an appetite, meaning how much time you are willing to invest in developing an idea;
• match the idea to the appetite, meaning narrow down the problem and find a solution that fits within the planned appetite;
• present the work to the team at the right level of abstraction.

The output of this process is therefore a presentation of the idea (or a pitch, as the book calls it) that must have three essential properties.

The team doing the shaping must not make the most important decisions at the moment when it has the least information. The team could end up locked in to decisions already made that might later prove to be poor ones.

Not too concrete: No detailed wireframes are provided, only very rough sketches that do illustrate the idea but leave the team room to apply its own judgment. Say the team is handed a wireframe with a sidebar on the right — even if it is just a suggestion, the team will still be influenced by that constraint.

Not too vague: Nobody can understand the problem and the solution if they are presented only in words, with no indication of what to cover and what to leave out. A striking example is the calendar, a new module Basecamp recently added, which is a good use case for showing why abstract ideas need to be given shape. "Build a calendar" can mean everything and nothing: designing and developing the ultimate calendar with every conceivable feature could take months or years of work — the real goal of shaping is to determine the 10% of features to build, the most strategic among hundreds of options, within a fixed amount of time. For Basecamp, this time is one work cycle, which is always six weeks: in other words, time is fixed and scope is variable. At the end of the six weeks, the same people who bet on the calendar must be able to look back and say "yes, it was worth it". Basecamp is not a calendar company, after all.

The team is presented with both the problem and the solution. Besides looking at it strategically, the team doing the shaping analyzes the problem from a technical point of view and can identify the biggest risks that implementing a new feature, for example, might bring. We explicitly ask what could go wrong, to avoid so-called rabbit holes, holes you can keep digging into forever without reaching a solution. A good pitch makes these risks visible and puts them on the table right away. A good way to find these holes is to imagine a use case and walk through it very slowly from start to finish. In short, the probability curve of a project whose biggest risks have been declared should fall very close to the planned deadline. But be careful not to assume that every risk can be found during shaping: I will come back to this point later.

The first information to give the team is the boundaries it has to work within. The appetite is what sets those boundaries: Basecamp is a company that works in fixed six-week development cycles, after all, as we mentioned when talking about the calendar. These limits set expectations and act as imaginary guardrails that help the team stay focused on the problem to solve. By his own account, Singer could have kept writing more chapters of the book if he had not given himself an appetite of time. Remember that there is no such thing as the best solution in absolute terms — a full three-course meal is better than a sandwich in absolute terms, but if you only have 5 minutes, a sandwich is the best solution. The appetite and a looming deadline inevitably drive decisions: one week before a book is released, would you focus on proofreading it and fixing typos, or would you write another section?

Once an idea has been analyzed and gone through shaping, it does not end up in a backlog of things to do. Those ideas would pile up on top of each other in a sort of task graveyard that could never all be done — rather than constantly feeling behind and wasting precious time choosing and organizing old ideas that may no longer be relevant, we bet on one pitch per work cycle. At this betting table sit the people who act as "ambassadors" for a given project: on the table are only ideas that have already been analyzed and could potentially be developed, and one of them will be chosen as the bet and handed to the team. Any idea on the table — perhaps revived after some time — is brought by a person, in a specific context, with a goal, and driven by a need that is real at that precise moment.

Singer is very careful with words: he never uses the term "plan", because it does not explicitly include the risk factor that is inherent in software development. You do not plan ideas, you bet on them — you use the language of risk, not of certainty. The reality is that we do not know exactly what will happen during a project's development, especially when new concepts are introduced or there are interdependencies between components. A work cycle is how much you are willing to bet on an idea, and if for any reason the project is not finished at the end of the cycle, there is never bonus time to finish it. A lost bet means losing 100% of what you put on the table, and nothing more — if there are six weeks on the table, a failed bet will cost all six, but not a day more. It is a bold choice, but according to Singer it works in favor of employee morale: imagine giving the team a job we think will keep it busy for two months, and imagine that after six months it still is not done. The team's morale would surely be at rock bottom.

Another key concept, and a truth sometimes forgotten in software development, is the difference between the work we imagine and the real work. We are naturally bad at giving accurate estimates for the things we are about to do: we think we can tidy up the garage in a morning, only to find it could take 3 full days. Development and every other creative discipline are fertile ground for these dynamics — you start with the most obvious tasks, the ones others depend on, only to discover that just as many are hidden below the surface and only emerge later, perhaps in the second or third week. That is why another promise made to the development team is not to disturb it during the work cycle — periodic check-ins would be counterproductive and misleading, because there could still be interdependencies or surprises that have not surfaced yet.

Scope creep (in Italian, the closest translation is kitchen sink syndrome) is a dynamic that occurs in project management where the scope (or breadth of the project) grows out of control as development proceeds and you run into not only things that should be done, but also things you think need doing. The team must be especially good at recognizing all these deviations from the project's primary goal and at telling the nice-to-haves that distract from the must-haves. The team has a huge responsibility in making these cuts and staying true to the original goal, without stuffing the project with features that were not in the brief.

If this article sparked your curiosity and you would like to know how Cantiere Creativo applies shaping concepts to its work, get in touch and let's talk.

Much of the content in this article comes from Shape Up: Stop Running in Circles
and Ship Work that Matters, which you can read online at this link.