In my role over the past number of years, I’ve had many great ideological DevOps conversations with many people from various organizations. I often explain that to me, DevOps is an approach and a mindset. Whether it’s implementing a deployment automation tool for the first time, strengthening a continuous integration (CI) implementation, or writing infrastructure as code, my approach is always:
- What are the requirements for success?
- What are the technology barriers that need to be overcome?
- Who is the team that I must work with and what are their strengths and weaknesses?
One question that is very often asked of me is what I think is the biggest challenge in DevOps, which I will address in this blog.
The people within your organization and its culture are the biggest challenge in DevOps. Please don’t take this negatively! Usually organizations have very good people working for them. They are very smart, talented people and they are very good at what they do. However, we are all creatures of habit. Every day when I wake up I have 1 cup of coffee with a little milk and sugar. That’s just what I do every day and when I don’t have my coffee I’ve been known to be grumpy. For many people, learning a new tool or working a different way doesn’t come naturally. There is the adage of “if it ain’t broke, don’t fix it.” People want to do their job well, get it done, and go home to enjoy their family. New tools and processes tend to make people feel uneasy as it’s something new to learn with new potential for struggle or even failure. Thus, the question becomes, what does DevOps provide to your organization to help with the challenge of change?
If some people are naturally resistant to change, how are you going to change them (this is a bit of a paradox)? Every person has their strengths and weaknesses. DevOps is about breaking down silos, improving transparency and predictability. DevOps is about removing the mundane and tedious with automation so that your engineers can focus on the new and exciting i.e. implementing powerful change. It is our job as DevOps architects to harness each person’s strengths and use the team to overcome any individual weaknesses. I believe that every person has the capability to learn and grow, so the real question is whether they have the motivation and are being held accountable for change for the better. If people aren’t being held accountable to implement real, positive change, then chances are that your DevOps transformation will fall short of expectations.
How does DevOps motivate change? From what I’ve seen, again, the challenge of change can be overcome by finding meaningful motivation for an individual. Upper management is always focused on faster, better, cheaper, but how does this translate into a driving force for an individual? The cultural shift of DevOps includes empowering your engineers to remove the mundane and tedious from their daily work. Implementing automation within your organization specifically targets the faster, better, cheaper business results. For example, it’s not worth an engineer’s time for an application deployment to manually stop a web server, copy files around, toggle the web server configuration, start the web server, and finally ping the web application to see if its running with the new updates. Those steps are laborious and boring to perform and error prone for a human. How many people dread the bloated release planning meeting? Is gathering 10+ people in a room to talk about a specific release for over an hour a valuable use of time? If instead we were to implement agile best practices with backlog prioritization based upon points, tracked this planning work in a team-based tool, and were able to then forgo the bloated release planning meeting every couple of weeks, would that be a good motivation? This would empower your product managers to have a real-time, accurate picture of their release plan and they would have real predictability about their product lifecycle. This is in stark contrast to manually keeping a spreadsheet of green, yellow, red status cells and having to go around to various stakeholders asking for a status update. DevOps motivates change by targeting objective metrics for faster, better, cheaper. DevOps also motivates change by targeting subjective metrics for engineers by removing the boring, mind numbing work, which opens up time to do true innovation.
So you, Mr. Trail Blazer, have now fully embraced the ideology of DevOps. How do you sell the idea of DevOps to management as well as the worker bees around you within your organization? How do you invoke this cultural shift for improvement?
Be patient!! DevOps is not a silver bullet. These changes take time and they focus on iterative improvement. There is no big bang and suddenly your organization is a utopia. One of my #1s to being successful with a DevOps initiative is that you must have an executive sponsor. The worker bees need to understand that the top brass is “kindly” asking them to improve. Sometimes you will find that top brass needs to provide additional motivation or praise depending upon the circumstances. The faster, better, cheaper usually resonates well with management. The other piece that resonates well is the improved predictability and reducing risk. Outages are extremely painful and can cost millions (just ask the airlines in 2015 and 2016). Invoking DevOps techniques like deployment automation or infrastructure as code mitigate risks and shorten recovery time if/when an outage does occur. DevOps techniques will improve the quality of life for worker bees within an organization. Implement standards and ensure worker bees are adhering to those standards. For example, developers despise the dreaded code merge, thus they should embrace continuous integration techniques like merging smaller changes more often instead of a big bang merge. Working with the Product Owner to minimize work in progress and limit development to current and release.next only reduces a large number merges all together by refactoring code to remove unnecessary branches. Also applying best practices techniques like build once, then have an automated deploy for any environment. This streamline builds and deployments with clear visibility of which builds are in the appropriate environments instead of developers wasting time waiting for things like a QA environment refresh. On the topic of environments, embracing the major advances in cloud automation and infrastructure as code. Dev/QA teams can no longer afford to wait weeks or sometimes months for a new environment. Its excruciating in today’s world to even wait a few hours, let alone days or weeks. I have yet to see a team transform over night, but give a good team enough time and a little direction and they will move mountains.
DevOps incorporates techniques for improved communication, teaming, and transparency. DevOps is about empowering the individual to invoke real, positive change, by removing waste and streamlining. It isn’t very difficult to sign up for a GitHub account, download Jenkins and create a simple build job, or even spin up a new server in Amazon Web Services. There are typically good examples and documentation out there for these things via a Google search or reading documentation. What isn’t ever straight forward is how to motivate and improve an organization for innovation. This is the real power of DevOps and the real challenge of DevOps. And with that, go forth and institute some real, positive change!!
