Throughout our previous posts, we have seen what motivates a company to adopt a DevOps approach, starting with the organisational transformation and the tools required to carry out this transformation.
Now we need to go a step further and address how to move this transformation forward. In other words, who or what will be the catalyst for change. In this article, I will discuss, from my own experience, a strategy that I have been able to validate while implementing DevOps within different organisations.
There are various alternatives:
- Establish a programme of change that comes from management and impose it
- Introduce a “change champion” in every single team.
- Hire a team to be responsible for carrying out the transformation.
- Etc.
Although some of these strategies could prove to be effective, there is one fundamental aspect missing: the change must take place from within the organisation, from within the teams that are going to be affected by these change initiatives. People have to be convinced by the change, and that is difficult if it comes from outside or is imposed.
In my opinion, the winning strategy is to form a DevOps team responsible for initiating the change. This team can also be the seed from where this transformation extends to the rest of the organisation. It is a complex process that typically requires involvement from an Agile Coach to provide guidance on how to make the transition, as well as knowledge and leadership in relation to the choice of tools. This Agile Coach will also provide guidance to the company and the team on the use of Agile frameworks. He or she must have extensive knowledge and experience of the Scrum framework, Lean thinking, Kanban, and so on.
At the same time, a Full-Stack Engineer should be engaged to work hand in hand with those involved, helping them and training them as a team. A full-stack engineer is someone who is capable of performing all tasks within the value stream, at the development level and the testing, systems and automation levels, for example. He or she is not an expert in all disciplines, but can function adequately in all of them.
This idea has certain advantages and risks that we must be very clear about in order to successfully implement the change process. If we want to form a DevOps team in an effective way, it must have certain very specific characteristics that promote success. Additionally, a series of best practices must be followed so that the change is carried out in the right way. There is nothing more wasteful than doing the “wrong thing” efficiently.
- One fundamental characteristic is that this team must be multifunctional, in the sense that it must be fully capable of delivering value autonomously and independently. It must include people from development, operations, quality, testing, security, the business and, ultimately, from any component within the value delivery process that exists in the company.
-
The first benefit of combining members from different departments into one team in this way is that the barriers between information silos are broken down. When you bring these people together, there is a considerable increase in empathy between them. This change alone affects the flow of information in a very positive way. To further enhance this team spirit, it is very important to set aside a physical space where the team can work together. This is not always possible, but we need to bear in mind that productivity skyrockets in teams that work together. In fact, this is one of the basic pillars of agilism.
At this point, it should be noted that, although the team is multifunctional, autonomous and self-organised, this does not mean that everyone needs to know everything, but rather that there should be certain characteristics or skills within the team. There are currently three types of profiles:
PROFILE DESCRIPTION I-shape Specialists in one specific technology. For example, a DBA, a webmaster, a network administrator, a Java programmer, etc. T-shape Specialists in one technology but with a wider breadth of knowledge in other areas. E-shape Specialists in several technologies and knowledge in several areas, with a greater capacity for innovation.
In our DevOps team, we need to avoid having members with I-shaped skills since they inevitably lead to the creation of bottlenecks. This effect is the same as that caused by silos. If you have very specialised departments, information does not flow, and a lot of work has to be exchanged, resulting in conflicts, delays and so on.
- Therefore, we need to seek out team members who are generalists and not specialists. With this in mind, what we are looking for is a Full-Stack Engineer.
- However, not only do we need the team to have this kind of technical training, but they must also show a marked ability for leadership and communication. This team will be the beacon or the benchmark for the other teams and they must therefore be able to communicate their work very clearly and be able to convince others of the benefits of the changes being introduced.
- The members of the team need to have enormous capacity for learning and innovation because they will have to invent and experiment a great deal.
Once formed, the team will have to follow best practices to ensure us that the transformation is being carried out properly.
The Scrum framework is highly beneficial for these teams, since it incorporates certain elements that encourage communication and group work. The following are particularly relevant:
- Keep the team very focused on the end goal.
- Using sprints, you can achieve quick wins that strengthen the team’s confidence and can be used to showcase the improvements to the rest of the organisation. For example, a sprint might focus on setting up the deployment pipeline on a continuous integration server. Another sprint goal could be implementing automated tests using BDD, another could be creating a procedure for automated environment provisioning, etc.
- Daily Scrum meetings. Holding daily meetings with members from the different information silos has a very positive effect in terms of encouraging communication and promoting team spirit.
- Retrospectives. These become essential meetings for evaluating the results of the experiments carried out.
"The change must take place from within the organisation, from within the teams that are going to be affected by these change initiatives."
Apart from these elements of the Scrum framework, there are other best practices such as using “pairing” at all levels. By working on all tasks in pairs, there is a continuous review of the work being done. At the same time, the knowledge about the specific tasks involved does not fall to one member of the team alone.
The result is a spectacular improvement in quality in addition to the dissemination of knowledge within the team.
Another element to implement are post-mortems for the problems caused. Jointly. These types of meetings are a great source of learning for all members of the team.
Last but not least, the quality of everything that this team produces must be exceptionally high. This is necessary because the result of its work will form the foundation for the other teams. In fact, one of this team’s main tasks will be to support the other teams when the time comes to adopt the improvements and changes arising from its research.
In order to bring about this transformation successfully, it is essential that the team has as much freedom as possible to be able to carry out its experiments. In other words, the team should not be subject to formal procedures and policies that might limit its innovation, creativity and capacity for change. The only limitation should be to ensure that it does not negatively interfere with production services.
Why this strategy works
Before deciding to train this DevOps team, we should have some guarantee that the results will be satisfactory. To this end, let’s take a look at some aspects that will build our confidence:
- The friction between departments is reduced, significantly improving teamwork.
- The famous Wall of Confusion disappears, initially for the team and eventually for everyone.
- The technical improvements are implemented in short iterations, which helps to evaluate the result. They also have immediate practical effects on the other teams.
- Cycle times are reduced, resulting from the methodology and technical improvements.
- The team’s motivation increases significantly as a consequence of the quantitative results of its work. This motivation causes a significant increase in the team’s productivity.
And what is crucial is that these improvements will provide the entire organisation with the confidence that the change is possible and beneficial. This both promotes and reinforces the change.
Risks involved in establishing a DevOps team
As I said at the beginning, it is important to be very clear about the risks associated with this way of implementing DevOps, so that they can be anticipated and mitigated if detected. The main risks are:
- The DevOps team itself can become a new isolated information silo. If this happens, the work of the other teams grinds to a halt, because the DevOps team has to approve their work. The net result is that cycle time increases rather than decreases by including an additional element in the value delivery flow
- A team focused on quality can lead to the work they review never meeting their expectations, which exacerbates the problem.
In both cases, the strategy to follow is to ensure that the DevOps team is not static by regularly rotating the profiles. This also ensures that the knowledge generated within the team is disseminated to the other teams. New people coming into the DevOps team will bring fresh ideas and encourage innovation enormously. Furthermore, the increase in lead times due to this quality analysis is mitigated by the fact that the outgoing team members themselves are responsible for carrying out the work. They also train the other teams, which means that the quality will be at the required level.
We need to be vigilant so that these behaviours can be corrected as soon as they are detected.
Wrapping up
In this article, I have explained how to begin the transition to DevOps with a dedicated DevOps team that is responsible for acting as the catalyst for carrying out this transformation.
I wanted to discuss what has worked for me, in the companies and with the people that were involved in each case. It is not the “silver bullet” that will guarantee success. My advice is to experiment and draw your own conclusions.
The ultimate goal of DevOps is to bring about a change throughout the entire organisation. Therefore, the more people involved in the process in that organisation, the better. But we have to strike a balance so that the change process does not cause any harmful effects in the organisation while the transformation is being implemented.
And all this knowing that an initiative of this kind should not be considered as a cost, but rather as an investment. This is important for promoting a profound change and also for the returns it will generate in the short and medium term.
Finally, remember that implementing DevOps is not an end in itself, but a tool for improving value delivery to the customer. Therefore, we need to evaluate continuously whether our initiatives are meeting their objectives and, if they are not, correct them accordingly.
Xeridia’s experience in supporting organisations from different sectors in forming DevOps teams will help guide your organisation through the implementation of these methodologies. Contact us to find out how we can help you.
Emiliano Sutil is a Project Manager at Xeridia
