Our development and product team are now in our first cool down period after one successful cycle of Shape Up. Not wanting to count chickens too early, we learned a lot in implementation. I wanted to share the practical reality of transitioning our team to Shape Up. I will be candid where needed in the hopes that reading about our process helps others move faster.
How we chose tickets before
Before we look at what we are doing now it’s worth looking at where we came from. Nothing in our previous process was broken on its own but the system we had wasn’t working the way we needed. We found ourselves bouncing between all in on one project and then only focusing on small individual tickets. This made both reactivity and predictability difficult.
Our previous product process was a combination of scoping one or two large projects a quarter and pulling tickets off the backlog. Those tickets arrived through customer and internal user feedback via a Wishlist. We implemented various scoring systems like RICE to try and sort or filter the growing backlog. When we tackled larger projects we went all in until the project was done. This approach often led to pushed out deadlines and delays in addressing other work.
While this all sounds messy, and it was, we managed to ship work. The issue was that we knew we could do more. We felt the process was causing a disconnect between the capabilities of our team and the output. Having run Shape Up before, I felt it might be a fit. As a company we had plans to expand our product from freight forwarding to a combination of services and software. To do that we’d need to ship a greater volume of high quality work.
Ramping up
I’m not a fan of process whiplash, nor do I love drawn out change management. To try and smooth the transition we took a few precautionary steps. Overall these helped the team and the wider company understand the changes we were looking to make.
Book club
Each week we assigned the team 1-2 chapters from the online copy of Shape Up. We read them and discussed them at the end of week all hands. We started at the implementation stage of the book. Those in the product team also read the early chapters on shaping.
Having everyone read through the book together we were able to incrementally adopt terminology like “uphill” and “scopes”. This shared language helped us talk about changes to the process in a condensed way.
We committed to a year
Changing workflows takes time. Building things is hard enough without the process changing every quarter. We wanted to focus on building and shipping value to users and committing to a year gave us the breathing room to get that done.
That’s not to say we wouldn’t adjust based on feedback but we’re giving Shape Up a chance to change the cadence of development. This also helped reinforce both to our team and the wider business that this was a change we were taking seriously.
Over resourcing
Shape Up by the book has teams of two developers on each project and each project was scoped for six weeks of work. We chose to run teams of three in our first cycle to give ourselves a safety net. Where possible we also aimed for what we felt was ambitious enough for four or five weeks rather than the full six. We figured this buffer would let us focus on a productive first cycle.
Cycle one
We’ve now wrapped up our first full cycle. Overall we’ve been very happy with the outcomes early in the process. Not everything was perfect but all the outcomes from our retrospectives were minor tweaks to the process which we’re happy about. Here’s a few key parts of Cycle one.
A mixed-bag project
One of the two projects we started with was a mixed bag. This was a collection of high priority tickets from our previous backlog and wishlist process. We knew this project had some quick wins in it and would help build some momentum for the Shape Up process.
Going forward we’ll prioritise larger focused projects but it’s helpful to ocassionally tackle a group of small, high impact tickets. This also allows us to keep cool-down open to more exploratory projects.
Focus on value
Our second project was a more traditional Shape Up pitch. We were looking to introduce a new feature to the application. It tied into our quote and charge management allowing us to set up rules and templates based on agreed commercial terms.
The initial scope for this project was, on reflection, overly prescriptive. We included too much detail on how the project should be built rather than a focus on the value and the outcome. As a result, early discussions in the first few days of the project led to a large, deeply technical scope. When reviewing the implementation plan we decided to review with the end users of this new feature and make sure we hadn’t missed anything.
After talking with our CS and sales team we realised there was a much simpler way to get to the value we wanted. One that aligned a lot better with the current user flows. We went back to a focus on key value and quickly got to a much simpler solution. Based on this we’ve made two changes to future pitches.
One, we’re reviewing them to make sure the pitch doesn’t dictate implementation details and more than is absolutely necessary. Second, to ensure those working on the project have the power to make their own choices we’ve added a new section to pitches called “One Key Thing”. This section is a single sentence that describes the ideal outcome from the project. With this sentence in hand, developers can choose to implement things as they see fit so long as choices align with that One Key Thing.
Small things and implementation details
That covers the major outcomes from Cycle One. There’s many more to go and we will no doubt learn more along the way. To finish this up here’s some small or miscellaneous things that came up that didn’t neatly fit into the rest of this content.
- The UX changes in our template project needed user training. We organised this during the cycle using a separate demo environment. This worked but there was some risk that training would hold up a launch. We’re working on how to avoid this in future projects with things like feature flags.
- We use Jira for project management. We have each project one epic and kept all tickets within that project. We also added any bug tickets resulting from the work done in that project within the epic to better track long term outcomes.
- We were open to the fact that sometimes something urgent comes up. To account for this we had an “Everybody Gets One” rule. Our CTO and Head of Engineering and I could all bring in one out of scope ticket if we felt it was urgent. This worked well.
- Alongside epics each project got its own slack channel. This helped keep discussions centralised and was useful during acceptance testing as a place to post feedback.
- We still have a backlog. We weren’t (and aren’t) ready to call backlog bankruptcy just yet. There’s a lot of scoped work in there that may work its way into future pitches. We do regular reviews to find tickets that aren’t needed any more so this should slowly whittle down with time.
- We used Jira ticket statuses to mimic hill charts. In particular we put an ‘Uphill’ status between To Do and In Progress. It was helpful to organise some process but overall Jira wasn’t a great replacement for hill charts in getting an instant read on how the team is going. We’re exploring some other options here.
Leave a Reply