Satisfying the mythical auditors is often one of the first barriers to spreading DevOps initiatives more widely inside an organization. While these process-driven barriers can be annoying and onerous, once you follow the DevOps tradition of empathetic inclusion — being all “one team” — they can not only stop slowing you down but actually help the overall quality of the product. Indeed, the very reason these audit checks were introduced in the first place was to ensure overall quality of the software and business.

There’s just as much pull for DevOps in government as there is in the private sector. While most of our focus around adoption is on how businesses can and are using DevOps and continuous delivery, supported by cloud, to create better software, many government agencies are in the same position and would benefit greatly from figuring out how to apply DevOps in their organizations. Just 13% of respondents in a recent MeriTalk/Accenture survey of 152 US Federal IT managers believed they could “develop and deploy new systems as fast as the mission requires.

Donkey teamwork What’s the point of it all? Why are we doing this? These questions pop up frequently in IT teams where the reason for doing your daily activities — like churning through tickets, whizzing up builds, or “doing the DevOps” — seems only that someone, somewhere told you to do it. If you’re in this situation — you have no idea how your activities are helping your organization make money — you should stop and find out quickly what your company’s goals and strategies are to make sure you’re not wasting time.

Think you can show DevOps ROI? Think again “What is the ROI for DevOps?” is a question that has been tossed my way frequently of late. There are numerous reasons why this is at the same time an absurd but also important question. Modeling DevOps ROI is absurd because predicting the gains and costs of a process, let alone one as new as DevOps, is difficult and dependent on all sorts of unique variables per organization.

A little while back I did an email interview with Ray Wang from iThome Weekly, in Taiwan. It’s a little piece about DevOps getting more and more into the enterprise. To read the Google, robot translation, it looks like I did some things “single-handedly,” where in fact I was one of many hands. As always, here’s the original email exchange we had: Q. You mention about software-defined business in your article, can you tell more details about what is software-defined business?

Can DevOps declare victory yet? Not quite, but soon. Figuring out when a technology inflection point happens is always hard, if not impossible, in real-time. It’s easy to point backwards and say when ERP, agile software development, the Web, business intelligence, mobile or cloud suddenly became “normal.” I think DevOps is right at the door of that point, and as some recent Gartner predictions have proffered, we could see something like a quarter of all large enterprises using DevOps next year.

Fun with market sizing I’ve spent a lot of time over the years working with cloud market-sizings, and occasioanlly on them. They’re always a bit whackadoodle and can be difficult to pull apart. But, so long as they’re consistent year of year, they do give a good intedication of momentum and a comparision to other markets. This is what you should be using emerging technology marketsizing for: just indications of which way the wind is blowing and how strong that wind is relative to other breezes.

(I originally wrote this April 2015 for FierceDevOps, a site which has made it either impossible or impossibly tedious to find these articles. Hence, it’s now here.) Quick tip: if you’re in a room full managers and executives from non-technology companies and one of them asks, “what kind of company do you think we are?”…no matter what type of company they are, the answer is always “a technology company.” That’s the trope us in the technology industry have successfully deployed into the market in recent years.

I had lunch with Israel Gat yesterday. Lobster bisque in a sourdough bread bowl, to answer your first question. We were talking about the concept of a “software defined business” (and I was complaining about how HEB needs more of that, if only to get digital Buddy Bucks). The question came up, so will companies really do this “software defined business” stuff (that’s the phrase I like for “third platform," “digital enterprise,” horseman style jabber-jargon)?

I’m just about the give a short presentation on developer relations and marketing at our HCTS conference. For those who didn’t make it, here’re the slides and the “script” I typed out. As you may recall, I wrote a large report on this topic published back in August. It’s been fun talking with people about over recent months. Lost presentation: Selling to Hoodie and the Sticker-Festooned - Building a Developer Relations Program to Win Over Developers as Paying Customers