Measure software development by predictability, not just speed

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...

Share

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 realisation of value is driving more applications and infrastructure into the cloud. Software vendors are realising 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.

It's easy to operationalise what Royce is talking about, since we've all paid the cost of unpredictability.

When a project jumps the rails, the business problem that was the target of that project remains unaddressed. A frequent culprit is the software vendor that fails to deliver on its promised road map. While the salesperson usually takes the beating for slipped release dates, the source of unpredictability lies further within the organisation.

It could be that the release is ready, but the customer-facing parts of the company (sales, marketing, support, etc.) aren't yet capable of delivering it. Or, the product development team might have honestly tried to make its deadline, but software development being what it is, ran into unforseen problems.

Frequently, unpredictability is not a single event but a chain reaction. Anything that can reduce unpredictability at the beginning of the value chain creates positive results all the way to the end. And that's why, as I strongly agree with Royce, one of the chief benefits of Agile is enhanced predictability.

We've been hearing this refrain for a while. For example, in a 2009 survey, 62% of respondents said that their reason for adopting Agile was greater velocity, and 55% percent cited greater predictability.

That's not a huge difference, especially given how the familiar description of Agile stresses velocity, velocity, velocity. I suspect that, if we asked the same question today, velocity and predictability might be even closer together in the ranking of Agile's benefits.

As new methodologies or movements emerge, such as DevOps, I'd advise them to start talking and thinking about predictability. DevOps is at the point where Agile was several years ago, a great idea still coalescing into a more clearly defined methodology, a movement still gathering adherents, and a strategy still building a portfolio of success stories. And, just as Agile did in its early years, DevOps is talking way too much about velocity.

When DevOps advocates talk about speed of deployment to the exclusion of all other possible benefits, they make their campaign harder than it should be. Sure, it's great that Flickr has overcome its DevOps challenges so that it can now do 10 updates a day without breaking a sweat. Of course, not everyone is like Flickr, or wants to be, or can be. The development and operations teams responsible for applications in highly regulated industries might not be impressed by that statistic. In face, it might turn them off completely, if it seems that DevOps threatens to blow past governance and safeguards.

Actually, by "might turn them off," I mean "does turn them off," since I've already had occasion to dispel some misconceptions about DevOps among IT people. Obviously, they don't want to deploy new code more slowly than they need to, but they also don't want to join some harebrained cult of speed. DevOps does have other potential benefits, including greater predictability. Now that's a bridge between development and operations that both sides can agree is built on the right foundations.

Posted by Tom Grant

"Recommended For You"

DevOps sysadmin strategy in focus at Usenix LISA conference Together we stand: Agile, Lean & DevOps against complexity