Autonomy vs Product focus
In 2017, our company adopted the Spotify Model. Or rather, we created our own model “heavily inspired by” Henrik Kniberg’s Spotify engineering culture videos.
We were so heavily inspired that we only differed from “Spotify” on details. The most important detail was that every team would work with Scrum. Scrum was well known by most developers. Our environment was complex. We considered it to be wise to all start the journey with Scrum.
We defined the following traits to be vital for our success:
Teams should be autonomous. This meant that the teams should have all the skills to be able to create an Increment every Sprint. On top of this, they should be solely responsible for a small and decoupled piece of the product. They should not require any help from outside of the team.
Teams should take ownership. This was tightly aligned with autonomy. Every team was responsible for a small piece of the total product. Every piece had a Product Owner. The Product Owner was accountable for the value of their piece, their piece of the product. As a result, every team had its own Product Owner.
Teams should directly align with their stakeholders. Communication would cease to be non-existent or via proxies. Stakeholders would be involved in the discussions, mainly at the Sprint Reviews and refinement sessions.
The model should be easily scalable. The theory was that due to the autonomy of all the teams they could work on their part without interference from other teams. In theory, we could have an indefinite number of autonomous teams.
We started off great. But eventually, we had to choose between “Spotify” and Scrum.
Our initial success
The change from traditional projects to our Spotify inspired model didn’t happen overnight. It was solidly planned, backed by leadership up to C-level, involved quality training and intensive coaching of everyone involved.
We were off to a flying start. From the getgo, we saw enormous improvements:
we focused on what mattered most and created higher-value products;
our customers were happier;
our people were happier;
our time-to-market shortened;
we delivered more than ever.
We expected the first three as these are typical benefits from Agile and Scrum. But the greater autonomy of the teams resulted in more focus and commitment. This led to faster results and higher productivity. Naturally, we were happy with these additional benefits.
To be fair, any change from what we did before would have resulted in improvements. We were in an awful spot. Now, everybody was excited and thought the “Spotify inspired” model was our saviour. But were these high spirits actually justified?
Our challenges
Inevitably, you will reach a plateau. When low-hanging fruits were eaten, the speed of improvements will decrease. There may come a point when you don’t see any tangible improvement anymore. We hit this plateau 30 months in our Agile journey.
At this time, we managed to achieve our objectives. Teams were largely autonomous and the model was highly scalable. Teams owned their piece of the product and they had a reasonable alignment with the stakeholders.
We did have some technical limitations on specific product components. Some teams needed to align on the integration of the work. And we had a few teams who struggled with Scrum because their work wasn’t suited for the framework. These teams decided to adopt other approaches, like Kanban.
The majority of the teams had other issues. Many teams had the same stakeholders. And these stakeholders had too many reviews to attend. So they cherry-picked and went to the ones they liked best. Some teams had many stakeholders at the Sprint Review. Other teams hardly saw them at this event.
Another issue had to do with the initial choice to have teams working on decoupled pieces of the product. This focus on team autonomy resulted in a diffused view on the total product. We didn’t have a good grasp of the overall goal of a product.
When we had a product objective impacting 3 to 4 teams, we simply missed the alignment on that multiple team level. Teams knew exactly what they had to do for their own part. But they missed the overview to consider the product as a whole. The Spotify engineering culture focuses on autonomy instead of this type of alignment.
Our learnings
It was around this time that I started to realise that Scrum is about building products and not about enabling teams. I realised our products were cut into multiple small pieces. Each team managed a piece with their own Product Owner.
Then it hit me. We should not have these 3 to 4 Product Owners each with the view on their own piece of the product only. We should have one Product Owner for that product as a whole. One Product Owner should work with the teams who all contribute to the product.
Reducing the number of Product Owners was politically impossible on short notice. So I suggested the next best thing: to combine Sprint Reviews. This way, the stakeholders would have the total view on the product, they would not have to manage their time as they did and the teams all had their important inspect and adapt moment with their stakeholders.
While we still had multiple Products Owners for one product, we at least could fix the issues with -arguably- the most important Scrum event. This had a positive impact in several ways:
we had a focus on the overall product;
the stakeholders were more actively engaged;
we had a better view of what we did, what we learned and what we best could do next.
After some time, we began to move towards having one Product Owner per product, having multiple teams. The Product Owners started to put more focus on the product strategy.
At the same time, the Product Owers allowed the teams more space to find their best way to reach their goals. The Product Owners couldn’t be at every team meeting anymore. They had to reinvent their role with the expanded product responsibilities. Focusing more on strategy and less on execution.
We are not where I think we should be, but we are moving in the right direction. And to be honest, we also see great collaboration in the cases when multiple Product Owners together own a product.
Our teams can still largely work autonomously. But the inspection event with the stakeholders, the Sprint Review, is a joint effort with other teams who support the same product.
My conclusion
Our journey with a Spotify inspired model showed me that:
Scrum and Spotify aren’t necessarily a good combo. “Spotify” is about autonomous teams owning a small and decoupled piece of the product. Scrum is about one or more teams serving one product, with one Product Owner.
We needed to alter our approach and partially move away from the principle of “Spotify”. Teams could be autonomous during the Sprint, but they needed to work together at the Sprint Review.
With multiple Scrum Teams, it is perfectly possible to create value Sprint after Sprint without help from other teams or external experts.
Our “Spotify” journey brought a lot, although our assumptions at the start were wrong. But we learned from our experiences and adapted. We moved away from the concept of fully autonomous teams. Now we have teams who are autonomous during a Sprint but align between Sprints. We are happy with how this works out.
We are still learning and adapting. But this is normal. We could have decided to leave everything as we had designed it back in 2017. But this would have been a mistake. The world is constantly changing. An organisation has to adapt to survive.