In an aviation death spiral, a pilot is often flying in clouds. Everything feels fine (maybe a little bumpy), but the altimeter and vertical speed indicator show descent. The pilot should trust the metrics.

Unfortunately, the pilot mistakenly believes the plane is flying with level wings even though it's not. The plane is actually in a banking turn, which pushes the pilot back in their seat. Call it a false gut feel of normal gravity.

To compensate, the pilot attempts to climb by sending more power to the engines, but that just makes things worse. Revving the engines has the effect of tightening the turn, causing the plane to lose altitude at an increasing rate. Think water swirling down a drain.

At this point there are only two possibilities. If you're lucky, you might exit the base of the clouds and correctly perceive what's happening. Let's hope for that outcome. If you're not so lucky, the clouds extend all the way to the ground and that's the end of pilot, plane, and passengers.

Agile Projects

Many agile projects are flying along a lot like that. Let me explain.

In an agile project, the business gives control over to a product manager (perhaps because the business doesn't have time to deal with details or feels they can't communicate with developers). The notion is that the product manager acts like a mini-CEO, a role that includes responsibility for setting up policies. So far so good.

The product manager, however, fails to ensure the policies are fleshed out sufficiently (interpreted into practicable rules). Nonetheless, the developers rev the engines and off they go. Although it all feels quite agile, they have failed to understand the basic business constraints and guardrails relevant to the product. They've initiated their own death spiral.

Where's the instrumentation that gives the real picture? Who's reading it?

The answer is metrics. Sooner or later, the business managers will want to gauge how well the product is working in operation, so they can pull levers to adjust altitude, speed, and fuel consumption.

Who's responsible for gathering the data to supply the business managers with proper metrics? Probably data professionals. Are they likely to be able to do it? Maybe they can gather data to produce something, but what quality is that data likely to have? And how good will the metrics likely be, coming out of it? Not good at all. Why? The appropriate rules were never put into place up-front.

Now you're in an agile death spiral. What should you do? You should trust what your instrumentation is telling you. Something is fundamentally wrong.

Unfortunately, that's not what usually happens. More likely, the product manager and software developers simply rev the engines even more, just tightening the death spiral.

Why can't data professionals step in and save the day?

First of all, they may not have the standing within the organization to do so. Were they even in the party to begin with?

Second, it's probably too late. Once business software is launched without data designs to integrate business functionality and bring coherent semantics to play, such designs can be retrofitted only with great difficulty and delay. Maybe you'll emerge below the clouds and see clearly what's happening before it's too late. Frequently you won't.

Flying Right

In a nutshell, what am I telling you? Three things:

1. No product, not even a minimum viable product (MVP), should be delivered without support for proper metrics.


2. High-quality metrics require proper data design and rules.


3. These data considerations should be part of initial product conversations, not something put off until later — or never.

If you're thinking that agile somehow lets you defy the laws of gravity about data and rules, well, I'm afraid you are simply very, very wrong about that.

Acks to Vanessa Lam, Director of BRSdata, for the core insights of this piece.

# # #