Learn why Lean is superior to Agile for hardware development (part 2 of 2)

Originally published at www.cytalytic.com in April 2018.

Agile principles and methodologies have been generating significant outcomes for software projects in the last few years. It hasn’t been all plain sailing and there are some vocal detractors of Agile and other related methodologies, but generally enough companies have seen positive sustainable results to create industry momentum. Inevitably the focus has moved on to physical (hardware) products with many agile consultants and evangelists looking at ways to adapt agile to work with hardware.

In principle this is a good thing as hardware development could certainly benefit from some of the positive attributes that Agile has delivered to the software world. However, many have discovered that hardware, and in particular mechanical hardware, has some fundamentally different challenges compared to software. Agile software experts who have tried to apply these cherished principles to hardware have run into some serious disconnects and dead-ends.

In Part 1 of this article I described an alternative set of approaches from Lean Product Development that are complimentary to Agile but augment your team’s ability to deal with the specific challenges of hardware development. Previously we covered the following aspects:

• Key decisions hierarchy
• Waiting and the cost of delay

In this installment we’ll move on to the following:

• Knowledge first risk management
• Design modularization

Knowledge first

A key realization with product development or R&D is that (unlike other business processes) it’s not about creating an output like a document, a specification, a transaction or a service. It’s primarily about creating knowledge, and not just any knowledge — knowledge that directly contributes to business value. Hence, during initial concept development for a hardware product, the content of a sprint should be about activities to gain knowledge that directly contributes to making key product and design decisions and not implementation. This includes everything from validating product-market fit (as per Lean Startup) to understanding what might be the best microprocessor for your circuit. These knowledge gains contribute directly to the decision hierarchy mentioned earlier and progressively build business value to the point where the key decisions about the product development can be made with complete confidence.

So how does this fix the waterfall related problems mentioned in Part 1 of this article? Well, if the product development is front-loaded with these knowledge gaining activities then the number of known-unknowns and even unknown-unknowns is significantly reduced. By the time the rubber hits the road and physical parts with long lead-times need to be ordered, the chances of the parts or the assembly or the product itself having issues is significantly reduced. Fewer unexpected prototype design cycles, less chance of product-market miss. The right product on the market faster.

But how does this relate to project risk? Well risk in the context of a project is commonly defined as follows:

A risk is an uncertain event that, if it occurs, will have a positive or negative effect on a project objective

Hence, any project risk will be defined by an uncertain event or outcome that is likely to impact business value. A key way to reduce risk (or at least quantify it) is to reduce the element of uncertainty. The more knowledge you gain about a risk, the better you understand it and the better your chance of mitigating that risk. This is the key linkage to the concept of gaining knowledge. Every knowledge gaining activity undertaken on the project directly contributes to reducing the project risk debt

Design modularization

Focusing on knowledge first ensures that the key obstacles to developing a successful product can be progressively removed as soon as possible. This allows the team to maximize their knowledge before they have to make the critical design decisions required to move into detailed design. However, this by itself is not a complete solution as learning can still take time if not approached in the right way. For example, many companies still take the approach of building fully integrated prototypes before they commence on any serious learning that may guide the design or remove risk. The assumption here is that true learning can only occur once every aspect of the interrelated design is in place. This is a perfectionist approach and forces development teams back into a batch-driven process where no value is produced until the entire prototype is ready for evaluation.

A better way is to take a modular approach and break the design down into smaller manageable modules that can be evaluated independently. Not only does this help in moving to the leaner “single piece flow” principle, it allows sub-teams to progress with learning about their own modules in parallel. There are some key principles of this approach that allow it to work effectively as follows:

1. Avoid perfection: The project team cannot not let perfect get in the way of good enough. Concepting, prototyping and testing needs to be undertaken on the basis that the module is an incomplete part of a larger whole. The aim should be to get some kind of valuable learning as quickly as possible knowing that the knowledge gained will not be completely accurate. However, even if it is only 80% correct, it is enough to guide the decision making process.
2. Aggressively eliminate poor concepts: By evaluating 80% mature module concepts, the ability to aggressively evaluate more concepts and eliminate poor ones is enhanced. Not only does this provide greater confidence that only the best concepts have “survived”, it also ensures that the team has not had to wait until the integrated prototype arrives to discover that many of their ideas were flawed.
3. Learning not implementing: Many critics point to the fact that design modularization increases product cost and degrades performance. However, this is only true if practiced during design implementation. However, during the early learning phases there does not need to be any design debt accumulated by using design modularization. The trick here is to allow early independent learning at the module level and then progressively move to a more integrated design as necessary once key system level knowledge needs to be gained.
4. Platform design: It is also possible to still get a win-win and retain some modularity once the team moves on to integration. The key here is to establish good interface specifications between different modules as the product concept transitions into a detailed integrated design. This is something a good systems architecture can help to implement and maintain. The key benefit here is that a platform can be developed where new versions of modules can be “bolted on” for integrated testing without fear of compatibility issues.

Detractors of the modular approach will point to flaws such as increased product cost and degraded performance, but often these are just a result of poor architectural choices. Indeed overall product cost will end up being less and performance better just due to fact that the project team was able to rapidly select the best concepts at a modular level and progressively mature them without waiting for other parts of the system to catch up. One great example of modularity in electro-mechanical design showcased by Modular Management is Volkswagen who have developed a modular vehicle platform strategy that they are leveraging to take a market leading advantage.

Putting it all together

Just by implementing the four Lean product development principles shared above, you can elevate your capability in hardware development well above what would be possible using Agile alone. However, the key to sustained success (as with Agile) is a thorough understanding of the principles and their rationale and not just blindly following the mantra. There are many evangelists and zealots who are sending product developers down a misguided path, so make sure you apply common sense to any advice you receive and consider alternate viewpoints.

One final point worth remembering is that the above discussion does not mean that Agile is irrelevant to hardware development. In fact many of Agile’s principles are based on the core lean principle of eliminating waste, so Agile and Lean are essentially baked out of a very similar mold. The key here is to understand the unique characteristics of hardware development so you understand what elements of Agile can be used effectively and what can’t.