8 DevOps Lessons IT Can Teach The Enterprise
DevOps has changed the way IT looks at Agile. Now there are lessons from the shift that IT can share with the rest of the enterprise.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt8ec5e79ea7e0bf42/64cb4303d51222285813984e/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
We live in an Agile world. Business cycles are faster and market demands more critical. Into this world, DevOps appeared to shorten the time between idea and product and introduce speed and flexibility into the entire IT organizations. The question is whether the IT department is the only business unit that can benefit from a DevOps approach.
For years we've been told that CIOs and IT executives should be business leaders, not just technology gurus. One way to prove business leader bona fides is to share best practices with colleagues in other business units -- to "infect" those units with the philosophies and practices that are successful in IT.
Many companies have found DevOps to be a successful approach to IT, so it's reasonable to ask which lessons can come out of IT for the benefit of the rest of the organization.
[See 10 Tools to Keep Your Agile Dev Projects on Track.]
It's important to note that DevOps is not a practice that is without controversy. The challenges come in two main areas: stability and flexibility. There are those who say that the push to be faster and more nimble necessarily cuts into the reliability and stability of the product. There are also those who complain that an emphasis on employee flexibility devalues expertise and overburdens the workers.
Each of those can challenges can become a real problem if DevOps isn't implemented properly. That's why IT is important to the enterprise when it comes to implementing this Agile process. The development and operational staffs within IT have learned what works and what doesn't from their own implementation of DevOps. Sharing that hard-won wisdom is as important as sharing the promise of DevOps when it comes to making the whole process a success.
Here, then, are lessons on DevOps that IT can share with the rest of the organization. How many of these lessons have you learned? How valuable do you think the DevOps approach is to the rest of the organization? If you've been through the transition, I'd love to hear from you. Let us know which lessons you've learned from the trip to DevOps.
Are you an IT Hero? Do you know someone who is? Submit your entry now for InformationWeek's IT Hero Award. Full details and a submission form can be found here.
One of the critical practices within successful DevOps is application release automation. This automates the software-release process from development through testing and into deployment. The key to successful application release automation is that visibility into the process is increased for every team and team member along the way.
In too many business units, automation means that visibility into the process is reduced. Automation becomes a black box that magically produces results, some of which might not make sense in a particular situation. Automation for repeated steps and processes makes sense because it makes everything faster and less prone to error. At the same time, team members must be able to see what's happening and know why it's happening, so that the process can continue to improve and rare exceptions can be dealt with gracefully.
In many organizations the "creative" people and the "operational" people fall into two camps that don't talk very much. In the DevOps world, there's no real difference: The creative folks (designers and developers) are expected to take on operational tasks, while the operational staff is expected to have input into the development and design.
In some organizations this is stretched to the point at which each member of the team is expected to do any role on the team. As we'll see in an upcoming lesson, there are limits to how far this can be taken, but the central lesson is clear -- sharp divides between team functions lead to poor communications, delays, and reduced quality. Mixing things up has benefits to people and the process.
How many times have you heard someone say, "That's not in my job description."? In the DevOps world that phrase doesn't have any real meaning because the job description is, essentially, "Do what's necessary to ship the product."
In practice, that means being willing to pitch in on tasks and, more important, understanding the basics of all the tasks on the team. Yes, some will be better and more highly trained at particular jobs, but everyone should understand the concepts involved at every step along the way, so that no task is left open simply because the specialist isn't available.
One of the things that makes enterprise life more difficult is a tool set that varies from group to group in a department or team. We're long past the days in which the creative team and the operational team might use different word processors, neither of which could understand the other's file format, but there are still many cases in which workgroups use tools to communicate or share data within the group, then have to do some sort of export before the information can be shared with the larger team.
"Shadow IT" makes this worse. Workgroups can easily start using a cloud service to do some nifty task without understanding how information is going to get out of that service to the rest of the department or team. Sharing information, working collaboratively, and communicating should be as transparent as possible within the entire organization. That's why everyone should use a single set of tools unless there is an exceptionally compelling reason to do otherwise.
Companies have a disturbing tendency to create new titles when a new way of looking at the world comes along. Don't believe me? I give you "chief digital officer" as Exhibit A. DevOps is a process for putting Agile into practice. It's not something that one person can do. It's not even something that a team or department will have as its only task. Shoving DevOps into a title or description guarantees that it will be easier to ignore and more difficult to incorporate into the entire organization.
Almost every IT executive I've talked to says that changing the culture is the hardest part of implementing DevOps. It's not hard to understand why. People get comfortable doing things one way and hate to change, even if they admit that the change will be for the better.
Successful change will mean having champions for DevOps (even though they won't have that as a title) and choosing pilot projects that are guaranteed to succeed. That success should come rapidly, too, since one of the reasons not to change is that it will slow things down. Keep your eye on the culture and be prepared to deal with those who would become obstacles. DevOps doesn't deal well with islands in the stream, and you shouldn't either.
OK, here's where we get to the dark side of DevOps. Because DevOps emphasizes flexibility, some companies use it as an excuse to task every employee with every part of the task, even if that means working overtime. If you use DevOps as an excuse to overload your employees, they will burn out, drop out, and leave. Replacing employees can quickly eat up all the operational efficiencies that you hoped to gain through DevOps.
We still haven't found the magical 28-hour day, and your employees are still human beings. Treat them as valuable colleagues and you'll find that DevOps can result in better products created in less time. Treat them as FTEs on a board and DevOps isn't enough to help you.
One of the reasons DevOps came into favor is that people saw the way teams work in a startup organization. Everyone pitches in, things get done, and people don't worry about job descriptions and titles. They worry about getting the job done. That's all great, and can be very real in a startup. The thing is, everyone involved in a startup knows that at some point the company isn't a startup any more. That means they get some portion of their life back and things get a bit less frantic in the office. Those are good things.
Don't try to use DevOps as a way of generating a false sense of panic in the workplace. Some managers thrive on chaos and adrenaline, but DevOps is not a good way of creating either. In DevOps done right, the flexibility occurs within an automated, controlled framework. It's the ability to respond to changes without flying into a panic. If your IT team can't share that lesson, then it needs to take a careful look at its own DevOps practice.
So there they are, 8 lessons that IT can teach the rest of the organization, based on DevOps. What do you think? Are there other lessons you would include? I'd love to see your thoughts in the comments.
One of the reasons DevOps came into favor is that people saw the way teams work in a startup organization. Everyone pitches in, things get done, and people don't worry about job descriptions and titles. They worry about getting the job done. That's all great, and can be very real in a startup. The thing is, everyone involved in a startup knows that at some point the company isn't a startup any more. That means they get some portion of their life back and things get a bit less frantic in the office. Those are good things.
Don't try to use DevOps as a way of generating a false sense of panic in the workplace. Some managers thrive on chaos and adrenaline, but DevOps is not a good way of creating either. In DevOps done right, the flexibility occurs within an automated, controlled framework. It's the ability to respond to changes without flying into a panic. If your IT team can't share that lesson, then it needs to take a careful look at its own DevOps practice.
So there they are, 8 lessons that IT can teach the rest of the organization, based on DevOps. What do you think? Are there other lessons you would include? I'd love to see your thoughts in the comments.
-
About the Author(s)
You May Also Like