For most of my professional career I have worked in software companies in Ops and DevOps roles.
It seems that overall, most organizations today are aware of the importance of DevOps practices and are more than ready to adopt the practices in their organizations changing them to DevOps.
This is probably due to the fact that most organizations developing software in today’s Agile world increasingly feel the pain of not having DevOps practices in place which leads to many pain points in the development process.
Some of these pain points include:
- Increasing and unnecessary tension between Development and Operation and teams.
- Excessive time spent by developers on delivery, operation and configuration tasks.
- Very long developer/QA feedback loops which lead to an even longer gap between development and TTM (Time to Market).
- Little or no automated software delivery processes.
However, when it comes down to making actual organizational changes for DevOps, I noticed there are some anti-patterns that emerge.
The Re-branding Anti-pattern
In some organizations, to achieve the desired “DevOps” status, existing Operations or IT teams are re-branded DevOps teams. To the extent that even some traditional IT positions that included managing physical hardware are re-branded DevOps.
The problem with re-branding is that it does little other than change the job titles of the Engineers and IT people in the team, so the main pain points that affect a non-DevOps company still affects them.
The Hiring Anti-pattern
This strategy basically goes like this: “No one has any idea how this continuous deployment thing should be done, let’s hire a DevOps Engineer!”
Now this masquerades as a legitimate approach, since the organization is trying to add an engineer who (hopefully) has some experience in implementing DevOps methodologies and practices.
However, the reality usually is that the designated engineer is told: “Ok, you are now our DevOps!” #true_story, however in actuality the the organization has little or no intention in changing the processes which are essential for an organization to become DevOps. Doing it this way will ultimately leads to just an additional unhappy engineer in the organization.
To conclude, the issue here is basically that organizations need deeper understanding that DevOps is fundamentally more than a specific tool, technology or job title. It is all about best practices governing the whole software development process rather than a single person or group engineering something nobody else should be concerned or know about.
What other Anti-Patterns have you met?