Tag: devop measurements

  • Beware False DevOps Metrics

    Beware False DevOps Metrics

    Metrics are important for any manager seeking to continuously improve critical work processes and the resulting work-product.

    That’s why DevOps leaders need DevOps metrics. With the right ones, those leaders can guide their organization’s adoption of DevOps best practices—progressively optimizing staff productivity, business agility and customer experience.

    But, what are the right metrics for DevOps success? And, what are the wrong ones?

    These next few blogs will offer field-proven guidance on DevOps metrics. Much of the material in these upcoming blogs can be found in the book, “DevOps for Digital Leaders,” which I co-wrote with Kieran Taylor and Peter Waterhouse. And I’d love for you to comment below so we can all share lessons learned about how to effectively measure DevOps maturity—and, just as important, how not to measure it.

    Change Your Metrics, Change Your Culture

    DevOps leaders tend to struggle with metrics because DevOps entails changes that are both operational and cultural—and span different teams or functional areas, including development, test and operations. So inexperience may cause leaders to adopt new ones that are counterproductive—or, as is often the case, continue using traditional ones that don’t align well with the cross-functional nature of DevOps objectives.

    Three pitfalls have proven to be especially common in the transition to DevOps:

    • Vanity metrics. These appeal to the “hero” mentality of individual coders, rather than the collaborative process goals of cross-disciplinary DevOps and continuous delivery teams. They include total lines of code produced and total function points created. If incentives are linked to these metrics, developers can focus too much on volume at the expense of other essential activities such as refactoring and design simplification.
    • Those that promote interteam conflicts. Metrics that pit teams against each other undermine critical DevOps behaviors—such as code-sharing, mentoring and constructive peer reviews. So, while gamification may be useful in other areas of the business, Agile leaderboards that rank teams based on the prevention of extraneous deployments and changes can actually work against DevOps culture.
    • Traditional metrics. Many DevOps leaders persist in utilizing traditional/incumbent ones such as mean time between failures (MTBF) and the ratio of full-time equivalents (FTEs) to servers. But while these may have been useful in the past, they can work at cross-purposes with DevOps transformation. After all, with faster delivery of services, some failure is to be expected. And as IT improves its responsiveness to the business, it must look past costs alone to total economic impact.

    What Makes a DevOps Metric Useful?

    While future blogs will propose some specific metrics that DevOps leaders should find useful in their efforts to bring about cultural transformation, here are a few general guidelines to consider:

    They must be obtainable.

    A metric won’t do you any good if you can’t actually capture it. So you need DevOps tools that help you capture the metrics you need. You may also have to measure some attributes indirectly. For example, rather than measuring employee morale directly, it may make sense to use staff retention rates—which you can readily capture—as your performance indicator.

    They must be reviewable.

    Any metric you choose to employ as part of your DevOps leadership effort must be able to stand up to rigorous scrutiny in a business context. Your credibility as a leader depends on your ability to communicate its relevance to the stated values and mission of the team.

    They must be incorruptible.

    It’s never a good idea to promote metrics that can be influenced by individual team members or any group as a whole. You should also be on guard against metrics remaining entrenched—despite the fact that they may inhibit change—because bonuses are linked to SLAs associated with them.

    Metrics must be actionable.

    Useful metrics must enable DevOps leaders to make better decisions about workflows, incentives, policies, training, tools or some other “lever” of transformation. Not every such decision will be a game-changing one—but incremental gains in knowledge lead to incremental improvements in process, which collectively do change the game.

    In my next blog, I’ll discuss the metrics that DevOps leaders are using today to successfully drive the digital transformation of their businesses. In the meantime, if this is a topic that interests you, be sure to request a free copy of my book, “DevOps for Digital Leaders.”

    — Aruna Ravichandran

  • 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

  • Funding Failure by Intent

    Funding Failure by Intent

    Why is it that when we purchase a lotto ticket, every part of our brain tells us we won’t win, yet some portion of it is able to inspire hope where there shouldn’t be any? Could it be the same part of our brain that inspires hope in the face of nearly certain failure has been nurtured by the software development projects we have been exposed to over the years?

    It would appear that the ability to prognosticate has been the foundation of nearly every waterfall project that had a timeline of three years or longer. It is this myth of “certainty” that agile methods are designed to eliminate. In our new approach, we simply break down and digest the scope of work until it is small enough for our risk tolerance, and easy enough to implement in our abbreviated time horizons. We try, we evaluate and we try again.

    But no matter how low we believe the risk to be (and generally the reward we expect from it), risk does remain. And now instead of a three-year project plan well-equipped with milestones, corrective actions and projected costs, agile gives us only the current sprint, based loosely on our historical velocity and a literal “addiction” to continue this process going forward without any real regard for a predictable end-point or total project cost. Continuous delivery infers continuous innovation (emphasis on the word “continuous”). And if done right, why would a business ever choose to end innovation that works?

    Imagine the analogy of Mozart sitting down to compose a quick advertising ditty that your company could play as background music on its website. Mozart begins with a few bars, and notices a theme that is worthy of far more exploration … so he does. He continues exploring this until an epic symphony emerges. This was not the plan and does not meet the original requirements. This could be considered scope-creep in the waterfall world, and thus a failure, as no one stares blankly at a website for the 30 minutes it takes to hear an entire Mozart epic … or do they?

    Every audience grasps the concept of background music we pay little attention to but subconsciously understand it improves our experience. But nearly every audience also realizes the beauty of a Mozart epic, and would gladly buy CDs, MP3s or concert tickets to hear one of those over and over again, relishing every note. The question this analogy begs is simply this: Would Mozart’s employer—more specifically, his development manager—have been free to fund this “failure” or not? What happens when a project changes direction significantly away from the first vision we had of it? Does DevOps enable us to pursue this radical change in direction, or are our legacy financial systems and methods binding us to a waterfall delivery and reporting structure—and, in so doing, limiting what we will ever be able to accomplish through radical innovation?

    The beauty of agile construction and DevOps delivery is that we may deliver “unexpected” innovation. Nearly every time a user “sees” what we have delivered to meet their need, they immediately think of “x” more things we could do to make it even better. This may result in taking a project in a radically different direction within the confines of a single financial year. To further enable our ability to do this, our legacy financial funding and reporting systems must evolve to match this demand. Our new risk profile must include the ability to fund failure on purpose, understanding that failure itself is part of the maturation process of innovation, not the death-knell of the company.

    A more honest approach to funding agile/DevOps efforts would be to determine the annual investment the organization wants to make in certain capabilities, and innovations it expects to see in each thematic area. Overarching themes are funded on an annualized basis; however, great autonomy is granted and expected within the themes to ensure delivery is achieved. Pushing financial responsibility down in the organization to as low a level as possible has the effect of pairing the team leaders with the costs of what they do. Spending too much time on delivery of any given feature or function may cause the team to re-evaluate the approach and propose a better solution. This is more unlikely when budget responsibility is managed several levels above the team doing the work—in that instance, the budget resembles more of an infinite resource they need not be concerned with, until it is too late.

    When proponents of DevOps claim it is changing the culture of a company, they are not limiting this view only to IT. Tertiary services in a company, such as the supporting financial budgeting systems, hiring systems and even contract management systems, may require significant change to match the pace of delivery and innovation DevOps delivers. As an enterprise looks to implement DevOps, it should look broadly at what else may be required to fully enable the pace of innovation it is capable of.

    To continue the conversation, feel free to contact me.

  • In DevOps, Business and Operations Metrics Both Matter

    In DevOps, Business and Operations Metrics Both Matter

    Proponents of adopting a complete DevOps approach to application delivery and deployment often note that DevOps includes a change in culture. And not just a change in lateral change in culture—improvements in the way teams across (and within) silos communicate and collaborate—but also horizontal change that permeates every aspect of the organization, from the top down.

    That change means more than sharing information, it means sharing the right information. And in the case of convincing business stakeholders and even executive leadership that DevOps is the right approach to succeeding in this fast-paced, API and app economy, that means communicating its impact as it relates to their primary concerns.

    trickle-up-devops soad16Surveys such as Puppet Labs’ State of DevOps has done an excellent job of providing insight into the operational impact of DevOps. We’ve seen improved mean time to recovery (MTTR) and shorter lead times required. If you’re familiar with these measurements, then said improvements no doubt provide an excellent reason to at least begin adopting DevOps.

    But what about executive and business leadership? They’re likely no more impressed by an improved MTTR than you are by a 10 percent reduction in average handle time or improved call resolution rate. To get buy-in from business and executive IT stakeholders, we have to provide proof of positive impact in their metrics. CA Technologies illustrated this divide in its DevOps Jigsaw survey, in which 86 percent of respondents consider “business stakeholder education” important, and yet only 33 percent have completed.

    Communicating the benefits of DevOps in a meaningful way to non-technical people is an important part of that educational process. That could mean translating MTTR to dollars saved by reducing downtime, or improvements in app performance (response times) translated into productivity increases or reduced abandonment rates. That means focusing as much on measurement after delivery as it does measurement of delivery. It means crossing the chasm (and I know it’s a big chasm, trust me) between marketing and IT to understand abandonment and conversion rates and how they relate to performance and availability. It means making connections between IT metrics and business impacts and being able to connect the two and educate business leaders on how DevOps will or can make a difference.

    It means, at a minimum, showing a direct and positive correlation between DevOps and a more agile IT environment and the metrics that consume the lives (and dashboards) of executives and business stakeholders. You don’t have to necessarily do the math for them (though that would be nice if you could), but being able to connect the dots between operational and business metrics should be considered minimum viable effort. And it’s a good place to start the process of affecting the cultural transformation required to sustain the benefits of a DevOps approach.

  • DevOps Dirty Little Secrets

    DevOps Dirty Little Secrets

    By all outward appearances DevOps is gaining real velocity within IT shops worldwide, Duh tell you something you don’t know. I have read much on this topic as I am sure you have, but I never seem to read much with hard data results, other than we are doing great with some very broad  metrics. What are the hard numbers as compared to the legacy IT shop?  So my search begins; where in the world are devops metrics in Fortune 500/Enterprise organizations?

    What got me thinking about this were a couple of recent AppDynamics blogs “Measuring your devops success” and   “Quantifying the value of devops”.  Both blogs do an excellent job at breaking down DevOps to the implementation level. Hard data creates metrics that set a baseline with the legacy system that is the critical measurement component, without a baseline there is nothing to compare or measure against. This approach creates a meaningful way to measure the success of executing a DevOps strategy within an IT shop.  The blogs also point other factors not quite as easy to measure, particularly human elements. Many others have written on measuring DevOps, you need to adopt the approach that makes sense for you and your organization.

    At that point I figured it was time to visit Puppet Labs, when you think DevOps Puppet Labs and their survey’s comes to mind. I utilized the 2013 State of DevOps Report; the 2014 report is not available yet. I believe that in order for any new philosophy to be adopted as a true standardized practice, the C-level in Fortune 500 organizations need to embrace it. In my long experience, typically the first sign of acceptance in traditional Fortune 500 organizations is when the financial vertical embraces it.  As an example, Wall Street traders will pay good money to save two milliseconds on a trade.

    The Puppet Labs report numbers demonstrate real velocity in the adoption of DevOps as an accepted business practice. The first takeaways I had from the report were that organizations ship code 30x times faster with 50% fewer failures. The numbers paint a glowing picture for DevOps. But looking beyond the glowing numbers, I see something else. DevOps is at a critical fork in the road and needs to cross the chasm before it loses its luster and becomes just another application development tool, as opposed to a practice.

    Only 17% of the respondents were Managers or C-level, with only 22% of respondent companies having 10,000 employees or more.  It is essential to look at individual Fortune 500 companies IT shops and measure them with hard data before and after the implementation of DevOps.  I would love to read some in depth case studies of the Fortune 500 with hard numbers and metrics; I did not find anything with the legacy baseline data. A huge benefit of DevOps to the Fortune 500 is it will enable them to fail fast as opposed to continuing an implementation that will inevitably fail anyway and consume a huge amount resource in the process. Anyone who has worked for a Fortune company I am sure has witnessed this.

    In truly understanding what DevOps is and is not, certain questions need real answers; Are Enterprise/Fortune 500 companies really doing the same old thing and just need to write better code utilizing some new application development tools, does that make it DevOps or just continuous improvement? Will some IT execs change the organizations title from sysadmin to Devops Admin to protect their silo and make them seem kinder gentler Ops? Are the DevOps tools available today ready for prime time in the Fortune 500 IT environment? Is Devops about technology and metrics or really about culture? We can speculate, but time will tell us the real answers. I am looking for good metrics on what does DevOps do to a Fortune 500 company Not some so called Unicorn that was born with a DevOps spoon in its mouth, but a good old fashioned Wall Street firm who adopts DevOps. Until then call me the DevOps skeptic.

    If you would like say something; email parker@devops.com and don’t forget to comment here.