Self-organisation can be challenging; you need to understand what’s required to achieve, and success needs to be visible, said Mirco Hering, managing director at Accenture. He suggested to create boundaries in which to self-organise and enrich the team’s context, showing how well they are doing.
"I have changed my mind on self-organisation a few times over the years; I really like the idea, but I have also seen this fail very often," said Hering at Agile Portugal 2019.
He mentioned that people who self-organise need to understand all the things that are required to achieve results, and that success needs to be visible to the team. In organisations, both factors are often not easily achievable, he said, which then results in self-organising teams who cherry-pick the things they want to do while ignoring other things. He gave the example of building a proof of concept that functionally works, but has security issues and does not scale.
Hering provided two ways out of this: Either create boundaries in which to self-organise, or enrich the team’s context so that they can see how well they are doing.
To create boundaries, you look at all the things that need to get done and agree where the team can self-organise and where they cannot. Hering gave an example:
In my world, our agile coaches can self-organise on which things they want to work and what clients to work with, but marketing budget and priorities for example are defined by the marketing team.
If you want to enrich the team’s context, you can give them more and more data over time, argued Hering. Let them see the number of security violations, the support tickets raised by users, telemetric data from the infrastructure, and others.
As this would be overwhelming if done all at once, Hering suggested to slowly increase the data flow while increasing the levels of self-organisation.
Mirco Hering spoke about applying ideas from the agile world to DevOps at Agile Portugal 2019. InfoQ interviewed Hering about balancing the needs of teams and organisations, and applying DevOps.
InfoQ: How can we balance the needs of teams, for instance autonomy and self-organisation, with organizational requirements like ensuring that it can be managed and governed?
Mirco Hering: Organisations will have to find the right balance. It is somewhat unreasonable to expect each team to cover everything from infrastructure over security to useability design. We want small agile teams, and they should really focus on what matters most to their stakeholders.
The other aspects should be covered through self-service capabilities like automated environment provisioning or security built into the deployment pipeline. Where that is not possible, shared functions will still play a role (e.g. having UX experts that the team can leverage).
What is key is making these processes as seamless as possible. I like the idea of measuring how dependent the team is on others outside the team, and how long each request for help takes. That gives you two good measures to improve along the way, to see how autonomous the teams are becoming.
InfoQ: What’s your advice for applying DevOps in organisations that are already on an agile journey?
Hering: My sincere hope is that if you are on your agile journey and have anything to do with software, DevOps is part of your journey. DevOps, in its broadest and most meaningful sense, is about improving the overall delivery process. Agile will help you build better solutions; DevOps will help you deliver it more efficiently and more independently.
The key to this is to use Agile for your DevOps journey and to manage your DevOps improvements as experiments in your backlog. Each experiment will either improve your delivery mechanism, or allow you to learn something about that mechanism. When applied correctly, DevOps will create capabilities in the DevOps platform that teams can utilise without having to worry about the details of infrastructure, security, performance and others. DevOps can be a great enabler of self-organising teams, by abstracting away those concerns and making them part of the platform that Agile teams deliver on. And of course the teams can get involved with the platform as much as they want or need to, but in general they can focus on delivering the functional outcomes that delight their stakeholders.
If you have meaningful metrics to guide you, then iteration by iteration you will get better. Don’t let dogmatism about what is or isn’t DevOps stand in your way; as long as you are getting better at delivering software, you are on the right journey.
