To many in the Agile community, especially those of us who’ve been around since the early-adopter days, “Hybrid Agile” is another way to say “not agile at all” or “agile in name only.” When the Project Management Institute first started picking up language and practices from the Agile movement, Agilists worried that they’d formalize the life out of them. And that skepticism wasn’t off base.
Most attempts at a “Hybrid Agile” stacked the weaknesses of waterfall and agile approaches. “Think either one is bad? Hold my beer! We can make it even worse!”
A traditional waterfall approach promises predictability but struggles to accommodate complex problems where information emerges during execution, rendering plans out-of-date almost immediately or creating analysis paralysis. A naive Agile approach focused on short-term delivery ignores the real business need for predictability beyond 2 weeks (and can still end up with complexity in the last 10% of a project—making work unsustainable and reducing value).
But what if you could have a hybrid that was legitimately the best of both?
We didn’t set out to develop one. But we realized that we’d helped several clients experiment in that direction and similar patterns emerged.
This was particularly useful for our clients in highly regulated domains like medical device development. In that space, predictability is especially valuable—regulators like the FDA care a lot about you calling your shot in product development and proving you actually built and tested what you set out to build.
Of course, the illusion of predictability is a waste, and that’s where a full-on waterfall approach to complex work falls down.
In order to get the best of both traditional project management and Agile product development, we need a clear distinction between complex and complicated work.
Complex work is where things are new and unpredictable. Complicated work is where things can be analyzed and planned.
The core value of a project tends to sit firmly in the Complex domain. After all, most projects are about creating something new for humans, and the top two sources of complexity in product development are newness (new scope, tech, team members, target markets, etc.) and the unpredictability of human preferences and behaviors. Complex work is also where you find most of the schedule and budget risk on a project.
Complex problems need to be solved by experimentation and iteration rather than analysis. Details emerge as we solve a complex problem—those details aren’t present in advance. But that experimentation needs to be focused and constrained so it doesn’t cause undue risk and unpredictability.
Complicated work may have uncertainty to it, but we know what we don’t know, and we can ask questions about it, analyze what we learn, and make plans. This is where skillful requirements gathering and project management succeed.
Any large initiative will have both complex and complicated elements. The temptation is to start with what we understand (the complicated) and move towards what we don’t (the complex).
The classic example is a team building a web application and starting with infrastructure, user management, billing, and eventually working their way into the core new capabilities of the application once those “foundations” are laid. It looks like progress from the beginning, but it defers progress on what’s most important.
This approach is what causes the last 10% of a project to become chaotic and stressful. And if the complex work is where the core value lives, saving that for the end puts the most important parts of the project at the highest risk.
Instead, our hybrid approach front-loads for complexity. We want value, learning, and risk-mitigation as early as possible. Leaders and teams start by doing focused work to resolve the core complexity, reducing risk and maximizing value early in a project. Then, they move into the complicated work, making the solution comprehensive, robust, and marketable.
We call the Humanizing Work hybrid approach CAPED, which stands for Complexity-Aware Planning, Estimation, & Delivery. Everything in the CAPED approach is shaped by complexity as a key force in product development.
Human work systems are themselves in the complex domain. We figure out better ways of working by doing it and helping others do it (as the authors of the Agile Manifesto noted). CAPED is no exception. It’s the result of experimentation with dozens of clients solving real, meaningful problems. We just named the patterns that emerged over and over again.
Learn more about CAPED here and schedule some time with us to discuss whether this approach makes sense for your organization.
Last updated