Our organisation is constantly changing
Bringing Dev and Ops together: “Now I’m wasting all my time on fixing incidents!”
Part 3: DevOps makes our issues painfully clear
This article is part of the series:
Our organisation is constantly changing. We have to inspect and adapt all the time to remain market leaders. Sometimes we have pivotal events that come across as drastic changes (like forming a new organisation structure), but in reality the changes occur organically with pivotal moments that define the current direction.
This article is part of a series. Some articles will describe the organisation of the change, other articles dive into outcomes. This article focuses on one of the outcomes: how DevOps made our issues with incidents painfully clear.
From Dev and Ops to DevOps
One of the pivotal moments in our journey was when we brought ‘Operations’ within the Development Scrum teams. The idea behind it is the obvious one: the team would take responsibility for the whole life-cycle of a product, from idea to support (and decommissioning — if needed). We brought the following message forward:
You build it, you run it! — Werner Vogels, Amazon
We expect that bringing Dev and Ops together will bring is many things, like:
- Cross-functional teams, able to create and sustain valuable products;
- Enabling CI/CD;
- Faster resolution of production issues;
- Increased quality and stability of the product.
Making the incident backlog transparent
It’s not that this started to materialise immediately. We needed to bring forward some improvements to help trigger this. One of the improvements involved incident management. We
- made transparent what incidents are pending per team. Teams could easily track incidents as they were presented on an easily accessible single screen.
- changed the incident assignment groups to include everyone of the Scrum team (and not only the people formerly from ‘Operations’).
Disruption
One of the teams — maybe other teams too, but from this one I’m the Scrum Master — felt it as a major disruption. During the Sprint Retrospective some brought the following issue forward:
“We don’t have time to work on new stuff. This is awful. I am wasting all my time on fixing incidents!”
Here’s why I was happy with this observation. Previously resolving incidents was done by a limited number of people from a different team and they were constantly overworked. But they did not succeed to bring their issues across. Even warnings didn’t work:
That has changed completely. The changes that we implemented to raise the transparency on the incidents resulted in more awareness. My team started to understand how much time and effort is needed to solve the incidents. “You build it you run it” materialised. Developers started to realise that they have the key to reduce the number of incidents by investing in stability before deploying to production.
Conclusion
In the past many in our organisation have tried to reduce the number of open incidents. We had many meetings, created many plans and failed many times. Now — with the decision to have DevOps teams and a bit of transparency — teams are triggered to resolve the issues themselves. And they do just that!
Long live self-organising cross-functional teams!
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
Do you want to share an article in Serious Scrum? Connect with us and make it happen!
Also, you’re all invited to the Serious Scrum Slack workspace. Come join the conversation! Just follow this link.
We also have a LinkedIn group to share our articles and discuss Scrum.