DevOps teams still need to mature – and so do their leaders
DevOps can ensure that IT services are delivered much more efficiently with the proviso that it is properly implemented. DevOps expert Niels Loader, a principal consultant at Quint Wellington Redwood, does, however, see some stubborn problems like a lack of good leadership and an ‘old world’ attitude among teams.
Facebook, Amazon and Spotify are shining examples of the application of DevOps. They are all able to introduce high quality pieces of software quickly and very frequently. But they are the exception, according to Niels Loader. “There are only a small number of IT departments that are currently using DevOps properly.” Most DevOps teams are still encountering problems that are preventing them from benefiting from the opportunities this method offers. And this has a lot to do with a lack of good team leadership, Loader believes. He notes that many IT managers cling to an entirely personal view of the way DevOps should work. “Most IT managers don’t yet understand what DevOps means. Many managers of departments that work with DevOps are convinced that developers don’t want to have anything to do with IT operations. And of course there will also be developers who don’t want to have anything to do with the production, because then they cannot be held responsible for anything. However, a manager must convey the message that the entire team is responsible for the service delivered to the customer.
You need to show customers that you are an integrated whole and thus make it clear that you are there for them,” says Loader. “Developers in a DevOps team must ensure that what is in production continues to work, and they need to take responsibility for this.” According to Loader, the average developer really does want to know how the system works in practice and how it is used. “But, by placing everything in silos, the management of IT departments has ensured that developers are isolated. They are too compartmentalized. Moreover, it is instilled in them that they are not part of production.”
Automation is taking over
The behavior of team members, too, is far from ideal. DevOps is focused on automating large portions of their work. Loader: “Most of them are not very keen on having automation take over their own work. Understandably so, because you want to keep your job. And yet it is better to automate the less valuable aspects of your work because what you’re then left with is a better job. For example: these days, the realization of a test environment can take a week. This can easily be automated and then your test environment would be ready in about two hours. However, the management pays too little attention to allowing their teams to work more efficiently. And in turn, the teams don’t seem to mind.”
It is therefore vitally important that IT managers pay a lot of attention to the composition and culture of a DevOps team. Loader: “Once a team has been set up, it usually doesn’t work well straightaway. There are many different roles in the team: developers, database administration, operations management, architect, application administration. What applies here is: one is none. Take the database expert, for instance. A team should realize that more people need to acquire database skills. Within DevOps teams, increasingly more overlaps of knowledge and skills need to be created. The team members should support one another in order to be able to do a lot together. What I say is: ‘A team is responsible for the health of the service.’ If the service has an illness, you have to cure it to improve the health of the service. That is the job of a DevOps team. When you put it like that, it does strike a chord.”
Molding a team
A new DevOps team is not perfect from the outset. According to Loader, in the beginning such teams virtually always go through a very difficult time because almost everyone still has to learn to collaborate and how to trust one another. That doesn’t happen automatically. “Many team leaders are not properly prepared for the job of integration management. They are given 8 or 9 people who they have to mold into a high-performance team. Team leaders need to be trained to achieve this. In addition, the team leader must point out to the members that they have a shared responsibility and he/she needs to support them in this.” It is important to eradicate any fear of failure. “People are seen as individuals but in DevOps they are a team. When a goal is scored in football, the goalie is not the only one responsible for not stopping the ball. That responsibility is shared by the midfielders and defenders. The same applies to DevOps. A team leader therefore has to coach a DevOps team in such a way that an awareness is created that scoring goals is a collective effort.”
Composing a team means achieving the right balance. For example, it is not advisable to put all your server administrators or database administrators together in one team. Loader explains: “Keep them as far apart as possible. People will then behave much better in terms of adhering to the architectural guidelines. If you put them together, they feel safe in their old way of working and they really won’t talk to each other about improving the quality of the service... If a single database administrator is the only database expert in the team, he won’t pull any stunts.” Once you have finally put your DevOps team to work, and as the IT manager you want to proudly announce this to your customers, you would be better off waiting a while, says Loader. “There is enormous skepticism amongst customers that we in IT can really get things properly organized. When you succeed, don’t shout it too loudly from the rooftops but instead explain it step by step to the customer and invite them to come and talk about it. After all, you have to make the promise come true.”
ITIL wrongfully forgotten
Loader believes that many IT departments that shift to DevOps often forget to think about how things should actually be done. Frequently, a good design is absent. “This is because you first have to understand what you are making a design for. For DevOps, you need to restructure your IT departement.” And then our old friend ITIL comes into play. The IT world is still highly ITIL-driven, Loader explains. “People claim that how you are organized doesn’t really matter very much. You take a few points and drive a process through them like a skewer. With DevOps, things are very different. You need to make a combination of the customer, the service the customer requires, the technology stack under the service and the DevOps team that will develop and manage the service. That is your new silo structure. You have to build silos in any case. Every partition always leads to silos. And that means you can better choose customer-focused silos rather than silos that are focused on the technology.” Loader believes that ITIL is still very valuable especially when it comes to understanding the processes. “In DevOps, the processes are small and simple.
Change management in a DevOps environment can be fully automated, for example. If you then look at DTAP (Development, Testing, Acceptance and Production), questions arise like is it properly built, or are you doing the right thing and what is the right time to go live with innovations. ITIL still helps to evaluate these steps properly. After all, you have to keep a close eye on the transition from a non-production environment to a production environment. Tooling cannot eliminate all human errors.”Although the IT world is highly ITIL-driven, increasing numbers of IT people are unfamiliar with ITIL. “An entire community is coming of age without being aware of ITIL. I see that people in IT often don’t know the basic definitions. DevOps teams make that worse. They are not familiar with ITIL and therefore don’t know the fundamentals of IT.”
Side note:Break those bad habits
According to Forrester the members of DevOps teams still have to break some bad habits in order to function optimally. These habits were acquired in the past when responsibilities were unclear and blame could therefore often be placed on other teams. Moreover, tiresome work was simply left undone without any consequences being attached. Dare to make mistakes. People are afraid to make mistakes. Only one in five people sees making a mistake as an opportunity to learn. This prevailing attitude stifles innovation. Dare to take responsibility for a project’s success or failure. Only 45 percent of IT people feel responsible for the success or failure of a project. Always measure the level of customer satisfaction with the result. Over fifty percent of IT departements do not measure customer or user satisfaction after delivering a service or application. If you consistently measure satisfaction, IT staff feel more closely tied to the business goal of the project. This in turn leads to better collaboration, especially where turning mistakes into improvements is concerned.
Use monitoring in combination with analytics. Using monitoring combined with analytics is important in guiding improvements. This approach delivers a lot of data which can be used to decide what actions should be taken. For instance, analytics provide insight into business performance. IT staff need to know these things in order to better develop the related services and applications. That awareness is, however, not widespread. Only 14 percent of IT staff see its importance.
Ensure that data is reliable. Most IT staff quite simply do not trust the available data, although they need it to make decisions. Make sure you have good analytics tools for making reliable measurements.
Find the leak first. More than half of the errors in applications are found by users first. Ensure that from now on the IT department finds errors in applications before the users do. Build a good dashboard. A good dashboard needs to provide a real-time overview. It has to show the release times quickly, as well as all the necessary information such as in what environment the releases are installed and produced. Everyone should have access to such a dashboard and they can’t be bought off the shelf. You have to build this dashboard yourself complete with various tools, for example for application release automation and application performance management. Forty percent of IT staff have no access to dashboards. Dashboards that are updated in real time are extremely rare and only 10 percent of IT staff have access to them.