AGILE FOR HARDWARE PRODUCT DEVELOPMENT?

The most obvious difference between hardware and software is that hardware cannot be undone, twisted, adapted and adjusted at the same rate, or with minimal impact to cost and time as software can. Procurement lead time, component cost and non-homogeneous work are seen as three major differences between hardware and software product development. Large procurement lead time makes it difficult to have shorter release cycles which is at the heart of agile. High component cost prevents a “just go and do it” vs a more carefully thought out release. Non-homogeneous work, meaning all the different type of people that are needed in addition to develop a hardware vis-à-vis a software: supply chain, manufacturing, receiving/inspection, field service makes it difficult to keep everyone in sync due to the complexity of communication channels.

The other big difference is the increasing share of complexity of a system that software has been taking due to the flexibility it offers and the advances in its domain – no disrespect here –leaving hardware to essentially do the primary job of converting one form of energy into another. Before people take umbrage, let me clarify that complexity here refers to the possibilities of interactions, logic and control that software offers. As a result of this complexity, there is a certain inability to completely grasp all the nuances and resultant needs upfront and therefore the changing requirements which are handled better in an Agile world of frequent build releases and quicker feedback. The challenges with hardware are less to do with the various complexities of logic that hardware can perform or changing requirements and more to do with its reliability under harsh environmental conditions and robustness against fluctuations in input parameters. Frequent releases of a software and hardware help in different ways. For a software, they help in defining requirements better and fixing problems faster, whereas for a hardware they help in climbing the learning curve faster and fixing problems faster. As described earlier, hardware doesn’t lend itself to frequent releases as software does, which begs the question: For hardware product development, is there a cheaper and faster way of climbing the learning curve and doing it ‘right the first time’? A great way to reduce the uncertainty around hardware product development by not only climbing the learning curve faster, but by also being able to reuse learning is the Toyota Product Development System. This is different from the more familiar Toyota Production System which, with its focus on lean and reducing waste, is similar to Agile. There is much to say about the Toyota Product Development System but to summarize, it is a knowledge based learning system in which the knowledge is stored in the form of trade-off curves between interacting aspects of a system, captured through extensive sub system testing. This product development approach follows a test followed by design method, as opposed to a more conventional design followed by test approach. Such testing at a sub system level to capture knowledge needs innovative test setups at a sub-system level as opposed to situation where we almost wholly depend on a test bench that tests the entire system. More reading at Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How you can Implement It by Michael N Kennedy

This is not to say that certain agile principles are not relevant for hardware; in fact I would argue that they are most essential to getting any work done. Let us look at the 12 principles in the agile manifesto and understand each one’s relevance to hardware development.

1.        Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.- My comment - As the cost to change is higher in hardware, I would place the relevance of this as low. One could make attempts to lessen the cost of change but this cost would not get anywhere near the cost of making a software change and in some cases may be plain impossible to reduce beyond a point. Consider if you are building a cryogenic engine, a nuclear power plant or machining titanium for a submarine hull.

2.        Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. - My comment – This is very important and an ability to make a late change if it improves business value is a great competitive advantage for any process be it product development or manufacturing.

3.        Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - My comment – Frequent releases of hardware are good to the extent feasible and if the benefits outweigh the cost of such frequent releases

4.        Business people and developers must work together daily throughout the project.- My comments – The number of teams that manage hardware as opposed to the number that manage software might make it difficult, if not impossible. Supply chain, manufacturing, receiving/inspection and field service are but a few.

5.        Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. My comments – Very relevant to all settings.

6.        The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. My comments – Very relevant to all settings.

7.        Working software is the primary measure of progress. My comments – Not necessarily. An evidence of being sufficiently high up on the learning curve in the development of the hardware product can be sufficient evidence. The 13 principles of the Toyota Product Development System listed at the end of this section reflect this opinion.

8.        Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.- My comments – Very relevant

9.        Continuous attention to technical excellence and good design enhances agility. My comments – Very relevant

10.      Simplicity--the art of maximizing the amount of work not done--is essential.- My comments – Very relevant

11.      The best architectures, requirements, and designs emerge from self-organizing teams. My comments – Very relevant

12.      At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. My comments – Very relevant

The 13 principles of the Toyota Product developments system are reflected below and note the similarities when it comes to mindset and culture and the emphasis on learning, but not on frequent releases as is in Agile.

1.    Establish customer-defined value to separate value-added activity from waste.

2.    Front-load the product development process while there is maximum design space to explore alternate solutions thoroughly.

3.    Create a leveled product development process flow.

4.    Utilize rigorous standardization to reduce variation, and create flexibility and predictable outcomes.

5.    Develop a chief engineer system to integrate development from start to finish.

6.    Organize to balance functional expertise and cross-functional integration.

7.    Develop towering technical competence in all engineers.

8.    Fully integrate suppliers into the product development system.

9.    Build in learning and continuous improvement.

10. Build a culture to support excellence and relentless improvement.

11. Adapt technology to fit your people and process.

12. Align your organization through simple, visual communication.

13. Use powerful tools for standardization and organizational learning.

In conclusion, since software is essentially complex in its logic and interactions it is difficult to define requirements upfront and an agile model works well. Hardware product development is plagued more by the inability of the product development team to be sufficiently high up on the learning curve to prevent the product’s failure during qualification testing or when being used in the field. Frequent releases help in getting onto the learning curve, but this is an inefficient way since a hardware product cannot undergo a change as easily as software can. There are instances where people have deployed scrum or agile for developing a hardware product. One such link was shared by a friend of mine https://futureofprojectmanagement.com/2011/12/02/joe-justice-built-a-100mpg-car-using-principles-of-agile-lean-and-scrum-how-did-he-do-it/ The key here was to be able to reduce the cost of change, something that may not always be possible to the extent desired. An economic benefit analysis could be used to make decisions about how frequent the releases can be. Deploying agile for hardware development without consideration to this can result in an inefficient product development system and at worst lead to a decision of a “no-go” simply because the product failed in its initial releases. Hardware is just that: hard!