At Playbook, creating velocity in product development projects has been our passion for 18 years. As a result, we’ve analyzed Agile and other product development methods such as Phased and Gated and Lean for their applicability to hardware projects.
Sometimes it's easier to talk about what doesn’t work, vs. what does work to illustrate a point. Here are our top four Agile product development techniques that don't apply to hardware development. If you want a deeper dive into Agile and how to apply it to hardware development, check out our 7 Part Series on Applying Agile to Hardware Product Development.)
In Agile, points are a proxy variable for estimating the duration to deliver working product, based on the amount of effort required and the availability of the resources. It works in software because duration and work are almost directly proportional during the delivery cycle, and resource availability remains fairly constant.
In contrast, in order to deliver working product in hardware development (e.g., a working prototype), component lead times are days or weeks long. During this time very little effort is required. Work and duration are not proportional. You can design something in a few hours that takes weeks to procure, or you can design something for weeks that takes only days to procure.
In addition, resource availability is often highly variable. Production issues, for one, can cause a few hours of design work to take weeks while the engineer puts out the fires on the production line. Highly variable availablity causes highly variable durations, with no change in effort level.
As a result points just aren’t a good proxy for estimating duration in the hardware development design/build/test cycle. We get better estimates for duration by estimating the hours of work in work-type tasks like design and test and measuring resource availability instead of guessing at it. For wait-type tasks like document release and part procurement, we can estimate duration directly as accurately as we could any other way.
In hardware we strive to accelerate the release of working product to our end customers, and release as frequently as we can. However, there are significant issues unique to hardware development that limit release frequency.
First, there is the obvious lead-time for procurement issue. But there is also the need for our product to be safe, and work well enough in real-life conditions to get realistic feedback.
Certainly we benefit by releasing what we can early for testing. For example, having customers briefly hold or test prototypes. However, to release a product that actually works very long in real-life conditions usually takes several iterations over many weeks or months. From there, new iterations can only be released as frequently as the design and drawings can be updated, released, procured, and assembled ...which is not very frequent in most cases.
While some aspects of sprints work well for hardware development, the standard approach in Agile does not. In hardware development, the expectation that sprints are 2 to 4 weeks long and can produce a working product isn’t feasible. The idea that no new tasks can be added to the sprint in the middle of the sprint may be feasible, but it's not the fastest way to get the right things done.
When we work in an environment like hardware development where new information about what we should do is emerging daily, a fixed batch size that is weeks long with no new tasks allowed is generally a bad idea. Single-piece flow is better than batches when there is some uncertainty involved, and there is almost always some uncertainty involved.
Single-piece flow happens one day at a time. When we look at the priorities of the day and adjust accordingly, we can sometimes scrap what we thought was a good idea a week ago and follow a better idea today. We also often need to adjust our plans and resources to focus on the most critical item of the day. Speaking of "critical," this brings me to the last point…
The fact is, we need to accurately predict how long our hardware projects will take. Suppliers and production facilities need to be able to ramp up and start delivering finished products on time, at a reasonable cost. Sales cycles can be long and we can’t start them until we are fairly confident in our delivery dates.
In addition, there are often many more relationships between different people’s activities in hardware development than in software development. For example, the mechanical engineer can’t test his design without a functioning PCBA. The electrical engineer can’t make his PCBA function without some firmware. And the firmware developer needs a board and sometimes some mechanical components to develop the right firmware. Without understanding these dependencies in our project model (our project plan) the model is going to be inaccurate and our prediction for completion date completely wrong.
In addition –- because of the high variability in the duration of the tasks in our plan — we can easily miss opportunities to accelerate delivery if we don’t have anything telling us what is really ‘critical’ each day.
For example, when you are ordering parts, do you expedite them or not? The answer can change based on what is happening with other parts. Getting the answer wrong will either cost you precious dollars or even more precious days on the schedule. And it’s hard to get the answer right all the time without some good details in a Gantt chart with dependencies clearly identified.
-----
Want to know more about Playbook? Watch this 9-minute video that show the number one cause of project delays. It's not what you think. They watch part 2 to see how Playbook solves for these issues.
Agile Development
Applying Agile Values to Hardware Development
Agile Principle 1: Early and Continuous Delivery of Value
Agile Principle 2: Welcoming changing requirements
Making Hardware Development More Agile
Early Learning in Hardware Development
Agile Principles 4 - 12 to Hardware Development