Betting on Shape Up at Pennylane
This series uncovers the way we approach Product Management at Pennylane, from how we discover, to how we strategize, build and go-to-market. In this specific article, Antoine Rivière and Laura Ville talk about how we use Shape up to discover and build Pennylane’s accounting solutions.
Two years ago, Romain, who had just arrived as Pennylane’s first engineering manager, shared his love for Shape Up with us. He used this methodology at his previous company, and was enthusiastic about how it empowered software engineers while making the team deliver efficiently.
Back then, we only had two squads working on the whole accounting product and we built features using a Kanban-like approach. We were operating in an organic and fast way, with all the flexibility you have when you’re only 10 engineers for the whole product. Yet, we believed this organization would not scale. We wanted to try a framework that would help us grow while keeping our execution pace.
We thought that Shape Up was a good candidate, so we decided to give it a go and implemented it in one of our squads. It was just a bottom up experiment and we were not 100% sure where it would lead us. In other words, it was just a bet.
In this article, we don’t explain what Shape Up is nor how it works. There’s already a lot of great literature available on the topic, including the (free) ebook by Ryan Singer from Basecamp. Instead, we want to share our experience using it.
Fixed time, variable scope: the principle that makes the difference
As the name suggests, the principle “fixed time, variable scopes” implies that, during a project, the two priorities are solving the problem while meeting the time constraint. How we solve the problem is likely to change, depending on what we find along the way.
We believe there are three key ingredients to be successful at applying this principle:
- Very clear project definition, based on the problem we want to solve, setting the foundations for all the discussions and iterations.
- Team autonomy, allowing software engineers and product designers to determine what they can or cannot achieve in a cycle.
- Continuous communication between Product Managers, Product Designers and Software Engineers, so that the solution implemented does not come to the detriment of their respective definition of quality.
Everything starts with a good pitch
Before the project starts, we (the PMs!) write a pitch where we clearly define the problem to handle and its appetite, i.e. the time we want to spend on it.
Let’s take the example of a pitch on improving our confidential company feature. When reading it, anyone can understand the problem and why it happens: when an accounting firm’s admin flagged a company as ‘confidential’ because it holds sensitive data, they could not prevent another admin accessing it. As for the appetite, it was set to 3 weeks based on business arguments and not on technical estimates, which were useful later when looking for the right solution!
Initially, the solution was nothing more than a rough sketch by our Product Designer. It was used as basis for discussion between the Product Designer, the Product Manager and the Tech Lead. Was this solution solving the problem? Could we make it simpler? Could we build it in 3 weeks? It’s only when the solution passed these questions that the Product Designer gradually improved the sketch. Ultimately, she designed the high-fidelity prototype very late in the build phase, when the details really mattered.
Acknowledging we lost a bet when things don’t work out
Sometimes, projects are more uncertain than the one described above. It may be because they’re much bigger, or because they hide some tech, product, or accounting complexity that will only be revealed during the build phase.
When such unexpected complexity pops up, team members collectively adjust the solution to build, so that we can still finish within our appetite. We remove the fat from the project by finding how to (partially) solve the problem out of the product, simplifying the UX, removing non-essential parts, etc. Any good idea is welcome. Interestingly, they systematically come up when the Product Manager, the Product Designer and Software engineers talk together!
In rare cases, when everything went wrong, projects are not ready to be released when the appetite is fully consumed. Here, giving an extension is not the default solution. Instead, we consider whether we want to place another bet on the project. Sometimes we do, because we feel more confident, because we have addressed all the uncertainties at that point, or even because the feature is too critical to be left aside. Sometimes we don’t go overtime and we use the circuit breaker, i.e. we don’t release anything. This is a tough decision to make, and we support it with 3 major arguments:
- We want accountants to love our product. If our solution is poorly executed, this is not likely to happen, especially when we know that our accountant users are working 8 hours a day on it (for real, who wants to work 8 hours a day on something that does not work well?).
- Poor quality features increase our colleagues’ workload. Success teams would be the ones suffering from it, with more touch points with users and more support needed because of us. We don’t want this to happen.
- Poor quality features negatively impact our velocity. They’ll eat some of our future bandwidth by requiring bug fight and feature improvements. We already went through this, and we want to avoid this as much as possible!
Shape Up does not work for every product work
Let’s face it: Shape Up has not worked well everywhere. There are initiatives where the “fixed time, variable scope” failed to operate, or was too risky. This is especially the case for bugs and some jumbo projects.
Shipping and scaling, all at once
If software engineers lose their focus, they’ll reduce their chance to meet a project’s appetite. That’s exactly what happened with bugs. Every time a bug popped up, it momentarily interrupted an engineer in their work. Ultimately, software engineers complained about how bugs were preventing them from working efficiently, putting the delivery of their projects at risk.
To solve this, we first decided to go by the book and follow Shape Up’s recommendation: pitch the bugs, put them on the betting table and prioritize them so they can be fixed during a cycle. This actually did not work, mostly because too much time went on between the bug identification and the decision to tackle it. For instance, if a bug was raised the first week of the cycle, we had to wait another 8 weeks at best (6-week cycle + 2 weeks of cool down) before it would be tackled. This was too long given the number of users impacted and the amount of time they spend on the app every day. On the other hand, if we we decided to fix the bug before the next cycle, we would end up eating the projects’ appetite, going back to our initial problem.
After a few iterations, we think we found a sustainable way to tackle bugs efficiently without eating our projects’ appetites. Each team systematically allocates some developers of the team to the fixing of bugs full time, every cycle.
We do it thanks to a Shared Scalability Team, which is made of team members detached from their squad for 8 weeks. The Shared Scalability Team has the same timing as the other teams following Shape Up principles, and its main objective is to fix bugs. This organizational choice allowed us to give enough resources to solve our bugs in a timely manner while keeping other engineers focused on their feature work. It’s not Shape Up anymore, but it works well too!
Navigating around the 6-week cycles
On a different note, there have been times where improving the user experience meant changing some core paths in the app, and where the changes were too critical for us to have a time constraint as short as 6 weeks.
For instance, the redesign of the app’s navigation was one of these projects where we parted from the 6 weeks constraint to make sure we were successfully addressing the problems, even if that meant spending some extra time on it. In that case, the endeavor was very large and delivering in 6 weeks would have potentially meant delivering very low added value to our users. On the other hand, compromising quality on something that literally all of our users leveraged multiple times a day was simply not an option.
The Pennylane app, hosts three main types of users (Accountants, their clients and staff) who all collaborate on the same app, but with different sets of permissions and views. With the growing number of functionalities, it had become increasingly difficult for users to know where to find what they needed and how to get from A to B efficiently.
For this initiative, success meant addressing the issue for all types of users at once by introducing a new design and hierarchy in the app. It could only work if all parts were released simultaneously, hence making the MVP approach complex for the project.
Instead, we gave ourselves 2 full cycles for the build of the project with the objective of having a first version of the new navigation up and running after 6 weeks then another 6 weeks to test it thoroughly internally and with a small subset of users, before rolling it out progressively.
What’s next?
Today, two years after our first experiment with Shape Up, the six squads of the Accounting product use this methodology.
Shape Up has been particularly fit to Pennylane’s accounting product environment. Following the principle “fixed time, variable scope” allowed us to operate at an extremely fast pace while growing from 10 to 60+ engineers. We are now about to catch up on 40 years of accounting features work from our legacy competitors’ softwares in just 4 years. Finally, it contributed to improving the communication between Product Managers, Product Designers and Software Engineers by encouraging them to build solutions collectively.
Yet, although it worked very well on green field projects, we faced more difficulties with the brown field ones and jumbo initiatives. For these cases, we tried to adapt the framework in order to reach our product objectives but we are continuously improving.
As we’re slowly entering a more mature stage of the accounting product, we don’t know if Shape Up will remain the most relevant framework for us over time but we do intend to keep experimenting with it and with other methodologies to find the right fit.
