As everyone knows, when compared to waterfall application development, Agile speeds things up, and DevOps speeds them up even more.

There’s just one little gap in what everyone knows: exactly what these things are that Agile speeds up.

When it comes to optimizing business processes and practices, speed has two very different and independent meanings — cycle time, which is the time that elapses between an average item entering the function as an input and the time it exits as an output, and throughput, which tallies how many completed items exit the function in a given unit of time.

For application development, I’m guessing most businesses care more about cycle time than throughput, but that’s just a guess. I’ve never seen any survey data to confirm it.

On the other hand, managers who want something from IT mostly ask and then gripe about is when they’ll get it. They care about cycle time and want it to be small.

So for the sake of argument, accept that the goal of supplanting waterfall development with Agile is to improve cycle time.

But as cycle time measures the time that elapses between something entering a function and exiting it, we’re back to the question of what are these things of which we speak?

Back in the days when waterfall held sway, the closest anyone came to nailing this down was the function point. Function points were (and are — the discipline still has adherents) supposed to correspond to business functionality, and so they do, in the sense of corresponding to software functionality business people use.

So we could ask the musical question, do Agile methodologies speed up the delivery of function points?

And we’d have our answer, which is the same as the answer to the question, “What’s the difference between ignorance and apathy?” which is, “I don’t know and I don’t care.”

That’s because Agile methodologies don’t deliver function points. They deliver user stories, each of which is assigned a degree-of-difficulty weighting factor, typically the aforementioned story points.

So on the subject of velocity we now find ourselves asking which delivers a user story more quickly — waterfall or Agile. But as waterfall deals in function points, not user stories, aren’t we still stuck with incomparables?

Well, yes, but not insurmountably, because a user story is, if you squint a bit and don’t worry overmuch about the details, pretty close to what in waterfall terms we’d call a requirement.

Al fin, nous arrivons! as a Parisian shopkeeper said to me many years ago as I was attempting, in my very limited French, to explain what I needed and he was attempting to make sense of my near gibberish.

At last, we’ve arrived: To compare the speed of waterfall and Agile, “all” we need to do is compare how much time elapses between the first articulation of an average requirement and its appearing in production some time later.

Interestingly enough, Agile doesn’t measure this. It measures throughput — story points delivered per week, or some similar metric. Why? Probably because throughput is what’s easy to measure never mind what matters most.

Superficially, cycle time doesn’t seem hard to measure. Except that with waterfall methodologies the early steps aren’t atomic: Business Analysts talk with a bunch of people (ConsultantSpeak: Stakeholders and subject matter experts), try to make sense of it all, and write up the result in a requirements document.

Average cycle time for this step: Total step duration (first interview through requirements publication and ratification) divided by the number of requirements described in the document, weighting each requirement by its degree of difficulty.

Agile equivalent: Time needed to rephrase someone’s requirement as a user story and add it to the backlog.

This isn’t an entirely fair comparison, though: Waterfall business analysts are expected to filter out low-value requirements. With Agile, they just sit in the backlog, never important enough to be worked on, either forever or until someone decides it’s time to clear all the dead items out of the backlog.

Which means with Agile, cycle time will have to be, shall we say, dynamically recalibrated from time to time to remove Worthless Items Never Worked On from the calculation.

Clearly, app dev cycle time measurement isn’t for the faint of heart. And we haven’t even begun to explore how to account for project failures.

Given the Standish Group’s current statistics — that Agile projects enjoy roughly three times the success rate of waterfall projects — accounting for this is an important piece of the puzzle.

News flash: business is speeding up.

Okay, maybe it isn’t news. But if it isn’t, why are so many businesses slowing down?

No, it isn’t your imagination. Read “The Hard Evidence: Business is Slowing Down,” Tom Monahan, Fortune, 1/28/2016). Among Monahan’s findings, using 2010 as a baseline:

  • IT project delivery has slowed, from 8.5 months to 10 months.
  • Open positions take longer to fill, from 42 days to 63 days.
  • Purchase decisions are taking 22% longer.

Like all statistics, these are open to alternative interpretations. IT Projects might, for example, have become bigger and more complex over the five years covered by the study.

Or maybe it’s due to Agile: Emptying a dynamically managed backlog might take more time than finishing waterfall projects that exercise tight scope management. Completion is one thing. Agile’s shorter time to first value is something else.

For hiring, with 2015’s lower unemployment rate, open positions might have become harder to fill. For purchasing … I’m sure we can come up with something if we put our minds to it.

Or not. Monahan’s data match my experience — the average business errs on the side of caution, never mind the impact on velocity and agility.

What if Amazon made decisions this way? Google?

A better question: What will you do if Amazon or Google decides to invade your markets?

This sort of invasion isn’t always apparent, either. For example, do you think the folks at Dex realized Google Maps was an invasion when it first appeared?

Truth in advertising: Neither did I, until I realized that’s where I was looking for nearby sellers of what I wanted to buy, leaving the Yellow Pages on my kitchen bookshelf.

But then, nobody was paying me to realize it, so I don’t feel all that bad about missing it.

Here’s a guarantee: If your business sells physical products, it’s at risk of invasion from competing products with embedded intelligence and connection to the Internet of Things. If you sell some form of services … see Google Maps, above.

Justifying delay until flank attacks appear by claiming a “fast follower” strategy is a losing proposition. Among the reasons: fast followers are rarely the companies that know how to be fast.

How does a business become fast? Getting rid of everything that makes it slow is a good place to begin. Start with decisions. These are things politically-driven business managers avoid like rabid weasels, by the way, so a business speed-up artist is operating in a target-rich environment.

And there’s no richer set of targets than the variety of governance and steering committees that pervade most enterprises.

Maybe you’ve avoided this infestation. But probably not. The bigger the decision, the more likely it will be governed by a committee, specifically to give decision-makers political cover should something go wrong.

Here are five straightforward steps for scaling back committee decision sclerosis:

  • Size: Committees generally make decisions by consensus. The difficulty of reaching consensus grows polynomially with the number of committee members: In round numbers a committee of ten takes three times as long to reach consensus as a committee of five.
  • Composition: Most committees are composed of representatives from different business constituencies. They’re included to protect their areas’ interests. Committees designed like this aren’t just a consequence of siloization — they’re an endorsement of it.

Populate your committees based on expertise instead.

  • Cadence: Most committees, most of the time, gravitate to a monthly meeting schedule. This make the month the standard unit of time for decision-making. Worse, it builds wait-for-the-next-meeting into the management culture.

Do something radical: Insist that all committees meet weekly instead. Don’t worry about this congesting the company. The effect can be the exact opposite: Committees that meet four times as often ought to have meetings that only last a quarter as long.

  • Culture: Make culture your new governance. Build the right decision habits into it, and culture can be your decision-making “lane markers.” Reserve formal governance committees for use as its guard rails.

Unless, that is, your company makes a habit of hiring and retaining employees and managers it can’t trust to make good decisions. If that’s the case, fix your staffing practices.

Then make culture your new governance.

  • Disband: Do you really need a committee to make this decision? Rely on individual stewards instead, requiring them to make decisions consultatively rather than by consensus or, at the other extreme, solely through their personal judgment and expertise.

There. That wasn’t so hard, was it? Sure, most members of most committees will run away screaming in terror.

But that’s a small price to pay.