How Do We Transform Our IT to a DevOps Culture? - TriNimbus

How Do We Transform Our IT to a DevOps Culture?

Over 80 percent of IT departments have or will soon deploy DevOps practices in their organization. Current processes will not be scrapped overnight nor will wholesale changeovers across departments be likely. That is because change is nearly always disruptive even when the benefits are obvious. The adoption of DevOps is even more so, since fundamentally it is a cultural change. Embracing a new technology is one thing, but changing people’s practices, behaviors and roles is quite another.

The Status Quo Languishes

What would motivate a CIO and IT staff to commit to such an endeavor? Pretty much the same things that motivate them now:
– Improving the quality, performance and stability of applications
– Increasing the number of platforms over which these apps can deploy
– Decreasing their applications’ time to market
– Providing superb customer experiences

Probably, there is a collective sense that the status quo is not working as well as it could to achieve these benefits. The current plan-driven methodology in place now could be getting in the way.

A Turning Point

The majority of IT organizations are turning to DevOps methodology in the hope that it can increase their effectiveness in meeting software development goals. Fully implemented, it represents a cultural shift valuing shorter development cycles, automation, a wider distribution of responsibility, a leveling of organizational roles and, above all, increased collaboration between developers and operations personnel.

How It Should Work

Here are the key elements for effective DevOps implementation:

– The guiding principle is to see products through the eyes of the customers, which means a focus on service instead of technology.
– Everyone becomes a stakeholder with cradle-to-grave ownership of their contributions.
– DevOps requires “all hands on deck” involvement to address defects: Developers, sysadmins, testers, DBAs, managers, network technicians, etc.
– Developers support Ops’ processes including infrastructure automation, configuration management, diagnostics, deployment scripts plus load, performance, functional and regression testing from the time of project initiation to product release.
– The Ops team provides tools, feedback, analysis and support to developers before, during, and after deployments.
– Silos are banished as stakeholders work together to break down walls and prevent them being rebuilt.

In this environment, team-playing skills are equally important as technical skills.

The Challenges

It all sounds easy enough in principle, but you know better than that. Cultural changes are typically the most difficult of all to implement in organizations. They mean change for just about everyone. Roles shift, reporting structures are adjusted, routine processes are revised or disappear and new tools must be learned.

Breaking down Silos

Enterprise org charts based on silos of responsibility are a natural phenomenon. Even within teams, micro-silos exist in the form of specialists with narrow functional domains. However, the throw-it-over-the-wall mentality is antithesis to DevOps. In DevOps, there can be no “us vs. them.”

Embracing More Automation

Extracting maximum value from DevOps requires automating as much of the software development cycle as possible. More automation removes bottlenecks created by waiting on manual tasks to complete. Automation must speed up processes, but equally important is that it enables multiple team members to keep development-to-deployment procedures moving without interruption.

Less Reliance on Specialists

An essential characteristic of DevOps is distributed responsibility. Many organizations are built upon specialization of roles and responsibility, however. To make DevOps work, you employ people with multidisciplinary skillsets who can function across both sides of the border between development and operations. You need operations people who code and debug and coders comfortable with infrastructure management and writing test scripts. Although there may have a few team members temporarily suffering from identity crises, most technical people are adept at augmenting their skills.

How to Proceed

If you are a manager or department head selling DevOps to your teams, you may find you are preaching to the choir, so to speak. Your people doing the heavy lifting in development and operations may know more about DevOps than you. At the least, they are willing to give anything a try to ease their pain. Given the opportunity, most will jump at a chance to perform their jobs more efficiently, learn new skills, reduce tedium and increase the time they have for innovative work.

Starting Small

Establish support for a proof-of-concept trial that is small enough to manage thoroughly but large enough to obtain meaningful, measurable results. If the project is too small, however, there is a risk that insufficient cross-team synergy is developed to apply the full-on DevOps methodology.

Forming the Trial Team

Seek out members for your silo-busting team who already demonstrate multidisciplinary skillsets across development and operations. They will have a natural affinity for DevOps concepts and can evangelize to other teams. If possible, select people who are drivers and successful at persuasion. Above all, empower people within the team to make decisions to avoid “death by committee.”

Project Selection

The driving team must select an existing software project or one about to be launched that will benefit the most from a DevOps approach. Candidate teams’ technical knowledge and behaviors must be surveyed so training efforts are focused. During this process, it is critical that goals and procedures be 100 percent transparent to reduce participant anxiety. Also, be creative about instilling buy-in and enthusiasm for the project. Frequent informal get-togethers of all those involved is good, since superb communication is an essential element of success.

Measuring Success

There are two key measures in DevOps: Rate of Change and Stability. The goals are to increase the rate of change, while keeping the system as stable as possible. Rate of Change might be measured s the number of releases or process change management tickets or whatever else is stressing the system. Stability is measured by availability of the particular service being provided to the user. An example is the availability of application features or the amount of uptime. The essential point is that these measures relate to the user’s experience.

Remind everyone that the meaning of success in DevOps is the outcome of the entire code-to-release-to-operate cycle and not what gets done at any component or functional level. Make it clear how vital full collaboration is to obtaining success. Innovation, particularly where it streamlines or automates processes, should be highly valued. Be aware that the DevOps reward paradigm may be foreign to team members accustomed to waterfall or pipeline development processes.

Conclusion

One of the hurdles to understanding DevOps is an entrenched mindset among enterprises that the problems of timely, quality software delivery can be solved by yet another silo, one-off project, a new technology or tool. When communicating the idea of DevOps, be sure it is not comprehended as merely one of those. It is much more, since fundamentally it relies on team and individual behavioral changes including shared ownership, end-to-end responsibility and an empathy for the customer experience.

Once the principles underlying DevOps are grasped, mastered and successfully put to practice, however, all practitioners will wonder how they ever got along under their previous paradigms.