DevOps and Change Agents: Common Themes
If you’ve been following our blog lately, you’ve seen (and heard) interviews with people talking about what it takes to launch successful changes in technology processes and teams. We’ve noticed that many of the things people say you need to launch successful change are pretty much the same things people talk about when they talk about DevOps.
That makes sense. DevOps represents a profound change from the ways technology organizations have traditionally worked — from siloed teams to all the technical teams working together to release better software more frequently, with an eye to creating products and services that are more closely aligned with user and business needs. Shifting to the DevOps way of working takes commitment and a strong will to improve technology processes and outcomes.
Below you’ll see some of the themes we’ve taken note of, and that apply as much to DevOps as they do to successfully launching change.
The urge for change is driven by frustration
Change is inherently difficult, so if things are going well (or even okay), most people aren’t interested in rocking the boat. It’s only when the current way of doing things is seriously inconvenient — even to the point of being painful — that people are motivated to look at what needs to change, and how to do it.<blockquote>It’s not that people say, “Oh, I want to be a change agent.” It’s more, “I hate the way things are, and I’m going to change it.” <cite>Luke Kanies, founder and CEO of Puppet Labs</cite></blockquote>
Change requires a shift how you think about work processes
Habits of thought are just as powerful as behavioral habits, and are equally powerful blockers to implementing change. To make a change in process, you sometimes have to change the thought habits first.<blockquote>It used to be we might spend a lot of time doing software development and then we would fall into this trap where the deployment would trip us up. Now we recognize that the deployment is part of the software development process, and that speccing out the server has to actually be part of the definition of what it means to create a new software application. It’s meant that we can build servers faster, that we can build them more consistently, and it’s meant that we can scale horizontally when we need to…..Since we’ve been investing more in DevOps processes and skillsets — for example building our server infrastructure with Puppet — it’s been a lot easier to get our new services out there and delivered.<cite>Bess Sadler, manager for application development, Digital Library Systems at Stanford University</cite></blockquote>
Pick the right problems to solve
Start by checking with the people around you to figure out why things are done the way they are — especially if you are new to the work group. You may have an idea of what should be changed first, but you could be wrong; there may be good reasons behind the processes that are in place
If you’re careful to pick the pain points that are most important to the people doing the work, you’re more likely to get buy-in from the people who will actually have to change how they’re working.<blockquote>Spend some time with [the people working with current practices]. It helps if you’ve done what they do, so you should take the on-call rotation, take the alerts, and walk a mile in the other person’s shoes before you speak up about what needs to be changed. <cite>Sam Eaton, director of engineering operations at Yelp</cite></blockquote>
Let people take responsibility and make important decisions
You’ll get more buy-in if people feel their professional judgement and decisions are respected.<blockquote> Our organization was flatly structured, so we were ultimately placing a lot of responsibility on everyone who was there. <cite>Gareth Rushgrove, senior software engineer at Puppet Labs</cite></blockquote>
Change the structure to change the processes
Traditional structures and hierarchies support the old way of doing things, so accept you will probably have to change at least some of these to get the results you’re looking for.<blockquote>Rather than a traditional [structure] — the operations people over there, the developers are over there, designers are over there, everyone in separate teams by discipline — our structure was very much teams around a product, around a thing. That forced people to work together much more efficiently and effectively, and to deal with day-to-day small issues very quickly, which led to lots and lots of incremental improvements, instead of hoping everything would come together at the end. <cite>Gareth Rushgrove, senior software engineer at Puppet Labs</cite></blockquote>
Start small; visible success will inspire people to sign on for more change
Trying to implement big changes right away will only scare people, and probably justifiably so: Big changes can have real consequences, including big headaches for the people on the ground, if things don’t go as planned. If you start with small changes and these result in real improvement (even small ones), people will have more confidence in you, and be more comfortable with making further changes.<blockquote>Once people get a taste of success, they are more willing to listen at the next meeting. Say, “I think I can translate that experience to the next line item on the list.” Then you get the buy-in you need to become a leader, a change agent, and apply the formula to the next thing.<cite>Kelsey Hightower, developer advocate at CoreOS</cite></blockquote>
Iterate, iterate, iterate
Once you start down the road of making small frequent changes, you’re able to gauge user response, whether it’s internal or external users for whom you’re creating software and processes. Gather data, and use your findings to design your next changes; rinse and repeat. That’s the path to change that will serve your customers better.<blockquote>Concentrate on evolution, not revolution. Even when you’re re-examining choices people made in the past, proposing change should be about, “Here’s something we can try and see if it improves things in this direction, so we can iterate,” not “That was bad, this is good, and it will be the permanent change.” Propose to examine the change again in three months, in six months, and have re-examining be a standard part of how people think about change: This is an increment, and there will be more increments. <cite>Sam Eaton, director of engineering operations at Yelp</cite></blockquote> <blockquote>Rather than taking two years to build something complex, ship early, ship often, ship something that’s maybe not quite finished, not quite ready for everyone yet, and to a smaller audience, or to a private audience. Do user research up front, get in front of people earlier and often; then pay attention to the numbers, how are people using it, where are they having problems. It’s only at that point you can start iterating and learning from usage. <cite>Gareth Rushgrove, senior software engineer at Puppet Labs</cite></blockquote>
Automation enables change
Change is a lot harder to implement when every change has to be made by hand. Automation allows you to make changes that are identical, repeatable, and if you’re using version control, easy to roll back. Without automation, changing process is tedious; with automation, it’s quick and accurate, so each change represents a much smaller investment of time and effort. That makes people a lot more willing to experiment.<blockquote>In the past, it was expensive and time-consuming to set up a new app server. Often, even if we’d written it out in meticulous detail, we didn’t get it quite right. Often [there were] discrepancies between the development server and the production server that we didn’t catch until the last minute. Because we’ve been able to automate more of it, in an easily repeatable way, we’ve been able to cut down not only on the time we we’re spending, but also the frustration. <cite>Bess Sadler, manager for application development, Digital Library Systems at Stanford University</cite></blockquote> <blockquote>Partway through the buildout phase, we moved the infrastructure from one supplier to another, moved to different underlying infrastructure platforms. [We] could do it reasonably straightforwardly, because we described our infrastructure in code, used Puppet to describe what our different machine roles were, and what software was required on them.<cite>Gareth Rushgrove, senior software engineer at Puppet Labs</cite></blockquote>
Recognize and acknowledge publicly that change is an investment
Change isn’t easy, and often involves learning new skills, plus adjustments to process that will probably take time to get right. You will likely need to assure people on your team that you understand this, and that they won’t be faulted for completing work more slowly than usual, or for putting some of their work to one side for a while. Just make sure you get that agreement from everyone involved, including executive stakeholders.<blockquote> [DevOps] is a worthwhile investment to make. I think sometimes people hesitate, because it can be some time away from your regular duties to invest in new skills, to start doing test-driven development, to move your infrastructure over to a configuration management system like Puppet. But what I’ve found is, it’s really a worthwhile investment that not only improves the quality of what’s being built, but the job satisfaction of everyone who’s doing it. <cite>Bess Sadler, manager for application development, Digital Library Systems at Stanford University</cite></blockquote>
Change can be implemented anywhere, in any organization of any size in any industry
Our interviewees have talked about launching change — including DevOps initiatives — at startups, within complex Fortune 500 companies, in Silicon Valley web companies, in educational institutions and in government. It doesn’t matter how large or small an organization is, or even whether it’s part of a traditionally slow-moving or risk-averse industry: When people see a real need for change, they’ll seek out ways to make it happen.<blockquote>Ninety-nine percent of economic activity and technology work isn’t happening in the unicorns; it’s happening in the non-unicorns….DevOps is for any company with Dev and Ops. These people are pioneering the practices to create a DevOps movement inside organizations that may not have the same genetic disposition to do something as crazy as DevOps as the unicorns.<cite>Gene Kim, co-founder of IT Revolution Press</cite></blockquote> <blockquote>Most large organizations — and governments are no different — tend to have lots and lots of different places where people go to find different information, and over time you end up needing to know how those organizations are structured in order to find information. We took on creating a single publishing platform for the entire UK government, to move away from hundreds and hundreds of separately managed, separately hosted, separately purchased, different tech stacks, different training requirements, different costs, and over time, amalgamate all that into one place. We launched that under the UK.gov banner, and it’s been a huge success. <cite>Gareth Rushgrove, senior software engineer at Puppet Labs</cite></blockquote>
If you’re looking for more inspiration (and some valuable tips) to launch change in your workplace, visit puppetlabs.com/changeagent, where you’ll find videos, podcasts, blog posts, white papers, and even an opinion poll (which we’d love for you to fill out).
- DevOps can boost overall organizational performance, and depends strongly on IT leadership for success. Read all about the state of DevOps today in the 2015 report.
- Watch the video interview with Bess Sadler of Stanford University.
- Read the interview with Sam Eaton of Yelp.
- Listen to the podcast conversations with Gareth Rushgrove, Kelsey Hightower and Gene Kim.