One of the primary goal of DevOps is the ability of an organization to bring an idea to market faster. But how fast is fast enough? Do they need to improve time to market by 10%, 20%, 50%..90%? Do all applications need to ultimately be released within hours? In order to compete do we all have to be the Etsy or the Netflix’s of the world?
Unfortunately there is no simple answer. Optimal application delivery speed (aka time to market) varies drastically across industries, markets, organizations, and even within an organization’s own application portfolio. Remember “two speed IT”.
In other words there is no “one fit for all” when it comes to speed. Yet defining your optimal speed – goal – is critical to your DevOps success. Without it, its almost impossible to provide a vision, measure progress, and fundamentally change the way you delivery software. For example, IT is very good at measuring costs. In fact they measure costs from every way to Sunday. As a result, cost takeout becomes the fundamental value metric for service delivery – “how low can you go to delivery the same service”. Similarly, if speed and agility is the goal then we must start with measuring our current velocity and then setting (realistic) goals for the future state.
The Definition of Speed
Before we go about trying to determine an applications optimal speed it is important that we first agree on the definition of speed. We like to think that speed is a fairly simple concept, but its amazing how mis understood it is.
Many organizations new to DevOps simply equate speed to release cycles. They believe that if they increase the number of cycles then they are improving their time to market. Unfortunately it does not work that way. Improvement in release frequency is a natural outcome of going faster (as we will see in the example below) but not the driver of speed.
True cycle time is measured from end to end – when the idea enters the development funnel to the time it is released to the end user. In other words it’s the Work In Progress (WIP) time for that particular piece of code and any improvement in speed is the reduction of this WIP time.
For example, a healthcare client recently shared with us that it takes them just 20 days to develop a medium size enhancement. For them, their cycle time was 20 days per enhancement. But on further inspection we found that it takes 20 days to determine requirements, 10 days for setting up environments (while using cloud), another 15 days for testing, 10 days for moving code from one environment to another, and a whopping 15 days for approvals. When we added all that up, we discovered that their true time to market (speed) for that enhancement was just over 90 days.
Once we were able to define speed in tsurehis context, it opened up an entire new world of dialogue within the organization. Now instead of optimizing 20 days, they have another 70 days of activities to pick on. Even if they were to shave just a mere 1/3 of the 70 days (cue automation with some simple processes engineering) they would be able to improve their time to market to 65 days. And as an added bonus, the team instead of just delivering 4 enhancements per year (90 days x 4) they can now deliver 5 enhancements (65 days x 5) much faster.
By defining speed in such broad terms, it not only gives IT teams a glimpse at the big picture but also visibility into areas of wastes, opportunities for true end to end improvement, and a platform for collaboration.
Now that we have our definition right, lets get on to answering the million dollar question,
How fast should I be (what is my optimal speed)?
The simple answer is fast enough to delight the customer and beat the competition. But to determine at what point you are able to achieve this goal is a bit more complicated.
Most organizations try to answer this question by looking inward. They perform a detailed value stream mapping exercise, determine cycle time for each activity, identify bottlenecks, and then triangulate how fast they can go if they eliminate some of the key bottleneck.
Unfortunately, speed is not a function of how fast can you go (IT view) but a function of potential benefits (business / market view). More precisely, your optimal speed is directly depended on the additional benefits the business will enjoy (additional revenue, higher customer acquisition, better customer retention etc.) as a result of greater velocity.
To help understand this relationship between benefit and speed better, ask yourself the following three questions,
- If we were to reduce our cycle time (from idea to production) by 10%, 20%, 30%, 40% etc., what is the incremental benefit to the business
- Can we quantify this benefit?
- How sensitive is this benefit to speed? Are they inversely proportionate, is there a benefit / speed plateau?
By doing so, there is a good chance that most applications will fall within one of the three scenarios.
- Benefit and Speed Are Directly Proportional
For some businesses, speed is king. The faster you can deliver a product the greater the incremental benefit. Consumer facing apps (Facebook, Linked In etc.) focused on revenue generation / customer acquisition work well in this scenario. For these applications, there is essentially no speed limit. The rule of thumb is step on the gas and get out of my way.
Optimal Speed: No speed limit, step on the gas
- Benefit Improves But Only To A Certain Point
Most SaaS applications (SFDC, Workday etc.) fall within this category. At a certain point the incremental benefit diminishes as speed increases. In other words, users like the regular updates and upgrades but to a certain point. Change too much too fast and you end up delivering little additional value. In this case, there is an optimal speed and any investment in speed after that is a waste of money.
- Benefit and Speed Are Adversely / Not Related
This is the opposite of A, where speed has an adverse / no impact on benefit. Here users prize stability and status quo over anything else. Changes are welcomed but need to be few and far between. Many on-prem legacy applications fall into this category. Imagine if your ERP provider published a new update (mini upgrade) every day. It would wreak havoc to the organization. If this happened to your general ledger system, you would never be able to close your books. If you find yourself in this category it is best to go pick a different application.
The graphs are a great representation of the various options but there are two caveats that every organization should be aware of, cost and competition.
Cost: The speed limit makes little sense if the cost of getting to that speed is greater than the incremental benefit potential. After all, like any other IT project ROI is key in deciding if DevOps is worth investing in.
Competition: Ultimately…competition holds the trump card. No matter what your charts say and / or your cost model shows, if the competition is going faster…you have no choice but to match that speed or better yet, beat that speed. Which is why we urge many of our clients to invest into DevOps early, set the benchmark, and build a competitive advantage.
About the Author/Mustafa Kapadia
Mustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.
Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.