Why we transitioned from Sprints to Basecamp’s “Shape Up” methodology

When experiencing team growth, things you did yesterday often won’t work for today. New problems need new solutions.

Let’s keep it 💯 — our two-week sprints weren’t working anymore. I mean they were ok we were shipping stuff at a decent velocity, but there were cracks showing in our process. Especially as we were experiencing hypergrowth (raised $39M Series B), we knew there had to be a better way to ship the most impactful features for our users and business.

So why weren’t the two-week sprints working?

There were a number of reasons why we decided to investigate our previous sprint process, but the main ones included:

• Large epics always overlapped into additional sprints
• The continued sequence of sprints gave us little time to pause, review, and refine the process itself
• Product team was spending too much time on what was being built now (ticket monkeys) instead of understanding our customers better and validating what should be built next
• We were growing rapidly and scalability was important: What worked yesterday doesn’t always work today.

And why not just make our sprints longer?

For us, we knew extending sprints to 4 weeks would solve some of our problems but not as many as we’d like. Specifically, we knew we weren’t utilizing the full potential of our dev and product teams by having everyone focus solely on the now. We knew we needed a team to focus more on what’s most impactful not only now, but next and later via obsessing over our customers/business needs, and validating these learnings before building.

How did we end up with Shape Up?

It wasn’t as simple as picking Shape Up off the shelf and running with it. We had many radical candor conversations about what was working, what wasn’t, what we’ve learned, and what’s ideal for us as a team. Remember, not every process is for every team — you need to understand what does and doesn’t work best for your specific team. What are your team’s strengths? What do you need to get better at? Reflection every few weeks is key to growth.

For us, we knew one of our strengths was a strong and motivated dev team that didn’t need babysitting via frameworks like story points or throughput metrics. On the product team our strengths were uncovering and diving deep into problems, hyper-prioritizing around goals, and doing obsessive research to fully understand our users and stakeholders.

While we were having process review meetings, a new hire (now Head of Engineering) suggested we all read Shape Up: Stop Running in Circles and Ship Work That Matters (it’s free to read btw). Upon reading this and having more detailed discussions, we felt a lightbulb moment as a group. Shape Up highlighted a lot of the same problems we were having and offered a solution for the majority, all while aligning with our strengths.

Shape consists of six-week cycles

Work is done in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and still short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The goal is to build, QA, and release in one six-week cycle.

Our decisions should solely be based on moving the product forward in the next six weeks, not micromanaging time. We say to ourselves:

“If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.”

Then we commit the six weeks and leave the team alone to exclusively get it done with no interruptions.

Dual Tracks: Shaping & Building

Unlike Agile processes where the team breaks a large body of work down into smaller sprint-sized chunks and starts to build them, Shape Up instead holds fixed the time to release a chunk of work to customers and focuses on “shaping” work into that time period. Teams are no longer asked to juggle multiple things simultaneously but instead are asked to swarm a project together and give it their undivided attention to see it through to completion.

During any six-week cycle, teams are building work that’s been previously shaped, and shapers (for us, our product managers & designers) are working on what the teams might potentially build in future cycles.

Two tracks when in-cycle (6 weeks):

1. Building: Uninterrupted work on approved pitches
2. Shaping: Gathering requirements for the next cycle

Shaping pitches

I can easily spend an entire article getting into the nuances of shaping, but it’s essentially a PRD or product requirements document, but referred to as a “pitch”, for what the teams might potentially build in future cycles. The key word here is “might”. Since business and product priorities change, so will the decision on what to build. Work on the shaping track is kept private and not shared with the wider organization until the commitment has been made to bet on it (see “betting”).

The make-up of a shaping team is up to you, but it’s typically led by a product manager with relevant stakeholders (design, customer experience, engineering, etc.) chiming in where they might have knowledge on the pitch. The main focus of shaping is to go really deep into understanding the problem before drafting any solutions. Understand the audience (users or stakeholders) and any insights (qualitative or quantitative) that help you understand the problem or the user more.

The Pitch’s ingredients include:

• Problem Statement
• Audience
• Insights
• Appetite
• Solutions
• Rabbit Holes
• Out of Scope (no-gos)
• Success

I highly recommend reading Chapter 6 of Shape Up (Writing the pitch)” to learn more about each of these sections.

Building pitches

Once a pitch is “bet” on, we commit to building and releasing it within the last 6-week build cycle. It’s not the PM’s job to just start assigning tasks. Nobody plays the role of the “taskmaster” or the “product owner” who splits the project up into pieces for other people to execute. And developers are no longer treated as ticket takers or “code monkeys”. Splitting the project into tasks up front is like putting the pitch through a paper shredder. Everybody just gets disconnected pieces without being responsible for judging how all the pieces fit together.

A core tenant of Shape Up is that we want the project to stay “whole” through the entire process so we never lose sight of the bigger picture. Trust the team to take on the entire project and work within the boundaries of the pitch (see setting boundaries/appetite). The team is going to define their own tasks and their own approach to the work. They will have full autonomy and use their judgment to execute the pitch as best as they can. Projects usually turn out better when the team is given responsibility to look after the whole.

Nobody can predict at the beginning of a project what exactly will need to be done for all the pieces to come together properly. Work in the first few days doesn’t look like “work.” No one is checking off tasks. There aren’t any deliverables to look at. Often there isn’t even much communication between the team in the first few days.

Why? Because each person has their head down trying to figure out how the existing system works and which starting point is best. Everyone is busy learning the lay of the land and getting oriented.

It’s important for managers to respect this phase. Teams can’t just dive into a code base and start building new functionality immediately. They have to acquaint themselves with the relevant code, think through the pitch, bring up questions, and go down some short dead ends to find a starting point. Interfering or asking them for status too early hurts the project. It takes away time that the team needs to find the best approach. Asking for visible progress will only push it underground. It’s better to empower the team to explicitly say “I’m still figuring out how to start” so they don’t have to hide or disguise this legitimate work.

Another great concept from Shape Up is thinking of work like a hill. First, there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.

Betting Table

Bets, not Backlogs. If you’re transitioning from agile, that might be a hard one to swallow but Backlogs are often big time wasters and anxiety builders. They also aren’t malleable to change. For example, an idea from 5 months ago might not be relevant anymore so why even spend much time on tracking it?

Another concept that might help you let go of backlogs is that important ideas come back, especially if you keep a strong pulse on your customers and internal team. If you hear an idea once and never again, maybe it wasn’t really a problem. And if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it in the next cycle.

So what’s the betting table?

During the cool down and before the next cycle kicks off, you host a betting table to decide what to build next cycle. This meeting should be extremely focused on reviewing what was previously shaped, and the deliverable of the meeting is a few pitches we decide to build next cycle — these are our “bets”. Anything not bet on, we let go of it for now, but they can be bet on again next cool down if you decide to.

The meaning of a “bet” is another important thing to call out about Shape Up. According to the Shape Up book, we use the “betting” terminology instead of planning because it sets different expectations:

1. Bets have a payout. We’re not just filling a time box with tasks until it’s full. We’re not throwing two weeks toward a feature and hoping for incremental progress. We intentionally shape work into a six-week box so there’s something meaningful finished at the end. The pitch defines a specific payout that makes the bet worth making.
2. Bets are commitments. If we bet six weeks, then we commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. We’re not trying to optimize every hour of a programmer’s time. We’re looking at the bigger movement of progress on the whole product after the six weeks.
3. A smart bet has a cap on the downside. If we bet six weeks on something, the most we can lose is six weeks. We don’t allow ourselves to get into a situation where we’re spending multiples of the original estimate for something that isn’t worth that price.

Who takes part in the betting table?

Typically it’s the highest people in your company, since buy-in and alignment from the very top is essential to making the cycles turn properly, but this is up to you. If pitches were reviewed properly before, then the meeting should be efficient, the options well-shaped, and the headcount low.

Currently, our betting table consists of our CEO, CTO, VP of Product (myself) and we’ve recently decided to add our Head of Product Engineering. I’m sure this will see more changes as we refine our own process. As I mentioned at the top, this is all up to you based on your organizational and team structure.

Finally, where are we now?

I glossed over our transition period, but it’s important to not rush any process change. Make sure you’ve thoroughly vetted all options, documented tradeoffs, have a well-crafted transition plan, and have buy-in from everybody. I should also mention that we didn’t follow Shape Up to the tee. We adopted the core framework of it (6-week cycles, dual tracks, betting table, etc.) but like most methodologies, they’re meant to be tweaked to best fit your team and organization.

So as of this week, we’ve completed 5 cycles thus far, which equates to a bit over three quarters of a year with Shape Up. Of course, we’ve had our fair share of learnings and adjustments along the way, but overall our team is very confident that this was the change we needed. Our product strategy is more focused than ever, dividing up our pitches by these strategic goals to provide better clarity about what’s important now vs later. This change has also resulted in better autonomy and focus for our teams, while providing a framework for collaboration and communication when needed.

In order to continually ensure our team is content with the process and exploring ways to improve it, it’s imperative to do retrospectives and be honest with yourself about how you can get better. Like most things, time and your users will keep you honest about whether or not this is working for you and your team.

Liked this article? I just published a follow up around Shaping Pitches within the Shape Up process.

If you made it this far, thanks for reading! Follow me on twitter and sign up for early access to something secret I’m building 🤫 — ProductHub.ai