Pitching 'Shape Up' to stakeholders
How I introduced the trial of a new product methodology to the teams
This is part two of a six-part series on implementing Basecamp’s Shape Up methodology at my company:
Part two: Pitching Shape Up to stakeholders
Part six: Behind the scenes, real-life Shape Up with Basecamp (+Resources)
A few months ago, I introduced the Shape Up product methodology to my team (read why).
It's a major shift from the typical-ish SCRUM approach to Shape Up. I was under no illusion: I would have to pitch this new approach not only to my product team (easy) but also to the heads of sales and customer service (hard) and the hierarchy (god mode).
I created a deck that summarises the Shape Up methodology. You can grab a copy here. I used this deck to back up every pitch.
For each stakeholder, the narrative around this new approach slightly changed. If you are hoping to introduce Shape Up to your organisation, hopefully, this breakdown helps you do just that.
Introducing 'Shape Up' to the dev team
Let's start with the easy one: the developers.
When implemented properly, Shape Up should be a blast for the dev team. I won't go into all the reasons why again, since I created a post specifically about this: read it here.
Still, there are a few points (and perhaps worries) worth lingering on with this team. Here's what I particularly insisted on when speaking to the dev team.
Discovered tasks. When transitioning from SCRUM to Shape Up, one of the scariest aspects will be that developers no longer get a tidy list of clear requirements. They'll have to discover the work for themselves. This can be daunting. I explained that, while this might seem scarier, it's also a much more exciting and fulfilling approach than ‘paint-by-numbers development’.
Prototyping. Discovering tasks and prototyping go hand-in-hand. I insisted on making prototyping a priority early on in the cycle. With SCRUM, developers are often conditioned to only deliver the finished product. This is a big change, one that requires them to openly discuss and present unfinished work.
Time left alone. Perhaps the most exciting part of Shape Up for devs is the idea that, during the first 1/3-1/2 of the cycle, they will be left alone to figure stuff out. I spent extra time explaining the benefits of this focus time.
Again, the dev team should be the easiest to convince to give this a try!
Introducing 'Shape Up' to customer service
As you excitedly talk about Shape Up to your head of customer service, here's what they hear:
'No distractions': What if I have questions?
'Longer development cycles': What about bugs? Will someone think of the bugs?!
'Single goal at a time instead of a myriad of unrelated tickets in a 2-week sprint': But I have 17 customers who need 34 different small things done!
To be honest, while I had my doubts about how the hierarchy would respond to trialling this new approach, speaking to the success team was the most nerve-wracking.
There's no way around it: with this approach, we're asking them to be patient and to trust that, in the long run, we'll deliver more value this way.
Here's what I focused on:
Showing the secret door. I’m not naive enough to think we will never deviate from the plan. If there is a critical bug, we will, of course, hotfix it. Import at this stage to provide a specific game plan for identifying hotfixes and to get them to sign it off.
Ticket bonanza still exists. We will still have bug smash and 'small jobs' smash sprints. They will just be a lot less frequent. (Basecamp seem to do one per year around Christmas time. I’m nowhere near confident enough to rely solely on one bug smash sprint; but good for them!).
Here to help. Finally, I assured him that I would be present every step of the way to help him with customer questions. This should be a given, but I believe it’s worth re-iterating here. Out of everyone, your customer service team will likely experience the brunt of this drastic change of pace.
Introducing 'Shape Up' to sales
Sales expect a lot from product. I would even expect that, often, introducing Shape Up is a direct response to sales demanding too much from product.
It's no surprise convincing your head of sales might be a tricky challenge. Here's what I focused on:
Things will still get done. While 6-week focus cycles may sound like 'less work' to them, I insisted that we'd get more done. We're 'doing less better'; not just 'less'.
Solving bigger problems means better opportunities. With the cycle approach, we're focussing on solving challenges rather than implementing features. Any salesperson worth their soul should immediately see the benefit of that.
Pain. Even if you think your sales team’s a heartless bunch of b*stards, chances are they are not. I spent some time focusing on the pain experienced by the dev/product team; no time to focus, feature factory, things breaking, etc. It’s worth showing them the other side of the coin.
Introducing 'Shape Up' to the bosses
Finally, we're down to the last group of people we need to convince: the hierarchy. In my case, this meant CTO and Head of Product.
The faith of your test lies in this conversation. You could have done the best job in the world with your previous chats, if the boss says no, you’re done. Unfortunately, I would expect you to have little to no control over the outcome of this chat. There are two big factors at play:
factors external to the stakeholder's decision (e.g. earning calls, deadlines, board members, etc.).
egos (e.g. 'SCRUM is the way we've always done it, who are you to tell me we need to change?').
I was lucky enough that neither of these came up during my pitch. You may not be as lucky. Nonetheless, here is what I focused on:
This is a test. I'm not changing everything forever. I laid out a specific, time-bound plan. I was going to give this new approach four months (two 2-week cycles and two 6-week cycles), and then we can reassess.
Focus on pain. Product pain, developer pain, delays, lack of focus; all of the above. Your boss(es) should care about these much more than the other stakeholders you've spoken to so far.
Be prepared. I made sure I had a deck, I brainstormed questions I expected they'd ask, I prepared a contingency plan for existing workstreams; I did my homework. If you're going to attempt a process-coup, you better be ready.
This work paid off. I got the (perhaps suspicious) nod from every head of department and the hierarchy green-lit my trial, too.
Next, I'll share insights on running our first cycle.