One of our many biases as human beings is to, every now and then, confuse the means (the approach; what we need to get somewhere) with the ends (the destination; where we want to go). This seems to be happening more and more often with Agile.
If we look at the slide decks by some of the world’s biggest consulting firms, you’d think that agility is the solution to all problems. A true silver bullet that can enable companies to become innovative, resilient, and adaptive, learning lessons quicker than before and gaining a competitive edge. We do understand there is a commercial factor involved, but still.
If we watch some of the more recent talks on Agile or read some of the books that came out this year, you’d be left with more or less the same impression. But the question is, is Agile really the silver bullet that so many folks are making it out to be?
Agile isn’t a silver bullet for the challenges and problems that the leaders, teams, and individuals working within an organization need to address and solve. It’s a mindset and approach that they can use to do so in a way that allows them to learn lessons fast and respond to change better.
It’s time we stopped confusing agile with something that it clearly isn’t. And start using it as the mindset and approach that it is to focus on the work that matters most, solve the problems with the biggest impact, and learn from the feedback and insights that we get along the way.
Why Isn’t Agile Working?
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 has 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 Agile into the spot. 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.
