Red Hat announced new capabilities and features for Red Hat OpenShift, the company's enterprise Kubernetes platform.
In this digital economy, enterprises must compete through faster software innovation. DevOps practices allow faster innovation with less risk and accelerate application delivery, but, scaling these practices in hybrid IT environments without compromising quality, security, and availability presents major challenges. Most organizations have made the decision to implement DevOps, but still struggle to scale across the enterprise. How do you know your DevOps transformation is on the right track?
Enterprise DevOps is a Journey
DevOps is not a project that you start and finish. It's a transformational journey that will forever change the way you build and deliver software. Organizations need to understand and accept that there will be many positive outcomes but also many challenges. Success does not travel in a straight line - the journey is often filled with frustrations and disappointments, which require preparation.
Often you get quick early wins followed by a slower, more frustrating, period where you are trying to solve the harder problems. Early DevOps adopters have referred to this as the "J Curve" effect. Your team's performance and attitude start to suffer as new headwinds and constraints arise. The environment is also always changing. Business objectives change, there might be organizational changes, and of course, the market is always in flux.
This is why you need to implement a culture of continuous improvement or "Kaizen" and make it a way of life at work. To do this, you must understand your current state, establish your future state, and incrementally improve until your future state becomes your current state. Then you can implement incremental improvements in small enough units to reduce dependencies and to ensure you have "line of sight" visibility to what's ahead.
Where to Start
Once you have established a culture of continuous improvement, what do you improve? How do you determine the priority of work? You first need to understand the current state of your technology value stream.
A technology value stream can be defined as the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer. A value stream is the flow of activities or processes as well as artifacts that deliver benefit to the customer. The value stream can be divided into two logical sections: "Product Design and Development" and "Product Delivery".
Most organizations start with the DevOps practice Continuous Delivery, but if you look at the entire value stream you see that lead time includes upstream processes as well. There are backlogs, constraints, and queues in product design and development that need to be optimized. In some cases, optimizing earlier in the value stream will accelerate flow and drive down cost significantly. It's important to look at the entire value stream as a system that you must optimize.
Focus on Outcomes Over Outputs
There have been many attempts to measure the performance of software teams. Most of these measurements focus on productivity. A CIO of a large healthcare company once said, "Nothing is less productive, and more demotivating, than to make something more efficient and effective that should not be done at all".
Most teams work to create a defined output, but just because you have finished making a thing does not mean that thing is going to create economic value for the company. With software, the relationship between what is built and the effect it has on the customer is not always very clear. This problem of uncertainty makes measuring your DevOps journey in terms of just outputs not an effective strategy.
If you reduce cycle time (output), how is that measured? Is it faster feedback, customer satisfaction, reduced outages? Does increased deployment frequency enable the business to bring new revenue streams online faster? Ensure you can connect the dots between the outputs your team produces and the value to the customer.
KPIs Are Your Compass
Treat KPIs as a learning tool where the goal is to develop and drive a "learning organization". The widespread practice of setting numerical targets and using simplistic metrics to judge individual and group performance undermines creativity and innovation. It puts the team's sense of safety at risk and undermines their sense of self-determination. This is something that W. Edward Deming argued against when he said, "85 percent of the reasons for failure are deficiencies in the systems and the process rather than the employee. The role of management is to change the process rather than badgering individuals to do better."
When leaders look at metrics as a learning tool, use them to find barriers to progress, and then take steps to break down these barriers, they build strong motivation and nurture creativity.
In summary, understand that DevOps is a transformational journey. You need to leverage the high points and push through the low points. Implement Kaizen – it's a new way for working, forever! Learn to manage and optimize the flow of the entire value stream and not just product delivery. Connect the dots between how you measure productivity and the value you deliver to the customer. You can't manage what you don't measure. Lastly, use KPIs as a compass to point you in the right direction and keep you on the right track.