The DevOps movement has had a profound impact on the way IT looks at agile methodologies. But there are lessons from the transition to DevOps that IT can share with the rest of the enterprise.
The five key lessons IT can teach the enterprise are as follows:
Being able to “see inside” automation is critical
Application release automation is a key practice for successful DevOps. Application Release Automation (or ARA for short) automates the process of software release through testing and into deployment.
I’ve found that a key success factor for DevOps automation. Automating repeating steps and processes makes sense because it makes everything faster and less error prone. However, team members must be able to see what’s happening and why, so that process can continue to improve and exceptions can be dealt with.
Cross-functional collaboration is vital
In many organizations, creative and operational teams were split, and for a long time, this was the case in IT. With DevOps, designers and developers were expected to take on operational tasks, and operational staff were expected to have input into the development process.
With the rise of technologies such as Docker, developers are expected to take on ever more operational tasks, and this is driving increased speed to market. The lesson for the rest of the enterprise is clear – sharp divides between team functions lead to poor communication, delays, and reduced quality.
Everything is easier with the right tools
One of the things that makes life in the enterprise more challenging is a tool set that varies from group to group. For instance, one team may be using a tool such as Tableau for Business Intelligence, another team may be using Excel.
There are still too many cases where workgroups are using tools where data has to be exported in order for another group to work with it.
This problem is made worse by Shadow IT. A group might start using a cloud tool to manage a task, without understanding how to share that information with another workgroup.
DevOps has shown that sharing information should be as transparent as possible. That’s why everyone should use a single set of tools unless there is a good reason to do otherwise
DevOps isn’t a title or a job description
Companies have a strange tendency to create new job titles or business areas when a new way of looking at the world. The title of “Chief Digital Officer” was popular for a while.
DevOps is a process for putting agile methodologies into practice. It’s not something that a job or a department will have as its only task, and forcing DevOps awkwardly into a job description or title only makes the practice more difficult to incorporate.
Every organization can learn from startups (to a point)
One of the reasons why DevOps became popular is that people saw the way that teams worked at IT organizations like Netlix, Etsy and Amazon. People pitch in, things get done, and people don’t worry about job descriptions any more.
At the same time, DevOps should not be used to create a false sense of panic in the workplace. Done right, the flexibility that DevOps offers should happen within an automated, controlled framework. DevOps, properly defined, is the ability to make change “boring”.
So there you have them, five lessons that IT can teach the rest of the enterprise, based on DevOps methodologies. What do you think? Are there others you would include? Please share your thoughts in the comments.