How to Make the Leap to DevOps
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source:- informationweek.com
While it’s easy to make the business case for DevOps, executing it may be the trickiest leadership task you’ll ever face. Here are three steps that can help.
It takes planning and persistence for companies to shift from Agile to DevOps, but the rewards can be huge.
DevOps has come a long way since it was first conceived a decade ago. It started as Agile Operations, which was a response by sysadmins to keep up with more efficient Agile product development teams who were creating production quality software more frequently.
DevOps stems from the belief that companies work best when supported by product development teams that are coordinated and collaborative. A well-run DevOps team iterates fast and provides benefits in some very basic ways: software releases delivered on time or ahead of schedule and with fewer problems in production. Even if problems do make it into production they are fixed more quickly, and the team learns and improves by leveraging the data available through the collaboration. High-performing DevOps teams deploy code 46 times faster than lower-performing peers and experience one-fifth as many failures. Along the way, the shift to DevOps reinforces a mindset of continuous improvement across the organization. And emerging AI capabilities in DevOps promise even greater efficiencies.
But getting your dev and ops teams to work together to quickly build and release code into production isn’t easy. It is heavily reliant on cultural and process changes alongside the availability of a dizzying array of tools. Many leaders get nervous when planning the transition. So, while it’s easy to make the business case for DevOps, executing it may be the trickiest leadership task you’ll ever face.
I’ve led many DevOps initiatives over the years. I’ve seen great success and borne scars of failure. Along the way, I’ve learned there are common pitfalls to avoid (or at least leap over). The core essentials include a well-designed plan, a clear set of goals to shoot for, and the right people and process to do great work at an incredibly fast pace.
Set manageable goals
The first rule of DevOps is to start with a pilot program. Your goal is not to become the next Netflix or Amazon overnight. Instead, you’re doing a dry run for how a successful DevOps program will look at scale. This is your sandbox, a good laboratory where you can experiment, occasionally fail, and learn.
Initially, you’ll want to set a handful of goals that are aligned with bigger objectives, but manageable in and of themselves. If a primary objective is, for instance, to increase product quality, break it down into more specific achievements like decreasing the issue backlog by 40% or reducing deployment time by two hours.
Ensure everyone on the team understands the goals; this makes it easier for team members to pull together, and it’s a hedge against finger-pointing when things get rough.
Focus on people, not just projects
A DevOps pilot is about more than technology. Continuous delivery of your product requires greater collaboration from developers, testers, UX, security specialists, product and operations people from start to finish.
Successful DevOps groups are focused, quick and have a startup mentality. They fail quickly and learn from their mistakes.
Each team member should have a clearly delineated role, but the DevOps group itself should feel like one. I’ve made the mistake of being fuzzy about roles, and it’s come back to bite me many times. In one project, I initially asked a developer to do operations work as well. He quickly became a bottleneck because he was being pulled in too many directions.
We fixed that problem by splitting the two roles and assigning an ops specialist to do the ops work. As your team becomes more mature, it may become natural to combine these roles. But initially it’s best to keep them separate.
Be forewarned: Dev and ops teams have a long history of blaming each other for shortfalls, and personality clashes may arise, particularly in the beginning. Meet this challenge head-on by scheduling blame-free post mortems to fix issues quickly and learn from them. These are about failing fast to drive innovation.
Market the benefits, and celebrate success
When scaling DevOps, it’s important to show how your work delivers value. It’s also critical to make sure the team members are motivated and know how critical their contributions are. It’s a powerful combination.
When speaking with others within the company, show (rather than tell) how DevOps provides benefits. Don’t just say that quality is improving. Track and show specific metrics about how far the needle has moved for things like speed of deployment and how many defects are being raised for each release; or how quickly you are resolving incidents because the teams are working together.
In addition, showcase the human value. Get testimony from the business team describing the improvements they see, including how your DevOps speed and agility is helping customers. Get testimonials from customers, too, and share them broadly.
Finally, have a senior leader talk about the benefits of DevOps during general meetings like town halls in which they can describe how DevOps is providing value for the organization.
Good luck setting out on your DevOps journey. With commitment, perseverance, and patience, DevOps can be the same type of catalyst for your company as it’s been for Netflix, Amazon, and many others.
RJ Jainendra is VP and GM for ITBM and DevOps at ServiceNow. He has worked in tech for over 20 years with a majority of his career building tools for developers and IT. Most recently, Jainendra was group VP at Oracle leading product development and service management for Oracle Sales Cloud. Prior to Oracle, he was chief product officer at Electric Cloud where he led product management, design and engineering to deliver ElectricFlow Deploy and Release (in the DevOps market). He holds a Master of Science degree in Computer Science from the University of Wisconsin and a Bachelor of Science degree in Computer Science from Angelo State University.
The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT