This article is part of a new series on Agile for Hardware Development. I invite you to sign up to receive the entire series if you want to learn more about how Rapid Learning Cycles fits into the Agile universe.
Last week I had a frustrating conversation with an Agile Software Development expert, focusing on Agile for Hardware, who shall remain nameless. In that conversation, the person argued that organizations didn’t need — and didn’t want — more than one framework for program management. They should Just. Use. Agile.
The conversation felt all too familiar.
The conversation felt like many I had about Lean ten years ago, when the field of Lean Product Development was flooded with people from Lean Manufacturing who gave out a lot of bad advice to development teams. A lot of time, money and life energy was spent on programs that did not move the needle on performance — at all.
Today we have a lot of people from the Agile Software world who are making the same mistakes that the Lean Manufacturing guys made about Lean Product Development.
The key mistake is that they are not listening to people who have given good-faith efforts only to see their work go unrewarded because it didn’t solve the problems their organization had. These misguided experts blame the users’ troubles on poor training, stodgy culture or resistance instead of looking deeper.
When A Team Is in Trouble, Believe Them
When I ask hardware teams what it was like to use Agile, they describe the challenges of force-fitting work into arbitrary time buckets that don’t make sense. They talk about the frustrations of daily stand-up meetings when things are just not moving that fast because they’re waiting on parts, prototype builds or test results.
They describe trying to translate their work into things like “demos”, “user stories” and “work packages” when those concepts have to be stretched beyond all recognition in order to accommodate their work. This only muddies the waters for everyone, since if a “user story” can be anything, the necessary rigor to get a good user story gets lost.
They describe producing demos just to have something to show at a Sprint event, keeping secret Gantt charts to manage dependencies and resource utilization, and wondering if they really need to spend so much time managing a backlog that is highly constrained by those dependencies and resources.
Instead of growing more flexible and responsive, they’ve become tied down to a method that isn’t working for them.
Rapid Learning Cycles Isn’t for Everything Either
My personal philosophy is that if you don’t know where a framework or methodology doesn’t work, then you don’t really know where it does work, why it works or what problem it actually solves.
I know that if you’re up to your elbows in UX design for a SaaS app, you don’t need Rapid Learning Cycles — you need Agile — because you need short, fast cycles of iteration and immediate feedback. And if you’re building an airplane that’s nearly the same as the last 20 you’ve built, you need a good Gantt chart more than you need a Learning Cycles Plan.
I know that because these represent areas where there is either low uncertainty, so decisions can be made with confidence, but teams have complex dependency chains to manage, or low cost-of-change, where teams can iterate with fast feedback loops until they find the right solution.
They don’t have the problem that the Rapid Learning Cycles framework solves.
What Problem Are You Solving?
The problem that Rapid Learning Cycles solves is the need to make good decisions despite high uncertainty, even when that decision will be costly to change later. Teams have this problem when they are building the first airplane of a new model, or deciding where to host their cloud-based SaaS app.
In that world, Gantt charts break down because plans change too much, so they are always out-of-date. Agile processes break down because they assume the work can be organized into short iterative cycles that can be driven to completion. They assume work can be managed with a backlog, which isn’t true if the cost-of-change is too high and the dependency chains are too complex.
Both of these methods seek to answer the question “what do we need to do?” instead of asking “what do we need to learn?” Therefore, they don’t solve the problem that teams actually have in the zone of high uncertainty / high cost-of-change: how to make good decisions that stick so that they don’t trigger expensive rework loops.
Rapid Learning Cycles Solves the Problem Hardware Teams Have
We can claim that we help teams get their products to market faster because we eliminate the things that slow them down: rework loops, reinvention, nasty surprises, late-found defects. We do that by helping them learn what they need to know to make good decisions that stick.
Teams running Rapid Learning Cycles still have a few obstacles to overcome in late development, but they have many fewer than a typical product development program. And that’s enough to accelerate product development across an organization.
So, by all means, your software teams should probably be using Agile, especially for anything that benefits from fast iterative development cycles with rapid feedback.
But your hardware teams should be using Rapid Learning Cycles to reduce uncertainty in early development, so that they can manage the execution phases with the right tools for the job.
Finally, I know engineers and scientists are smart people. They will not have trouble with more than one framework for how to organize their teams. They will be relieved at the ability to use the right tool for the job at hand.
They are definitely capable of knowing when they are in Agile space, when they are running Rapid Learning Cycles and when they need a Gantt chart.
