How Memo Bank leveraged Shape Up

If you are interested in product management, you may have heard of the Shape Up methodology. If you haven’t , don’t worry, we’ll explain everything. At Memo Bank, we switched from two-week sprints to the Shape Up way in January 2020. Over a year later, it's now time to share our experience.

What is Shape Up? And how does it work?

Shape Up is both a book and a methodology. The Shape Up methodology was created by Basecamp in response to some of the problems they faced with the Agile methodology. The main principles behind the Shape Up methodology were also outlined in a book (of the same name). More and more start-ups, facing the same issues with Agile, decided to give Shape Up a try. We’ll do a summary of Shape Up's fundamentals before explaining how we adapted the methodology to our company. If you’ve already read the book, feel free to skip this part.

The three main problems Basecamp faced were:

• No time to think: they didn’t have a dedicated time to think about the product vision and the long-term strategy. They would spend the majority of their time heads down, solving operational problems.
• The tunnel effect: developers were losing motivation because they couldn’tsee the end of the feature they were developing. They could spend several weeks on a feature without knowing when it would be done and released.
• Lack of visibility for the management team: as Basecamp grew, the operational team became more and more autonomous. Since the management team was no longer involved in day-to-day discussions, they did not understand why everything seemed to take so much time.

As existing Agile methodologies did not seem to solve their problems, the Basecamp team decided to create their own methodology based on three principles:

• 6-weeks development cycles: after several experimentations, they agreed that a 6 weeks cycle was the optimal length of time for both their structure and developments. 6-weeks cycles gave the developers enough time to build something substantial while allowing them to see the end of the tunnel soon enough.
• Appetite: that’s one of the main differences between Shape Up and Scrum (another Agile methodology). With Scrum, product managers define the new feature and developers estimate the time they need to build it. With Shape Up, it’s the other way around: first we decide how much time we want to allocate to a specific feature (that’s what they call the "appetite") and then define its scope, with the time constraint in mind.
• Autonomy: it’s necessary to give autonomy back to the teams. They must own their topics. Developers in particular need to feel like they have a stake in the game.

Basically, the cycles are punctuated by several steps:

1. Shaping: shaping a given topic means setting its scope. A product manager and a lead developer decide the appetite they want to allow for the development of a given feature (2 weeks or 6 weeks) and then highlight the pitfalls to avoid. The challenge is to be specific enough so that the outcome of these discussions is clear for everybody, without including too many trivial details.
2. The betting table: before each building phase, a meeting with the C-suite occurs. The purpose of the betting table is to review all the pitches (i.e. the topics) that have been explored during the shaping phase, prioritize them and decide which ones will be implemented during the next building phase. The selected pitches are called "bets".
3. Building (6 weeks): as you may guess, bets are implemented during the building phase. Small teams are created and each one ownsa bet. The team then divides the bet into several smaller parts and starts with the most difficult one. Team members are autonomous but they have to keep in mind one important principle: done means deployed. After 6 weeks, the bet must be in production.
4. The cool down (2 weeks): there is a 2 weeks break between each building phase. The engineering team can use this time to breathe a little, fix a few bugs, explore new ideas.

Why we made the switch to Shape Up

We were a team of 3 product managers, 2 designers,about 15 developers, and a total of 40 employees when we decided to implement Shape Up. Until then, we used to create a quarterly roadmap and work in two-week sprints cycles.

We were not experiencing any major problems with developments as the engineering team had always been very autonomous, but we knew we could do better. Being a bank, therefore a regulated institution, many stakeholders need to be involved in order to make a decision on specific topics. For example, our risk team and our legal team needed to validate our intentions before we decided to implement a feature. Consequently, we never knew in advance how long it would take before a topic was ready to be developed. Similarly, the stage at which the developers should be included in the conversations wasn’t clear. We would sometimes involve them too late, and spent a lot of time explaining our choices to them as a consequence, which was a source of frustration for everyone. It became a necessity to find a way to provide a clear rhythm of work to the company.

Shape up ticked a lot of the boxes for us. Firstly, setting fixed-time parameters allowed everyone to clearly identify when they needed to focus on exploration and when they needed to focus on production. By doing so, all the experts had a dedicated timeframe to give input and feedback during the exploration phase. Secondly, we avoided unrealistic commitments while maintaining a strategic vision over the cycles by removing the quarterly-driven roadmap, which had shown to be almost impossible to manage.

Like any methodology, it had to be adapted

Shape Up seemed great on paper, but for it to be successful at Memo Bank, we had to adapt it to our culture and to the specificities of our business (banking).

Everybody on shaping

As opposed to Basecamp, we were convinced the shaping phase should involve all the stakeholders, not only the product managers and lead developers. That’s why we decided that the shaping and building phases would not occur simultaneously , but one after the other. Consequently, at Memo Bank, the cycles are organized this way: 2 weeks of shaping, then 6 weeks of building and so on.

During the 2 weeks of shaping, the developers don’t code. They still fix bugs, but their priority is the shaping, like it is for everybody else in the company.

To make sure we all focus on meaningful topics and to avoid misalignments, we have created an additional meeting called "The strategy meeting", which brings together the CEO, the CTO and the lead product manager. Their purpose is to decide which topics will be tackled during the next shaping. Beforehand, everybody in the company can create pitches. Pitches are a small paragraph where any given employee explains why they think this topic should be built. The strategy meeting participants review all the pitches and select the most important ones.

We then form teams for each topic and start investigating together. Most of the time, a team consists of a product manager, a designer, two developers and, depending on the topic, a banker, a risk analyst, or a marketing manager for example. Doing so allowed both business and technical teams to communicate synchronously and avoided for developers to discover the topic once it had already been shaped. It provides visibility to everyone and avoids unexpected issues. There’s obviously a risk of losing efficiency when including too many people in the teams. It happened to us at one point and we are now careful not to fall into this trap again.

Another risk was to "shape" too many topics at the same time. Firstly, it is exhausting. Secondly, if there is not enough bandwidth during the building phase they can’t be implemented right after the shaping phase. Consequently, the topics would often have to be postponed two or three cycles later. But the product could have changed during this timeframe and some choices might no longer be adapted and might have become obsolete. As a result, we would end up having to shape the topic again. This scenario happened to us at the beginning: we would shape nearly 15 topics per cycle and it was impossible to manage them all at the same time. That’s why we decided to add a priority score for each pitch. The strategy meeting picks about 10 pitches and ranks them by priority. We then focus on the most critical ones and if we don’t have enough time to shape all the topics, we focus on the ones that have the highest priority score.

Continuous improvements

The key to making the switch to Shape Up a success was to redefine the methodology as we went, cycle by cycle, and accept that it was not going to be perfect from day one. For example, after the first 6 cycles, we realised the rhythm was too intense and the engineering team was starting to feel exhausted. We were also frustrated because we didn’t have a dedicated time to test the features before their release. In consequence, we decided to add a one-week cool down period after each building phase to "breathe" and test properly.

We officially launched and welcomed our first clients in September 2020. As we began production, the engineering team couldn’t devote 100% of its time to development: there were bugs to fix urgently, clients and bankers that needed help, and more and more unexpected events. Therefore, we decided to introduce focus factors* for developers and designers. Each developer and designer now decides which percentage of their time will be dedicated to building. In addition, lead developers and the lead designer need to spend time on management. All focus factors are then taken into account when the betting table decides on the bets for the next building phase.

*focus factor: percentage of availability of a team member that will be dedicated to development during the next cycle (forecast)

Template creation

We also added some structure to keep global consistency among topics. For each new topic, we create a dedicated Slack channel (named #framing-name-of-the-topic and then renamed in #building-name-of-the-topic) and a page in Confluence (our wiki). This page follows a strict template and has several advantages. First, it guides our conversations so that we do not miss an important part of the process. Secondly, the Betting table can quickly review all the topics as they all follow the same structure. And finally, as this page is our single source of truth during the whole cycle, if the building team is different from the shaping team, they can easily see the summaries of past discussions and understand the choices that were made.

Similarly, we keep improving this template over time. For example, we recently added a product checklist for product managers to avoid unexpected events, with questions such as: do we want to specifically communicate on this feature? Does this feature require updating the FAQs? Does this feature trigger new email notifications? And much more.

Improved company alignment

As of today, 10 cycles after the implementation of Shape Up, we are still not 100% satisfied. But overall, if we were to go back a year and half, we would decide to make the switch to Shape Up again.

Shape Up has improved our company alignment. Today, each and every employee knows about the topics we are currently working on, even people who are not directly involved, such as the human resources department. In that sense, it has also improved the product culture in the company: everyone feels involved as it creates a rhythm of work for almost all stakeholders. Communication between our bankers and developers is now easy and everybody participates in the shaping with enthusiasm.

We haven’t measured to what extent Shape Up improved our productivity but it surely has had a positive impact. As we now have a regular working pace , there is less down time during which nobody knows how to move forward. Shape Up has reduced uncertainty and improved visibility. We haven’t experienced any failures so far : all the topics have been deployed on time. Sometimes, we have to reduce the initial scope during the building phase ( removed items are called "leftovers"), but it is part of the process. It can be frustrating at the beginning but it forces us to focus on the essentials.

Some challenges remain

Of course, Shape Up is not a magical formula and it may not be suited to all companies. For example, it can be difficult to implement Shape Up if you have a lot of external dependencies, which is not the case for Basecamp. At Memo Bank we have several critical topics where we depend on external partners. When we work with large companies it is impossible to use Shape Up. Consequently, those topics are not included in the Shape Up cycles and require a separate process, and managing two different processes simultaneously is challenging.

Shape Up is also not really suited for business emergencies. Sometimes, a new opportunity comes up in the middle of a building phase and some small developments are needed to win a deal. However, it implies putting other bets on hold and potentially compromising their deployment. It also means that this new development will not follow the usual process and therefore will not be shaped properly, which can lead to frustration and a final product that could not be completely suitable. But in these cases, the business priority wins.

In addition to that, there are things that are not explained in the book and where it is necessary to improvise. Shape Up is great for delivery, but what about discovery? When are we supposed to do UX research or to show prototypes to our clients? As the design team starts their work at the same time as the frontend team, how can we avoid bottlenecks? It requires a lot of anticipation and we still have room for improvement.

Similarly, small improvements can be hard to integrate into the process as they are too small to require two weeks of our time during the building phase. To solve this issue, we created a backlog with all the small tickets that take no longer than two days to complete so that our engineering team can pick some of them during the shaping and the cool down phases. However, there is no guarantee as to when they will be resolved and they can quickly accumulate. When there were too many tickets, we created a dedicated bet to tackle the highest priority leftovers. It doesn’t follow the principles of the Shape Up methodology but it is the compromise we’ve settled upon for the time being.

Conclusion

Shape Up significantly improved our way of working. It has provided a clear pace for the entire company and allowed our teams to commit and take ownership on their projects, thus avoiding unclear responsibilities. Of course, we are still not 100% satisfied with Shape Up: as we grow, new challenges and needs arise which force us to regularly adjust the methodology to our business.