7 Steps to Bridge the Gap and Start with DevOps
Larger vendors often call software companies an Independent Software Vendor (ISV). In short, when you make software yourself and sell it to customers, you are an ISV. Certainly, as an ISV, you want to start with change so that your company will connect with the changing world. This is because you believe that it contributes to growth: personal development of people, creating successful teams and the growth of your company as a whole. You, as a developer, see these signals. After all, you are working on cool developments! But when these signals start to show, how then do you get your management along?
I believe that every software company is on the verge of important strategic choices. I also believe that Developers are the first to see those signals, if only because you feel the pressure of life-cycle management and the release of new functions.
In this blog, we'll take a look at these seven signals: *
1. User adoption of management concepts is not optimal.
2. Adding functionality and updates has impact and takes a long time.
3. Documentation or understanding of the architecture is difficult to find so tasks are repeated (processes are not visible).
4. Users complaining about subjects that are not being measured (“If we had that, then…”).
5. Business value, customer value and IT value are treated individually (or not).
6. There is no time to celebrate success, we are busy putting out fires and pointing fingers.
7. The operational and management teams do not know each other's agenda.
*Tip: Click the hyperlinks above to navigate through the blog!
Beginning with New Management Concepts
Gurus have written about various management concepts for years- we all start with such a concept, but perhaps just don't finish it; maybe we only want to install some parts of a concept. In the last decade, I have seen various trends. Think of: coaching leadership, performance management, self-management teams, competition management and just-in-time management. All of which are management concepts that focus on people and their knowledge. This is positive, even though it may not always feel like it. Currently, because of the 360-degree assessment, the opinion of your colleague is important and becomes part of your KPIs.
With all these concepts, support/user adoption is essential. Nevertheless, I regularly see and read that these concepts are imposed from above, and there are also examples of organizations that use different concepts throughout. What you typically see are organizations who add new concepts and processes, but never say goodbye to the old ones. The negative side effect can then be that we become tired of new management concepts and come to look at change sceptically.
The disadvantage of hypes is that we all want to participate, and from there comes the enigmatic DevOps culture. No, DevOps is a culture and starts with the merging of traditionally separated silos, so the decision comes from the team, not from above.
1. Ensure Adoption Among Stakeholders
In my previous three blogs (blogs 1, 2, and 3 here), I consistently wrote that DevOps is not a methodology, but a culture. I believe that this is necessary to be able to meet the current needs of companies because the developments follow each other. The term DevOps originated in Belgium in 2009 as a result of the so-called 'DevOps-days'. These days were hosted to bring IT experts from both the project side ('development') and the related 'operations' together. Similarly, the term DevOps has been placed in this context: a multidisciplinary team that is fully responsible for the management and continuous development of the service software.
Implementing a new version is already quite some work. A whole new culture team is therefore especially a considerable task, and certainly for larger organizations. Like any transformation, it requires overcoming the feat of getting people on board, or in other words, creating support. How do you ensure that DevOps, when executed, will add value? It starts with education. Make clear what one can expect and what value this can entail, and what it means for customers, people and IT investments.
In my first blog, I illustrate the difference with the traditional method: the waterfall model. I’m currently speaking to various software companies that are writing a new version suitable for the cloud. They all say it is a lot of work and it will take a while. Ideal to start there. As far as I am concerned, a large application should be split into several applications, and then start by capturing the specific application code and the common source code in a repository. This way, the first step has been made for continuous education. This adoption step is an essential step to take advantage of the benefits of DevOps and later continuous delivery.
2. Start Small with a First Application
A well-known statement that demonstrates this step is that of Neil Armstrong,"That’s one small step for man, one giant leap for mankind". We can build a small application faster than a larger application, and a small application can also be tested, maintained, and easier to adopt by users. Why then, would we still build an application that does many things and becomes too large?
3. Make Processes Visible
I prefer to bypass difficult processes. Ultimately, we must all begin to contribute to the continuous improvement of these processes. Transparency is very important to me; working together is not a magic word or a process that you can turn on- you can just do it. It’s the same that we often see communication as a synonym for sending an e-mail. I think it is useful if you chart the strengths and weaknesses of all your processes and make them accessible (in Teams for example) for your entire organization. Then you can add any missing parts or remove unnecessary parts. As far as I am concerned, you could therefore also apply continuous learning to your processes.
A well-known and simple approach is to have an overview of all current tasks and the people to whom they have been assigned. This is possible with a scrum board or the ‘tasks’ feature in your mail program. Are all those involved aware of how to deal with an incident or a problem in a production environment? Often, we lose time explaining the architecture, which has problems, rather than fully concentrating on solving the problem.
4. Measure as Much as You Can
“Measuring is knowing” is a very old saying that is still relevant. For example, what is the average lead time of your tasks from the start of development to completion? What is the response time to your services? How much time does it take to expand an infrastructure cluster? If you know all your numbers, you may determine what you can improve on.
Imagine that one of your applications stops responding due to a technical problem. For example, a problem with the load on a processor. Your customer service will quickly begin to receive phone calls and messages from customers who experience problems. We often measure availability, not all sorts of details. Go measure everything! That way you are more aware of potential problems and you will know the use of your application down to the last detail. That saves a lot of time searching for the problem. A bigger advantage is that your customers will not be duped, and you can add new, more relevant functionalities because you know how your user interacts with your application.
5. Make Value Visible
We create value. We all say that. This is how we earn our money and that is how we distinguish ourselves. If you know everything about the value that you create and for whom, you have a powerful tool at home; you can create value for your customers in order to increase the value of your company.
But what about making IT more valuable, which reduces maintenance costs and allows new products to enter the market faster? It is important to start collecting data; data with which you can increase the three core values (business value, customer value and IT value). Let us no longer discuss these three themes separately, but as an integrated whole. There are various tools available with which you can bring data together and start to enrich it.
6. Celebrate Success
Perhaps one of the most important steps in any change process is to start celebrating success. At Microsoft, Ernestine van Rappard once said to me, "Celebrate every success”, it doesn’t matter what, as long as you celebrate it. If that is a part of your DNA, you understand that it's about people! DevOps is very much about the people we work with, and it's about how we work together and that we trust each other as much as possible.
So how do we do that? I don't think that should be very difficult at all. Start eating out with the team. Celebrate achievements as a team. State what the journey looked like, what you encountered, which gaps you had to bridge and bypass. In short: "Yes, we fixed it! Thank you all!".
Thank each team member personally. You must earn respect and trust; you cannot enforce that. It starts with acknowledging and recognizing what each team member contributes. You need each other; you alone can't do it. That pat on the back is appreciated- I know this from experience.
The reward doesn’t have to be in the form of a raise or financial bonus. For example, reward with more flexibility. This provides a priceless feeling of trust, that you matter, and that you can start new initiatives yourself. You as a team are allowed to prioritize (or in some cases decide) as a team, what you do.
7. Invite the Operational Team
You can't do it alone. You need each other, and if we all use our own strength and work together like this, something beautiful begins. With DevOps, the point is that we control the entire chain from Dev to Ops; include the operational team! In larger organizations, these are often teams that you never meet. Let's start with that. Knowing and merging each other's interests creates a kind of magic, with mutual understanding of each other's views. Instead of fighting each other, you now fight together with the goal of bringing great services and software to the market very quickly.
Does the DevOps culture suit you?
In summary, adopting the DevOps method (ahem, culture) can blow new wind into the sails of your organization. Of course, I know that you cannot start immediately with all seven aforementioned suggestions, but just choose one. Choose which step you like best and start today. Tomorrow is a busy day, so take small steps and make the change manageable!
We learned from a large broadcaster that two parties were fighting for an assignment. This broadcaster did not decide who was chosen in the boardroom, but asked the DevOps team who the best party was. This culture contributes to connectedness and creating synergy with each other. The bridge to our services is that we want to support the release, deploy, operate and monitor side of DevOps. Coding, building and testing is the power of you. Working together in this process is essential.
In our masterclass sessions, we want to showcase the value of managing with this method of collaboration and thereby help bridge this gap. Our next session is on the 10th of July, where we will be joined by a special guest who will speak about User Adoption and how to support employees to adopt the application in their own context.