JUNE 20229parts or circuit boards and the cost of specialized components that many software developers simply don't have to address. All of this means that while agile hardware development is possible, it won't be sufficient to blindly copy existing agile methodologies without accommodating some unavoidable realities of hardware development. However, it is quite possible to develop a product as a series of product increments instead of the traditional waterfall approach. Rather than follow a linear series of events from stakeholder needs ­ requirements ­ system design ­ specification ­ hardware design ­ verification ­ validation, one can treat each of these as a living document and develop them in parallel as the product matures. This acknowledges the very real learning that occurs, especially when developing novel products. While the customer may always be right, the customer may not always know what they want--or at least they often don't know what is possible, and sometimes the developers have to show them.A key part of successfully executing on an agile hardware development project is planning a series of iterations. Each iteration is designed to help you explore the stakeholder needs and requirements and the limitations of the technologies being applied. What this means in practice is that rather than specifying the final product, the focus is on first defining the problem to be solved, and then identifying the first steps--what David Allen would call the next action--to advance towards a solution. This could mean that a computational model is quickly developed to answer some early questions. It could mean a non-functional prototype is made to evaluate concepts and look and feel. Software engineers have used these techniques for years and there is absolutely no reason not to use them with hardware. There are key differences that distinguish agile hardware from traditional agile projects. Most of these are due to the nature of the artifacts delivered by hardware projects. One simply can't avoid the need to know some basic architectural details before getting started. Sometimes this is described as the agile on-ramp and it acknowledges that software and hardware are fundamentally different in certain key respects. Details that must be handled in the on-ramp include a merging of the concept of user stories--which are often problematic in hardware development--with product requirements. Some work also needs to be done to address iteration planning. It's not sufficient to wait for Iteration Two to plan Iteration Two because the changes in hardware might make moving from Iteration One to Iteration Two prohibitively expensive. I like to think of this in terms of road mapping. You have a sense of where you are going, but you don't know where the roadblocks are going to be. Despite some differences, once a team moves into execution the agile nature of the hardware development becomes more apparent. Each sprint moves through a phase of build, design, and test that includes integration into previous iterations, validation that the parts work together, some sort of demonstrable output, and planning for the next iteration. Companies that can quickly develop products that meet the customer needs are always going to have an advantage over those that don't. These changes have been coming for years, starting in the software development industry where more and more new products are being developed faster and faster. This same disruption is now moving into hardware product development and companies that learn how to leverage a modified agile methodology to support hardware development will ultimately outperform those that don't.
< Page 8 | Page 10 >