2 years with Shape-Up, and why we switched back

After 2 years, we decided to end our journey with the Shape-Up software development methodology. We hoped the longer cycles would help us ship projects faster, but ultimately we found the rigid structure wasn’t the right fit for our evolving needs. Here are my takeaways on why it was no longer a good match and what I learned from the experience.

Why we tried Shape-Up

At Customaite, we were sometimes struggling with projects that dragged on across multiple sprints and it felt we kept adding on to work-in-progress. Shape-Up’s promise of longer focus periods and value-based prioritization seemed very appealing to tackle these challenges in a different way.

For those unfamiliar, Shape-Up (developed by Basecamp) uses 6-week development cycles followed by 2-week “cooldown” periods. Projects are shaped into pitches with an ‘appetite’ specified. Unlike typical bottom-up estimates, which are very hard to get remotely right without already jumping into the work, the appetite looks at the problem from the expected business impact. How much is this worth to us, given the expected impact? The projects and appetites then make it to a betting table to decide what the eventual scope will be for the next 6 weeks. Projects must either ship within the cycle or be canceled altogether, to encourage cutting scope rather than cutting corners.

Focusing on fewer initiatives and prioritizing them in a different way seemed especially appealing to us at the time and worth trying out.

Planning perils

We particularly liked that project pitches needed to be backed up with a ‘falsifiable hypothesis’ on what the expected usage or impact is shortly after go-live. It forced us to think about value rather than just implementation details.

However, Appetite proved to be a difficult concept to calibrate for us. In theory, it acts as a maximum budget. In practice it was sometimes interpreted as a target duration (“this is a 3-week project”). We found that when we assigned a 3-week appetite, the work naturally expanded to fill that time which may actually encourage gold-plating. At other points these deadlines worked well to encourage scope adjustments and larger projects would benefit from this approach with less overhead.

But our biggest struggle was that our projects were often smaller than the standard cycle size. We found ourselves trying to plan several smaller projects into a single 6-week cycle, effectively trying to run a planning two months ahead to fill the bucket which is more difficult and less reliable than in a shorter cadence. We lost the flexibility to reprioritize every two weeks, but we didn’t gain the benefit of deep, singular focus on one large feature. It also meant ‘fast-follows’ on projects to steer impact had to wait until the next cycle.

Cooldown: a double-edged sword

Shape-up tackles specific software delivery challenges in an unusual way. And while there were benefits (we stuck with it for 2 years and kept iterating after all), the sword often cut both ways. The cooldown period is one such example.

Six weeks of planned project work is followed by two weeks of ‘cooldown’. It’s some buffer time to finish rolling out the projects, prepare the next cycle, and let devs decide which work to take on.

It’s an interesting concept to encourage important, non-urgent work to be done that’s often forgotten. It was one of the main avenues for me to plan projects that contribute to the technical roadmap, prioritize tech debt, perform updates, and run migrations. Part of the allure of Shape-Up is to increase the work being done and reduce talking-about-work (in Jira or large planning meetings). There is immense value in engineer-driven work: fixing a bug immediately is far better than throwing it on the backlog and re-discussing it every grooming session.

The cooldown is sometimes picked up as an infrequent ‘fix it sprint’ for teams doing Kanban or Scrum, but there’s a definite advantage to it being a recurring phenomenon. Because we all know cooldown is coming, work that’s not as important is often delayed for later to focus on shipping projects, knowing it won’t die forever on the backlog.

However, the sword cut in a different way.

Because we knew a cooldown was coming, we started treating it as a parking lot for everything that wasn’t a main project. We didn’t always succeed in ‘protecting’ that time once it arrived - urgent bugs, holidays, or spillover from unfinished projects often ate into those two weeks. We also found it counter-productive to cram every meeting (such as knowledge sharing sessions) into cooldown just to keep the 6-week cycle pure, turning what should be “creative time” into “administrative week.”

Finally, the frequency became a friction point. Waiting up to six weeks to address a small piece of technical debt or a minor annoyance created too much latency. By the time the cooldown arrived, the context was often lost, or it was difficult to coordinate the team to work on shared improvements because everyone had their own solo lists piled up. It also meant initiatives were fragmented across cycles over a large timeframe.

Focused, or too rigid?

Shape-Up is designed to have a team focus purely on their projects, and ruthlessly cut everything that is not directly related to it, lest they delete their code before the 6 weeks are up.

Shape-Up has strong opinions on focus, and our quest for it may have become too zealous at times, tossing out the baby with the bathwater. Not every ‘distraction’ from a feature project is necessarily harmful. Senior engineers still need to track more important non-urgent work or programs across the year, or prepare technical designs. At Basecamp, a separate team handled shaping projects for the next cycle. It does not work well if a team is doing both.

The only way we could even start to make this work was to split our resources. We tried a setup where only one team worked with Shape-Up, while a second team would shield them from ‘distractions’, including on-boardings, customer-facing work, and even on-call. We would shift the teams after each cycle to balance the work.

While this theoretically protected the Shape-Up team, it had its own set of challenges. It resulted in an uneven distribution of on-call work and required context-switching between domains and projects every time we rotated teams.

Six weeks is a lot of time to plan ahead for. Because we refused to delete code at the end of a cycle if a project was not in a state to be shipped yet, the deadline lost its potency. We found that locking ourselves in for 6 weeks meant we lost the flexibility to adapt to changing market circumstances or product usage compared to a standard sprint cadence.

Looking back

Every team evolves and as members join or leave, the “right” way of working shifts. Looking back, our Shape-Up experiment was addressing symptoms rather than root causes. We turned to the framework to create focus and discipline through process when what we really needed was clearer product direction.

Because we were in a phase where work was often reactive (greasing squeaky wheels), we struggled to fill the 6-week cycles effectively. However, as we established a new direction with better North Star metrics and OKRs, the equation changed. The longer 6-week cycle became a hindrance rather than an enabler. It made more sense now to re-adapt Scrum in shorter sprints with domain-focused teams with some changes than to cling on to what was now a rather heavy process we were forcing to fit.

I can see Shape-up being a useful framework if you’re in a similar situation as Basecamp: larger projects that seem to linger on, ideally with a separate team focused on design. The book itself is definitely worth a read.

That said, I still find the framework’s unique perspective on cooldowns and value-based thinking valuable. I try to carry these learnings forward, ensuring devs can raise ideas just as easily as they did during a cooldown, and lead technical initiatives with the same ownership as a feature project. Keep learning and iterating, and reflect if your process still fits the team.

Photo credit: Venti Views

• Previous
  Simplifying Code: migrating from Reactive to Virtual Threads