Preamble
I was talking with Mike, my consultant colleague, about this new methodology called DevOps. The promise of better working together developers and operations and of seeing our dear organizations of information systems change… less silos they said. Fools! More efficiency is also fewer potential customers for us contractors.
“Listen” says Mike, “The resistance is organized. Agilists are already confronted with neoconformists. The latter managed to divert their propaganda and turn it against them. They gave their waterfall processes a Scrum color, but it is obviously not Scrum. The essence of agility, its mindset, has disappeared and the neophytes haven’t noticed anything. Even Dave Thomas, one the co-author of the Agile Manifesto recently announced the clinical death of Agility. You see, nothing is impossible!”
He then describes to me how they did it.
“First, do not change the organization, simply change the name of the job positions without giving any training (eg. Project Manager into Product Owner or Scrum Master), estimate the features in time rather than in complexity, ignore the team feedbacks. Above all, do not involve an Agile coach because he might suspect the deceit. Make the changes ‘reasonable’ but do not make significant changes in the structures of the organisation.”
After this list of unexpected efficient actions, I asked him how the neoconformists had those ideas. He then told me about that CIA document describing the measures to be taken to disrupt the organization and the means of production of Nazi Germany during the Second World War without arousing suspicion. “Passive sabotage!”, he exclaimed.
I look at him incredulously.
“We managed to adapt this document for the first time in the 1980s”, he continued, “to counter the emergence of LEAN manufacturing that was sweeping the automotive industry with great efficiency.”
“ITIL!”, I realized suddenly.
“Yes, ITIL”, he confirmed to me, “or Information Technology Infrastructure Library, a set of measures officially designed to organize information systems, but unofficially, it was a question of multiplying communication channels to reduce their effectiveness.”
“And to make us indispensable, we consultants”, I concluded.
“Exactly. Then, the agilists appeared in the 2000s and wanted to reverse the status quo. However, they only addressed part of the problem, software development and we managed to scatter their efforts somehow.”
“But now there’s DevOps that addresses both development and operations, and LEAN is back with that. The threat is real!“, I warned.
He then told me 7 specific suggestions to sabotage DevOps simply.
1 - Apply DevOps because of the hype
The worst reason to apply DevOps is because of the current hype. Gartner has helped in this, putting DevOps as one of the main axes of its digital transformation. However, DevOps without vision, it is like a hamster wheel, it doesn’t move anywhere. Nothing like putting devotees in the DevOps in this hamster wheel as they will exhaust themselves effectively.
2 - Bet everything on the automation
Bet everything on the automation and insist that all DevOps resources focus on it. This excellent measure will make you appear pro-DevOps as you focus attention on activities that will not require rethinking the organization or culture of the company; Automate even the bad habits already installed and it will be won.
3 - Put too much faith in the tools
Do not be afraid of DevOps tool sellers because they are your allies. They will apply themselves to convince that their tools will be sufficient for the installation of DevOps. Put as many tools at the operations as you can and take them on. The purpose of the maneuver is to divert attention from the inefficiency of the company’s processes.
4 - Call “DevOps” SysAdmins, CICD engineers or any DevOps fellows indifferently
Call DevOps for any roles indifferently. This sows the disturbance between roles, practices and culture. Let the SysAdmins take over DevOps; They will rush once again on the tools and will not seek to change the culture of developers. Developers will then consider that DevOps is a matter of Ops and they will continue their WaterScrumFall without more disturbance.
5 - Underestimate the initial investment
Refuse any budget allocation that would allow the DevOps to surpass the initial inertia. Prevent teams from meeting to discuss process improvement on the grounds that there are other priorities. Make sure DevOps fans are scarce, isolate them so that their will runs out over time, but always claim DevOps is essential to your business.
6 - Create a dedicated DevOps team
If, however, you have resources for the DevOps, make sure they are not properly assigned. Create a dedicated DevOps team. This will further isolate the developers from the operations and the support. This measure will also have the benefit of creating a new silo that can be exploited by managers and contractors. If some DevOps fellows warn you on the risk represented by a dedicated DevOps team, then just pretend this will last as long as the DevOps is set up.
7 - Imposing the DevOps without adaptations
If the previous measurements were not already enough, then apply the DevOps practices, but in the wrong order. Give developers the power to deploy their applications without teaching them operational constraints. Apply the same Scrum methodology to operations as to development without taking into account urgent ops tasks.
Conclusion
Finally, my colleague urged me to apply these measures in an iterative way and to measure their effects; To seek to improve them constantly and to concentrate on the pockets of resistance. The most important thing to fight DevOps is to acquire the right mindset, the rest will follow. So here you go. You may have noticed, after a careful observation, that some are already at work and indeed you are not alone…
comments powered by Disqus