My colleague, Glenn O’Donnell, and I (do I sound like the Queen?) have delivered a Forrester report called “Improving The Ops In DevOps” inspired by the long-bemoaned tension between “change-the-business” (dev) and “run-the-business” (ops) IT teams and their activities, and the need for change.
This tension inflicts a detrimental impact on the business. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Does this sound familiar? Ops people see dev people as sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints; dev sees ops as cog-turners ensuring that the IT infrastructure doesn’t break under the strain of poorly written code. Chances are that your organization is not this bad. But this exaggeration is indicative of the tension between these two IT “tribes” and their opinions of each other. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.
Getting DevOps right will address many of the issues enterprises consistently have with IT, such as applications failing to meet both functional and nonfunctional requirements, delivery delays, increased costs, and an inflexibility to change. But is DevOps enough to save I&O from extinction?
It feels as though the word "value" has appeared in more discussions about software development and delivery than in the previous two decades. We see this increased demand for immediate, tangible value across the entire range of technology producers and consumers. The dubious value of legacy applications, which have grown like kudzu, is the impetus for many painfully difficult cutting and pruning jobs within IT departments. Faster realization of value is driving more applications and infrastructure into the cloud. Software vendors are realizing that, while revenue is vital, the long-term relationship with the customer depends on the mutual value that both parties think they're getting from the relationship.
If we measure software by value, instead of cost, revenue, completeness, or other possible measures, we have to measure the software development process in a complementary way. What characteristic of software development is most likely to generate a valuable result? If your answer is "speed," think again. Predictability is a much better measure.
At the IBM Innovate conference last month, Walker Royce made a very plausible case for valuing predictability over velocity. Here's his keynote address, which is definitely worth watching.