Many organization beginning their DevOps journey create a separate DevOps team to start thinking about implementing practices to achieve efficiency promised with DevOps. Thinking about DevOps adoption and breaking it into steps which are to be followed, are influenced from the term itself ‘DevOps’, where meaning starts to take place in mind that it is Dev+Ops. This meaning (Dev+Ops) hardly promote thinking about DevOps holistically which is, everyone ‘together’ in it. The question is who all are ‘in’ it, is it not only the team from development and operations, to which clear answer is ‘no’. The simple reason behind that is, whatever it takes to create product or feature, everyone involved needs to embrace the culture of ‘DevOps’, be it PMO or QA along with Dev and Ops.
Idea of a separate DevOps team does not make sense as it seems implicit, that, it is bound to become a ‘silo’ again in sometime due to about-to-die cross communication. The good answer to this situation could be a separate business function or alternate team structure where everyone represents rather than only Dev or Ops dictating the way forward. Then what is DevOps culture any ways, is the question if it is not a tool or simply Dev + Ops?
- No matter we have vertical structures, but customers or users experience is horizontal. Users or customers are happy if product works for them as they intend to use, they do not think in terms of development teams or operation teams or QA teams. Promoting this point will help think about team structures rather than having a separate team. Customers or users experience is in totality and we need to adopt structures which promotes this thinking.
- Further to point 1 above, when team structures are aligned as a separate function or otherwise, the traditional project management has to change their idea about utilization of team members due to simple fact that, if team is trying to adopt practices to do away with inefficiencies, then there would be time required to think and experiment about ways forward. Vertical teams can represent themselves in other teams, e.g. Ops representation in multiple development teams but then that would be asking for multitasking, as each team needs or maturity would not be same at anytime. Multitasking is considered good, however in reality it has not produced desired results simply due to context switch that is required, it introduces delays. Promote thinking around multitasking as this will directly impact productivity.(Doing several things at once is a trick we play on ourselves, thinking we’re getting more done. In reality, our productivity goes down by as much as 40%. The more you multitask, the worse you are at it.)
- Taking the point of team structures further, separate team promotes culture that for tasks which are said to be part of other teams does not belong to them. This culture deters ownership in big way, as culture required is, if I am changing it, I own it. This is specifically true for development and testing.
- DevOps (DevSecOps) would required usage of tools to implement practices or tune processes. They are multi-domain and thus every team members need to be aware of the implementation to realize the importance, why something is being done and how people would be impacted in their day to day working, as it provides a chance to reduce reluctance of adoption plus pave the path for cross domain knowledge which is essential for any DevOps implementation.
In nutshell, to think about culture, think around points of structures, utilization, ownership, multitasking and cross domain knowledge and how these points are interlinked
ABOUT THE AUTHOR
SANJEEV MALHOTRA
Director – DevOps and Cloud