Tech.Zealot

As a manager, one of the biggest challenges is figuring out which software development methodology works best for your team. These processes are meant to enhance productivity, but choosing the wrong one can have the opposite effect. Agile and Scrum are the most prevalent methodologies today, while Waterfall still finds its place in larger, more conventional tech companies. Over the course of my career, I have experienced Agile, Waterfall, and Shape Up across different teams and products. However, my most striking experience was with Shape Up—a process that, within just two months, nearly dismantled our team.

This happened only a month after I joined my current startup, and the lessons I learned from that period were invaluable. In hindsight, one of the key takeaways was that before choosing a development process, you first need to truly understand your team.

What is Shape Up?

Shape Up is a software development methodology introduced by Basecamp, designed to increase productivity by ensuring that the right people work on the right features. It operates in six-week cycles, during which teams go through the phases of shaping, betting, building, and shipping. Teams are structured as small, functional groups composed of designers, front-end developers, and back-end developers. Each team is responsible for delivering a complete functionality from top to bottom.

In our case, we had about 14 developers split across three teams, each tasked with a specific feature. The process is unique in that there is no backlog—only bets on what should be built. Progress is tracked through hill charts that highlight unknowns in the scope. Another distinct feature of Shape Up is its rigid approach to time constraints: teams must deliver within the six-week cycle or risk having the entire project scrapped.

While we adopted most aspects of Shape Up, our approach was an almost implementation. And therein lay the problem.

For more on shape up: https://basecamp.com/shapeup

The Pitfalls of an “Almost” Implementation

There are inherent risks when a company partially adopts a process without fully committing to its structure. For us, two major issues arose: the betting phase and ownership of decision-making.

Betting on the Wrong Features

The betting phase determines what the team will work on for the next six weeks. This is a critical step—it sets the tone for the cycle, ensuring that the chosen features have a strong business impact, align with the team’s motivation, and are feasible within the given timeframe.

In theory, this sounds great. However, in practice, it went horribly wrong for us. The features we bet on required significantly more effort than initially estimated. As a result, our teams were forced to work late nights for nearly two weeks straight, leading to burnout, frustration, and a massive drop in morale. While the feature was eventually shipped, the exhaustion it caused was unsustainable.

Shape Up suggests reducing scope when teams are overwhelmed. But in our case, the team had no say in the decision-making process. This led to our second major issue.

A Lack of Ownership

According to Shape Up’s principles, teams should be given full ownership of their work, making decisions collaboratively based on both business and technical considerations. However, in our implementation, upper management (C-level executives) dictated what was built, both before and after the cycle began.

This significantly altered the dynamics of the process. Instead of a lean, autonomous team making decisions, leadership overrode the team’s insights and technical constraints. From their bird’s-eye view, the features seemed incomplete, buggy, or insufficient—without understanding the trade-offs and limitations that the team had worked through. As a developer, I felt that our team’s recommendations were not effectively communicated or considered by decision-makers.

The Missing Metric: Team Capacity

Another factor that could have prevented this burnout was understanding the team’s development capacity. In Scrum, this is referred to as velocity—a metric that quantifies how much work a team can complete within a sprint. Had we been more aware of our team’s capacity, the betting phase could have been managed more effectively.

Additionally, the sketches and vague requirements used to pitch features often lacked clarity. This resulted in constant back-and-forth discussions at the start of each cycle, further delaying development. The process of refining requirements became exhausting, requiring squad-level discussions followed by rounds of approval from decision-makers.

In a startup, where resources are limited, tracking team velocity can be challenging. However, I later realized that understanding the team’s working rhythm is more important than rigidly adhering to a predefined process.

Transforming Shape Up Into a Process That Works

Despite these struggles, Shape Up was not a complete disaster for us. Instead, we adapted its principles to create a process that better suited our team. Here’s what we changed:

• Retaining the squad-based approach – We found that small, cross-functional teams worked well for collaboration and visibility.
• Breaking down features into smaller pieces – Instead of committing to six-week cycles, we shifted to two-week sprints, making workloads more manageable.
• Giving the team more control – Teams were given greater autonomy in defining their scope and deciding how to tackle problems.

Reflecting on this experience, I’ve come to appreciate that no single process works for every team. While Shape Up has its strengths, its success depends on how well it aligns with your team’s needs and organizational structure. The key takeaway? Know your team before choosing a methodology. Process should serve the team—not the other way around.