'We already do that, we’re just OG* enough to not call it DevOps'

When your finance guy is like, c'mon...

Cool guy with shades on. Photo by shutterstock

At this point in the innovation curve for something like DevOps it’s fashionable to start asking “Where's the Return On Investment?”

Answering that question is always tedious. For the hopeful, starry-eyed practitioner, spitting up the ROI figures is akin to the irrelevant water-carrying and wood-chopping trials imposed by a kung-fu master. Except instead of cold rice with snow-white topknots, it’s dreary spreadsheets with pearly toothed finance flacks.

If you’re lucky, your organisation will be dead-set on taking on that “survival is not mandatory” mind-set, ignoring questions like ROI. But, most everyone else has to fill cell range C45:G60 with all that water and wood.

First, go drink

Your first inclination will be to crack jokes about flossing and Blockbuster. “What’s the ROI on flossing, you ask? Well, do you like having teeth?” You’ll follow up with erudite commentary on all the Blockbusters out there who were rearranging the deckchairs on the RMS ROI as it descended into the icy depths.

This is not helpful. Find yourself some colleagues, get a few pints, and have a laugh play-acting this out. Once you’re back from second breakfast, try some more helpful approaches.

What is this “ROI” you speak of?

When finance and management interrogators ask about “ROI” and “business cases,” I find that they’re mostly asking three questions:

  1. Will this fit in the budget?
  2. Are we paying too much?
  3. Will this change actually work?

Sometimes they’re asking all three questions, sometimes just the first two. Sometimes they’re using you to practise their Cenobite impersonation with implements scrounged up from about the cube-farm. More likely, they’re asking at least one of these three questions.

Will this fit in the budget?

Of all the ROI questions, this is the easiest to answer. If you know the budget, you just need to figure out how you’ll meet or come under it. When looking at DevOps, this means you’ll first establish the baseline cost of following the “old” way, like staff’s pay, tooling, and the expected cost of fixing screw-ups. Then model how DevOps concepts such as "two pizza teams" and "reducing release cycles" will lower your costs.

If your teams spend less time communicating with other teams, there’s less time in meetings, clicking up presentations, and coordinating what to do after the meetings. Communication is more effective and efficient if you’re all on one, small team.

You want your product teams spending 90 per cent plus of their time on product, but they’re probably spending more like 20 to 30 per cent. Fewer, silo’ed teams will result in fewer errors caused by hand-offs between teams. Meanwhile, DevOps’ smaller batches of code and weekly release cycles will increase the resilience of your applications (faster time to recover) and the productivity of your software (as you iteratively release, observe the use of, and improve your software’s usability).

Cost-cutting? It's possible...

If you want to pull out the trimmers, also look at staff reductions. Several large organisations I’ve spoken with have drastically reduced their operations and QA staff after modernising their software development and delivery approaches.

You can dress this up by saying those “resources” will be re-allocated to “more high value activities,” but if you’re slotting in a huge amount of automation and pushing routine testing to the product team you may find yourself with a sizable thumb-twiddlers' budget.

When fitting into an assigned budget, your ROI answer is on the subject of “doing more with less.”

Are you paying too much?

We all like a good deal, and can agree that getting fleeced is a poor outcome. You’d like to know you’re not overpaying. With a process change like DevOps, the tough question is “paying for what?” There are costs associated with modernising your software approach like buying new tools and hiring consultants (or “coaches”) to help change your organisation.

When it comes to tools - which usually means software, SaaSifed or otherwise - you’re talking procurement negotiating and producing a proof of concept. There’ll be alternatives for your development toolchain, for where you run your software (public cloud or on-premises), fees for middleware you use, and support and maintenance costs.

There are no easy answers, just models and competitor matrixes to work over. The raw tools here are standard technical tests to prove out the alternatives and the track records of other users, good and bad.

You might also ask if an outsourcer can do it more cheaply than your organization. Answering this question requires more of an assessment of the your organisation’s willingness to change, and not only the staff, but management as well. The change is not easy; executives I’ve spoken with estimate that anywhere from 30 to 70 per cent of people “won’t make it”.

Will this actually work?

You’ve crafted up numbers for a business case, horse-traded your way to a good deal, and ensured that your people can pull it off. And seemingly, true to Larman’s Law, people keep insisting on more justification.

Other than table-flipping your way into a new job, I’ve found three useful tactics here:

  1. Other people’s success, first hand - doubt about success tends to revolve more around “we already do that, we’re just OG enough to not call it DevOps” and “we’re not good enough.” Occasionally (and always in comments from you, dear El Reg readers) there’s the cry of “it’s an Augean Stables’ worth of offal.” While there’s no end of success stories when it comes to DevOps, rather than sending an email full of links that’ll never be read, arrange actual meetings between your doubters and outsiders who’ve been successful with DevOps.
  2. Hide - creating a “skunk works” is a tried and true method to bootstrap a new process, ignoring the haters in dry-clean creased dark denim. If you fail, there’s massive risk. But if you succeed, you’ve demonstrated that the new way is effective and to be trusted. Someone might even thank you.
  3. Start small - do a series of small projects to prove out the new process. These can’t be “science projects” and instead need to be something that’s small, yet important to your organization. In doing these little projects, you’re building up credibility for the new process and also learning how to do it.

What’s the ROI on ROI?

Finally, you should assess your own return on your time spent on cleaning out the stables. Will it be worth your time, personally and professionally, go to all these meetings and hustle up justifications for all the naysayers? Ideally, the answer is yes, of course, that’s my job even! But carefully look at your situation, the political climate in the office, your chance of success, and the pay off you’ll get. If you’re on the wrong side of that Deming quote, it’s best to enjoy the deck-top orchestra while you find elbow your way into a life-boat. ®

* Original Gangsta. Man, why does the CFO have to talk like that?

Sponsored: The Joy and Pain of Buying IT - Have Your Say


Biting the hand that feeds IT © 1998–2017