After years of various incantations of Agile, sprints, half-baked estimates, story points, and rolling deadlines, we decided to try something new: We decided to adopt Shape Up at Differential.

When Ryan Singer (and Basecamp) released Shape Up as a free web book in 2019, I read it immediately (and then again for good measure). I felt complete alignment between our experience with the software-development process and how Shape Up articulated its approach.

But how is Shape Up different than the traditional approach?

Cycles instead of Sprints

Instead of working in two-week "Sprints", we work in six-week "Cycles," which is long enough to do meaningful work, but not too long where you don't feel the deadline looming, which forces the right trade-offs.

But not every feature is given a full six weeks to complete. Sometimes our cycles break into multiple two-week or one-week projects. This gives us the flexibility in how we tackle the work while providing a consistent cadence for planning and alignment across our Product Teams.

Appetites over estimates

Instead of specifying arbitrary estimates, we define appetites to set a constraint for how long we're willing to spend on the work. This means we ask ourselves "how long are we willing to spend on solving this problem?" vs. "how long will it take to solve this problem?" While it's a simple shift in language, it has a measurable impact in how the work is approached.

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.

— Ryan Singer in Shape Up

We've seen benefits in this language when speaking with client partners. They're already naturally using the appetite language by talking about how much time, money, or energy they're willing to spend on solving a problem. This just establishes better language for how it's communicated.

Shaping the project

In an effort to combat the unknowns in software development, the typical solution involves defining tasks before the work begins. But therein lies the problem: You can't imagine the work that needs to be done; you have to discover the work, which means handing responsibility over to the team and letting them find the lines of the work when the development begins.

Instead of creating an imagined list of tasks before the work begins, we create a pitch to define the solution at the right level of abstraction, taking into account the inevitable unknowns the team will encounter when the real work begins.

The goal is to define a project, not tasks. We set the guardrails in the pitch — even taking time to technically de-risk the solution — but we don't create the tasks for the team to work on.

Handing over responsibility to the team

Instead of daily stand-ups and status meetings, **we hand over responsibility to the team so they can define the lines of the work and deliver on time. **But handing over responsibility to the team means more than just giving them the right guardrails and freedom to do the work — it means dedicating their time and giving them the focus to complete the work.

Fixing the time, varying the scope

While there is a hard deadline — as defined by the appetite in the pitch — the team has the ability to vary the scope. The scope is mutable, and the deadline exists to force the trade-offs required to ship on time.

Our teams continually evaluate what is "core" — that is, what has to be included in the feature to ship — vs. what is a "nice-to-have". These are the decisions made in order to deliver working software on time. And it only works when the team is empowered to make those decisions.

Creating a sense of calm focus

Instead of finishing a project and immediately moving onto the next one, we have a two-week "Cool-Down" after each six-week cycle in order to tackle fixes, improvements, and plan the next cycle. We also take this time to do our retrospectives and share what we're working on across our Product Teams.

Disposing of "backlogs"

"Backlog" has become a loaded term designed to define a collection of tasks that is continually reviewed and prioritized. However, the problem is the list of things to do becomes a demotivating list of things we'll never have time to do.

Instead of maintaining massive backlogs, we start with a clean slate each cycle knowing the highest-priority items will continue to float to the top.

Finding our own flavor

While we've found tremendous value and alignment around Shape Up, we're continuing to iterate and refine the process at Differential. There is never a one-size-fits-all solution to software development (or most things), but Shape Up defines clear, simple, and realistic principles that have improved our process.

Our mission is to rapidly unlock value for good people with meaningful ideas, and Shape Up has helped us do that even better than before.