If you don't understand what DevOps is, here's a brief cheat sheet. DevOps is a set of practices that reduce engineers' fears and minimize failures in software production. Typically, they also shorten the time to market — the period from idea to delivery of the final product to clients, which allows for rapid business experiments..
How to start a DevOps transformation? In short: choose the service to begin the process, identify those involved with the service, build a Value Stream Map, create a temporary team that will handle the transformation initially, and set them a task. Repeat the cycle as many times as needed.
A detailed plan for DevOps transformation with examples and instructions is available in the breakdown Andrey Alexandrov — by an engineer at Express42, a company that consults on cultivating DevOps, expediting this process as they have already built a map of pitfalls. If you feel that transformation is unnecessary for you, or your specifics suggest DevOps practices are not suitable, use the report as a guide to identify and eliminate constraints.
If you are concerned about DevOps transformation, you likely have a large company, and you need to gradually scale this process across the organization. As long as there's a need to transform a team or resolve any constraint, the algorithm below can be repeated.
Choosing a service
The plan is set; let's start with the first step — choosing a service. The first criterion is lifespan: there are old services — legacy, and new ones. You can start with either.
Choosing a young service makes sense. It's fresh, without an established team workflow. There is no mountain of technical debt, so we can do whatever we want with it.
With an old service, there are problems associated with the fact that change is always difficult.There may already be a set of serious constraints, but perhaps there are people involved who are ready to overhaul everything — they are tired and want to do things differently because it's painful for them.
Working with an old service creates a powerful precedent in your company — something can be changed. If you've altered the new service and it rolls into production 100 times an hour without issues, people in your company may say:
— This is a new service! Everything was straightforward there, try doing something with our old clunker.
A legacy service makes sense to transform when you're doing it with someone, for example, if you invited an external consultant. Let's be honest, transformation will shake everything it can.. You experiment and don't know where you'll end up, what technologies you'll use and for what purpose, where and what pitfalls will arise in the processes. That's why it's easier to change to a new one.
If you're doing everything yourself and the company lacks serious expertise — we take the new service. If you know an external consultant and have the funds — choose the old one.
There are services that are simply interfaces for users, like a basic website or a mobile app. But there are serious things like billing. If something goes wrong with the billing — sorting it out will be difficult. We have choices here too.
We either work with a critical service, but already suffering because of it, it creates limitations, or we work with the interface. This is the second criterion for choice. Similarly, there is an opportunity to attract an experienced consultant — we work with the heavy option.
But even in this case, I wouldn’t recommend doing so, because until there’s an understanding of what to work with and in which direction to transform, taking a critical piece and shaking it up is not a very good idea. Therefore, in this case, we prefer to work with the interface, the failure of which is not critical.
Next, let's consider the service team. We'll have to work and interact very closely with those who handle this service.
People in the team can be conditionally divided into two categories: conservatives — they live in the old world, or simply know nothing about DevOps, and innovators, who bring in all the trendy practices. The latter don’t always understand the topic, but at least they are ready for it.
On one hand, conservatives are experienced people: they've been with the company for a long time, understand everything from beginning to end, but they don't know much about the practices. On the other hand are the innovators, who may have heard something, but most likely haven’t been with the company for very long. Who is better to work with?
You will have to interact with the conservatives anyway, as it is their service. You need to communicate with them, clarify the specifics of the service, what can be done this way and what can be done that way. We depend on their consultations. Surely, we will have to delegate something to them, because they know their service better. Therefore, it is important which team we will ultimately be in contact with.
It makes sense to choose innovators for the team, because conservatives might throw a wrench in the works.
In practice, it often happens that conservative people have substantial experience but lack an understanding of how to move forward. They are just afraid that after the transformation and overhaul of the service, they will be let go due to redundancy. Sometimes, simply out of misunderstanding of what is happening, they sabotage the work.
I had a case where a guy from the team repaired everything he could find, thinking it was somehow more critical than what we were currently doing. We set a task: implement this piece today — but no, there’s a fire on the other side of the world, let’s go fix it. It's challenging to work with such people.
Team members who are conservatives often neglect tasks or postpone them until the last moment. And if, heaven forbid, you made a mistake and attached KPIs to the number of completed tasks, and some of those were not included in the KPIs for some reason, then they simply won’t do anything. In essence, they would be right because they would lose their bonuses.
Working with innovators is easier — they are more loyal.They have already heard something, want to go somewhere, so they will help. We need people who are ready to endure in the beginning: if a service is changing, the innovators will be the ones bearing the brunt of the new challenges as pioneers. Innovators want all the latest and trendiest, and are willing to suffer for it.
You can convert conservatives to your belief later. When you show that a piece has been changed and everything works well, most likely they will want to try as well and accept the new DevOps religion.
To sum up. If we are carrying out the entire transformation in our company ourselves, then we choose: a new service, preferably with a simple interface, so that we do not suffer too much from its breakdown, and a team of innovators.
If we can summon an external consultant, instead of a new one, we should stick with the old service that has already caused us trouble. People who have been involved in transformation for a considerable time across various companies have seen different cases; they already understand how to do things correctly and the direction to take.
Who is involved?
We need to identify everyone who has any relation to the service: developers, testers, admins, security personnel, managers, and possibly Product Owners. Despite not being technical specialists, Product Owners are connected to the service: they make decisions and assign tasks.
Everyone who makes any decisions and influences what happens with the service must be found, introduced, and engaged in conversation.
Why do we need them? To know who to negotiate with.. During the transformation, when the familiar work principle changes, the service will inevitably face turbulence. There will be some disruptions while we test new approaches. People need to be prepared for this and agree to it.
Next, we will have to build a Value Stream Map, and without these people, it cannot be created because only together do they know the full picture of what is happening. No one person knows everything about the service.
They will recommend people for the team. Later we will discuss why a separate team is needed. It will require taking people from existing departments. Those connected to the service will be able to recommend colleagues who think in our direction, who can help us and have the necessary expertise.
Next, we gather all these people from different departments in one room and start building the Value Stream Map.
Building a Value Stream Map
A Value Stream Map is a diagram or map that illustrates the flow of value to the customer.. It covers the entire process from the conception of an idea to its implementation, including all intermediary stages and how the value ultimately reaches our customers.
A Value Stream Map is needed to visualize all stages of development, localize problems through measurements present in the current process, and begin to address these issues, and set an initial goal. This is where we will start taking real action.
Metrics
Much literature on Value Stream Maps describes various metrics, but to start, three will suffice.
Lead Time — delay/waiting — the time we wait for something. For example, a tester is waiting for a test bench to become available and cannot do anything during that time.
Value Added Time — the time of productive work. — the time we spent at a certain stage to create the final value for the user. For example, a tester ran their test and started checking something. This is the productive work time when we are really doing something for the product. This is what clients pay for — quality software.
%C/A — percentage of accepted work. We have one stage — development, the second stage — testing. How many features testers accepted from developers, and this is the percentage.
This is roughly what our map looks like.
It may look different depending on the organization's structure, the number of departments, and what you do. But generally, the map will have two stages: the idea and analytics. At this stage, data is expected, for example, Lead Time 2 weeks and Value Added Time 2 days.
We cover absolutely all stages with metrics.
Backlog — how many tasks were left after the analysts came up with them.
Development — how many weeks developers waited for clarifications on tasks, test benches, or equipment — it doesn't matter, but they are waiting for something. For example, they spend 4 days implementing a feature. Here, the metric %C/A appears. Developers picked only 80% of tasks from the Backlog. They believe that the remaining 20% lack a clear specification and sent them for revision.
Testing. In the diagram, LT is set to 4 days. For example, testers waited for the test bench to be released, VA 2 days they are actually testing something, and %C/A = 40%. — only 40% of the code or features sent by developers were considered adequate by testers. The rest did not meet their expectations for some reason.
I won't go into detail on how to conduct these measurements; at the end of the article, I will recommend literature where you can learn about them.
The only advice I can give is — don't trust people who will create the Value Stream Map with you. They estimate how much time different processes take, but these estimates are not always accurate, so it's better to measure yourself.
We had a situation where we went to the Operations department and asked how long it takes to deliver a new feature to production. We were told it takes 10 minutes, and we wondered why we even joined this company. It turned out that the 10 minutes is the time it takes for a script to take the code and deliver it to the server. However, before that, the release sits on the server for three days collecting dust — there’s a task in the Backlog that needs to be deployed. So, before the deployment stage, there is a waiting stage where the project just sits idle. If we hadn't gone with a notebook, noticed a task in Jira, and started tracking it step by step, we would have thought everything was great, and there was no problem.
Therefore, you'll have to take measurements yourself, preferably more than once, to get a realistic understanding. Depending on the Value Stream Map, you'll decide where to start and what to fix first.
Temporary Team
Many companies that decided to implement DevOps create a team, but not a temporary one; instead, it exists for several years. If you look at DevOps service apologize, which describes various patterns for building organizational structures in DevOps, you'll realize that this is an anti-pattern.
When a DevOps team exists permanently for several years, it's a significant mistake because DevOps is about communication between departments, speed, and efficiency.
If a team exists between departments just to do something separate and has been around for a long time, it creates an unnecessary barrier. Now, instead of a programmer going directly to the administrator to resolve an issue, they first have to go to the DevOps department, and then that team will take it from there.
Therefore, to get started, you need to create a temporary team.It will exist conditionally for about six months, at most a year, depending on the task at hand, just to eliminate one limitation we have chosen. After that, it will cease to exist. If we identify the next pain point where we are struggling, and realize that we also need a separate team for that, we will create it again. However, such teams should not exist on a permanent basis, as they only disrupt communication and take on entirely separate tasks just for the sake of doing something. These tasks may not even be related to DevOps or transformation. Why not delegate this task to existing departments?
Why a temporary team is needed
Conflict with current processesDevOps transformation involves not just changing the technologies and tools we use, but also altering the very work processes, mindset, and values. If the team operates in the way it is accustomed to, it will not be able to explore different approaches.
These individuals must adhere to different rules: ignoring all company KPIs because they are attempting to work differently. Temporary teams will not submit requests to obtain servers; they will go directly to the department that manages them, demanding to receive what they need first, as it is a priority task, and because they strive to operate differently. The team is in complete conflict with all current processes. To prevent existing work methods from hindering them and vice versa, we isolate these individuals by forming a separate team.
Avoiding bureaucracy in experimentsIn temporary teams, there is no bureaucracy; they do not fill out timesheets and do not report to managers. This is a completely separate world where people think and live differently and engage in entirely different activities. They should not be unnecessarily disturbed.
Continuous work on the serviceIn the first point, we selected something on which we will experiment. Experiments and finding better ways to work are great, but we also want to implement features. If the entire team focuses on transformation instead of features, we will begin to lose revenue, and bugs will linger for too long — that is not acceptable to us. Creating a temporary team allows us to experiment without halting work on the product.
Don't waste time on work tasks. This is about the product again. It takes a lot of time for the team to try out other tools and so on. For people to master the tools, start implementing them, and use them properly, it will take at least six months. If they are also working on the product — the six months will stretch unreasonably. If people are working on the product, they are back to old processes — we don't need that.
Therefore, we are selecting people from different departments to form a separate team that will focus on service transformation. As a result, the service works, continues to evolve, and at the same time we conduct some experiments on it.
The temporary team is solely focused on the DevOps transformation — eliminating the limitations we identified, and nothing more.
The team consists of versatile people. This means that we did not just take developers. We did not come to the service and take half the team away — no, we took people from different departments. A few items back, we identified different departments and various employees related to the service being transformed. From these, we are assembling a team because it needs to be versatile — we will change both the testing process, the development process, and the service maintenance process. Different competencies are required.
Usually, we conditionally take one developer, one tester, and one engineer — and together with them, we come up with a solution that allows us to function differently.
Ideally, these people should have authority within the organization. We might need to bring in a conservative, even though we prefer not to. If we have a large company, not everyone will believe in our plan, and some may throw obstacles in our way, for example, by not allocating a stand. This is where 'authority' comes in — a respected person with significant experience who has earned good relations with colleagues. An employee's authority in the team will simplify the task and work of the temporary team. People will think:
— Aha, this cool guy, whom we all know and love, has signed on — there must be something worthwhile in DevOps to check out!
We set a goal
We gathered people, selected a service, examined the limitations, and identified which people we can influence. Now we need to set a goal, and it must be directly by SMART — just as we like.
Specific — specific.
Measurable — measurable. This is a very important point of SMART. If you cannot measure something, you cannot change it and understand what and how you did better or worse.
Achievable — achievable. Adjust for your specifics. If you are an enterprise company with a long history and a large burden of responsibilities that releases a product version once a year, you won't be able to achieve releasing new product versions every hour within six months. That's not going to happen. Therefore, set a realistic goal that can be achieved within an acceptable time frame.
Relevant — relevant. We eliminate only those constraints that truly prevent us from achieving our current goals.
Time Limited — time-limited. If there is no deadline, the team will engage in anything: trying out 15 technologies instead of 3, writing huge reports, conducting useless research, polishing their implementation to perfection when the goal has already been achieved.
We derive the goal using a Value Stream Map — again, gathering everyone and drawing. But this time, based on the previous Value Stream Map, we sketch what we want to achieve.
We identify one constraint that we will eliminate right now — and that is what the team will focus on. As an example, I took the waiting from a completed release to its deployment in production — this is the most common constraint that people consult with consultants about.
Based on this, we set the task: we want the wait time between a completed release and going live to be a maximum of one hour.
Examples of tasks.
- Reduce test Lead Time from 4 days to 1 hour.
- Reduce Value Added Time for testing from 2 days to 3 hours.
- Reduce deployment Lead Time from 5 hours to 10 minutes.
- Increase C/A from 50% to 95%, that is, increase the number of features accepted by testers, in other words, improve the quality of developers' work.
Examples of tasks are not taken from thin air — they are based on measurements we made when developing the Value Stream Map.
We set a similar task for our team and a time constraint. Depending on how well things are going in your company, you set different deadlines. On average, eliminating a constraint, if people are doing this for the first time and do not yet know which technologies and how exactly they will solve the problem, usually takes six months.
Short planning
So, our team is formed, we have a goal, and people are starting to work. An important aspect is short work planning: sprints lasting one to two weeksand no more than that, measurable improvements every week and course correction.
For example, we often use the approach moving-moving, where the whole team gathers at the beginning of each week, jots down in a file what each person will be doing. After a week, we check: what has been done and what hasn’t, if not, then why, and we think about what to do next.
Sprints allow us to correct our course in a timely manner.
For a week or two we experiment with something: technologies, approaches, ways of working, after which we measure again and see—did this approach get better or worse? If it’s worse, it means we are headed in the wrong direction; we need to correct our course: set a different task, adopt another technology, or do something else. Short sprints of 1-2 weeks allow us to navigate effectively and promptly avoid bad decisions.
We share our successes
The team achieves certain successes, whether small or large—it doesn’t matter; there is always some result. Everyone should know about this result: both those involved in DevOps and neighboring departments. Ideally, it should reach all people in the company.
Why? If we want to transform not just a part of the company, eliminate not just one limitation, but everything so that the company becomes agile, code flies quickly to the client, and nothing breaks, everyone needs to be loyal to the idea of DevOps. You cannot apply the approach to services and teams that are fundamentally against it.
To gain loyalty, we must tell everyone what we tried—here’s our result, try it too! This will raise interest and loyalty to what we are doing, and people will start trying to do something right now. As practice shows, when we share what we tried and what we achieved, other teams begin to ask questions about how and what was done. They look at implementations, code, documentation, approach with questions, and try to change something on their end.
Sharing about your successes is important. This way, you can convince the conservatives, who wanted to do everything the old way, to shift to your camp and transform them into innovators.
Total
We select a service, as a starting point—the place where we will begin changes in the company. Identifying everyone involved with the service and working together with them to build a Value Stream Map, measuring and observing where and what limitations exist.
Creating a new temporary team, which will solve the assigned task. Based on the measurements and Value Stream Map we draw a new map, highlighting the limitation we will address. Based on this limitation we set a task, which the team will tackle. The task must be definitely SMART — specific, measurable, relevant to current tasks, and time-bound.
We repeat the process, until we transform all our services into the required form and eliminate all limitations.
Bonus. Useful materials
For those who decided to delve into DevOps on their own.
The Phoenix Project
The original title is ‘The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win’. This is a novel about DevOps — a story of how an employee became the head of a department that was always on fire. The new head was tasked with:
— You have several years to fix everything so that we can finally deliver our product to our customers quickly and efficiently.
‘The Phoenix Project: A Novel about How DevOps Changes Life for the Better’ is a book for all executives, as these individuals make decisions about what happens in the company. If you are an engineer or programmer and want your company to start moving and transforming — buy this book and gift it to the leadership. This novel explains everything and is quick and easy to read.
DevOps Guide
A more complex book. It was released a few years ago in English under the title ‘The DevOps Handbook: How to create world-class agility, reliability, and security in Technology organizations’, but is now available in Russian. This is a true handbook — a practical guide: on how to conduct measurements, what a Value Stream Map is and why it is necessary, where to move, and in what order. The book is precisely for those who want to do everything independently. Most importantly, it contains examples of other companies' experiences.
For example, it describes how one company created a Value Stream Map and realized that its limitation was not in the product but in the fact that the cashier had to walk from the store to the neighboring office to use that product. Instead of addressing the issue with the software, they simply bought tablets for their salespeople, so now no one has to go anywhere; all actions are performed at the workplace. Conclusion: Value Stream Maps can be applied not only to software but also to all processes within an organization.
Accelerate
Full title: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations." This is the next level — hardcore. The book was released last year, currently only in English, and it’s about research. The authors — Nicole Forsgren, Jez Humble, and Gene Kim — have applied various practices in different companies over many years and studied which practices affect what and how.
In the second chapter, dedicated to measurements, Value Stream Maps are mentioned, along with the metrics I referenced and many others, as well as a detailed description of the measurement process. The authors conduct measurements using questionnaires and self-tracking of tasks. It explains what metrics to measure correctly, which ones to avoid, and human errors in measurements. If you have difficulties with measurements, refer to the second chapter of the book "Accelerate." If your team has many practices but it’s unclear which ones to apply now, which ones later, and which ones actually work — read it; everything is explained in the book.
Transformation is a question at the intersection of DevOps and management. Somewhere in that overlapping area of development, operations, and testing lie the topics we try to discuss at , the same integration is needed for creating a quality product – the main topic of . Management at the festival around — means all ideas for transformation will be there. Join us on May 27 and 28; we will integrate and transform.
Source: habr.com
