When Team Autonomy is a bit too much
source: https://stocksnap.io/

DevOps initiatives are everywhere. You can’t go to a meetup or conference without being exposed to at least 1 track about DevOps. Companies share their achievements and DevOps always plays a role in this. One of the great things about DevOps is Team Autonomy. Teams which are responsible for their IT product from the very start of the source code all the way to deployment.

Scope of responsibilities

Talking about the scope of the tasks of DevOps teams gives insight in their responsibilities. Start with the business perspective. Teams have to work according to the needs of their stakeholders. User stories should reflect this.

Remember the User Story format? As a … I want to … so my customers can do …If your User Story does not contain the last part, there is no clear business value. At best the User Story provides an improvement to a certain situation. If it comes to requirements engineering, it is crucial to setup the right requirements at the very beginning.

Changes to application pop up at any moment in time. Even when applications are already in production. That’s the nature of DevOps teams: you build it you run it, and you continuously improve it. Once in production the team has to think about logging, monitoring or auditing the system. If DevOps teams have a high level of autonomy they have a lot of responsibilities. So should their capabilities. It’s one of the risks being faced by this “new way of working”.

Risks at several places

When an organization moves towards DevOps it’s wise to think about the level of desired Team Autonomy. Given the fact that there are a high number of DevOps and Agile coaches and courses it proves that a lot of DevOps teams can use some advice.

When Team Autonomy is a bit too much
source: https://stocksnap.io/

It’s not very difficult to change User Stories to support the business objectives – however it is difficult to oversee all of the (possible) technological solutions which DevOps teams create. Think about a big bunch of micro-services, the security of a containerized environment, the various ways to run serverless code, etc.

In the public cloud, things get even more complicated. In AWS – teams can be bound to a single Virtual Private Cloud (VPC) to deploy their resources in an isolated way. Azure has the concept of resource groups as a boundary for resources. With these models, DevOps teams work in great isolation.

Isolation and risks

In the use cases mentioned above, it is possible to share resources between teams. However, how to keep track of all of the connections between resources (and thus teams)? Great to reduce security risks but pretty bad for other cases.

All of these examples can pop up very soon when the level of team autonomy is a bit too much. Consider the following risks when thinking about the desired level of team autonomy which fits your organization.

The organizational perspective

  • Although a lot of DevOps teams have highly skilled people, multiple teams can make the same mistakes when working in too much isolation. It’s difficult to spot these mistakes when there is sharing of information between teams.
  • If every DevOps team is allowed to use the public cloud in the way they want, they might not choose the most cost optimized solution. Pay per resource per time unit is very common. Budgets can get out of control very quickly. Your cost advantage of running your applications in the cloud is gone if you don’t manage cloud resource usage.
  • Once every team can do whatever they think is perfect, a lot of discussions can pop up – slowing down the development and progression of the entire organization.

The source code perspective

  • Patching security vulnerabilities across a lot of (similar) components can slow down an organization. If components are created by a central team and reused by other teams, this is not the case. Reporting and prioritization vulnerabilities takes more time on a team level. It also creates more risk of being exploited.
  • When each DevOps team has its own source code management solution (e.g. CodeCommit) which make it impossible for other teams to read and learn from source code of other teams. Collaborative building up knowledge will be very hard/impossible.
  • When working with container images – teams create their own (base) images which might have similar features of other container images. Building similar things is a waste of human resources. Container images are large: it eats a lot of disk space. So better reuse the existing base images.
When Team Autonomy is a bit too much
source: https://www.docker.com/

OK, then what?

With these considerations in mind – what would be the best solution? As always the answer is “It depends”. It really depends on factors like: what is the business culture of your organization, how mature are your teams, how much control does your organization require, how many teams do you have, etc.

Maturity of the organization and individual teams matters more than you might think at first glance. Check out the state of DevOps article for more information on DevOps maturity and performance.

All in all DevOps tries to break silos, let’s not create a large number of new silos consisting of individual teams. I hope you are aware of the risks being mentioned in this article and that the considerations help you to define the right levels of team autonomy for your organization.