Being an Aerospace Engineer by training, I find some parallels from time to time between product development systems and flight systems. One that I particularly like helps to compare and contrast Lean and Agile product development systems with ‘Traditional’ product development systems.
Why is Agile better than traditional project management for hardware development?
An Agile system, like a fighter jet, is able to change directions very quickly. Traditional systems are more like passenger jets, which change direction much more slowly.
There are inherent aspects of these two different types of aircraft which determine their ability to change direction quickly. The most important one is where the ‘center of lift’ (or aerodynamic center, or center of pressure), is located relative to the center of gravity. Specifically, which center is in front of the other?
Read our complete guide to Applying Agile to hardware development.
Think of throwing a dart or shooting an arrow – the center of lift (CL) is in the tail of the dart where the ‘airfoils’ are. (They even call that part the ‘flight’). The center of gravity (CG) is further forward, toward the middle of the dart. When you throw a dart forward, point first, the CG is in front of the CL so the dart flies smoothly toward its target. (Depending on your skill and how many beers you’ve had, perhaps not directly to your target, but smoothly.) The dart stays pointed in pretty much the same direction the entire flight.
It would take some effort, some work, some force to change the dart’s direction. It is in a ‘stable condition’, like a ball sitting in a cup is in a stable condition, as opposed to one sitting on a rooftop or Pringles chip. When something is in a stable condition, natural forces and physics keep it there. No effort is needed.
In contrast, if you throw a dart backwards and the CL is in front of the CG, it is in an unstable condition. It flies in unpredictable directions until it flips itself around into the stable condition again. It is easy to move something in an unstable condition. In fact it takes work, effort, and force to keep it in that unstable condition.
Passenger jets are built to be stable, so the CL is behind the CG by a little bit. This way, if the pilots happen to eat some bad fish, you have time to get to the cockpit, save the passengers and win the girl back. (Think Peter Graves and Kareem Abdul-Jabbar in one of the best movies ever, Airplane! (Video) ...and don’t call me Shirley. )
In a fighter jet, though, you must be able to change direction quickly. As such, the CL is actually slightly in front of the CG. This makes the plane inherently unstable, but the pilot and some electronics provide the ‘force’ needed to keep it pointed in the right direction.
Traditional Flight Systems Similarity to Traditional New Product Development Systems
So how does this relate to product development systems? There are some inherent characteristics in product development systems which tend to force them into a more stable, ‘traditional’ condition. Like the laws of physics, these natural forces are ever-present and some of them always will be, driving our systems back into their current stable and slow-to-change condition.
One ‘law’ is the fact that there is uncertainty in new product development. There must be at least some uncertainty in product development or we aren't innovating and our new product really won't be 'new' or innovative and won’t sell.
Another characteristic of new product development is the fact that we are inherently overloaded with work, and that makes us feel like we have less time and energy to exert the forces required to keep us Lean and Agile. Whenever there is a Cost of Delay (which is always), there will be some pressure to push us toward a higher loading. Counterbalancing this pressure is one of the keys to Agile and Lean development.
The last characteristic is that we tend to be overly optimistic about things – lots of things. How long it takes to do something, whether a potential problem will actually occur, and the cost of that problem if it does occur - these all tend to be underestimated.
"These natural forces combine to push us toward a more stable, ‘traditional’ product development system."
For example, consider what happens in the day-to-day throes of a product development project. We have milestones to reach, often with deadlines associated with them. We are expected to march toward them every day, as quickly as possible. When a new risk pops up, one that may or may not really be a problem, what do we do?
Well, we tend to be optimistic and assume the risk won’t eventuate, and/or we throw that question into the pile with the rest of the questions we are charging forward without answers to. We see Project Risks as questions like: Will that part eventually break?; Will your customer really like this new feature?; and/or, Will that supplier be late when it comes time to deliver? There are so many of these maybe-so/maybe-not questions, especially when time and money are tight at the end of a project, they can be easily avoided. When we don’t exert effort to keep lean and agile, what happens?
Of course, the result is that we don't mitigate enough of these risks (uncertainties) and some come back to burn us. Then we enter ‘fire-fighting mode’, and time and money get even tighter, so then we skip mitigating other risks. Then they blow up too, and so the cycle continues as we continue digging ourselves a nice stable hole to get out of. Then, by the time we finally get done with that project and move on to the next one, we are already late, time and money are tight again, and so we race through planning and risk management again, and the cycle continues.
Lean and Agile Product Development Systems Have Similar Characteristics to the Fighter Jet
In contrast, truly Lean and Agile companies put in some work regularly to keep themselves Agile. Their agility works to counterbalance these traditional forces. For example, they consider every risk as something potentially worth mitigating, even late in a project. They tend to mitigate more risks than not, because even those mitigations that don't entirely pay for themselves in reduced delay still provide better predictability, which has a lot of value to it.
Taking an Agile Approach to Burning Down Risk
For example, say it would take one additional week to run some tests early in development to see if our product may break during later Verification & Validation (V&V) testing, like repeated-use tests performed after accelerated aging. Say we thought it was very unlikely – perhaps a 10% chance it would fail during V&V. But if it does, it would cost 10 weeks to update our design, update the molds, and get new parts. The one-week mitigation would eliminate the 10% chance of a 10 week delay. The net gain in cycle time is a wash, but we gain certainty in our schedule – and that is highly valuable, too.
Sometimes we have to put in a little work crunching some numbers to keep us on this Agile path, because some risks really aren't worth mitigating. Seeing the line between risks which should be mitigated and those that shouldn’t is key to minimizing waste and completing projects as quickly as possible, with as high of certainty as possible. When we don’t put in any time or work to find that line, we typically mitigate less than we should, and we get pushed a little more toward a Traditional product development system.
Test Until You Know What is Right For Customers
Consider another example of the natural forces pushing us toward traditional product development. As described so well in Lean Startup, we tend to assume we know what is best for our customers, what will delight them, and what they will pay for. Especially when we are short on time and money and customers to ask, we go with our assumptions. We exert no effort, no work to keep us moving in the direction we are moving. This is very stable and ‘traditional’, but we too often end up wasting time and money flying the wrong direction by building things our customers won’t pay for. When we do eventually find out, we are slow to change direction and fix it, because we are overloaded with so many other things to fix too.
Lean and agile (Lean Startup) companies assume the opposite – that we don't know what our customers will buy, and we need to put in some effort to understand it before we put in a lot of time to build it.
Good planning, tracking performance (throughput) metrics, regular ‘scrums’ or Daily Huddles, deeper & wider understanding of customer needs – these are a few examples of some of the ‘work’ which keeps the lean and agile companies lean and agile. We need good pilots (Scrum Masters, Lean and Agile Champions, etc.) to counteract the forces pushing us in the wrong direction. We sometimes even have to add some effort to remind people why we do things this way. A pilot must keep his hands on the wheel (yoke) of his fighter jet.
What Weighs Product Development Down
There is more to this analogy, too – like the importance of closed-loop, fast feedback control systems.
I’ll save that for another post (or three). For now, consider the ‘center of gravity’ in product development. It represents the things we can easily see and feel. For example we can easily see and feel the parts and weight of an airplane. This is the expenses on the project, the costs of the components we are designing, the time required and work the project creates for people.
When we put the CG in front, we focus on it first and try to minimize our costs and work. As a result, we make more assumptions, create bigger batches, more organizational ‘silos’ and a more traditional, slower, harder to change system.
The ‘Center of Lift’ in New Product Development
In contrast, what is the ‘center of lift’ in product development? It is the ‘lift’ we get by developing great products quickly and the profit we achieve. Truly lean and agile companies put this center of lift in front of the CG, and recognize that without adequate lift and the ability to move quickly with it, the weight doesn’t do us any good.
It takes a little work (mostly upfront) to keep the lift in front of the weight. We must put effort into redesigning our processes and continuously improving them and keeping them pointing in the right direction. We put more work into understanding our customer’s needs, and architecting our product to be easy to adapt to those needs as we learn more. We put work into diffusing risks before they blow up on us.
But we put less time into the upfront work than we would into building features that won’t sell or putting out fires created by all of the risks we would realize if we didn’t mitigate them. Overall, we move faster, change faster, have more certainty about when we will be ‘done’, and we make more money which keeps us flying higher.
What is the number one cause of project delays? It's not what you think.
Related articles
Lean project management
Lean project management methodology
Lean project management Kanban
Lean project management principles
Lean project management resource management
Lean project management Pull vs. push
Lean project management task management
Lean project management and shared project buffers
Lean project management and decentralized planning
Daily stand-up meetings
Guide to Lean Project Management
Guide to Lean Product Development
