In my role as a DevOps advocate, practitioner and teacher I often find myself talking to companies when they are partway through a DevOps transformation, but things have seemingly stopped progressing or even begun to go backwards. I’ve come to call this the DevOps Speed Bump – because it is usually exactly that – a temporary slowdown that is part of the natural cycle of organizational change.
On occasion the speed bump becomes more like a mountain however and requires some level of intervention to get things back on track. In these cases an outside opinion can be helpful, as it’s sometimes difficult for people in the trenches to see the bigger picture clearly.
How It Happens
A DevOps slowdown usually occurs after a period of transition to newer systems, particularly after they have been partially or completely automated. This automation usually results in faster build, deploy and development cycles but edge cases begin to emerge which require significant time and attention to properly handle in an automated fashion.
The 80/20 rule applies. The last 20% of the work in automation usually takes 80% of the time and requires deep expertise in company systems or data. This can be planned for and mitigated somewhat but it can also cause slowdowns in other areas since attention is diverted. This often results in resentment and pushback amongst developers or management when things don’t seem to be progressing.
Unrealistic promises or expectations regarding automation are also common culprits that can indirectly cause slowdowns. When expectations are out of line with reality focus is often placed on less productive areas to make up for the perceived deficiency. Managing expectations accordingly is a key part of any successful automation roll out.
It is common for developers to think that automating a build pipeline or development process is easy, and this isn’t entirely wrong. But it’s often the slew of requirements and related or connected processes that make it more complex than it appears at face value.
Getting Back ON Track
Fortunately once you are aware of these phenomena, you can begin to plan for and mitigate them. If you are starting a new project or devops transformation make sure you include time for learning and perfecting any new systems which will be put in place.
In cases where planning did not occur and you are trying to minimize damages, make sure you communicate as early and as often as possible. More communication amongst all stakeholders is a key tenet of DevOps and should be practiced as much as possible in cases like this. If other stakeholders understand the tradeoffs being made and the reasons for prioritization early, it becomes much easier to craft a compromise that meets the needs of everyone.
Making sure that the communication happening is the right kind of communication and that it happens in a timely manner is also important – as is making sure that the right people are the ones talking to each other. If Ops people are not communicating with the Dev team but just pass info back to a manager then important context will often be missed. Successful DevOps teams communicate directly with affected parties and not via managers or third persons.
This communication must also be two way and education is the key component to it happen. If teams are not aware of each others capabilities it’s difficult for them to make good requests. It is often helpful for infrastructure focused teams to think of developers as their customers. However It’s equally important that they be given the authority to maintain operational standards and push back on requests when needed to maintain robust and highly available systems.
Staying On The Path
Once you’ve got things back on track make sure that teams and individuals internalize these practices to ensure longevity. It’s not uncommon for a yoyo cycle of success, slow down and back to success to continue if these types of issues are dealt with superficially. For processes and practices to stick, stakeholders must understand not only the mechanics of the process but the value as well.
A good DevOps advocate understands this and makes sure the value of good practices is understood before implementing the practices themselves. Of course not all team members will agree immediately but long term consistency and demonstrating results goes a long way with even the most hardened skeptic.
