DevOps Culture Anti-pattern: Silos

The technology industry has embraced the DevOps definition around the idea that it is used to break down silos and barriers to teams working together. As a portmanteau, the word DevOps clearly states in its own name the purpose of the philosophy. However, just smashing together a development and operations team does not just automatically eliminate silos within an organization.

There is an excellent explanation of DevOps team topologies that describe how DevOps functionally works within a team structure and organization. Each situation is unique and this resources describes some common options for structuring to avoid a team anti-type. However, there are red flags that warn of issues a work environment must overcome to fully take advantage of a mature DevOps practice.

Some warning signs of silos within an organization may seem minor or trivial, but they can make a huge difference in flow of work through a system.

  • Limited or no developer access to operations documentation, tools, or data
  • Project estimates do not include operations work in timelines or cost
  • Operations work is expected to be completed in “Sprint 0” instead of finding a way to stagger the effort across many sprints
  • Operations teams do not sit with developers

Being intentional about work between multiple teams is the critical path to solving these types of problems. Make sure that an entire technology org has access to documentation for each of the teams. But a better step would be to proactively share knowledge and information with each other in a way that helps solves other problems. This should not be limited to coordination and collaboration between just Dev and Ops. A better description could be BizDevSecQaOps (or whatever combination of teams works here).

In my experiences, the path to success between two teams involves running through the  problems someone is dealing with and using your skill set to uniquely solve problems. This simple skill is called “listening” and I have been able to successfully employ it to improve build processes to help developers and create a new automation server for the QA team. It takes concentrated effort to try and hear what issues someone else is facing and distill that into a reasonable solution. I have found that every iteration of combination of efforts leads to improvement and provides great business value.

Post will all the anti-patterns: