devops-team-structures

Which DevOps Team Structure Are You Using?

Implementing new DevOps methods into existing business processes represents a huge challenge, and research has found that the approach taken, and the corresponding team structures put in place, can seriously inhibit or accelerate
success.

Typically, researchers found that there are three different models currently being used, with the different approaches reflecting the level of adoption and confidence in the technology:

  • Most common is the DevOps team silo model where there is a separate DevOps team that sits between Dev and Ops.
  • The second most used is the DevOps full collaboration model where there is no distinct team, but DevOps becomes an additional task and part of everyone’s job
  • The third most deployed team structure is that of the DevOps tool team where a separate DevOps team is responsible for the new applications and tools required to implement the DevOps processes.

DevOps Team Silo

In this approach, a separate DevOps team is created that sits between Dev and Ops, so that the original organization is preserved. The responsibility and advocacy of the DevOps adoption is given to this new team.

This approach feels comfortable as it maintains the current status quo, but it can lead to a much slower implementation and limited acceptance of the new DevOps methodologies. This is because silos can create a structure in which departments focus on their own goals instead of working toward common organizational objectives.

Unfortunately, a silo mentality can often lead to strained relationships between departments, which can negatively impact efficiency and affect profitability.

How DevOps Can Eliminate Silos

In today’s fast-paced and ever changing world, a silo mentality is detrimental to the innovation required for companies to stay ahead of the competition. The integration of the DevOps mindset will can help to break down silos, and increase collaboration and overall productivity.

To facilitate a change to DevOps, organizations should create DevOps “champions” to act as mediators between departments. This role works to communicate and implement the DevOps methodology across teams while helping to break down inter-departmental barriers and facilitate collaboration.

To successfully implement a DevOps cultural shift, the following strategies can be used:

  • Focus on common organizational goals. Define specific goals that are aligned with the organizations’ common objectives. Set out in detail how departmental goals directly support overall business goals.
  • Use shared metrics. A consistent measurement tool holds everyone accountable and encourages stronger teamwork by enabling leaders to track progress across the organization as a whole.
  • Organize regular meetings. Inviting team representatives to participate in recurring meetings creates an opportunity for everyone to give project updates on progress and status.

DevOps’ philosophy and methods such as continuous delivery will drive collaboration among development and operations teams. Although businesses may struggle at first with DevOps due to existing siloed IT functions, a DevOps-focused culture empowers developers and operators to deliver new services and resolve issues at a faster pace.

DevOps Full Collaboration Model

Collaboration is the key cultural aspect of DevOps, bringing together the Development and Operations teams and using real-time feedback and communication to allow rapid changes to applications and services while keeping a stable and robust environment.

How to achieve collaboration in DevOps

Initially, focus on reducing any existing operational delays and communication gaps, particularly among geographically distributed teams. An inspired cultural change driven by all teams is required, so consider some of the following techniques to drive collaboration in your organization:

  1. Define clear goals is the first step to team collaboration. Identify a common set of objectives for all teams and stakeholders involved. Often teams struggle to engage when their priorities are different and they cannot find a common ground. A common set of priorities lays the foundation for developing an approach and working together to achieve the goals.
  2. Promote a “one team” approach to build trust between teams and foster a culture of collaboration. This cultural change is vital in order to make everyone feel part of the team and emphasise the important nature of each individuals’ work.
  3. Develop a roadmap that defines a path to success. The roadmap should define everyone’s roles and responsibilities, and how each team’s work contributes to the overall objectives. Setup regular check points and reviews to make sure the roadmap is still leading to where you would like to go.
  4. Use collaboration tools to create automated systems development life cycle (SDLC) workflows, and the integration of teams into these workflows.

The DevOps collaboration model shows a strong desire and determination to extract the most value from DevOps, and it is probably the most challenging but most rewarding approach. A lot of work and persistence will be needed to transform the existing structure into full DevOps, but the benefits will be worth the effort.

DevOps Tool Team

Often, there is an initial focus on exploring the tools required to setup DevOps workstreams and automate existing processes.

Business managers can be extremely wary of overloading development teams with the need to use new, complex tool chains that required for building DevOps workflows. As well as learning and keeping up-to-date with the new technologies, there are ongoing maintenance activities, upgrades to build servers, operating systems, plugins, test automation tools, and so on.

So on the face of it, setting up a separate “DevOps tool team” appears to be a good solution that can help address these issues and boost productivity. Dedicated experts can then implement and maintain the required DevOps tools and make them available for others to use. This leaves the current organizational structure intact and allows the development teams to continue to focus on current project deliverables.

However, while a dedicated team can be beneficial in terms of an improved tool chain, it’s unlikely to have any impact on the overall cultural values or structure of an organization.

Therefore, organizations should be wary of prioritizing tools over communication, and failing to make the significant cultural shift that is needed to implement full DevOps by breaking down silos, bringing development and operations closer together, and promoting cross-team collaboration.

DevOps Transformations Are Difficult

Remember, DevOps transformations are a fundamental change in the traditional structure of IT and are therefore difficult to implement.

A shift to DevOps represents not only the adoption of new technology but also a cultural and organizational transformation which can be challenging for existing functional or departmental silos. These changes may easily be perceived as threatening for departments, people and processes which are comfortable with the current organizational setup.

So before starting with any implementation, you need to decide if DevOps will be useful to you and what will be your likely return on investment.

Important key information to consider includes:

  • The history and definition of DevOps
  • DevOps development as an evolution of Scrum, Kanban, Lean, and other Agile methodologies
  • Processes and activities that would benefit from DevOps implementation
  • The steps required for the implementation of DevOps in your organization
  • Real world, best practice case studies from other successful DevOps implementations
  • How to measure the results of your DevOps implementation
  • The best way to get started on your DevOps implementation
  • Decide what DevOps structure you are aiming for; are you aiming for “full” DevOps or just a bit of automation here and there?

You will need an honest assessment of your organizations culture and ability to adopt and see through change as this is the most important key factor in determining the success or otherwise of any DevOps initiative.

Give a Comment