Talk notes: Making The Business Case (#DevOps Day)

DevOps Day, Santa Clara, CA
June 25, 2010

I'm here to participate on a panel called "DevOps Outside of Web Operations."

Making The Business Case

Jay Lyman, 451 Group (analyst covering enterprise software)
Kurt Milne, IT Process Institute
Jody Mulkey, Shopzilla (CIO, including Bizrate)
Rolf Andrew Russell, ThoughtWorks (lead DevOps engagements)

Moderator: Damon Edwards (DTO Solutions)

• What are the anti-patterns
  • Jody: "focus on what is creating the most unplanned work" (it's so cool to hear all these mentions of Visible Ops.  It's totally making my day!)
  • Rolf: "don't mention DevOps. Mention cycle time, throughput, feature delivery. Language of your audience"
  • Kurt: "business executives think in terms of outcomes. IT will think of the process."
  • Jody: "IT ops as cost center view is interesting. It's really about time to market and innovation. Those are the drivers and pain points to hit." (great point. Can't believe I didn't say this in my talk.)
• What are the business drivers? As opposed to just making pagers go off less?
  • Jody: "making freaking graphs to show how it impacts revenue.  I call it the 'rabbit feeder', because it connects the entire company to what we do: sending leads to merchants, connecting buyers and sellers. Making data democratic and tying everyone to obvious business outcomes."  (haha.)
  • Rolf: "the client global CIO needs the 'double double.' The current cycle time is too slow and the projected work load is projected to double. I'm trying to make that reality."
  • Kurt: "DevOps could be pitched as a new way to run IT. In business, it fulfills the intent of a 'low cost probe' to experiment/course-correct. As opposed to traditional model which is like building a satellite. That's a great story."
• Question: "IT people feel like they're measuring everything, while business thinks IT is bad at measuring anything. What should IT be measuring?"
  • Rolf: "So dependent on the type of organization. Velocity conference talks alot about tying downtime to lost dollars, especially in media companies. I like to focus on what work you're doing (WIP), how long are your release cycles, and how much stuff can you get out in each release."
  • Kurt: "Time to capability: business wants X, how long does it take to get it? Speed is one aspect. Variability is another expect: how long vs. promised. If you can reduce variance, that builds confidence"
  • Jody: "We're really proud of what we've built at Shopzilla, around scaffolding. It takes a lot of work to build it, but then when you track the time to market. You spend a couple of weeks, then a couple of hours. That's a remarkable improvement that's great to show. You first have to be able to measure it and get that telemetry, and then use it as a goal metric for infrastructure work that supports continuous integration. Financial industry: pay yourself first to build capabilities."
• Question: "Re: paying everyone on the performance of the entire system. It sounds good, helping business to support its goals. But it's frustrating to be in a position not to affect sales, but performance is based on it."
  • Jody: "Shared goals was around performance. It's great when you hit bonus. But when you goose-egg. Then blame-game. It's code problem, no it's infrastructure. The point is, we're in business together. It doesn't matter whose fault, because we have a common goal. You can make the goals more granular, but we've chosen not to."
  • Jay: "It could be wrong model, because it could backfire, especially if you feel powerless to engage."
    • "We're ops. We can make trains run on time. We can't over-exceed. We can't make sure the trains are full." (interesting. yet, ops should make sure that ops bottleneck is not wasted!)
    • Damon: "if we're great at our jobs, it's awesome when we can get paid and rewarded on company profitability."
• Question: Israel: "too many metrics. Focus on the outcomes: dollars. If you can't focus on dollars, then focus on outputs. Second: quality metrics of what you're doing, otherwise today's success turns into tomorrow's disaster. Third: cost: all you need to do is look at relationship between output/quality and cost. If you can do all three, then you have governance frameworks you need without 18 metrics"
• Question: "war story: just ask business what your KPI should be. I sat down as head of development with business, and asked what KPI should be. We were able to quickly get agility/TCO/availability/resourcing on new features vs. maintenance. We achieved it without a lot of psychic pain."