Update Report: Trialing Basecamp's 'Shape Up' Methodology

Last year, I attempted to move my product team from the classic SCRUM approach to Basecamp's Shape Up methodology. It was an incredible experience; I've learned a lot from it and thought I would share some of my findings with you.

If you've experimented with it yourself, I'd love to hear how it went. If you haven't, I'd love to hear why you stayed away.

Part 1: Why Shape Up?

My team had been running on SCRUM since forever. During our startup days, we were living the classic tech cycles: work fast, ship, and don't think about processes too much. Then, we got acquired.

Once I had a bit more time to consider our product methodology options, I decided to give Shape Up a try. There were a few reasons:

1. Up until then, we were attempting 2-week sprints and pretty consistently failing to finish them. Every week felt like a conveyor belt of tickets we'd never quite finish.

   
   

2. The team felt like code monkeys. Pick ticket. Work ticket. Deliver ticket.

   
   

3. Because we never finished the sprint, tasks would always spill to the next one. Eventually, the dam breaks.

   
   

4. We all lacked focus. Each sprint was a pick & mix of things to work on across the entire code base.

   
   

5. Very little teamwork. Each developer would work on their little piece of the pie, leaving little room for learning from each other and, frankly, a sense of community.

   
   

6. Almost no customer understanding. Devs would pick up tickets assigned, get them done, and have no clue why/who/what.

After re-reading , I thought I'd give it a try as it claimed to solve most of those issues.

Part 2: Pitching Internally

One of the hardest parts of moving to Shape Up was pitching the idea internally.

I spent extra time internalizing most of Shape Up's concepts to ensure I was ready for any questions. Unsurprisingly, developers loved the idea of this new approach (more time, more focus, more collaboration; why wouldn't they!).

Also unsurprisingly, the hierarchy was more reticent. Ultimately, I managed to convince them by:

1. Ensuring that it was just a trial. If things didn't work out, we'd go back to 'normal.'

   
   

2. Ensuring I was going to remain as available as ever to help them. The devs would be focused and uninterruptible, but I wasn't.

   
   

3. Highlighting Shape Up allows us to solve bigger problems which means bigger opportunities.

   
   

4. Insisting on the pain product is currently experiencing and how it affects each team.

I prepared a very clear slide deck and ran each head of department through it (customer service, sales, and C-suite).

Part 3: Fears & Concerns

My experience as a founder, marketer, and product manager has taught me it's always worth writing concerns down before starting an experiment. I had a few with Shape Up:

• How do we handle distractions? I know I'm supposed to 'say no.' 'We're busy.' 'Next cycle, we can look into that.' That's the theory, and it works if the whole company is bought into this methodology. During my first cycle trial, I was concerned an emergency would pop up.

• Backlogs? Shape Up recommends no backlogs (chapter 7). Since we were just trialing this, I obviously didn't go and cmd+a+delete our backlog, but still. If we were to adopt this methodology, I would feel somewhat lost without a backlog.

• 'Almost finished.' This one really scared me. What happens if we reach the end of the 6-week cycle and we're tentatively there, but not quite? Basecamp says 'start again' (unless you're so super close). I was concerned we'd miss the mark by the annoying 20-30% range.

Ultimately, none of these fears/concerns could stop me from carrying on with the trial. It was worth keeping them in mind, though.

Part 4: The Cycle

And we're off!

I kicked off the first cycle on a Monday morning, looking at six weeks of intense focus and teamwork. Here's a summary of what happened each week:

• Week 1: Kick-off and... silence. Leaving the team be, letting them research, and diving into the code on their own time are all a major part of this methodology. It was incredibly hard for me to let go during that first week and not ask for updates. I held strong!

• Week 2: The team finally came out of their shell. Communication picked up. Design for the work started appearing, got to give some feedback and work together.

• Week 3: In theory, week 3 should be the top of the cycle curve. By the end, the team should have a very good idea of how they're going to build what needs building. We created a cycle-specific Slack channel as communication started to properly ramp up. By the end of that week, we saw prototypes, designs, snippets of code, and more. We were on track!

• Week 4: Quiet again. All the back and forth from week 3 produced a focused week 4 as everyone implemented their work. We kicked off a Friday 'show & tell.'

• Week 5: Curveball week. One of the scopes started to generate quite a bit of chatter. It quickly became clear the scope wasn't clear enough. I hadn't been precise enough in my requirements, and what initially seemed nice and simple turned out to be complex. I had to make the tough decision to cut this scope.

• Week 6: The remaining scopes were ticking away nicely. The intensity drastically picked up in week 6 as I was QA'ing all over the place, and the devs were iterating on my feedback incredibly quickly; we were all pulling together to reach the target.

In the end, we hit the target. We made it! It was super intense, and I was devastated we had to cut one of the scopes, but we made it.

The following Monday at 10 a.m. we shipped into production.

Part 5: A Few Lessons

In no particular order, here are a few lessons and recommendations:

1. Shaping is hard. I thought I had done a decent job shaping most of the scary parts of the cycle. Turns out I missed something blatantly obvious which almost derailed the whole cycle.

   
   

2. Include your team during shaping. I shaped it mostly on my own, and sometimes, with my dev team lead. It would have been valuable for me to include other developers.

   
   

3. If you find yourself discussing or shaping mid-cycle, something's gone wrong. Stop everything. Your priority is to figure that thing out before it completely derails everything else.

   
   

4. Intensity is not evenly distributed. Whether it is between team members or throughout the cycle, the work intensity is going to greatly vary. As PM, it's your role to spot these pockets of intensity and pay special attention to the individuals going through them.

   
   

5. Create a separate Slack channel. It made communication much easier but also much more fun. The cycle team quickly developed a shared language, memes related to the work we were working on, and so on. It basically felt like being a startup within the team.

   
   

6. Implement show & tell meetings from week 1. We waited too long to do this. There should be enough to show or discuss from the end of week 1. It's also an opportunity to meet up, discuss, learn, etc.

   
   

7. The cooldown period turned out to be much harder than the cycle itself. All the 'other work' had piled up for 6 weeks; it felt like going right back to SCRUM. This is something I'm still working on improving.

As you can probably tell, I was sold by this trial.

Implementing Shape Up and adopting its quirks is certainly not an overnight thing. I suspect it'll be a long learning process. I have particularly appreciated the mindset shift this trial has allowed us. We (and the other teams, I hope) learned to see the work for what it is: an exciting challenge we'll overcome together.

If you've trialed this (or not), I'd love to read some stories or feedback!

If you enjoyed this post, you might enjoy . I write about product management, share actionable insights, and take on real-life product challenges for fun (I know, right?).