A couple drawings…

I was visiting a relative a couple years ago. My poor cousin (the CEO of an insurance company) had been sold the Agile Silver Bullet ™ and was pissed. He said something like:

It’s a sham! We changed the way we do everything. We brought in consultants. We hired these master project managers. And nothing worked! It made no difference. There’s no accountability. All I get is excusesI forget how I responded, but I know how I’d respond today. I’d draw some pictures and not even mention the word Agile. There are a couple core concepts I’d need to communicate to him….

1. Flow Efficiency

First, if we look at lead time — the time from when we dream up an idea, until it reaches customers — you’ll notice that most of the time is spent “waiting”. 15% flow efficiency (work time / lead time) is normal. Crazy, right? Yet we focus on what’s (relatively) visible…the small amount of time spent actually doing the job. The best companies hit 40%. Short story, to go faster, you need to address the waiting time.

2. Unplanned Work and Multitasking

It is not uncommon to have teams paying 75% “interest” on a combination of unplanned work and task switching. The team may not even be paying down the principle. It’s literally overhead, and often never tracked in the ticketing system. Most likely, the team complains about this (it is a terribly uninspiring situation). But ignored long enough, they accept the dismal reality.

Now imagine if this is a “shared service”, and the team is responsible for addressing production issues, or provisioning new infrastructure while simultaneously doing “projects”. Suddenly you have a bottleneck.

Lesson: Address sources of unplanned work, and quantify the economic impact of having a shared service. Shared services make intuitive sense, but they often inspire a good deal of expensive pre-planning.

3. S, M, and L

This is a fun trick. Plot the time-to-completion for your large, medium, and small work items. Try to move up a level and focus on items of actual customer value (not tasks). What you’ll notice in many organizations is that the “size” of the work has no bearing on the time-to-completion. Why? There are too many other factors influencing how long it takes to complete the work (e.g. dependencies, unplanned work, lots of work in progress, etc.)

4. Benefits Realization

So much effort is spent reducing what I call “delivery risk”. This makes sense if you deliver custom projects and the customer pays cash-on-delivery. In SaaS (software as a service), we don’t get paid when we deliver the work. The benefits accrue over time. I call this “benefits risk” (the risk the work will be a dud).

It is common for big orgs to adopt Agile, but see no financial benefits. Why? Development is faster, but that has no bearing on 1) making the right product decisions, and 2) working to realize benefits. The whole POINT of Agile is to reduce risk. In project work, that risk is “on time / within scope”. In product work, that risk is “this thing doesn’t ****ing work”. This is the whole fallacy of the PO “accepting” delivery of a feature. No benefit have been delivered!

Lots of companies adopt the model on the left. Few adopt the model on the right. When they get shitty results, they try to cram more work into the system which brings about a world of hurt.

5. Unmanaged Complexity

And finally. Take a well understood reference feature and pass it through your product development system. Without managing complexity / refactoring / automation, it will take longer to complete this feature each year. Even if your team remains the exact same. Having something go from 3 days to 6 weeks is not unheard of.

Agile

Which brings me to Agile. Agile is worthless unless it serves as a catalyst for continuous improvement. Scrum and SAFe are worthless unless they serve as a catalyst for continuous improvement. Why? Because the factors that are slowing you down, are only partially due to whether you are sprinting, writing user stories, and doing biweekly demos. I’d argue those things are relatively minor (once you wrap your head around the idea of incrementally lowering risk).

To “be Agile”, you’ll need to spend a good deal of money and energy on:

• Doing the work that actually matters (benefits). Doing less.
• Automation, tooling, deployment pipeline, feature flags, etc. (DevOps)
• Changing your management culture
• Adjusting how you fund initiatives. Shift to incremental, mission based funding vs. funding projects
• Allocating resources to manage complexity (regular refactoring and re-architecting)
• Mapping value streams, and treating your business a service ecology
• A fresh look at shared services There’s no silver bullet. You have to do the work. Beware of anyone who says otherwise.