From common maladies to rare pathologies, some fascinating clinical tales emerge when organizations look to achieve DevOps at scale. As I have analyzed and correlated flow metrics to business results, I have found the common, the problematic, and the bizarre.
In his book, The Man Who Mistook His Wife for a Hat, Oliver Sacks recounts case histories of his patients—those lost in the bizarre world of neurological disorders—among whom are those no longer able to recognize common objects and the people they know.
Many executives who have never coded exhibit a similar inability to see technical debt for what it is, despite its severe impact on the health of the business. Technical debt—the cost incurred when development teams expedite the delivery of a piece of functionality or a project that later needs to be reworked—is often the kiss of death of any digital transformation.
CIOs estimate that technical debt amounts to 20% to 40% of the value of their entire technology estate before depreciation, and it's only getting worse following the pandemic. Technical debt not only slows down time to market and innovation velocity; it's estimated to cost companies up to $85 billion annually as well.
Companies need to make tech debt visible for executives who can't see it directly. Value-stream metrics, also known as flow metrics, measure software delivery performance against business results.
By holistically considering this data, as well as the human and organizational aspects of the work, you can identify bottlenecks in the value stream, or in areas where problems have been simply misdiagnosed, and correct course.
Measuring flow opens the door to providing clinical diagnoses of digital transformation problems: no finger pointing needed.
Why technical debt can be a death spiral
When software delivery goes from a crawl to a standstill, the business symptoms include:
- Unacceptably low time to market
- Decreasing team happiness
- Declining quality
- Slowing of new-hire onboarding
- Increasing cost of delay
One financial services company I worked with had deemed its agile rollout a success, and it had a mature CI/CD pipeline. However, feature delivery was painfully slow, and business leaders were concerned about the lack of timely innovation.
A look at their flow metrics revealed where the problems truly were:
- Feature flow time was increasing.
- Feature flow velocity was decreasing.
- Flow distribution of technical debt was invisible.
- Flow distribution of defects was increasing.
These metrics forced a conversation about a bottleneck in core back-end services. In the end, everyone—technology and business leaders alike—agreed that if they didn't "slay the monolith," they would never be able to compete.
Neglected work in progress: The most common value-stream health problem
A healthcare company was rolling out SAFe, and the technology team could not keep up with the needs of the business. Although the team was championing the reduction of tech debt, the company's "patient chart" told a different story: Flow load was increasing, and flow efficiency was decreasing.
In truth, technical debt was not the problem; the company's flow load was much higher than predicted, based on its flow velocity and flow time (detected by the application of queuing theory). This is the most commonly misdiagnosed problem: It was not technical debt, but simply that more work was coming in than was being completed, causing instability in the value-stream system.
A tale of obscure workflow
Another organization made the shift from project to product and had a mature agile deployment, but those measures had not translated into satisfactory business results. Why? Because the true bottleneck was hidden. The flow load was artificially high, while business results were not improving.
Conversation and collaboration using the shared language of the metrics revealed that, in this case, "done" didn't necessarily mean "implemented," which in turn created a measurement black hole.
Without the proper metrics, the organization would have optimized around silos and not solved the true problem affecting the flow of business value. Essentially it had optimized the middle of the value stream, which hid the fact that the bottlenecks lurked elsewhere.
Eventually the organization was able to shift to a customer focus and identify handoffs and manual process constraints to dramatically reduce flow time and increase customer satisfaction to meet that business goal.
Change must come from the outside in
These stories illustrate that you can't change a system from within. As W. Edwards Deming noted, you must get outside the system and measure from the outside in, to see across people, tools, and processes.
Technology leaders can help their business counterparts break free of their blind spot "disorders" (like talking about cycle time). With the help of flow metrics, tech teams can leverage what they know (flow time) and relate that to what the business knows (time to market) to treat the real issues impeding their business agility.
If you want to know more, register for the DevOps Enterprise Summit Virtual — Europe, which runs May 18-20, 2021, and attend my session on Wednesday, May 19, at 7:05 am EST.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
