Moving from SCRUM(-ish) to Shape Up
Moving from SCRUM(-ish) to Shape Up
Trialling Basecamp’s product methodology
This is the first of a six-part series on implementing Basecamp’s Shape Up methodology at my company:
Part one: Moving from SCRUM(-ish) to Shape Up
Part six: Behind the scenes, real-life Shape Up with Basecamp (+Resources)
It's time for a change.
A year after the acquisition of my company and our software development lifecycle is still the same. In fact, it's been the same since the inception of the business about seven years ago:
Write a bunch of tickets
Cram as many as possible into a 2-week sprint
Get about 75% of it done
Over-spill the last 25% to the next sprint
Repeat
High velocity is the lifeblood of a startup. But following the acquisition (and my transition from CMO to product manager), I was eager to grow up.
My first attempt at introducing a form of 'Shape Up' failed miserably. I tried to shoehorn these changes amidst the acquisition, which added to the stress.
This time, we're ready.
Why I'm moving from SCRUM(-ish)
There are many reasons I'm trying to move away from SCRUM. Here are a few:
2-week sprints are too fast-paced. By the time the team gets the new sprint, starts wrapping their head around the work, and gets to coding, it's almost already time for the retro.
Close to zero customer understanding from the dev team. I would get a vague idea of a customer need (from sales/support), translate it into a bunch of tickets, and handover to the dev team. No ownership.
Code-monkeys. Or, as our lead engineer puts it, 'paint by number development'. No room for creativity, problem-solving, etc.
Always chasing our tail. We'd never finish a sprint and have to make awkward decisions (ship or no ship?).
Estimation was a constant battle. "How long will epic X take to build?". No f- clue my guy.
Lack of focus. Each sprint is full of tickets, usually with one epic and a bunch of unrelated tickets.
Very little teamwork. Team members rarely work on the same thing at the same time, creating development silos and overall sad faces.
The usual suspects.
Don't get me wrong. I think there is a place for such a fast-paced SDLC. In fact, in startup mode, speed is all you have. But eventually, you have to level up.
The brief 'Shape Up' overview
'Shape Up' is a practice created and immortalised by Basecamp in a handy (free) ebook. It's the methodology they've used, and many others since, to create software.
The principles are somewhat simple:
Shape an idea. At a startup, there are always a million things to work on. Each of these million things could go in a million different directions. Individuals narrow down the problem they think is most important to solve and present it to the leadership team.
Bet on an idea. The leadership team bets on a shaped idea and assigns it to the development team.
Limited time, variable scope. The engineering team is handed a shaped project to work on with only a few parameters:
Each project lasts six weeks, including QA.
Boundaries and rabbit holes to avoid.
Scopes to achieve (e.g. things the customers should be able to do by the end of the project).
Ship. When the six weeks are up, the work is shipped. (Almost) no exception.
I recommend reading the book to truly get all the nuances of this approach.
Trialling Shape Up
Over the past couple of weeks, I've worked internally to introduce the changes.
In a future post, I will share how I packaged the methodology and presented it to the various stakeholders of the business (dev team, leadership, support team, etc.).
We will trial this new approach for approximately four months (2x 6-week projects, 2x 2-week cooldowns).
Here's what I'm most excited about with this trial:
Bets
I feel like Basecamp underplay this sneaky rebrand. They don't talk about epics or even roadmaps but bets.
The leadership team bets on shaped projects. That is a key mind shift. It means the whole company understands that:
A bet has an upside (winning) and a downside (losing). Sometimes a project will not pay off, features get scrapped, ideas are crap, etc.
A good bet has a minimal downside and maximal upside. Shape and de-risk your projects accordingly.
Bets are calculated. They're not gambles, they're bets.
Whereas a rigid roadmap of features puts enormous pressure on everyone to pick 'the right thing' to work on next, shifting to a betting mindset is a much better representation of reality.
No one knows what the next step has to be. But, as a team, we can bet on what we think is likely the right move and, importantly, make that bet together.
Working together
Standup, for the past few years, often bummed me out. A series of people talking about the thing they are working on today, with close to no overlap, everyone pretending to listen.
Waste of time.
With this approach, the team works together towards a single, focused goal. Front- and back-end work together to understand the problem, create a prototype, and finally mop things up.
I'm excited to see teamwork rather than work in a silo.
A better division of labour
As a founder turned product manager, it's easy to fall into the trap of over-preparing each sprint. I know what I want my product to do/look like, right?
So, I'll prepare the epics, the user stories, the tasks, and the acceptance criteria, then hand it over to the dev team. Bish bash bosh.
In reality, this blurs the lines too much. I don't actually know how things need to get built.
With this methodology, there's a clear separation between the shaping phase (which I'm leading and highly involved in) and the building phase (which is where the engineers shine).
Hill of progress
One of the more interesting concepts of Shape Up is the 'Hill of Progress'.
The Hill of Progress aims to answer the eternal cringe-inducing question: how much time will take to build X (or, as I like to say to tease my team, "is X a big ticket?").
Care to guess what the answer will inevitably be? That's right:
"I don't know".
Look, as a product manager, I wish it wasn't so. I wish I could for ONCE. IN. MY. LIFE. get a clear answer to this question. But I also know it's impossible.
So, we mostly estimate (very poorly). And (vastly) miss the mark. And get (unnecessarily) stressed out.
Shape Up's answer to this madness is the hill.
At the start of a project, all of the scopes ('things' you need to achieve) start at the bottom left of the hill in the 'Figuring things out' quadrant.
It is understood that, while in this quadrant, we simply don't know how much time/effort a scope will take to complete. We can guesstimate, that's it. It is the dev team's job to move each of the scopes along towards the top of the hill through research, coding, and prototyping until they reach the top.
At the top, the developer(s) know precisely what needs to be done to achieve this scope. No more guesstimates. Tasks are clear. Let the 'Making things happen' phase begin.
We also know the entire hill must take a maximum of six weeks, which creates the right amount of urgency.
I'm excited about this because it clarifies everyone's understanding of where we are in the development process.
What next
I'm planning on documenting my team's transition to this new methodology over the next few months. I'm excited to share these 'field reports' here as we go through the ups and downs of implementing Shape Up.
Next, I'll share how I pitched the methodology to various stakeholders and how our first shaping sessions went.
If you're looking to implement this methodology yourself or are simply curious as to how this will turn out, make sure to subscribe.