One of the major components of DevOps is people, more specifically the culture that it brings to the table. For the culture of blamelessness to be imbibed, there needs to be major overhauls to be done with the way teams are structured. Most of the culture that we see today in non-DevOps environments stem from the organizational structure.
In this article, I will discuss the nuances of a DevOps team, and how it differentiates from any other team that exists – including the agile teams.
DevOps Teams Redefine Silos
Current team structures in organizations are based on functions. All Java developers are bundled into a single team, server administrators into a team, testing professionals into a team and so on. This represents various silos that exist in an organization. Each silo will look out for their own interests, in terms of agreed delivery targets, career achievements and capability improvement. What they don’t focus on – is the customer, because the structure is conducive to looking internally rather than to the objective of existence (meaning customer and the products to develop and support).
The new look teams – read DevOps team redefine how teams are formed, and which roles must be clubbed together.
DevOps Teams Revolve Around a Product
The new teams – DevOps teams revolve around a product or a service. The new teams will have all roles that support a particular product or a service. For example, if there is a product called as Pickaxe, then all the people involved in the development and maintenance of the product would make up a team. For example, the Pickaxe DevOps team will have a scrum master, developers, testers, business analyst, architect, DBA and operational roles.
The people in this team will only work on Pickaxe and not on any other product. In other words, they are unlikely to be shared across DevOps teams. The only exception being an architect, who might not have a role to play across the entire product lifecycle.
DevOps Teams Follow Blamelessness
The principle of DevOps is to transform to the culture of blamelessness. This includes collective responsibility, and failures are not blamed on individuals, but rather work as a group to get past it.
You will find that the DevOps teams don’t believe in me or you, this gives them a better environment to not blame individuals when things go awry. Nobody is perfect. We are humans, so making mistakes (read defects) is something that happens from time to time, so there is no point in blaming individuals after all, right?
This aspect is critical for teams as DevOps aims to build a system in which the defects if any get captured in the earlier stages.
DevOps Teams Collaborate
Collaboration is one of the major pillars of the DevOps culture. Collaboration is where the DevOps team works as a single unit in achieving the common objectives. The DevOps team’s journey starts with blamelessness and briskly moves towards collaboration and cooperation.
Suppose there is a defect. And let’s say that the defect was caused by a particular individual. There is a popular saying associated with DevOps – you build it, you run it. In this case (where a defect crops up), it does not hold water. When there is a defect, the DevOps team that believes in collaboration, works as a team to fix the defect, and then move onto other development activities. In other words, the defect is not left to the perpetrator to rectify it.
Collaboration in a DevOps team also refers various levels of collaboration, including collaborating with the operations during the design and build phase, developers collaborating with testers across the lifecycle and business analysts collaborating with the development teams during various defined stages of the development and support lifecycle.
DevOps Teams are Agile
Agility is the new normal in software development. Agile project management has taken over in a big way, and DevOps complements Agile project management by speeding up the cycles, and reducing defects.
To this effect, DevOps teams are expected to be Agile, they are expected to be flexible for new requirements, defects cropping up at any stage in the lifecycle and for unexpected events like problems with the delivery pipeline.
You have also seen Agile (project management) teams in action as well, such as scrum teams. The difference between an agile team and a DevOps team is straightforward enough. An agile team consists of people who are involved in the development of a product, and a DevOps team consists of development as well as operational resources. So, in a way, agile teams are a subset of DevOps teams. In a typical setting, a DevOps team could be made up of multiple agile teams, plus the operational resources.
DevOps Teams are Multi-Skilled
Our industry is moving towards automation and people with single skill are soon fading out. It is expected that people can do more than one kind of activity, to ensure optimum use of time and money.
A DevOps team too expects its resources to be multi-skilled to ensure smooth functioning, and even loading of work activities throughout the product lifecycle.
I often get asked if a server administrator would be asked to start coding. The answer is no! Multi-skilled does not mean that you pick up activities that are outside the realm of possibilities. What could be expected is that a server administrator doubles up as a tool expert, a developer who can also test and a tester who can also write code.