CIOReview: DevOps Team is a Myth

To prepare for the future, you must understand the past. To understand the term DevOps, we must deep-dive into the original ideology behind it. When Patrick Debois first introduced the term “DevOps” in 2009, it was simply a re-arrangement of Development and Operations teams, to work towards common and non-conflicting goals. Since then, practicing DevOps has evolved, and its implementation now addresses the entire software development lifecycle management. Still, nobody seems to agree on what DevOps means. As a conceptual and holistic approach, it’s about culture, automation, lean, measuring and sharing (CALMS). The foundation for DevOps should start by establishing teams with full autonomy inside their domain to nourish the culture of ownership and innovation.

DevOps emerged to streamline software development in both the productivity of developers and the reliability of operations. Promoting a better understanding of service quality, security and foremost end-to-end accountability, it's not about creating new teams or roles, but rather a cultural shift that impacts the entire organization. However, what started well, some organizations have regressed by creating DevOps roles and teams and delegating responsibility for infrastructure, tools, and software delivery capabilities to someone else. Where did we go wrong?

DevOps Delegation Downfalls

A typical challenge is understanding that DevOps is not a position, a tool or even a process. For years, companies used to buy DevOps engineers, tools and platforms from vendors and consultants that were trying to make a market around it. Finally, we’re ready to call it DevOps transformation, which is a cultural change in people rather than a solution you can buy. People create new habits, processes, and tools, not organizations.

During my career, I’ve worked on different teams like CI (pipeline before DevOps), Platform, Microservices, and Cloud Operations, all of which were eventually referred to as DevOps teams by others. The common thing is that all these teams support other teams, and I think what happened is that old service teams are now rebranded as DevOps. Similarly, most Ops professionals who can read code are now called DevOps Engineers. What happened?

Scaling the Human Challenge

The problematic assumption in DevOps is, that product teams with full autonomy are expected to have end-to-end responsibility. No single product team is truly responsible for the production environment but managing their application in a production environment. With the accelerated speed of cloud computing, emerged compliance regulations and raised several integrations and technologies, no team can master them all. To manage this complexity, the product team would need very capable people with different skills, from developers to hardware experts and from QA engineers to network specialists. Having a big team with conflicting interests is hard because the slowest factor in software development is us, humans, and in the end our memory is limited. We can work asynchronously, but we scale badly.

DevOps is a culture based on a service mindset and a role, that promotes developer productivity. DevOps is not a job, but it’s an organizational strategy. Ultimately, DevOps is all about communication and in one doing.?

For the human mind, it’s logical to limit the scope of work by setting artificial boundaries. This is where service teams come in. They exist for a reason and are healthy for the developer experience. However, service teams should be helping product teams, not making things on-behalf of them. The best way to do it is to provide self-service solutions. One of the best examples is how public cloud providers work: they offer on-demand resources through self-service provisioning.

Balancing Efficiency and Responsibility

Different organizations need different team structures and capabilities for effective DevOps. Calling your rebranded Operations team or dedicating tools team “DevOps” is a huge anti-pattern. Embedding Ops people into product teams can work, but they will ultimately work from a different backlog with different priorities for stability, while businesses may prioritize speed.

If DevOps is culture and not a team, why a service team is doing things for you, on your behalf, is a huge DevOps anti-pattern? Because it violates the responsibility in the “you build it, you run it” mindset. By delegating part of your operations to another team, you’re also transferring part of the responsibility.

If product teams are expected to be responsible for all aspects of their applications and connected services, it could potentially make them too big and inefficient. This would lead to a waste of time on tasks such as updating dependencies, maintenance, and learning individual services, taking focus away from their core product. Using service teams is a must to retain software development speed and stay competitive. Same way, if every product team would implement duplicate copies of the same services other teams are using, it would not only be ineffective but create unnecessary silos.

The Evolution of Service Teams

Service teams often evolve into platform teams, but they have a long reputation for being inflexible, costly and a single point of failure. It's important to treat them as a real product team with user-driven development having a visible roadmap, and clear priorities. Platform teams are an essential part of DevOps and can greatly enhance the developer experience.?

Service teams working for product teams are good, but sometimes that doesn’t cover all the required knowledge. Welcome to DevOps advocacy! Our?DevOps & Developer Experience?team helps and enables product teams and leaves ownership and knowledge to them. We provide hands-on support, do coaching, workshops, and tooling and share knowledge. To be able to support and spread awareness and practices throughout the organization, our team includes DevOps professionals, Advocates, and Security and SRE leaders with diverse backgrounds. Our team does not have an expiration date, but as product teams mature, we will work towards making ourselves redundant and transition to other areas.

DevOps: Improving Developer Effectiveness

Our focus is to make developers more?effective?and spread good practices from team to team. While it's not feasible for product teams to possess expertise in all areas, we assist them in achieving that goal. And that’s what DevOps is all about continuous learning, and we strive to foster that mindset within our organization.

For me, DevOps is a culture based on a service mindset and a role, that promotes developer productivity. DevOps is not a job, but it’s an organizational strategy. Ultimately, DevOps is all about communication and in one doing. DevOps means different things for each company and it’s a good thing, but eventually, practices will standardize. Someday, DevOps will be ready, and we will move on to the next buzzword, which might already be here… Have you heard about Developer Experience?