6 Steps To Survive A DevOps Transformation - InformationWeek
IoT
IoT
IT Leadership // Enterprise Agility
Commentary
4/1/2015
10:06 AM
Jez Humble
Jez Humble
Commentary
Connect Directly
Twitter
RSS
100%
0%

6 Steps To Survive A DevOps Transformation

From measurable goals to targeting quick wins and sharing lessons learned, here are the steps that can lead to DevOps success.

Shadow IT: 8 Ways To Cope
Shadow IT: 8 Ways To Cope
(Click image for larger view and slideshow.)

DevOps is everywhere, and if you're not already in the middle of a DevOps adoption program, there's probably one coming your way. Here's how to survive, in six only moderately painful steps.

1. Insist On Measurable Business Goals

The DevOps community is still evolving, so everyone defines DevOps differently. But you must be clear about what DevOps means for your organization. Otherwise your objectives will be similarly undefined. That will lead to confusion and cynicism. Insist on a shared set of measurable goals and an agreed-upon timeframe to get there -- an ambitious, but achievable, plan.

The point of DevOps is to make your systems more resilient, your software delivery process faster and less stressful, and your working environment more humane. Use these themes as your starting point.

For example, you could aim for 10% fewer critical defects, 20% higher uptime, doubling your release frequency, or some combination of outcomes.

Just make sure everyone in the organization knows what they are, agrees on them, and understands the timetable.

2. Give Teams Support And Resources To Experiment

Teams can’t be expected to do their usual duties and work towards these new goals. Much of DevOps is about process improvement, such as simplifying and automating manual processes. This is real work, the same as implementing features or fixing bugs, and it needs to be managed and prioritized in the same way.

[Get practical insights on how to launch a DevOps program at the Interop workshop Achieving Operational Excellence Through DevOps.]

There are a number of techniques to make sure there is sufficient capacity for this kind of work, such as using Kanban to limit work in process, assigning part of the team to work on the initiative full-time, or giving teams a certain amount of time per week just to work on process improvement.

The crucial thing is not to let regular duties crowd out improvement work, because the improvement work is what’s going to fix the inefficiencies that make it so slow and painful to deliver and support new features.

3. Talk To Other Teams

People often cite compliance, security, governance, and so forth, as obstacles to improvement. These concerns are valid, but usually the solution is to be found inside the walls of your company.

Talk to the people in charge of these domains and discuss how you might find win-win solutions that help you both achieve the outcomes you want. You'll almost always be surprised at how receptive people are to this kind of discussion if you approach them with respect.

Also, experiment with process improvement in ways that won't cause huge problems if they don't work. Most importantly, don't let the complexity of your environment dissuade you. Even high performers such as Amazon are subject to regulations such as Sarbanes-Oxley and PCI-DSS.

4. Achieve Quick Wins

The art of success in a change initiative comes down to three factors. First, tackle something that will have a quick and measurable impact on one of your goals. Use a tool such as the Theory of Constraints or value stream mapping to find where you’ll get the biggest bang for your buck.

Second, do the least amount of work needed to move the needle, which means limiting the scope of your work.

Third, partner with a team that's interested in pursuing change, and has sufficient capacity and capability to succeed.

You're unlikely to get all of this right the first time, so pull the plug if things aren't working and try a different approach. Your first shot should aim to get some concrete improvement in a month or two.

5. Share What You Learned

To get support from other people in the organization, talk about what you've been up to, what's worked, and what hasn't. People are often reluctant to try something new. They need to see it work with their own eyes. However, once you win these people over, they can become your biggest advocates. It's always better to have other people champion your causes.

Several organizations I've worked with have held internal conferences modeled on devopsdays, bringing people together from across the organization. It's hard to overemphasize the amount of energy and momentum these events created.

Lunch-and-learns, internal blogs, mailing lists, and Slack or HipChat channels are also great ways to get people involved. Provide enthusiastic help and support to others within the organization who want to try your ideas.

6. Keep Going

High-performance organizations always pursue improvement opportunities -- it's a daily work habit. To quote Taiichi Ohno, one of the creators of the Toyota Production System:

"Kaizen [improvement] opportunities are infinite. Don't think you have made things better than before and be at ease ... This would be like the student who becomes proud because they bested their master two times out of three in fencing. Once you pick up the sprouts of kaizen ideas, it is important to have the attitude in our daily work that just underneath one kaizen idea is yet another one."

These six steps are nothing new. They are proven ways of pursuing higher performance that should be familiar to anyone who has been involved in successful organizational change.

What's new is the idea that -- done right -- the goals of faster releases; more stable, resilient, and secure systems; and more humane organizations can be mutually reinforcing. This philosophy should always light your path.

Attend Interop Las Vegas, the leading independent technology conference and expo series designed to inspire, inform, and connect the world's IT community. In 2015, look for all new programs, networking opportunities, and classes that will help you set your organization's IT action plan. It happens April 27 to May 1. Register with Discount Code MPOIWK for $200 off Total Access Conference Passes.

Jez Humble is a VP at Chef, a lecturer at U.C. Berkeley, and author of the award-winning Continuous Delivery : Reliable Software Releases through Build, Test and Deployment Automation (Addison-Wesley 2011) and Lean Enterprise : How High Performance Organizations Innovate at ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
jezhumble
50%
50%
jezhumble,
User Rank: Apprentice
4/4/2015 | 10:24:42 PM
Re: What's needed is trust beween siloed departments
NB - Information Week comments don't allow URLs so you'll find short links that go into bitly in square brackets: Charlie, I think you are spot on. My two favourite practices to enable this are: * Game days / Disaster Recovery Testing (DiRT) exercises - there is a great article on this on ACM Queue [RlTlsv] - I particularly like Kripa Krishnan's comment (Kripa Krishnan did a talk on Google's DiRT exercises which is awesome [1DAd8Rn]): "for DiRT-style events to be successful, an organization first needs to accept system and process failures as a means of learning. Things will go wrong. When they do, the focus needs to be on fixing the error instead of reprimand- ing an individual or team for a failure of complex systems...we design tests that require engineers from several groups who might not normally work together to interact with each other. That way, should a real large-scale disaster ever strike, these people will already have strong working relationships established." * Blameless post-mortems, which you need to hold as part of game days [1GPyDPa] is a great presentation and John Allspaw's article is great too [1P2WQ8f]
zerox203
100%
0%
zerox203,
User Rank: Ninja
4/4/2015 | 4:16:13 PM
6 Steps To Survive A DevOps Transformation
This certainly gets at the heart of what DevOps is and where it comes from. Looking at all these larger business philosophies, you see how many of them predate DevOps by so much, and yet how applicable they still are to it. Many people's interpretaiton of DevOps is that it changes the work environment to be how people actually already want to work, and it just eliminates needless red tape and processes that are in the way. You can see that here. These tips also highlight the potential downside of DevOps. I've heard it tons of times before that ra culture shift that comes from the bottom up is required - or at least, it requires real stakeholders across the organization that will show people the benefits. If it simply comes as an order from the top, it'll never stick. People may follow the processes to the letter, but it won't make an impact unless they're on board with the spirit.

A lot of these synergize with each other. The measurable goals and the quick wins, for example, go hand in hand. You can set your metrics for what you want to measure and then pick a quick achievable for it that you can get done in the next release cycle or so. "Talk to other teams" may seem like a no-brainer, but Charlie's right; it's more art than science. Giving them the support and resources and making them feel like they're not stranded on an island goes a long way towards stimulating that cross-team communication. All in all, I'd say that these tips are applicable to more than just DevOps, and are good overrall - but that doesn't mean they aren't great for DevOps as well.
Drew Conry-Murray
100%
0%
Drew Conry-Murray,
User Rank: Ninja
4/2/2015 | 11:45:23 AM
Re: What's needed is trust beween siloed departments
That's a good point Charlie. There's a significant human component to DevOps, and if that human element can't come together, all the frameworks, processes, and tools in the world won't help.
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Author
4/1/2015 | 8:05:33 PM
What's needed is trust beween siloed departments
These steps or goals are well stated. But when push comes to shove, what's important is how effectively people who aren't used to talking to each other actually do so and listen as well as talk. Someone has to build up the element of trust. The more the embedded friction between historically siloed parties, the less likely these steps will actually work, even though the implementer claims to be following them to the letter.
Commentary
5 Machine Learning Resolutions for 2019
Lisa Morgan, Freelance Writer,  12/13/2018
News
What Tech Mega Hubs Will Do to East Coast Cities
Kayla Matthews, Technology Writer,  12/11/2018
News
Daimler Financial Services CIO Says: Don't Get Comfortable
Jessica Davis, Senior Editor, Enterprise Apps,  12/5/2018
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Enterprise Software Options: Legacy vs. Cloud
InformationWeek's December Trend Report helps IT leaders rethink their enterprise software systems and consider whether cloud-based options like SaaS may better serve their needs.
Slideshows
Flash Poll