devopsy.kinsta.cloud

Author: Justin Arbuckle

  • The Real ROI of DevOps

    The Real ROI of DevOps

    Many established enterprises are stuck in reverse. Dragged down by legacy IT systems and sclerotic software workstreams, these businesses simply cannot adapt and get up to speed in the continuously changing, high-velocity global marketplace of the 21st century. Delta Airlines’ recent technology crash, for example, dramatically illustrates how aging and inflexible IT systems can cripple a company in 2016 and lead to millions of dollars in lost revenue, as well as the dissipation of a hard-won reputation among customers.

    But an increasing number of organizations are accelerating their cultural transformations to become software-led companies that can consistently deliver new products and services as a result of automated and collaborative workflows. Alaska Airlines, which focuses relentlessly on measuring the innovation velocity of its business, is a powerful case in point.

    This is DevOps at work, and it’s how IT must operate to be the business engine of our quicksilver digital economy.

    Measuring the return on investment (ROI) from DevOps is critical to convince organizations falling behind that they can still shift course, transform and head to the IT future. Measuring DevOps ROI is also essential for companies that are embracing the industry’s forward movement, so they know if they’re on the right track and can keep turbo-charging their DevOps efforts.

    The most proactive approach for measuring DevOps ROI is to gauge the impact of products and services on customers. But, to get there, we must also assess and analyze the efficiency and effectiveness of the software development process.

    Which brings us to the one metric that’s truly relevant in business today—velocity. Without velocity, you can’t quickly recognize and remediate problems. More significantly, you’ll fall behind in the marketplace because you can’t innovate fast enough to keep pace with competitors and customer demand.

    Enter DevOps: The culture of innovating at velocity.

    Of course, that’s easy to say, difficult to measure. The real ROI of DevOps is how rapidly you can ship your new ideas to customers—and, importantly, understand if those ideas meet customer needs.

    Many may look at cost savings and headcount as their first DevOps metrics. These are important barometers but don’t measure long-term value back to the business. Two places to start for value-oriented metrics are time to delivery and quality of release.

    Measuring time to delivery shows how long it takes to get new product from code checking to production. Ideally, you want to see your time to delivery drop from months to weeks to days, and then literally to hours and minutes.

    Quality of release reveals how many bugs and errors are found in each iteration of the product. Companies should look to remedy these immediately and to develop a pre-production environment and workflow of automated testing for issues.

    It’s equally important to measure how rapidly you can get feedback from customers and incorporate that into the next development cycle. Development teams must get clear, direct and actionable feedback about whether their products are moving the business forward. For example, did the two-week sprint to build a new landing page for a bank’s website increase customers’ online banking sessions? Did it generate more cross-sell for the bank’s product portfolio? How soon can we see an uptick in customer satisfaction? This is significant information, and the question is, how fast do the developers respond to this feedback?

    The bottom line is that DevOps metrics should always connect back to the business; they need to show a measurable improvement in the customer or staff experience. This could be more quality touchpoints with customers, an improved customer satisfaction score (such as a Net Promoter Score) or increased customer activity in areas such as online billing or account management.

    “Delivering on the final product is key,” says Adam Mikeal, director of Information Technology at the College of Architecture, Texas A&M University. “Your job’s not done if the customer can’t accomplish what they want. If the customer can’t do it, it doesn’t matter if your section of the code was good. The customer experience is all that matters.” 

    Another important part of this equation is measuring your team’s efficiency on the road to velocity. To truly ship ideas at speed, and positively impact your business and its customers, you also need to understand how smoothly your teams are working—in addition to how quickly they’re delivering.

    Banks Cash In on DevOps

    Westpac Bank in New Zealand fully grasps this imperative, for example, and it enacted DevOps practices to deploy a new pricing engine for mortgages in just three months—from concept to customer. In the past, this project would have taken Westpac 18 months.

    Additionally, Westpac measures how well it’s using resources—for every $1 spent on a problem, how much is chewed up by politics and how much actually goes to solving the problem? Before adopting DevOps practices, Westpac was delivering a return of about 20 cents to 22 cents. Now, that number is just shy of 40 cents. That’s a near-2x increase in the value delivery. Westpac’s goal is 3x. In addition, Westpac has increased the amount of work its development teams accomplish by more than 40 percent over the previous year.  

    Like Westpac, Standard Bank in South Africa has boosted efficiency, thanks to a thriving DevOps culture. The cost of production at Standard, for example, has dropped from about $4,000 to $700—a 300 percent improvement.

    The goal for companies in every industry and economic sector around the world today is clear: Accelerate your business so that you create and provide greater—and faster,—value for the customer. But, to drive a robust ROI on this journey, it’s crucial that you carefully measure the true velocity of your organization, whether you’re just beginning with DevOps or you’re well along in the transformation.

    — Justin Arbuckle

  • Redefining Product Value in the Continuous Economy

    Redefining Product Value in the Continuous Economy

    The internet is now more than 20 years old. It’s older than my kids, which is a scary thought. It’s older than Kendall Jenner. It’s older than Uber, Grey’s Anatomy and the iPhone. And so now, after more than two decades of software and e-commerce, it’s high time we take stock of where consumers really are today.

    First, consumer expectations are shifting dramatically. The digital world has brought a whole host of changes in how people work, shop, interact and engage with businesses.

    Second, the notion of brand loyalty has dissolved, shattered beyond recognition.

    And, third, this utter lack and loss of loyalty puts companies at an insane disadvantage. We’re living with a “see you later” digital mindset, where it’s easy to say goodbye to something you know online for an opportunity with the newest, next-best thing.

    All of this means that companies must deliver a constant stream of software that is fluid, flexible and competitive to gain and retain customers.

    It also means that companies absolutely must understand how consumers weigh and determine product value today, because, quite clearly, buyers aren’t making product choices in the same ways anymore.

    Indeed, 20 years ago, customers chose products based on product features. Today’s modern consumers are continuously looking for new products, embracing them and then discarding them for something even more new. In fact, the willingness to switch is so strong, according to Harris Interactive, that 86 percent of consumers quit doing business with a company because of a single bad experience. And 90 percent say they would be willing to pay more for the same product if they received a more positive purchasing experience.

    This continuous process of discovery, adoption, discarding, discovery, adoption, discarding, discovery, adoption and discarding tells us—very loudly and unequivocally—that value isn’t in the actual product itself, but in our ability to continuously evolve the product.

    Shifting Consumer Expectations Require a Continuous Approach to Business

    If you can’t continuously transform the way you deploy your product, people and processes, there’s no way you can keep up with customers’ “see you later” mindset and their continuous discovering, adopting and discarding of products.

    Two decades ago, for example, you chose a car based on ideal product characteristics (make, size, etc.) and how much you could afford to spend. Your choice would live with you while you paid it off or until you could justify changing it.

    Now, software and the speed of innovation have allowed consumers the opportunity to make product choices at a greater frequency. Instead of only getting the newest features when you buy a new car every 10 years, car operating systems are updated wirelessly and provide the latest and greatest features to existing owners, without the need to buy a brand new vehicle. The car has become a software platform.

    Even the physical choice of platform (the car itself) is beginning to change. For those who wish to change their car regularly, there are many services (such as Zip Car) that allow you to rent access to a car and return it when you’re done. Or even not to drive at all, with the advent of software companies such as Uber and Lyft.

    Obviously, each product—software or otherwise—must have a set of threshold features, or else consumers won’t choose it. A car, for example, needs to be waterproof with airbags and ABS brakes. And a task app needs to allow you to add appointments and meetings to your calendar. But to be competitive today, products must now also include the ability to switch away from features and add new ones seamlessly.

    Value is Driven by Option

    This “optionality” drives product value in what has become the ‘continuous economy’ of 2016. Companies can deliver “optionality” only by eliminating barriers from their production processes.

    Companies need to adopt product development processes that are lean and high velocity to provide customers with an ongoing series of new product features and choices. That’s why you need to continuously deliver and continuously change your software.

    Keeping Pace with the Acceleration of the Continuous Economy

    If you can’t—or won’t—continuously transform innovative software products and the way you produce them, you won’t be able to compete in today’s quicksilver-fast marketplace.

    Or, to put it more broadly, software, as well as the organization and its people and processes, must be able to pivot with agility in what seems like a nanosecond to keep pace with the acceleration of the continuous economy.

    This is all very different than what we’ve experienced in the past.

    Two decades ago, an organization confronted a new competitor or change in the market, by developing and deploying new operations, organization adaptations or products to meet the challenge.

    Today, software is the primary route to market, so companies must continuously develop and deploy new software as part of an always-transforming organizational culture. If you’re unable to develop and deploy on a sustained basis in today’s continuous economy—if you only transform on a selective basis—you won’t be in business very long.

  • Learning in the Continuous Customer Economy

    Learning in the Continuous Customer Economy

    We live in a continuous customer economy. Buyers in the 21st century are continuously discovering, adopting and discarding products and services online, telling us—very loudly and unequivocally—that value isn’t perceived in the actual product itself, but rather in our ability to change a product continuously. So, it’s now about the options to change the product, not the product options themselves.

    This utter lack and loss of brand loyalty puts companies at an insane disadvantage. They’re living with a “see you later” digital mindset, where it’s easy for consumers to say goodbye to something they know online for an opportunity with the newest, next best thing.

    Take this to the next logical business level and you see why continuous transformation of your organization is so critical. If you can’t continuously transform the way you deploy your people, processes, skills and resources, so everything is aligned with the consumer’s “see you later” mindset, there’s no way you can keep up with customers, who are continuously discovering, adopting and discarding products at what seems like warp speed.

    Obviously, this means learning and acquiring new knowledge fast.

    The same old knowledge, the knowledge of the past, just doesn’t work in the world of now. But, more profoundly, to continuously transform your organization and meet customers where they are today, you need to learn how to learn.

    Yes, sure, you have to learn from customers and gain an understanding of what they want and need. But every organization does that today. It’s no longer enough to simply grasp that insight and intelligence and run with it. No, you have to continuously improve how you learn from customers in this fluid and fast-changing world.

    Why? Because, at the end of the day, continuously improving how you learn is the only way to continuously transform your organization. And, thus, continuously improving how you learn is the only competitive advantage you have.

    Continuously Improving What—and How—You Ship

    Assume, for a moment, that you’re shipping an update of 1,000 lines of software code each week.

    That’s great.

    You’re likely using continuous delivery.

    But if you can’t continuously improve how you’re learning from customers and continuously improve the teams inside your organization, you can’t ship continuously improved products. So, you need to improve what you ship and how you ship to continuously transform your organization.

    Here’s an example of how this works.

    Let’s say your software development team senses the customer wants an improved red button that’s square instead of round. Okay, development of an improved red button proceeds and is completed in one week. But, at the same time, the team creates an automated test for the red button as well as clear metrics for determining if the red button is actually the problem. Remember, the idea that the button needed changing is a hypothesis until it has been tested with customers.

    So, in addition to shipping the new square button to some customers, the team keeps some subset of customers using the round button. The customer test is then simply whether the click rate of the square and round button differs.

    Let’s imagine that the processes are not currently in place to enable the development team to receive these metrics, as many teams are kept in splendid isolation from the results of their work. Then the establishment of this relationship, perhaps with the web operations team, is also going to be required.

    This is as much a requirement of successful deployment of these features as the features themselves. The focus on the delivery of function, as well as developing internal capability, is a core principle of continuous transformation.

    The Two-Product Principle

    This is the Two-Product Principle.

    Think of the product we ship to the customer as “Product 1.”

    Meanwhile, the internal capabilities we wish to develop—our view of what we need to improve while we build—is “Product 2.”

    To recap two critical points:

    • You always ship twice—you ship an improved product externally and you ship improved capabilities internally.
    • All of our product decisions, what to build and what to deliver, are theory until the customer actually uses the deployed product and we learn from that interaction.

    If you take these two critical points to heart, then your organization will do all it can to shorten the time to deployment and action to shorten the time to gain new learning in the market. This limits the length of the costly business guessing game, the cash-draining theory time.

    Continuously Learning at High Velocity

    The way you can do this is by continuously shipping, continuously delivering, continuously learning how to improve how you learn and deliver—continuously improving your internal capabilities and continuously transforming.

    Unfortunately, many organizations that want to increase velocity go faster without improving their ability to learn at this new speed.

    The implications of this short-sightedness are profound: When you’re leaning and looking backwards, you’re not improving how you learn from your customers in real time and, instead, you’re adding to your risk going forward because you’re so out of step, and out of touch, with what the market wants and needs.

    Every Act of Design is an Act of Feedback

    Too many companies fail to obtain crucial feedback. They throw a ball up in the air and walk away before it actually lands. We see this in software development when an organization releases a new quarterly product or feature and returns four months later; sadly, this approach doesn’t allow for much effectiveness tracking, or much learning, or much improvement.

    Which is why every single action in the continuous transformation process needs to be an act of design. The act of design is an act of feedback. And, in continuous transformation, you’re continuously getting feedback—whether you’re shipping product externally to a customer or you’re making changes inside your organization.

    The bottom line is that you need to continuously test your assumptions about the world, as well as your effectiveness in responding to those assumptions, if you want to keep up with continuously changing customers in the continuous economy of the 21st century.