Why and how we switched to Shape Up for product delivery

A few months back, we embarked on a journey by adopting 37signals ' Shape Up methodology for our product development and delivery process. Our path here has been shaped by learning from failures, regular adjustments, and finding the right fit for our team. Not everything is perfect yet, but in this article I want to share a snapshot of our experiences so far.

At Menlo79 GmbH , our journey began with an earnest attempt using Scrum, followed by Kanban methodologies. Despite our best efforts, something was missing, and the expected results remained elusive. We then tried the shift towards a more project-based approach for building the larger features and modules into our product. While the process worked well for some projects, we found that it lacked structure, planability and a common language. Delays, dependencies, not having the right people available at the right time, and unclear outcomes were becoming all too familiar.

This led us to Shape Up - a framework that not only addressed our challenges but reshaped our approach to product delivery.

What is Shape Up?

The Shape Up framework is a project management methodology developed by Ryan Singer , designed to help teams work on complex software development projects more efficiently. The framework is organized around three main phases: Shaping, Betting, and Building.

During the Shaping phase, the team focuses on understanding the problem and exploring potential solutions. This involves creating a pitch, which outlines the problem to be solved, potential solutions, and the expected outcomes. The pitch is then evaluated to determine whether it's worth pursuing further.

In the Betting phase, the team (in close alignment with the management) works on developing a plan, which outlines the scope of the project, the resources needed, and the timeline. The "bet" is then evaluated to determine whether it's feasible and financially viable.

During the Building phase, the team works on executing the plan and building the feature. This phase is divided into six-week cycles. In the cycle, teams self-organize to break-down the shaped concepts (pitches) into tasks and ship it within the defined time-frame. At the end of each cycle, the team evaluates the work done and decides whether to continue with the project or make changes to the plan.

Shape Up is targeting a specific risk: the risk of not shipping on time. The risk of building the wrong thing is part of the product discovery, which is a topic in itself.

Our journey with Shape Up

To align Shape Up with our unique requirements, we made a few adaptations.

Cycles

One significant difference between the textbook Shape Up and our implementation was the structure of the cycles. We shifted from 6-week cycles to 4-week cycles and opted for a 1-week cool-down period instead of two.

Planning and team topologies

While 37signals has a "pool" of people from which the project teams are reassembled in each cycle, we work in cross-functional, cohesive teams. Each team contains a Product Manager, Designer, QA, and around five engineers. This was another point where we had to adapt the framework to our needs. We decided to plan the projects and cycles per team.?By limiting simultaneous projects to two per team, with 2-4 engineers per project, the goal is to ensured focus and efficiency. On the one hand, this has taken away flexibility in planning - but we are convinced that the advantages of having teams constantly working together outweigh the disadvantages.

Shaping and Building tracks

37signals was able to set up two tracks for their team members - one track who only shapes and one who builds. We don’t have the luxury with an eye on our time size. Most of the concepts are prepared and driven by the product management. Our most senior engineers and designers need to reserve time for contributing to the shaping while still supporting hands-on in the building phase.

The role of design

While 37signals' structure includes a substantial ratio of designers to engineers, we had to take a slightly different route. We moved more design work into the shaping phase with the goal to ensure that we can answer important UX and design questions and reduce usability risks before the project start. This does not mean, that the fully blown Figma click-dummy needs to be available before project start. Every project is still supported by a designer so that teams keep the flexibility to figure out the final elements/designs/interactions in the refinement along the way.

No backlogs?!

37signals supposedly does not keep a backlog. Everyone tracks what is important to them and prioritizes it in the form of a pitch. We still track and manage feature ideas in Productboard and do a first prioritization of what we want to shape next. We also track bugs and smaller tasks in Jira to have a backlog for idle time or cool downs.

Assign projects, not tasks

A perceivable and intended shift emerged in the way we approached problem-solving. Instead of top-down mandates and tasks prepared in detail, common in traditional frameworks like Scrum, we fostered self-organization within teams. At the start of each cycle, the Product Manager outlines the plan and solution for the problem to be solved in a project kick-off. Within the project, the team is responsible to define how to implement the solution and to break down the work into relevant scopes and tasks, while always focusing on the most critical paths to ensure to deliver "some" solution to the problem outlined in the pitch.

One of the most important guidelines from the framework for us is the following: Fixed time, variable scope. Teams need to decide along the way what they can leave out or where they can make compromises and short-cuts while still solving the overarching problem for the user.

Teams manage their work in Jira. One epic represents a project. User stories represent the scopes of the projects whereas subtasks of the stories are the individual tasks the teams breaks down to fulfil the scope.

Handling Bugs and Refactoring

Critical bugs are dealt with immediately, while non-critical ones are bundled and prioritized for the cool-down weeks or as a collective project. Testing and QA is an integral within the cycle, aiming to ensure completion by the cycle's end.

Retrospectives and Communication

Even as we embraced Shape Up's principles, we retained the essence of retrospectives. Learning from each cycle's experiences remains crucial. Some teams also still find daily stand-ups effective for communication, while the cool-down weeks allow for reflection and learning.

Summary

Our journey from traditional methodologies to Shape Up reflects the dynamism inherent in product delivery. The switch was not without its challenges, but it feels it brought us a bit closer to the ideal.

During the first cycles, we had to deal with unfinished work that was moved from one badge/project to the other. Additionally, we discovered that we had not considered the buffer for testing and QA work within the projects sufficiently. Finding the right balance between how much to already invest into Shaping vs. what is part of Building remains a common challenge. Aligning the team with what is possible within the given timeframe and setting the right scope for projects are also things that can be continuously improved.

However, the framework has delivered a common language across our organization and enhanced planability. Cycles are now our roadmap, guiding us with more precision than before. By adapting Shape Up to our unique context, we've improved empowerment, structure, and a renewed sense of direction. We are excited to continue using the Shape Up process and further improve it to meet our needs.