DevOps: How to start scaling better, faster

Large scale enterprises are struggling to adopt the transformation to a digital enterprise. DevOps is an important part in this journey. As a consultant we are writing the DevOps story for our client and this story will make or break our client’s digital transformation. We have to lead with a portfolio analysis that creates initial success. When clients experience success in the early part of the process, the story has a positive beginning. This overcomes the resistance and failure that we encounter so often.

I was working for a large Financial Institute in the US. It was one of my first client engagements after I moved to New York in 2019. My client’s IT department had started to adopt DevOps in their organization, but had to stop the rollout because the business department was not willing anymore to invest further. The unfinished rollout slowed down the IT department and the promised improvements could not be translated into business improvements.The business department felt that their workload was increasing. They had to test more frequently (because the automation was not finalized yet), deal with constant requests and alignments, and make multiple changes to the product management process. Also they felt that the capacity from the IT department was less because they had to work all the time on “reducing the technical department” and “automation.” It was painful for all involved. 

Is your business department ready for DevOps?

This is not the first time that I have seen this pattern: IT departments become doubtful when the DevOps adoption doesn’t immediately show results. Perhaps you are facing the same issues in your company. However, transforming DevOps is an investment. The entire business improves through this. Investing in automation and people require time. Therefore, this investment has to be agreed on and approved throughout the enterprise. If everyone doesn’t buy in, it will fail. Just to stop the DevOps adoption is no option for a company. IT departments have to be able to change their organization and software development model. If ongoing change and optimization is not possible, survival is at risk. So what was our advice to stop the burning platform, bring back confidence in DevOps and show results? Our advice was to focus selectively on a few areas - areas that we can quickly change and that will have a high impact for the business. We kept the business department, operations and security untouched. We only focused on the development - and test-team. We felt this would give us the quick wins we needed to restore the confidence which is so crucial for DevOps transformation.

Start with the team and people who are willing to lead the change

Our starting point was the portfolio analysis. This was the biggest change. Before my team started, DevOps was approached from the bottom up. All the development teams had been forced to adopt DevOps and the adoption had been reported. Here we were different. We didn’t want to change all the teams, we wanted positive results for the business first. Our capacity and also the time we had was limited.

First we picked one IT department from the organization, the risk department. This department was responsible for all applications which had to do with the risks a financial institute faces. We had chosen this department according to the willingness for change and openness for DevOps. It was a subjective decision, and felled in minutes.

Next step was the portfolio analysis to set our focus. We executed the portfolio analysis in a short 3 hours meeting. We had no time to lose. Here is how we did it. 


pasted image 0.png

We brought the head of the risk department and two of his colleagues in a room with a white board. We already had all the names of the applications which were his responsibility on post-it notes pinned to the white board in a straight line from left to right. The first task was to sort the applications according to the effort that a DevOps transformation would cause. It’s less effort when:

  • Test cases are already automated

  • We start from scratch in a greenfield application

  • The team is willing to change

  • The team is trained in DevOps, Lean IT and Agile 

  • The team has quality and security skills

  • The business is willing to invest in the application

  • The technology is not challenging (niche technologies, old frameworks, etc.)

  • The application architecture supports DevOps (Microservices, Cloud, …)

After one hour and some initial doubts we had the applications in order from left to right. No post-it notes were above one another. It was helpful to be reminded that it doesn't have to be perfect.

We can adjust later when we see the final result.The next iteration was to move the stickers into a vertical line. The vertical represents the intensity of impact a DevOps transformation could have. We defined a high impact application as having the following aspects:

  • Quality or security issues

  • Creates new business

  • Its target is a longer term cost reduction, not short term

  • Is defined as highly business critical

  • Volume for changes is high

  • Has multi-vendors, multi departments or multiple handoffs are required

After an additional 60 minutes discussion and two telephone calls to get some details we finally had all the applications on our matrix as you can see it in the picture. We added the details for sunset (applications which will be shut down soon), greenfield (new applications) and the volume (people in development, test, security and operations that are working in the application). Here again is the advice: it doesn't have to be perfect. All in all it took us three hours to complete the full analysis. 

Understand your value stream and start with more than one application 

The last and final step was to identify which applications are linked to each other: you can call that the value stream. If the team of developers changes something in App 26, then, in most cases, they also have to change App 2, App 4, App 6 and App 14. Each product is related to multiple applications (value stream).

We chose these five linked applications (see the decision matrix above) and used them to showcase the positive impact DevOps has on the business. This short analysis kept our limited capacity focused. In a short iteration, we delivered tangible results with minimum investment. After one and a half years of unfocused activities, now our client had a showcase to explain further investment and to drive the change.

My takeaway from this situation: showing results is more important than just following an idea

When I work for my clients, I always learn. My lesson this time was that showing results is more important than just following an idea. For a few years now, the idea of DevOps has been circling around. However, the change DevOps entails impacts more departments than only development and operations. The benefits of DevOps success are not understood and accepted in all departments. “Change yes, but please not for me” is the motto of the resistance. We have to lead the change with results. Only showing results which are relevant and easy to understand changes people's thinking. That's why I always start with the portfolio analysis - to set the right focus and start writing a new success story for my client. 

RobotMatrix_2.jpg
Previous
Previous

Bringing DevSecOps transformations to maturity with team dynamics