Lean and Agile in Hardware Development
There seems to be some confusion about which works best for the hardware development process. This makes sense. Agile came from the software world, and Lean came from production, so manufacturers have most likely been exposed to both.
The good news is you don’t need to choose between one or the other. You should adopt the relevant parts of both because they not only work well together, they have a lot in common...
Lean in a production environment means things like eliminate waste, reduce variability, single piece flow, just in time inventory, and continuous improvement.
Agile in a software environment means things like rapid customer feedback via the delivery of working software instead of plans, responsiveness to changes, sustainable processes, and continuous improvement.
If you study both topics or read between the lines, the items they have in common are value to the customer, rapid learning, smaller batches (or continuous flow if you can), and continuous improvement.
The differences are caused by the different environments they were developed for. Manufacturing has visible parts moving thru a well-defined process where variability is a bad thing. Software development is the creation of a digital work product where the requirements might not be clear, so rapid customer feedback and agility is important.
The hardware development world has things in common with both so it benefits from a hybrid of both Lean and Agile and looks something like this...
Rapid Learning
Like software, many work streams involve unclear requirements so rapid learning is important. Not only learning from the customer, but since we’re dealing with a physical product we also need to learn things about cost (material and production), lead times, multiple types of engineering analyses (strength, thermal, weight & balance, etc). These learning efforts are different, but they both require us to do definable work in order to generate information that will guide our next steps.
Visible Work
Even though hardware development creates a physical product in the end, for much of its early life it is either invisible or digital. The invisible attribute causes a big problem because you can’t track it to see how (or whether) it is getting done. And the digital form of our product isn’t much better. We still need to organize and track it somehow in order to manage it. But unlike a physical product, digital products can exist in more places than one at the same time—which can be either good or bad!
Flow
Flow encompasses multiple benefits along the lines of small batches, just in time, sustainability, and the elimination of bottlenecks. When done correctly, it ensures the right work is done at the right time so the project is never delayed because of a blockage on the critical path.
How does Playbook facilitate these?
We like to facilitate Rapid Learning through a Risk Management process. Risks are the result of uncertainty, so the elimination of risk requires the development of knowledge, which is done via learning (and the faster the better!) So these terms are generally interchangeable but we prefer the Risk Management process because it allows us to better prioritize the necessary learning, track progress, and generate useful knowledge in a continuous fashion (flow) without the delays caused by artificial time boxes used for sprints.
Visible work is made possible from the details in the plan. Creating a plan is a critical step that shows the effect of dependencies (that aren’t as predominant in a software environment) and enables the team to not only see an overall timeline but look for ways to shorten it as well. And the major value of this plan is that it allows us to determine the relative importance of all the tasks based on whether they’re on the critical path or not.
Once we can sort the work based on relative priority, we can create flow by pulling the work from a backlog that ensures everyone is always working on the most important task. And by using frequent standup meetings (from the Scrum method from Agile) we can quickly see blockages that are causing delays and preventing perfect, continuous, flow.
When this is done correctly, companies are commonly able to achieve 20%-30% reductions in development times.
So what's next? There's a lot of ground to cover! Downloading our eBook on how to apply Agile to hardware development is a good next step. It tells you which Agile principles work, the ones that don't, and why, and suggests an optimal approach.
Related articles
Guide to Lean Project Management
Guide to Lean Product Development
Science and economics behind “failing fast”
Lean Product Development the Opportunity of the Century.
Lean Product Development Case Study
Principles of Lean Product Development
Lean Product Development Value Chain
Get started with Lean Product Development
Lean Product Development: Cultural Resistance
4 ways to Ensure Your Lean product Development Initiative Won't Fail
