First ‘Shape Up’ cycle: A play-by-play
First ‘Shape Up’ cycle: A play-by-play
Every challenge, decision, and milestone faced while trying out Basecamp’s Shape Up methodology for the first time
This is part four of a six-part series on implementing Basecamp’s Shape Up methodology at my company:
Part four: First Shape Up cycle, a play-by-play
Part six: Behind the scenes, real-life Shape Up with Basecamp (+Resources)
Oh boy.
First big 'Shape Up' cycle wrapped up. It's time for a deep breath, a debrief, and then perhaps a nap.
If you missed it, here's why I've pushed my team to trial Shape Up, how I convinced everyone to come along for the ride and some of the concerns I had before diving in.
Throughout our first 6-week cycle, I took copious notes. I made sure to write down both the project's progress and how it all felt along the way.
Let's review.
Week 1
On Monday morning, I debriefed the product team on the project. I walked them through the shaping board and, jointly with their team leader, explained the goal and the scopes.
Then, silence.
One of the core principles of Shape Up is to leave the team alone as they discover the scopes. The first week (roughly) is meant for deep focus, experimentation, diving into the code and generally figuring out what the hell this project is all about.
Looking back, week 1 was probably the toughest week for me. In Scrum, you're constantly talking to your team and getting feedback. Having to sit back and leave everyone alone was a challenge.
Throughout the week, I had six brief calls with different members of the team to clarify scopes and answer questions.
At the end of week 1, we spontaneously organised a show & tell. Admittedly there wasn't much to 'show' and was more of a 'tell'; but I was pleasantly surprised to see:
A clear understanding of the scopes
A spontaneous urge to get together (I didn't call that meeting)
A shared excitement for everyone's progress (particularly between design & back-end)
It turned out this spontaneous gathering would become a staple of our cadence. From there on out, we organised a show & tell at 4 pm every following Friday.
Week 2
Week 2 started as week 1 ended: leaving everyone time to figure things out on their own. The only difference was, this time, no one came to me for further clarification.
This made week 2 quite a struggle.
While I trust my team completely, it was almost impossible to avoid intrusive thoughts. Was anyone progressing? Was anyone working? Did everyone take the week off? Being remote only added to the concerns.
I stuck to my guns and remained quiet. I spent the week QAing different parts of the app and ideating on a potential next cycle.
On Friday, we meet up for our now-famous weekly show & tell. The week turned out fruitful for some, frustrating for others:
Design made huge progress. One of the scopes required a complete redesign of a key part of our app. The bulk of the work had been done, in collaboration with one of our frontend dev. We had a clickable mockup!
Backend struggled. One of the scopes included a slight variation to an existing feature, and they weren't sure how to handle it to ensure scale and make it futureproof.
Overall, the progress was there. Week 2 was a good reminder: trust the team and trust the process.
I scheduled some time to chat with the backend dev and act as a sounding board for next Monday.
Week 3
Entering our third week out of six felt like a milestone.
By now, I thought, nothing should stop us from achieving our scopes. The two previous weeks should have been enough to flag any major problems with what I wanted the team to achieve.
Week 3 should also be the start of the turning point, going from mostly brainstorming and prototyping to implementing bits and pieces.
I was extremely excited.
At the start of the cycle, I created a Slack group specifically named ‘c1-name-of-project’ (c1 for cycle one). So far, activity had been relatively low in the Slack group. When people needed to talk, they seemed to do so privately.
Now, communication was picking up. And it was glorious.
Throughout the week, I saw prototypes, questions, back & forth on key code decisions, feedback and iteration; all in our little bubble of a Slack channel. I loved it. It felt like the project was coming to life and everyone was 100% engaged.
On Friday, we met up for our show and tell. It was the cherry on top. The team had managed to:
Put together a working prototype which included five out of six of the scopes.
Include redesigns as part of the prototype.
Put together a demo showing the prototype solving one of the challenges I had used in my original pitch.
It was epic. Everything was coming together. We all left this meeting on a high.
In addition to the obvious progress made, we also now had a very clear idea of how the rest of the cycle should work. We were at the top of the proverbial 'Shape Up' hill, and the view was excellent.
Week 4
Ok so, I made a huge mistake on week 4. Huge.
I took the week off.
Now before you start cursing at me, please understand I had no idea this 'Shape Up' thing was going to get approved (or when). I had booked the week off months ago and... well, that was that.
As I travelled across the English Channel to visit my family, my team continued to plough through the scopes. I was glad week 3 ended the way it did. I left confident in everyone's ability to progress without me.
I missed week 4's show and tell.
Week 5
Back to work.
During my time off, I missed some important developments.
One of the scopes, one that had eluded us a few times throughout the cycle so far, was causing issues.
During the shaping process, I identified a clear use case for it. Its implementation was clear to me, as was its place within our app.
Between weeks 1 and 4, my team had taken my shaped approach at face value. Yep, they absolutely could do what I asked. But in week 5, one of them raised their hand: I had missed something.
His questions raised more questions. Questions turned into debates about the purpose of the feature. Debates became a set of different use cases and, you guessed it, each use case became a tiny pitch.
Uh oh.
I kicked into gear. I tried to shape the scope further. Live. On week 5.
Uh oh x2.
Week 5 ended up quite stressful. I had missed a crucial part of the scopes. The more I tried to solve it, the worse it got and the more (seemingly) random decisions I made. I had to call it.
Mid-way through week 5, I officially got rid of that scope.
Although an obvious mistake, I learned a few valuable lessons:
Dig deeper when shaping. I should have spotted this mistake weeks ago. Classic case of scope bloat.
Encourage the team to raise their hand and speak frankly. I'm so glad that one developer felt he could be so honest with me.
If you find yourself shaping mid-cycle, something's wrong. Making decisions is fine. Shaping is not. You should feel the difference (hint: if there are loads of debates around it, it's probably a shape).
If you end up cutting one of the scopes and the rest of the project is roughly unaffected, it was probably not a great scope to begin with.
That week's show and tell was rough. We debriefed on my mistake(s), looked at the wider team's progress, and anxiously set our expectations for our final week.
Week 6
Final week.
I didn't know what to expect for week 6.
Part of me hoped for a soft landing (everything's built, just a few final tests, iron out kinks, aaaaand wrap it up).
Part of me expected chaos. Six weeks to build something is, all things considered, quite short. I wanted to do something ambitious, which meant stretching a little bit. In this case, the final week could be the rush before deployment.
Turned out to be the latter.
Cancelling one of the scopes the week before ended up saving us some time, which was great as we desperately needed it.
During the final week, discussions in the Slack channel were at an all-time high, though mostly discussing details (which had now become important, such as naming conventions, colours, etc.).
I spent the week on high alert, essentially QAing every release multiple times a day. With every tweak, I was back in there testing everything. It was an intense week and, particularly, an intense final two days.
I was adamant we wouldn't miss our release (the following Monday). Our backend developer and I worked extended hours on Thursday and Friday to make sure of it.
And we made it, by the skin of our teeth.
Our Friday 4 pm call was a mix of excitement and relief. We had done it. I was exhausted, and I'm sure everyone else was, too. I cut the call as short as I possibly could, told everyone to have a nice relaxing weekend and scheduled a debrief for Monday afternoon.
On Monday at 10 am, we released the project into production.
A few random notes
Looking back, it's insane the speed at which we worked. Collaboration (once it kicked in on week 2ish) was at an all-time high. The velocity of work towards the end of the cycle was crazy.
I struggled to organise feedback inside our Slack channel. When I had to raise a ticket, I would @here and preface it with an emoji (bug). Not the best, as I continuously distracted people. If you have an idea or recommendation for this, let me know in the comments.
Although not perfect, feedback inside our Slack channel also induced quick responses and iteration. I often raised a bug only for a fix to be pushed a few minutes later. I loved that.
Part of my week-6-stress was the expectation of issues. What if I found a huge bug two days before the end of the cycle? Would I call it all off? Add an extra week? A lot was riding on the project business-wise, but also team-wise. I wanted to make sure our first project was a success and, in retrospect, that likely only added unnecessary stress for everyone.
Next, I'll share thoughts on working through our first mop-up cycle. Stay tuned.