DevOps Insights

Just completed the excellent webinar hosted by XebiaLabs with Jez Humble to distill the findings in the 2018 State of DevOps report. 

Beyond the normal metrics of performance, I found the following points to really resonate with my views on DevOps and the manner in which teams deliver software:

Understanding the J-Curve of Transformation

Teams are quick to begin transformations by simply automating their current processes and approaches, without really addressing the underlying constraints and technical debt. This results in progress being blocked, delivery slowing down, additional manual controls and further slowing work. 

Only through relentless, measured and planned improvement does the productivity jump. 

Outsourcing whole functions

Often seen as a quick way to expand capabilities which may be beneficial in the short term, the functional division severely impact agility and create barriers to high performance. It results in bigger batches, longer lead times, and with a significant cost of delay.

Private cloud

Although there is intrinsically no problem with private cloud, it cannot be classified as a cloud if consumers still have to wait for resources to become usable. In that case, it is simply a data center, not cloud. 

Cloud according to NITS adheres to the following principles to become truly effective:

• On-demand self-service
• Broad network access
• Resource pooling
• Rapid elasticity
• Measure service

Off the shelf products

I have often noted that the customization of purchased products is a very real risk to organizations, due to the maintenance overhead and subsequent inability to upgrade. The upgrades are often coupled with painfull and rigorous testing of customized code. It is critical for organizations to change their processes to the software, not the other way round.

The key difference is that the customization is not a competitive advantage and should be avoided.

Unfortunately, there are numerous teams that focus on just getting some software out of the door, which is usually the low performers.

I believe that the correct approach to DevOps transformation is the following:

• Firstly, establish an agreement between all parties involved, not only in development and operations.
• Secondly, instead of diving head-first into technology, do the necessary measurements and derive a strategy to guide the process.
• Thirdly, start small, protect the organization, learn and then expand.