Why Scrum wasn't working
Before 2023, developing new cross-functional features at Storyblok was challenging, mainly because of the complex integration requirements and internal team coordination.
We had 5 product development teams and around 80 talented people working together. Our work was organized around 3-week Scrum Sprints, and while we were able to complete our assignments, we were far from delivering our best work.
What I learned during this period is that, while Scrum can work for some, it’s not a one-size-fits-all solution and it may not work for every team or organization. The main reason it didn’t work for us is because it brought developers to work in silos, and our time was mainly spent in meetings and reporting rather than on focused development tasks.
Another reason it wasn’t great for us is the “Scrum Sprint Burndown”, which is a visual representation of the work completed daily. This gave the team a false feeling of fulfillment because, while they were seeing a progression in terms of the work delivered and a decrease in what remains to be done, they were delivering little business value for our customers.
For one year, we tried to bring improvements to Scrum, but it didn’t really help the teams to work better and release features faster. That’s when we started thinking about a different solution.
What we wanted to achieve
Our objective was to:
Improve our delivery times
Make projects more predictable
Give more freedom to the developers
Allow more creativity within the teams
Get rid of micromanagement and ticketing systems.
We realized that a similar work frame was already being addressed by an existing method called “Shape Up”.
What is Shape Up?
Shape Up is a straightforward and project-based product development methodology. Its core principle is to deliver meaningful products within a deadline.
It is based on 6 week-long working cycles, followed by 2 weeks of cooldown. The method is also meant to give ownership back to the developers.
What’s really stimulating about Shape Up is the fact that it’s not based on an estimation of work but rather on defining the size of the team’s “appetite”. What can we get done in 5 weeks? What resources can we spend? How can we deliver something meaningful? These questions can not only motivate your Product Teams but also inspire them to leave their comfort zone.
Shape Up Vs. Focussed Scrum: The Experiment
In the run-up to Christmas, when people are generally in a more relaxed mood, the Storyblok teams like to take advantage of this downtime to fix bugs.
At the end of 2023, we decided to spice things up a bit and test Shape Up at the same time as fixing bugs. We intended to compare "Shape Up" with "Focused Scrum", and see what happens.
At the time, we had 2 priority projects to deliver:
“Ideation Room” (a new AI-powered Storyblok feature)
“New Trials” (an improved version of our Storyblok trial experience).
We tasked the team responsible for New Trials to keep using Focused Scrum (twice a series of 3 weeks), and in parallel we built a new team to work on the Ideation Room, using the Shape Up method for 6 weeks.
For the new “Shape Up” team, we mixed more senior and less experienced developers. Then, we shared the final goal and specifications with them, but no directions in terms of team structure or work distribution. We asked them to organize themselves as they preferred, autonomously, and to deliver as much work as they could in 6 weeks.
In the first 2 weeks, things didn’t look good - the new team worked for 9 days but we did not see any significant outcome. However, after that period, they identified what they wanted to accomplish and even brought new ideas to the dev cycles. In the remaining 4 weeks, everyone got up to speed, the team was aligned and working in sync, and they made things happen with confidence.
At the end of the 6 weeks, we had a beta test of the Ideation Room, ready for our internal teams and Ambassadors to test.
The team that used Focused Scrum for the New Trials also worked efficiently and achieved some improvements compared to the past. However you have to keep in mind that these developers were already familiar with their project (Storyblok’s trial experience), so we were expecting that they would progress in some way.
After careful consideration, deciding to implement Shape Up was a no-brainer.
How to implement Shape Up
The first thing to do if you want to test Shape Up is to make sure that your teams understand its basic principles and what’s expected from them. After deciding on the project they’ll work on, you’ll need to follow some guidelines and rules, such as:
Define “Shape Up cycles” for developers, product owners, and designers. This is very important as during these 6 weeks they’ll have to deliver something meaningful and valuable for the customer.
Write “Pitches” that describe the feature’s must-haves and nice-to-have is also crucial. This phase is sometimes referred to as “Shaping your teams’ work”.
Plan a “Shape Up kickoff meeting”. In this session, ensure that your team understands that they’ll own the development and that the focus is on their “appetite”. The objective here is to let them take responsibility and be fully accountable for their work. Let them be “hungry”!
When building the “Shape Up team”, bring different people with different profiles and different seniority levels together. Don’t forget to include programmers and designers, as they’ll be part of the development process.
Remember that other aspects such as the design and specs of your feature don’t have to be perfect from the start. They can be finalized and improved later.
What we like about it
We have been using Shape Up for 4 months now. Besides the improvements in terms of productivity, one of the best changes we’ve been experiencing with this method so far is that it gives the teams the confidence to talk about their achievements, the challenges they faced, and how they overcame them.
At the end of each cycle, we have meetings where everyone is encouraged to share their experience, and also raise any problems they encountered. This is a big step forward for us, because we knew that people sometimes noticed things that needed correcting, but with the old set-up, they weren't encouraged to share them with the rest of the team. This new mindset has given them a sense of purpose and responsibility to the people they work with.
What our teams also like about this method, is that there’s a dedicated maintenance team with a bug coordinator. This means that the people working on projects with Shape Up don't need to take care of maintenance, but can focus 100% on development tasks and creating business value.
The Drawback: Team Composition
For “Shape Up” to work, you need to have a certain number of Senior profiles in the team. The method requires team members to give (and receive) a lot of feedback, be very outspoken, and be comfortable in high-intensity work contexts.
It is also not a setup where management is there to hand-hold less experienced team members.
The idea is to give people a lot of freedom and autonomy so they can come up with their best ideas, try new things, and do their best work. This may be a barrier for some startups where the majority of employees are young and still learning.
In our testing phase of Shape Up, we tried different combinations of people, and some just did not work out. To put all odds in your favor, be flexible and open to experimentation, and listen to people when they share what they like or how they feel working in this new setup.
How to Test Shape Up [Checklist]
The best way to find out if Shape Up works for your organization is to test it.
To help you complete your Shape Up test effectively, you can steal this checklist:
Define a solid “Shaped Idea” (the feature or product you want to bring to life)
Rotate team members to find the best combination
Plan a Kick-off meeting (blocking 2 hours is recommended)
Plan 5 development weeks + 1 cooldown week
Assign projects, not tickets
Plan weekly stand-ups & mid-cycle Product Leadership sync meetings to show the work in progress to the CTO and/or other teams (like Marketing) to collect their feedback
Stress team accountability and ownership regularly
Review every cycle (evaluate both the project & the people who worked on it)
Appoint a dedicated “Maintenance team” with an official “Bug coordinator”.
Conclusion
As I already said, Shape Up (just like Scrum) is not for everyone. So - besides personal preference - how do you decide if you should take the plunge or not? First off, I’d advise you to take a closer look at the results you achieved with the Shape Up test and talk with your teams.
Naturally, the best performers in your organization will love this approach as it gives them room to excel, while it will make underperformers uncomfortable.
Secondly, if your organization hasn't yet established a culture of continuous feedback and recognition, I suggest you start there.
The “Feedback culture” associated with Shape Up only works when the feedback shared - be it positive or negative - is constructive.
If you truly want to work with a method that reconnects employees to their work and helps them feel valued for their contributions, then Shape Up may work well for you.
You can watch the “Shape Up your team’s appetite” Masterclass on demand here