Months to Minutes

Unlocking productivity, creativity and competitive advantage

Survival in the face of digital disruption

Enterprise organisations must embrace digital business models to remain competitive. Otherwise they risk disruption, or worse, closure.

Digital transformation demands a modern IT capability where speed and stability coexist to enable greater responsiveness. Rapid and safe innovation rooted in customer insight leads to the competitive advantage needed to thrive in the digital economy. It’s about putting the customer right at the heart of the business, and meeting their evolving needs.

DevOpsGroup is well placed to provide the capabilities that help deliver better software, faster and safer. Self-service platforms, software delivery pipelines and Agile and DevOps practices simplify, accelerate and improve governance of change and operations across the software delivery lifecycle.

By reducing software delivery performance from months to minutes, we unlock productivity, creativity and competitive advantage.

Adaptive IT™ Framework

Download Digital Transformation Done Right to find out how the AdaptiveIT™ Framework can help your organisation navigate the complexity of digital transformation.

Download Whitepaper

Speed as a competitive advantage

Moving critical business processes from “months to minutes” creates a sustainable competitive advantage and enables new business models.

When Toyota sped up its supply chain and moved to “Just-In-Time” (JIT) it freed up capital that was normally locked up in parts inventory, enabling them to invest in further manufacturing innovation such as production line roboticisation.

The Lean principles that underpin the Toyota Production System (TPS) are not just applicable to manufacturing.  By considering a systems-wide view of their organisation, concentrating on the flow of business value and optimising for effectiveness and not efficiency it is possible to use some of the same principles to revolutionise the work of the 21st-century knowledge worker.

Why are Enterprises slow?

Most organisations are struggling to get changes into production with both speed and stability. Even for those organisations that are not looking to deploy features multiple times a day, the ability to ship bug fixes or security updates should be considered a core capability.

Given how critical this capability is for an enterprise why are so many still struggling to break the cycle of large, high risk and difficult deployments? While there are many reasons organisations are struggling some are universal.

“Pushing code to production should be a business decision and not a technical constraint”

Dr Nicole Forsgren, Velocity Conference

The 'Project' mindset

The process of delivering a project, where people are assigned to the work for a set period, drives a short-term focus. Teams focus on delivering features and not paying down technical debt or building for long-term stability. Armed with a fixed scope we starve our teams of the opportunity to be creative in how they solve users needs. With fixed time and cost also part of the equation, the only variable left to flex is quality. It is any wonder that: “According to “Improving IT Project Outcomes by Systematically Managing and Hedging Risk,” a 2009 IDC report by Dana Wiklund and Joseph C. Pucciarelli, 25 percent of IT projects fail outright. Meanwhile, 20 to 25 percent don’t provide ROI and up to 50 percent require material rework.” https://ibmsystemsmag.com/Power-Systems/2/2012/7-reasons-it-projects-fail

Functionally aligned teams

Most IT organisations remain functionally aligned. That is to say that teams are made up of people with the same skill or specialism and work is moved between teams. Whilst the concept of a cross-functional team has become more common in for development teams in recent years the reality is that they rarely go far enough and are even less common outside of the remit of software development.

Functionally aligned teams require any truly valuable work (i.e. something a user sees value) has to be passed between multiple teams. Handovers like this create dependencies between teams which then need to be managed and inevitably no-one has visibility of the whole value stream. By optimising teams to focus on efficiently delivering these outputs we introduce huge delays to the delivery of anything of value.

Moving to cross-functional teams that are aligned to things our users (internal or external) reduces the time it takes to deliver value by reducing the need for many handovers. They also serve to put the people doing the work much closer to their customers providing insight and feedback to ensure they are focussed on building the right thing.

Technical Debt Quadrant - via Martin Fowler

Technical Debt

The term Technical Debt is generally used to describe the action of taking a shortcut today to deliver something quickly and paying for it later.

Technical Debt can be incurred either deliberately or unintentionally but no matter how it accumulates, like Financial Debt, it comes with interest. The longer it takes to pay off, the higher the cost of borrowing.

Many IT departments have been building up Technical Debt for decades to meet the demands of the business. Technical Debt is difficult to measure, but figures published by Gartner estimated global Technical Debt to be at around $500 billion in 2010; that’s $3.61 per line of code!*

Martin Fowler, Chief Scientist at ThoughtWorks.com categorises Technical Debt into four key areas, which he refers to as The Technical Debt Quadrant.

 

Types of technical debt

Deliberate reckless debt: This type of debt is incurred when the IT team have made a conscious but naive decision to abandon tried and tested methods, usually in the belief that it will speed their path to delivery.

Inadvertent reckless debt: This is similar to deliberate reckless debt, but it’s when the team don’t make use of a standard approach simply because they are not experienced or knowledgeable enough to know better.

Deliberate prudent debt: This is where a compromise between IT and the business has been struck to deliver something quickly. For example, this could be to enable the business to hit their quarterly targets or win competitive advantage. However, it is being done with the clear understanding that a shortcut is being taken that must be dealt with soon.

Inadvertent prudent debt: This is the least detrimental of the scenarios and is when the team learns and improves from experience. Post-delivery, the team reflects on what’s been delivered and identify areas for improvement. Arguably this is progress, not debt

What is the impact of being slow?

So what is the impact of “being slow” on an organisation? Research from DORA (now part of Google) in the annual “State of DevOps Report” shows that “elite performers” who have adopted the DevOps patterns, practices and technologies to move them from “Months to Minutes” are twice as likely to exceed their profitability, market share and productivity goals as compared to the “low performers”.

Even looking at a single factor – deployment frequency – we can show mathematically that moving to a daily cadence of deployment will increase the value delivered by 187% over a year compared to quarterly releases.

Speed also has a huge impact on innovation. If you can move quickly through what Eric Ries calls the “Build-Measure-Learn” loop you can learn what your customers want – and don’t want – sooner, reducing the waste spent on projects that don’t deliver tangible benefits and getting the product they do want to them sooner.

Being able to move quickly, safely, can also have huge benefits on the stability of your production systems, which might seem counter-intuitive to organisations that historically have seen change as a threat to the stability of their production systems. Again, the DORA research shows that organisations that adopt the DevOps methods that enable them to move quickly also gain stability benefits – 1/7th the change failure rate, and a recovery from failure (MTTR) 2604x faster than the low performers. When we look at large-scale IT failures such as TSB I’m sure that the (former) leadership of those organisations would have been much happier with 1/7th of the risk and a 2604x shorter outage…

What can you do about it?

So how can you shift your organisation from “months to minutes”? The large scale answer is to re-invent your IT department based on DevOps principles.

Our AdaptiveIT™ Framework defines the 5 pillars and 15 sectors you need to change in your organisation to build an adaptive IT capability based on DevOps.

But what are some tangible things you can do immediately while you plan your DevOps Transformation?

A great place to start is “Value Stream Mapping” (VSM), a concept taken from Lean management. Microsoft has a free value stream mapping training workshop available in Github here. They suggest mapping out the value stream of a recent deployment to production, capturing all the steps (manual or automated) back to the initial idea/feature request that started the end-to-end value stream. VSM normally identifies “low hanging fruit” that can speed up your end-to-end flow just by eliminating waste in sub-optimal processes.

The next place for immediate action is in the Technology pillar of AdaptiveIT, specifically the Platforms and Automation segments. The focus here is to start eliminating “toil” – low value, repetitive work that can be automated away, freeing up team members to focus on higher-value improvement work. A classic example of toil is the provisioning and configuration management in new IT infrastructure (aka “environments”). Tools from our Partners Terraform and Puppet can make this process fully automated, repeatable and reliable, particularly when combined with cloud platforms from AWS and Azure.

Speak to our team

Book a call here to arrange a free 2 hour AdaptiveIT Framework workshop to help kick start your DevOps transformation.