Chapter 5: Applying Agile Hardware Techniques and Changing the Normalized “Old Ways”
In the previous chapter the differences between agile Hardware and Agile Software were explored. This chapter explores the first part of a practical look at how to apply agile methodologies to your hardware development process.
First let’s examine the impact of following the “old ways” that have become normalized as part of the everyday hardware development processes:
Developing any hardware-based product requires careful planning, management, design, and testing before it can be manufactured and shipped to customers. This has resulted in the traditional “waterfall” development model, where work is done in a series of serial activities, with review and approval requirements before moving along the development path.
(image source: D Eden)
However, because activities are done serially, the waterfall model typically requires more time to get a product to market, which in turn increases both development costs and market risk.
For hardware product development, success depends on integrating many factors such as supply chain readiness, manufacturability, test, quality, regulatory and reliability, requiring a skilled cross-functional team and strong collaboration at every stage of the design process.
The challenge with the waterfall method is that these interactions are inherently constrained. Agility is limited as people and processes have to wait for each serial stage to complete before they can move on to the next activity.
Companies that follow a traditional waterfall, or even worse, an ad hoc, unstructured development process will often experience the product–profit lifecycle curve illustrated in the diagram at the beginning of this blog.
Coordinating the right resources at the right time and aligning them with a realistic schedule is both challenging and inherently risky. Too often, the “ideal” project plan (for sales and company profits) starts with a fixed shipping date and then compresses all activities and teams into an unrealistic schedule in order to meet the target.
At this high level of planning, the complexities and subtle dependencies of the hardware development waterfall methodology are often ignored leading to missed schedules for hardware deliveries to software teams and vice versa.
While these dependencies remain hidden, the true challenges and risks of development are also hidden. The consequence is often late delivery and last minute design compromises, including undesirable product feature reductions as the teams struggle to meet an unrealistic plan
Join us next time for the second part of this practical look at how to apply agile methodologies to your hardware development process where we discuss how the application of agile-like principals can solve many of the issues of the waterfall methodology and increase profitability while reducing time to market.
Sources:
Extracts from the completely revised book Agile Hardware Product Realization (version 4.0) by Michael Keer and David Eden.
Leave a Reply