I've been working professionally in the tech industry for more than 7 years. The change has been always one of my things. I started to do that starting from my first day in this career!
And that's actually why I love the "DevOps movement", because it's about "change"!
Change management
DevOps and Agile are two different things but mostly they show together like two sides of the same coin. Flexible change is always part of Agile, but in the end, change is a risk and it should be planned and be part of Agile processes and strategies.
When I move to a new company I normally do something: once the onboarding starts, for the first one or two months I take notes, watch, and learn. What's good? What's bad? What could be better?
Then I start to discuss my findings with the team and managers. I used to do that verbally. But a few years ago, I saw this graph called "J-Curve"! So I do a presentation and make sure the whole team is aware and ready for the next steps ... to the change!
Change curve
With any change, there is always a "deterioration" of something related to that change (that could be actually anything! Velocity, efficiency, or anything else). Let's have the following scenario as an example.
If we have a manual task and we want to automate it, working on the automation for this task will consume time, which means less time available for the actual task.
1. Before the change.
We have a task, and it's done manually. After some time, the task is done in 10 min with a small error rate. The situation is stable at this point, however:
- The task couldn't be done in less than 10 min.
- The task depends on people' skills. That means it's not the same for new people who could work on that task (e.g. more time and error rate).
- The task depends on the people themselves. That means if people are busy or on vacation, the task will no be done anyway.
2. During the change.
Normally the task is done manually in 10 min. However, in the transition phase probably there will be a general slowness in doing the task. So while working on the automation, the same task might take more time, let's say 20 min.
3. After the change.
Once the change is done (here it's the automation), the task will be done in 1 min! Not only that, but also more accurate and fewer errors.
Change progress
Obviously, during the change, there will be a kind of slowness, and people shouldn't panic because the goal of the change is to make it "better" and that's part of it! Hence it's important to make it clear that deterioration is already expected!
Also, I explain that the deep part of the curve (which represents the deterioration), first and last, depends on all the people who are involved in the change ... it depends on "all of us"! So we could actually get a different result which's the dotted line in the curve.
The nice thing is that every time people are aware of "what's next", they are more likely to adopt the change at an earlier stage. And you get pretty good results.
Resistance to change
On the other hand, you will always find people not in favor of "change"! Some are against "change" in general! Some will just deal with the situation as it is and they don't try to fix the root causes because it requires "change"! And some are simply afraid of "change"!
You need to deal with it and plan accordingly. But never let your anger control you! First of all, you need to remember that some people will never change ... that's life!
Nevertheless, also remember that some people are not really against change per se but they could be just "shy", not "early adopters", or just want to "see" more the benefits of change. You just need to find the sweet spot to deal with that.
...
That's it! Keep moving, keep the change!
