All organizations strive for high-performing IT departments, it can be said the health of an organization could be gauged by looking at their IT department alone. We see constant change programs devised and rolled out to tackle inefficiency with results that are often disappointing which need more changes! Unless changes are made based on relevant hard data this cycle will be difficult to break. Nicole Forsgren is a Chief Scientist who analyses data to prove certain hypothesis – it’s this type of research that should get our attention.
Nicole explains this research in her What I Learned from Four Years of Science-ing the Crap out of DevOps talk. The survey questions were created based on Westrum typology which looks at organisational cultures and has a close mapping technology. The survey data reveals things about Continuous Delivery, Management, and Culture, but it’s CD I’m interested in here.
A lot is at stake with IT performance…
“Firms with high-performing IT organizations were twice as likely to exceed their profitability, market share and productivity goals.”
Also Nicole shares, IT Performance is predictive of organizational performance. If the organization struggles to get releases out there will obviously be an impact on other goals. Embracing Continuous Delivery can be a game changer for performance but, as the data shows, this needs to be done properly.
All the factors need to be in place before the real benefit of IT performance is gained. Doing trunk-based development and having all your code in version control is good and you will see benefits but without quick automated tests with extensive coverage, you will fall short of higher throughput and stability goals.
Continuous Delivery is not easy to get right which is why it needs to be investigated and planned with the suitable expectations. So, what should be the expectations? Obviously increased IT performance is the larger goal, but there are a number of factors that feed into this.
Lead time for changes – create a value stream mapping chart to measure the time it takes to get a code change into production. Changes made for CD should improve this, especially automated deployments, but this could also show other places that cause delays/blocks.
Release frequency – are you able to release into production more frequently? An easy one to measure.
Time to restore service – how long does it take to recover from a failure? How quickly can you identify there is a problem? Is your monitoring effective enough? Can you rollback to a previous version of a component quickly?
Change fail rate – are bugs/issues being found in the pipeline before they get released to production? Are you reducing the number of issues that get into production?
These are all closely linked, as Nicole explains, they all move together. As improvements are made to automate pipelines, for instance, this will benefit each measurement in some way. It is a continuous improvement cycle, once you improve one area it will highlight another and so on. The hope is to start an improvement culture, they can take time to get going but when people see the benefits and believe in the vision they become champions for the process.
No one wants to be constantly firefighting deployment issues. I’ve witnessed it, it’s not good and hits morale hard. Pursuing CD not only gives performance gains in IT but also in the teams. Observing the efficiency of automated builds and tests, and less deployment pain increases excitement! The teams end up working better together and are more optimistic that improves morale levels.
As companies are deploying more frequently now than before the IT organizations need to continuously improve. The competitive edge is at stake! As CD transformation initiatives are planned we should never forget the hard data. We can get lost in the pursuit of a goal that we forget the fundamentals. The data shows the factors that need to be in place, these cannot be sidelined or deemed insignificant. Continuous Delivery, as well as management and organization culture, drive IT performance, just as the data shows. Let’s allow the scientific data to guide our process changes over other assumptions.