Random Thoughts on Business Models and Cost of Delay

I cover Cost of Delay and CD3 (Cost of Delay Divided by Duration) in my Essential Agile Product Leadership course. (CD3 being similar to WSJF). This part of the course is derived from from the work of Joshua J. Arnold, with Mike Cohn's business modeling "dimensions" (may be my term) as a starting point in the thinking process.

Mike Cohn's business modeling stuff is somewhat software-oriented, so it may be a good place to start for Agile (or Agile-hopeful) organizations.

I think I may have divided Mike Cohn's business modeling stuff into "dimensions" so that I could better explain them, but I'm no longer certain who did what.  I also added a little to it. It's safe to say this is strongly based on the work of Mike Cohn.

Purpose

The dimension of Purpose is the selection of why we are building what we are building:

• New: New customers, new markets, improved cash flow.
• Upsell: Upgrades and enhancements for existing customers.
• Retention: Avoids losing customers or cash flow.
• Efficiency: Saves money while enhancing growth.
• Reputation: Improves our standing in the market, e.g., feature-parity, repairing defects. (I may have added this one...)

Necessity

The dimension of Necessity is a rough model of how we see this feature improving value:

• Mandatory: A Minimal Marketable Feature (MMF).
• Linear: Adds nominal value to the MMFs.
• Exciter: Will create enthusiasm and joy in the user community.

Process

Lastly, the dimension of Process, which may have been added by me as a catch-all for remaining things from Mike's set, or so I could add topics that I think folks should consider when exploring their Cost-of-Delay and Duration estimates:

• Cycle Time: Time it takes between receiving a request and delivery (or use) of the feature.
• Waste: Things we do that may not provide value. E.g. re-work due to defects.
• Risk: Things we may or may not be doing that will result in a loss of value.
• Operational expenses: Keeping the lights on, and many others.
• Cost of Delay: What it obviously costs to wait, i.e. lost opportunity. (See below.)
• Complexity: Keeping it smartly simple.

Cost of Delay

The dimensions give leaders some starting points to think about as they come up with their cost-of-delay estimates, and helps them identify other folks to talk to--and what to ask them--in order to uncover other time and hidden cost estimates. "CD3 is cross-functional!" I say. At least as cross-functional as the best DevOps-embracing Scrum team.

I strongly emphasize that:

1. All estimates must be provided by the people doing that part of the work, and that know the most about that estimate based on prior experience.
2. Estimates must come with the mutual trust and understanding that an estimate is neither commitment nor guarantee, but is being used to choose between high-level options.
3. CD3 is a starting point for ranking features, but that leaders cannot just sit back and let the equations do the release planning for them.
4. If these techniques are not being done at the highest levels (e.g., portfolio planning), then they're going to be pointless at the feature level.

And I sometimes quip that, since value is an estimate, and time is an estimate, that the "estimate" units cancel out. ;-) 

Religion: An Apt Analogy for Agile

There are very few topics of exploration that have unceasingly retained my curiosity throughout life. One is software development, another is religious thought.* But in my teens and 20s, I didn't really expect them to overlap...

You've likely heard the word "religion" used to describe the Agile movement (or, now more aptly, the Agile industry), and usually it's meant unkindly.

But it's an apt analogy, and I've often used it myself.  In a way, Agile is indeed an umbrella term for a collection of "religions of software development." I don't think that's a bad thing.

A religion, as a topic of study, circumscribes a set of beliefs, ethics, and practices.  Every religion in history and today has its share of dedicated practitioners, crackpots, expert teachers, and charlatans. Every one started out as a new, challenging idea, appropriate to historical context, and usually rejected by the status quo. Every one provided value to its adherents. Every religion has been abused for personal gain. Every single one.

Over time, some ideas become the status quo, some practices that once had value are performed mechanically, and some ethical systems are paid mere lip-service. Like in a "cargo cult", people will continue to perform the practices though they get none of the value.  Often because they've confused cause and effect.

Agile is no different.  In the late 1990s, we were considered rebellious. Now you will encounter Agile frameworks that recommend ritualized adherence to well-regarded practices, and are packaged in a way that's palatable to folks with Theory X management styles.

Just last week I met with a team resisting Scrum as "too heavyweight" and "requiring attendance at too many meetings." That's sad, because Scrum is intended to be an extremely lightweight approach, with minimal overhead, oversight, or waste. "Where do such misinterpretations come from?!" you may ask. Human nature, my friend.

With Scrum and Extreme Programming (XP) in the 90s, we were looking for a "middle way" (if you'll pardon the personally-biased reference) between basement hacking and the Rational Unified Process (RUP).

We are still, today, looking to improve on the way we build software. The search for greater fluency doesn't ever end.

In my experience, the chosen system of thought, to continue to provide value and comfort, needs to (a) be self-reflective, and adapt to changing context (i.e., it has to "change with the times"), (b) adapt to regional realities and native cultures, while still providing the original, foundational values, and (c) be easy to describe and to learn the basics (though there are always higher and higher levels of fluency to be explored over a lifetime).

"Is he still talking about scaling Agile in a complex corporate setting?!" Of course.

* There are others, and you may note significant overlap, but they are not as relevant to this post: Science, and fitness. Ask me about those; I'll pedantically talk your ear off. You've been warned. ;-)