DevOps is actively developing, and many IT specialists become interested, accumulate knowledge, and think about implementing DevOps tools in their company. But before going to the leader with a proposal, the specialist must have a plan with a ready-made solution, a list of responsible persons, specific tasks, stages of implementation, and arguments in favor of the proposal.
HOW TO START PREPARING AN OFFER
The DevOps implementation process is an adventure. Therefore, before embarking on it, it is necessary to clearly define what will change in the work processes, who are interested in these changes, who to involve in consultation, implementation, and control.
Preparing an offer for the implementation of DevOps in a company begins with the understanding that this process will capture the technical aspects of the company, roles in teams, competencies and areas of responsibility, processes, tools, and practices. In some cases, even the business model may change because the company has new opportunities. Most importantly, determine whether DevOps is needed at all in the company, whether its implementation corresponds to its business goals.
First of all, you need to substantiate the expediency of DevOps. The initiator of the changes must sell this idea to his own colleagues and negotiate with the business. Implementation will require resources that only management can provide.
It is important to substantiate what problems the DevOps implementation solves:
- Speed of delivery of product changes. If a company has the ability to quickly and easily test product hypotheses or react quickly to market changes, that’s its competitive advantage.
- Site/application response time or the number of failures seen by users. The company has technical risks that relate to fault tolerance, speed of recovery after failures, and security risks.
- By eliminating routine and repetitive work from the development and delivery processes, the team can focus on developing their products.
WHAT DIFFICULTIES MAY BE ENCOUNTERED
The implementation process itself will require investment. This will most likely lead to a slowdown in the work of teams for a period of time. Because everyone will have many new tasks and tools, work processes will change. Lack of sufficient training and competence in practices and tools can lead to an increase in the number of errors, technical failures, and problems with the use of technology. It is desirable to agree in advance with management to increase the error budget and the amount of testing.
Many processes and delineation of areas of responsibility can work with some difficulties. In this situation, you may need a specialist to facilitate and control the processes.
There are times when initiators of DevOps implementation are sabotaged by employees who are not ready for change. They want to leave it the way it was or keep their KPIs. Despite the changes you need to prepare for the fact that you will have to communicate a lot with people and help them achieve their goals.
In addition, resources for training will be required: new practices and tools require mastering, it will not be superfluous to attend conferences/summits on the topic of DevOps. Keep in mind that you and your colleagues will have to break away from the current work tasks more in order to take an online course or master class, or view the recordings of reports.
HOW THE EXECUTIVE MIGHT FEEL ABOUT THE IDEA OF IMPLEMENTING DEVOPS
Not all leaders are ready for such changes without understanding the value that these changes will bring, the necessary investments, and stages of change. Thus, the challenge is how to convince a person that these changes are appropriate.
Over the past 10 years, there has been a lot of material, books, reports, and research on the subject of implementing DevOps from various representatives of the IT industry. Education writers at Write my paper for cheap say it’s worth reading the cases of famous companies – many of them willingly talk about the results of their DevOps-transformation. It is also helpful to read the book “Accelerate“, which is based on 4 years of DevOps research. And if the executive is not convinced by the experience of other companies, then perhaps he is being held back by factors that are not obvious to the initiator of the DevOps transformation.
Most executives understand that DevOps can accelerate delivery, improve quality, expand a company’s market position, and prepare infrastructure and processes to reach a wider audience. In any case, it is important to enter into dialogue and think about the benefits of the company: stability and speed of processes, risk reduction. Even if you make only technical changes, at least the engineering work can be made more pleasant. And spend time free from the routine on the next stages of improvement and demonstrate the results to the executive.
If the executive is afraid of uncertainty, you can invite help from outside. There are many specialists on the market who can build an individual roadmap for a company, analyze it, and make recommendations.
WHAT TO DO IF AN EXECUTIVE WAS SKEPTICAL OF THE DEVOPS OFFER AND REJECTED IT
If you have analyzed the software delivery processes in the company and made sure that DevOps is needed, but the manager is against it, then you can try to get approval for changes that affect only the technical component of the development and delivery processes. It can also bring results. Better to start not with tools, but with engineering practices.
These are some of the most common practices of continuous delivery and infrastructure as a code. It is not so important what tools you will use to do it. For example, an automated repeatable process for deploying a company’s product or creating testbeds “by the button”. And only after that look at what you can use for this: what competencies and tools already exist in the team, what tools are available in your programming language system, etc.
After you manage to implement some changes on your own, demonstrate them to your executive. These results can be: time savings on manual operations, increased autonomy of product teams, process transparency, good monitoring that notifies of problems faster than they affect users, and much more. Tell about the effort that went into making these changes.
But if the manager doesn’t appreciate it, the results can be shared with the corporate community, such as other development teams. Or with the head of another department, who will evaluate the results, try to repeat them in his department. Perhaps a successful implementation experience in a neighboring department will influence the opinion of your executive.
The main thing is not to act as a partisan. The executive may have had good reasons when he made the decision to refuse. Try to understand them and form an offer that suits everyone.
HOW TO CALCULATE THE INVESTMENT THAT WILL BE REQUIRED TO IMPLEMENT DEVOPS
If a company understands what losses it incurs for minutes of inaccessibility per day or week of lagging behind a competitor, then the financial expediency of implementing DevOps practices will be easier to substantiate.
There are 4 basic metrics in the software release process: update rate, time from idea to production release, percentage of unsuccessful changes, and recovery time after a failure.
In addition to these metrics, there is a part of the company’s work that is called “Unnecessary work.” It can be estimated in hours – how much extra work the employees do. This includes, for example, manual updating of servers. Automating this work will save staff working time. In this case, it is possible to estimate in advance, that the implementation of the technology will save 10 hours of work per week for an engineer. From this time is estimated how many new features the engineer will be able to do in a week in the free time. If you collect such calculations throughout the company, it turns out that the refusal to implement DevOps leads to lost profits.
HOW TO BUILD A DEVOPS IMPLEMENTATION TEAM
Forming a dedicated DevOps team is an anti-pattern. DevOps works when the practices are applied by all the people you already have in the creation and operation of products.
In modern tech companies, there are several types of IT teams:
- Stream-aligned-team (product team) that targets the value chain. The team develops products and does everything for the company directly or indirectly to make money.
- The Platform team provides product team members with the services needed to support the development, testing and operations processes. This keeps product teams focused on value creation. Platform specialists can act as consultants and assistants to product teams on the tools they use, use cloud provider services, and create internal tools that are useful to product teams.
- The Enabling team is a team of domain-specific experts who temporarily join the product teams and help them in a mentoring, analysis, and technical problem-solving format.
Another question is how to choose from the existing product teams in the company the one that will become the pioneer in the implementation of DevOps practices.
The pilot team is chosen so that its results are exemplary. For example, you can implement automatic delivery, but if the product is updated once every six months, this change will not be indicative for the rest of the team. Also, we must not forget about the desires and initiative of employees, the willingness of the team to spend part of their time on changes, shifting the focus from product development for a while.
HOW TO FORM A STRATEGY FOR IMPLEMENTING DEVOPS PROJECT: STAGES, TASKS, BUSINESS GOALS
You can start by building a Value Stream Map for your product. This way you will see the most inefficient places in the processes and understand where to focus your efforts.
Create a list of metrics that are important to you. At least the four mentioned above. Get the current metrics for these metrics and figure out what your target metrics will be.
Form a list of tasks for changes together with the team in which the changes are taking place, inform the team why you are doing this, what will happen, how the work of each of them will change after the changes.
All things being equal, start with processes that, if changed, will not block your colleagues’ work. Create automation solutions without breaking existing ones. Regularly measure the metrics of your delivery processes. It will be better to automate it and make an available dashboard for the whole team. It shows how long it now takes to release a new version of the product and how many errors users encounter.
There’s definitely no need to rush. It takes time for people to adapt to new processes and learn new tools. Do not forget about informing, demonstration, and training – a spread of knowledge is closely embedded in the DevOps culture.
SCALING DEVOPS TO OTHER TEAMS
You should think about scaling the DevOps approach to the entire company after the pilot team has successfully completed the project. It is important to understand here that the DevOps implementation process is long, and in order to scale it to the entire company, it is necessary for other teams to understand what processes and changes they should prepare for, what new tools they need to master, what literature to study.
To make it easier for others to implement, the pilot team should generate documentation and other things, presentations, descriptions of their experiences, mistakes, and difficulties they went through. Because other teams will follow in their footsteps later, but with fewer losses. They will save time and resources.
In the scale-up phase, you usually find that it’s much harder to introduce changes to 10 teams in a company than it is to lead one (pilot) team. This requires synchronization and change control and management processes. This means that separate management competencies are required from the initiator of the DevOps approach.
Most initiative guys in the company usually go to the pilot team. But in scaling the DevOps approach to everyone else, it often turns out that not everyone needs or is interested. Be honest, if you can make a colleague’s job better – tell how it will be. If not, tell why it is important for the company.
It is important to pay attention to the spread of knowledge. It is necessary to create a common information space, within which all participants can discuss problems and find solutions. We are talking about chats, internal meetups, corporate channels. It’s important to get people out of private spaces into a public space where everyone can participate: to ask/to advice, to find out/to tell what’s going on. That’s how synchronization happens.
For scaling up, it will be useful to organize training with practical exercises. But the problem is that not every company is ready to undertake the creation of such an internal school. The way out of the situation is to seek help from people or companies who are ready to help with training.
It’s also important to understand that only the pilot team is changing, and these changes have little effect on the work of others. But when all the teams start changing at the same time, because of the length of the change process, it is likely to feel like endless chaos.
In this case, it is better to prepare for a long and gradual scaling. It means not to implement DevOps simultaneously for the entire company of 50 teams, but to work with each team in turn. And use the experience and results of the pilot team to reduce risk.
WHAT SOFT SKILLS A DEVOPS INITIATOR NEEDS AND HOW TO DEVELOP THEM
Implementing DevOps requires the initiator to have good communication, self-presentation, knowledge sharing, and planning skills. It is also important to have at least a basic understanding of the business as a whole in order to adequately assess how the results of your work ultimately affect business performance.
It’s important to pay attention to things like mutual help and empathy. Strive to understand what is important to your colleagues, how to help them do their job better, what nuances to explain to them. After all, all of the company’s employees are one big team.
DevOps transformation sometimes requires new competencies from employees. In such cases, mentoring is necessary, when a senior colleague or team lead pumps everyone else, broadcasts the values of the company, and is in constant communication with the team and helps to solve problems.
As an analogy, we can use the practice of development – code review, when a developer, before sending changes in the product to users, shows his work to colleagues for constructive criticism. In this case, criticism is a learning format. The critic should strive to help and give advice on what to fix in the work in order to improve the result.
Another way to learn something and develop a skill is to teach someone else. Make a report, a presentation, a study, and present these materials to the team. And here it’s important to get people out to discuss, to get them to talk, to share their opinions, to have a discussion. But do it culturally – without insults and personalities.
