An Engineer’s Perspective on Switching from Scrum to Shape Up
Last year at Beam we made a big change in how we deliver software. We transitioned from Scrum; a suite of processes intended to facilitate iterative development to Basecamp’s Shape Up framework; a combination of tools intended to cut through process and promote developer empowerment. We’ve had great success in some areas and some speed bumps in others. There’s many different perspectives of this switch already, so we’ll keep it from an engineer’s perspective and pretty high level. If this is interesting, we could do a more broad overview of why we shifted, and how it’s going from the wider organization. Just let us know in the comments!
Shape Up Overview
If you haven’t heard of Shape Up I’ll give you a quick overview from someone that learned about it last year and is still learning 😅.
Shape Up is a framework of tools that allows you to get work done without a ton of overhead (meetings, processes), or fully vetted out solutions being turned into tasks that engineers estimate, pull and complete. We “shape” problems into solvable “pitches”, remove some nuances, and rabbit holes and then allow engineers to dictate how to solve the problem themselves.
Each cycle is six weeks in length, and in between each cycle we have a cooldown period where we work on other issues like tech debt, experiments, small bug fixes, and training.
We select what to work on each cycle by going to the “betting table”. Leaders discuss the importance of each pitch and then set an “appetite”. Smaller appetite pitches tend to be two weeks in length versus big appetite ones that take the whole six weeks. At Beam, we aren’t treating appetite as a deadline but more as a gauge determining the importance of solving that problem i.e. we think solving this is so important we want to dedicate six weeks to it.
You aren’t required to do standups, retros, estimations, refinements or anything else you don’t want. But on our teams we still find value in doing daily standup meetings, and retros.
That’s the gist of it, although there are definitely tons of detail that go into each core part of the process. The peeps at Basecamp have an awesome free book if you’d like to learn more, additionally they have a forum for questions and topics.
Why did we shift?
Alignment
With two week sprints across five different dev teams it was tough for our senior leaders to accurately tell what teams were going to be working on at a glance and usually had to go through multiple levels to get that information.
We also move very fast. As engineers we love being able to merge our pull requests and almost immediately see change reflected in production. But there were cases where we would bulldoze changes into production without having a clear picture of how it would affect our users. Getting cards across the board helped us deliver a ton of great value, but we would assume somebody else was tracking ROI on features when really we were leaving all that juicy feedback/data on the table and assumed we had accomplished our goal.
Meaning
With great backlogs comes great responsibility.
As a fast growing startup we accumulated a TON of tasks (read: JIRA cards). It became hard for us to know with certainty that we were working on the most important item at that time. Items on our team backlogs were vetted of course, but if a team is rocking through a sprint and looking for extra work we’d be reaching for the next task in our backlog without really asking ourselves, is this truly the next most important thing or just the next most important thing in our backlog?
Our shared backlogs had become a catch all for all kinds of tasks that were logged since we started using JIRA. We thought having backlogs for tech debt, and bugs would help us prioritize items for future sprints, but as these grew we were overcome by tasks that no one truly felt strongly about or were important at some point and had been resolved by another feature or process.
What we enjoy
Simplification
Shape Up simplifies a significant amount of the development process. It empowers engineers to make decisions and decide what needs to be done versus what are nice-to-haves, instead of these being black and white on tickets. At Beam, we already adopted this mindset to an extent, but Shape Up allows it to go into overdrive.
Vertical Collaboration
Ideation of solutions happens hand in hand with our stakeholders. Before, this work was done mostly by our product managers before a sprint, but now we are collaborating throughout the cycle with our stakeholders and coming to solutions as a team. We’ve had great experiences with sharing screenshots of features and receiving feedback right away through Slack or a Google Meet. This also empowers our whole company to feel like we are creating something together instead of features being thrust upon our users.
Return on Investment
Our monitoring and metrics are cooked up by the people working on a pitch, which encourages ownership and helps us prioritize future pitches. This emphasis on data also allows us to measure the success of our pitches.
Our monitoring suite leverages Datadog, Slack, Rollbar and Metabase, as well as Tableau for metrics coming out of our data lake.
When we ship something, we have multiple ways of knowing whether something is working as expected and if an incident arises we are able to quickly assess the severity.
What we could improve
Prioritization
Previously, prioritization occurred from the product owner or engineering manager’s perspective. When things shifted in priorities this would happen opaquely without affecting engineers.
Shape Up empowers engineers to prioritize items themselves, which isn’t necessarily a tool we had in our toolkits before our move.
We have run into situations where our focus shifts to issues/opportunities happening tangentially to our pitch work, and instead of communicating and saying no we’ve found ourselves working extra to catch up.
No doubt our shift to working remotely has also exacerbated the issue. Our leaders can no longer turn their head and see engineers slowly slipping into a pressure cooker. I’ve adopted a mantra for this that has helped me a bit, so I posted it on my office wall:
Cooldown Leftovers
Shape Up promotes a six week period of cycle work followed by two weeks of cooldown. If a pitch is not ready to ship at the end of the six weeks it is metaphorically scrapped because our initial appetite for that work is not in line with the amount of work it required.
We have had some scenarios where it has made sense to continue work on a pitch past the end of a cycle, but haven’t quite yet mastered spinning up a new pitch to encompass the remaining work, taking that back to the betting table and deciding on its priority then. We’ve instead been “leaking” into our cooldown period and then working on it through the first two weeks of the next cycle like a small batch.
We’re keeping a close eye on this because it could lead to eventual burnout and allow for unintentional scope to creep into our pitches.
Wrapping Up
We’re still learning a ton of what works for us as a company, and what Shape Up encourages, but have definitely had successes throughout our shift. Have you had similar experiences? Connect with us in the comments and share your thoughts!
