Some time ago I defined a DevOps Maturity model based on the different ranks that exist in martial arts. Many people benefited from being able to understand where they were in their DevOps journey.
The problem is that even that model doesn’t present strategies for scaling from lower to higher levels (the point where you become a DevOps unicorn!).
In this article, we’ll review sustainable growth strategies.
Take the “Before” Photograph
Before applying strategies, you need to honestly identify where you are in the DevOps Maturity Model.
It is very likely that you are at different levels in the three areas (Culture, Processes, and Technology). And, that’s fine!
Be very honest, and if there is any doubt that you are between a lower level and a higher level, round the result to the lower level. In this way you will be able to refine and make solid the foundations to progress with more confidence.
After evaluating (taking a “Before” picture) your maturity in DevOps, it is time to define your goal and the strategies to reach it.
The goal will be one of the levels above the one you are currently in on any of the three pillars mentioned above. With that defined, you already have a destination in mind ;).
Now, let’s review the strategies.
1. Take the Immediate Opportunities on CD
In a nutshell, it starts with Continuous Deployment.
Why? … Well, it’s very likely that if your maturity level is halfway down, it’s because your work team has not yet automated its Continuous Deployment Pipelines.
So, analyze which of your products frequently have problems with the deployment. For example, servers with misconfigured products after a manual deployment, or problems in a product version that forced a manual rollback to the previous version, or perhaps the development team continually releases unexpected patches that are manually deployed.
In essence, analyze the most tedious and manual deployment processes of any of your products and automate it mercilessly.
2. Take the Immediate Opportunities in CI
In this case, analyze those routine processes that your development and/or quality team performs manually and on a daily basis.
Suggestion: Ask them: What do you do manually? Is there a way to automate it? If the answer is something like: “I do builds/tests/packages, … but it only takes a few minutes”, you found what needs to be automated… also mercilessly.
3. Kaizen every Sprint
From the book “The One Thing”, use the question:
What is the one thing I can improve in this sprint (2-4 weeks), that doing so will make my life easier?
Identify only one area, and define what is the least you can do in 2-3 days to improve it. Schedule it, and make it happen.
That is Kaizen or Continuous Improvement, put into practice.
The next Sprint, ask yourself the same question, and repeat the process ad infinitum.
4. Change what you control. Influence who you can’t change
Many times we are between a rock and a hard place as a team, in the sense of not being able to make many decisions (and at least we perceive it that way), and therefore we have very little range of movement.
Identify what you have total control over, where no other team or manager has a say, and improve it slowly but surely.
Working on those projects won’t necessarily be within your working hours (initially), so be prepared to work overtime for the sheer joy of Kaizen.
This is a strategy that takes several months (even years) but it is effective if you want to become a “Linchpin”.
Now, this is the important part:
After several projects in which you have improved something that is under your control, organize presentations with your work team or webinars or even record them and distribute them to everyone in the company.
Do it no matter what others think of you. Many times, you will find that you have inspired others to do better in their own little kingdoms, or you will even be invited to work with them.
DevOps (and Kaizen) start with oneself.
5. Create Constructive Chaos
Beware, this may go against your professional ethics. But before you stop reading and judge me, let me tell you that several of my mentors used this technique and the results were spectacular.
The problem of a stall in the progress of software teams is not due to processes or technology. It’s given by the cultural part.
If your team isn’t making progress and you’re feeling frustrated, use the chaos to your advantage.
Unfortunately, many humans need to go through events that challenge our comfort (wars, catastrophes, pandemics) to see ourselves forced to improve/innovate.
In the case of technology teams, those crises are usually:
- Downtime of servers in Production
- Suffer continuous paperwork in front of your customers
- Hacker attacks
- Loss of code repository (yep, I’ve seen this myself several times)
Now I ask you, what would happen if any of these events happened on your computer?
Surely the ways of working would change culturally and therefore would have a positive impact on processes and technology, right?
Without the intention of motivating you to be an Agent of Chaos, I invite you to simulate what would happen in a controlled environment with one of these events and thus rediscover the motivation to improve your team’s work.
Take the “After” Photo
Whatever strategy you decide to carry out, remember to take a new picture (before and after) of implementing it, either in 3-6 months, in order to assess how far you are still from your goal, or you will most likely discover that you already got it and now it’s time to define a new goal.
Now, what do you think of these strategies? What others do you have in your arsenal? Let me know in the comments below and let’s continue the discussion online!
Keep on Learning