When Do You Need a DevOps Team?
With all the focus on continuous delivery and test automation, the inevitable question arises, “do I need a DevOps team?”. Just as with other Domain type teams that support software delivery teams, looking at the general question, “should I form a Domain team?” will help answer our DevOps question. So let’s back up.
What is a Domain Team?
A domain team is a cross-functional software delivery team with a special skill set. This skill set is needed by some or all of the delivery teams in an organization. An example of a special skill set is ETL Developers. Where the database structure and queries can be developed within a delivery team, the data loading and associated file maintenance is a small portion of the entire functionality. To bring in an ETL specialist for one or two sprints and then send them off again defeats the purpose of keeping the team together.
Collecting the ETL new development work with the ETL maintenance work into a single backlog presents the opportunity to staff an ETL team that can support multiple delivery teams. Now here is the tough question in Agile Software delivery terms. Is this an Agile team? They have a defined backlog of work. They are cross-functional if we include a Business Analyst to help with story analysis and Quality Analyst to help with testing. What they may not have is a product or project and probably not a release as thought of in the Java world. The kicker is whether or not they would have a product owner. In most cases they will not have a product owner or a product team, but will need to gather stories from other teams.
Justifying the Need for a Domain Team
The answer to the question, how do I know if I need a domain team, is to collect the numbers. Is the capacity of the delivery team impacted by the need to “occasionally” perform with specialty skills? Do we have a quality issue with the work completed? Are there other teams that need this skill set? Will there be a maintenance load that will need this skill set?
Answering these questions and collecting data will not only help to define the size of the team needed but will provide numbers for the justification of the team. We all underestimate the cost in productivity of context switching. Having members of the team stop functional delivery for operational maintenance or to use a special tool can drag down the entire team. Use velocity variance, escaped defects and hangover points to build the case for having a specialty team. Collect the same data from other teams to strengthen your case.
How Do I Know if I Need a DevOps Team?
First define the work of the team. The team could be responsible for only building and deploying software in different environments. It could be responsible for building metrics, analyzing regression suite failures, running security and performance test.
Once you draw the line on the responsibilities collect your data. If your team in combination with other teams in the organization are spending more than one person’s effort on these activities every sprint make the business case for creating the team.
Create the policies for this team to accept work. These policies and their work-flow must be explicit. Without clear guidance the other delivery teams may see your new DevOps team as an opportunity to move all tasks remotely related to the DevOps team. Defining how the software will be deployed and writing the deployment scripts still lies with the delivery teams. Making sure the deployments are fast, accurate and report results are the responsibilities of the DevOps teams.
Finally, expect some hiccups along the way. Whenever new teams and new processes are introduced there will be the need for education as well as trial and error. Make sure you have strategies that allow for some mistakes. Whether it is training, communication plans, user guides or on-boarding practices, everyone needs to know what the new team does and how to work with them.
You need a DevOps team if you can justify the need with data, define the responsibilities, and define a strategy for communicating who is in the team and what the new processes are.
Comments (3)
frank olsen
hi Jann,
please help me here – why isn’t this (any ‘domian team’) just yet another specialized team, creating functional silos, hand-overs, delays, dependencies, un-done work , and other waste in the organization?
To the extent you need a whole team doing this (whatever the domain team is doing), it must certainly be something all teams have a need for, thus the skill-set should be present in all team. Cross-functional, end2end, etc
So – what am i missing? :)
cheers
frank
Good Morning Frank,
Thanks for reading the post. The idea here is to consolidate the work that is common across teams in your organization but is not intensive in any team. You would only create a DevOps team is you have enough framework, deployment, analysis and reporting work to support the DevOps team. Having the work as an add on to each delivery team may create inconsistencies. While this may not be a problem for small organizations it will definitely create coordination problems at scale.
Jann
frank olsen
hi Jann,
thx for your reply
Well, i assume we are at scale since we’re talking about creating specialized teams supporting other teams
Re “inconsistencies” – well, if that’s a concern i guess it would apply to anything the teams are working on, ie the shared code. And that’s for sure something traditional folks raise as a concern when explaining why agile can’t work.
Re “coordination problem at scale” – well, i tend to think we have more coordination problems when working specialized/in silos
I prefer to solve this kind of problems according to how much use/need you have for a skill-set. If it’s enough to staff a full team, it’s probably something which all teams should be capable of doing themselves.
If it’s rarely used, i’d ask 1-2 of the delivery teams to cover that skill-set
Cheers Frank