Learn about the characteristics of these three team structures for DevOps adoption and success, and how to choose which one is right for your organization.
Agile is taking the world by storm. Businesses of all shapes and sizes are seeing the benefits of embracing DevOps and moving to adopt a more agile culture. A number of high-profile companies have had great success in applying DevOps, including streaming giants Netflix and Spotify.
We’d like to tell you that everything is rosy but, while some are celebrating, others are struggling. The reason? It’s often the way they’re working.
Getting the formation of teams and structures right in order to implement DevOps efficiently isn’t easy but it’s absolutely key to a successful DevOps adoption.
So, what exactly is the best way to work?
To answer that, we need to look at what companies are doing. Whilst there are many ways you could structure your teams, we typically see three types in our work with clients:
In this scenario, the Platform Operations Team sits inside the different business units (e.g. mortgages or payments) to help the teams in that unit adopt different working practices. This provides a wider holistic view to the different business units.
The team comprises developers, QAs and release engineers who are responsible for building out platform availability, upgrades and providing new services. There would be an overarching Platform Engineering team to ensure consistency across business units. They may sometimes be referred to as SRE s (Site Reliability Engineers) but the responsibility is a far wider reach as they need to enable business units as well.
This is a way of organizing around virtual teams. The idea is to take people from each of the business units and form one single virtual team where the high-level strategic and tactical decisions are made.
The virtual team can then take information from the business units to bring out a holistic view of what each unit needs and wants, using that to build out the practice.
Rather than being a dedicated platform team, it is designed to leverage existing knowledge within the teams themselves.
This is a much more traditional way of working. Instead of being formed by business units, the process is built on different specialized functions such as developers and sysadmins.
Rather than attempting to create a collaborative model, this method is extremely linear – you start with the developer to build out the practice, following which it is pushed out to the different functions. All the teams have their own champions and essentially do their own thing independently of other teams.
All businesses need to adopt the strategy that works for them. The three we’ve outlined above are some of the most common ways of working that we’ve seen our clients use and that we’ve used to help transform our clients’ organizations.
In addition, this structure provides the most consistency thanks to its dedicated team. In more regulated environments where governance and regulation compliance is key, a central team can ensure compliance across the organization.
