Author’s note: As the New Year began, I wrote about why DevOps transformation can be so hard for an enterprise, and I resolved to share more about how to overcome process, psychological and business barriers. And while some of my other New Year’s resolutions might have bitten the dust already, I’m happy to be keeping this one. What follows is Part 1 in this three-part series.
If Hercules had been an enterprise, process change would have been one of his 12 labors. Process change is one of the hardest things an enterprise can do, and yet process change is at the heart of every DevOps transformation.
One of the most common process barriers we face when implementing DevOps in the enterprise is legacy organizational silos. Silos are typical; enterprises have been set up in silo formation for a very long time. Consider the quintessential IT org chart: you’ll find separate server, networking and storage groups, and you may also have line-of-business IT teams that focus on a specific segment of the business. All of these “IT silos” not only have to learn to communicate and cooperate but also have to align their understanding and commitment to the agile and integrated nature of the DevOps process. [Insert deep breath here!]
Accepting that deeply ingrained processes have to change is not an easy task for people working day to day in these environments. The resistance can be formidable. I once heard one of our customers declare, “We need to ‘respect’ the boundaries that exist in order to drive success”— this was from a resource that was tasked with changing the way his business was operating!
Fortunately, years of guiding enterprises through the DevOps transformation have shown me pockets of exceptions in this area, where people have gone out of their way to break down boundaries. Here are three of the most effective barrier-busting techniques for facilitating this transition:
- Include the team.
A great example of how silos can negatively impact the business is when a dedicated engineering team evaluates and deploys a technology without requesting input from the development and operations teams that need to utilize it. Once in production, a system that has been selected in this manner has a very low chance of success; it will suffer not only from the lack of complete requirements but also by neglecting the soft side of human nature. People want to give their input. Changing the way we interact with teams is critical to the long term success. When people are allowed to give input, even if their recommendations are not chosen or utilized, they appreciate being considered, and this creates a team environment that facilitates success.
- Pull—don’t push—code.
Most enterprise IT operations that I speak with are using a push system. You’ve probably seen this common push-style scenario: a team develops software, and once they are done there is big deployment project, followed by handoff to the operations team. “This is my code base, it is ready, now you use it.”
And sometimes it’s just the opposite scenario. “This is my infrastructure, it is ready, now you use it.” Yes, when infrastructure becomes code, it can be versioned just like all other code that is being developed. This includes base operating system images, load balancer configurations, application code, etc. With this approach, a base operating system image is forced upon a team, with no thought to compatibility.
This process of throwing code at each other reinforces silos and fosters interdepartmental angst.
There is a better way. Pull code when you are ready to consume it. Let’s use the base operating system image as an example. When version 1.0 of a base operating system is ready, it will be accompanied with release notes about what is included, and teams across the enterprise can consume this while fully understanding the features that are offered. Down the line, this operating system needs patches and updates, so Version 1.1 is released for consumption. This release has release notes too, so that consumers of this code base will understand what has been added and what has been changed. Teams can can test their application on this new operating system image with a full understanding of what has changed. When they are ready, they will pull the operating system image into their application and test. The process of actively pulling in new code makes people aware of the fact that they are doing something different and gives them a better understanding of how they need to adapt, if at all.
- Slow down to speed up.
A colleague of mine taught me that every software project needs a good metaphor. One that he likes to use is “Good brakes make the car go faster.” You see, this colleague of mine is a big race fan. He knows that when a group of cars are coming to a turn, the car that has the best brakes—and can therefore apply the brakes last—will come out of the turn ahead of the pack. How does this apply to software development?
Stick with me, and I’ll explain with an example…
Testing is core to any successful automation project. There is no way to know if your code is working without it. Yet, one of things I have seen with many enterprise software developers is that testing, in their minds, is another department, someone else’s role.
Understanding the need for code testing is even harder when you are transitioning to DevOps and adding software development, a new process, to the list of Enterprise Infrastructure teams. Let’s face it—testing slows people down. Not only do these tests take time to develop, they have to be maintained over time as well.
However, what testing does provide is an instant understanding of whether the code is working. If you have an automated test, and you break the test, this immediate feedback will push you right back to your code base to repair the issues while they are still front of mind. Deferring the testing process causes bigger problems, because the more time you have away from a problem, the harder it is to solve.
I have seen this time and time again, where code that has not been tested is pushed to another team – the “testing” team. The team that receives the code spins their wheels repairing the code when the source of the problem is not theirs but rather code that has been received from another group. Eventually, the problematic code gets pushed back to the offending team, and the battle of the departments continues.
So slow down and test your code. Not only will this increase quality, it will reduce, and in the long term eliminate, the need for handoff to a dedicated testing team. Knowing that your code works will ultimately accelerate your processes. There are many parts of this process change where people will feel that this is slowing them down; in the long run this will be overcome, and one of the side effects will be increased quality. This is when the investment pays off. In other words, good brakes will make your enterprise go faster.
I encourage you to try these three techniques—inclusiveness, pulling code, and slowing down—to bring down the silos and blast through the process barriers that are inhibiting your DevOps transformation.
Coming in the next post … we’ll wrap our brain around some psychological barriers to DevOps transformation and how to overcome them.