Inspired by Spotify, DevOps, LeSS and Scrum
Sometimes you have to take a step back to appreciate the full picture. This is certainly true with how I view my companies’ Agile journey. When I am in the midst of it, I am focusing on the things that don’t go well. Things that we struggle with, things that we wish to stop.
I believe this is the nature of a learning company. You put all your efforts into improving and fixing. You have more focus on the things that don’t work than on the things that do work.
Throughout the years, I have found inspiration in the things that we didn’t do so well and I wrote about it. The majority of the “Are You Serious” series discusses anti-patterns that I have seen in my own company.
I have been frustrated at times. Sometimes I wasn’t happy with the decisions my company made. Other times, I thought we improved at a snail's pace. But lately, my perception has been changing. I came to realize that, compared to other companies, we have been doing quite well.
Here’s the story of our agile journey:
We started our journey inspired by Scrum and Spotify.
We then moved further towards DevOps.
We are now working to optimize things inspired by LeSS.
Lessons from Spotify and Scrum: autonomous cross-functional teams
When we started our journey, our main issue was the heavy governance and the handovers of the work between teams. It undermined our growth. Our product development was slow and indecisive. Other companies had all the opportunities to overshadow us.
At the time, Scrum was already the most popular agile framework. It promised many benefits:
Cross-functional teams with all the skills to develop and deliver their product feature, removing handover issues.
Decision power at the team level, with their stakeholders, removing the necessity for additional governance.
Focus on delivering value first and foremost.
Another influence was Spotify. The Spotify Engineering Culture videos were loaded with inspirational topics. The main thing we took away was the concept of autonomous teams.
We wanted to remove dependencies between teams. Each team would be responsible for its own product feature. A team would not need other teams or people to create product increments.
This was a major change of culture and of the way of working. The organisation invested heavily in it to maximize the chances of success. It wasn’t a simple flick of the switch.
From the moment we started to work in autonomous Scrum teams, the results came almost immediately. The teams fully utilized their autonomy. They worked hard and were motivated to remove dependencies as fast as they could. We also succeeded in doing away with many governance procedures.
After a few months, we saw measurable changes for the better:
Our customers were happier with our products. Their appreciation for our company went from neutral to positive.
Our employees were happier, rising from mildly positive to extremely positive about the company.
The stability of our product increased, although there was still room for improvement.
We were able to deliver more features with a shorter time to market. We saw this impact due to the removal of handovers and heavy governance.
We had taken a major step in the right direction. But we always looked for additional improvements. Our first focus was on IT Operations.
Lessons from DevOps: you build it, you run it
One of these improvement areas involved development versus IT operation. We still had that separation. We had teams who built the product and people who deployed and monitored the product.
This separation of responsibilities was a major obstacle to improving the stability of the product and our feedback loops. A year after the move to Scrum teams, we initiated the formation of DevOps (Scrum) teams.
Previously, the Scrum teams were responsible for building the product. The move to DevOps added deployment and monitoring. This included the handling of production incidents.
This step helped us to put more focus on topics like test automation, CI/CD and monitoring. We reaped the following benefits:
We simplified and stabilized the quality control and deployment of our products.
We were able to deliver faster, allowing us to have faster product feedback than before.
Being responsible for the production incidents, teams were more aware of the quality of their product feature. They put stability higher on the agenda, resulting in a drastic decrease in production incidents and technical debt.
We had taken the next step in our journey. But we still saw improvement areas. At this point, we were a feature factory. We had grown to be very good at creating and maintaining product increments. But we didn’t have an overall feel of what would bring the highest value to the product.
The focus on team autonomy led to suboptimization. Every team optimized their part of the product. They didn’t have a good idea of what would bring the most benefit to the product as a whole.
Lessons from LeSS: the product has centre stage
We had autonomous teams. Every team worked on a small piece of the product puzzle with their very own Product Owner. But those Product Owners operated without a full picture of the product. This brought us to the next step in our agile journey, the focus on the product. This is the phase that we are in right now.
Scrum is product-focused. The Product Owner works to maximize the value of the product together with one or more teams. This brings us to the definition of a product. What is a product in the first place?
The Scrum Guide says the following:
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract. — Scrum Guide 2020
This is a vague definition. Especially the part that says “a vehicle to deliver value”. An online reporting feature is such a vehicle. It helps the customer to gain insights into the history of their transactions with us. It brings them a world of information. But without the online payment functionality, the reports are worthless. Reporting is a piece of the product.
Another example is our anti-money laundering tooling. It helps us to adhere to the regulations of the financial supervisors. But again, it is nothing without actual payments. Anti-money laundering also is a piece of the product.
We decided to use a different definition of our product. We started to look at the product as a whole. This meant a shift of perspective of the Product Owners.
Product Owners had to make decisions involving the product as a whole instead of the smaller piece of the puzzle. They also had to work with multiple teams. Multiple autonomous DevOps teams would together create the product.
This brought us to the lessons of LeSS (Large Scale Scrum). To increase alignment and focus on the product as a whole, we have started to introduce:
Combined Sprint Reviews. Multiple teams working on the same product have their Sprint Review together to align with their stakeholders. This brings the focus on the product as a whole instead of a product feature. It also makes the life of the stakeholders easier, who now only has one Sprint Review instead of multiple.
Combined Sprint Plannings. All teams working on the product will start the planning together to define their goals that align with the overall vision of the Product Owner. The second part of the planning has the teams creating their plans separately.
These are inspired by LeSS. We are not doing full LeSS. We haven't experimented with the combined Sprint Retrospective yet, to name a typical LeSS thing we don’t do.
The benefits of this step are:
We have a better focus on what brings value to the product as a whole.
We have a better conversation with our stakeholders.
Everyone has a better understanding of the impact of their work on the product as a whole.
We have created our own blend: groups of autonomous, cross-functional DevOps teams working on a product, using Scrum and parts of LeSS. It’s been several years since we started our agile journey. And we are far from finished.
Next steps
We are in the middle of our transition to the focus on the product, away from product features only. But we are already thinking about and working towards the next steps:
We wish to put the outcome above output. We need to find ways to align business goals with the product we are building. We need to start understanding the impact of our product. Delivering increments is not the same as delivering value.
We need to focus on the complete product experience. Our agile journey has been heavily IT-focused. But a product is more. We have to find ways to better collaborate with sales, operations, finance, and all other people adding to the product experience. We need to focus on the overall value of the product and on how everyone works towards the same goals.
There are plenty of challenges ahead. Sometimes, it feels daunting. But when I look back and realise what we have achieved in a few years, I’m confident we will succeed.
Join Medium with my referral link — Willem-Jan Ageling
As a Medium member, a portion of your membership fee goes to writers you read, and you get full access to every story…medium.com