Agile: From Software to Hardware (Part 3)
Our study based on interviews with managers in (mostly) Silicon Valley companies found that the aspects of Agile that experienced managers believe have the greatest impact on software development are not at all unique to software projects. However, hardware and mixed (system) programs are significantly different from software development. Hardware and mixed programs tend to be longer in duration. They also involve tooling, assembly, and supply chains that make them inherently less agile than software programs. The need to manufacture and distribute physical products, as opposed to instantly replicable lines of code – the process of going from one prototype to many products – is the most significant difference between hardware and software development.
To apply Agile to hardware development requires a map that compares the territory of Agile software to Agile hardware projects. One section of the map covers the cultural terrain. Our findings indicate that the Agile “attitude” is a key to its success. The following attitudes, cultural traits, and related processes move readily from Agile software to hardware or mixed programs:
High performance teams
Senior management trust and team empowerment
Customer ownership & daily team interaction
Tolerance around changing requirements
We found that experienced practitioners keep the Sprint cadence as planned. If the hardware schedule slips, they do not delay the Sprints, but align the next hardware/software integration point with the next completed Sprint. That is, they do not alter the Sprints because of a slip in hardware’s schedule, but time them to align with the next integration point.
Another practice we uncovered is that some companies put a small contingent of software engineers on the hardware team. These engineers act as a liaison between the software and hardware groups. They can write the interfaces and help the larger software development team to work efficiently and shield them from the impact of changes in the status of the hardware team.
Experienced Agile practitioners are also testing software on simulators or emulators rather than on prototypes of the hardware itself. For example, Android has software that emulates the mobile handset hardware on which its software will run. One company in our survey had the software team write a hardware emulator as its first sprint in the project. Providing the software team with the capability of testing its code separately from a physical prototype increases speed, quality and the ability to respond to changing requirements.
In addition, our experienced Agile practitioners revealed the following nuggets of wisdom:
User Stories are needed to make the best tradeoffs
User stories allow engineers to look behind the requirements and discern the pain point the customer is really trying to relieve
Plan to have multiple DVTs that involve the customer
Involve customers in the middle of the development program and not just at the start or end
Build multiple variants in DVTs (buttons, PCB layouts, firmware)
This approach can get expensive, but experienced Agile practitioners buy themselves flexibility by building variants
If lead time is six months and you need to go to market in four, ask suppliers for their buffer stock
You only need to satisfy the first month of production; for many start-ups, suppliers will not demand orders in the quantity that they expect from larger companies
Use reference designs & allocate BOM choices to supplier
Delegate choices to partners as much as possible
The entire team must be Agile for the methodology to work
All functions must buy into the Agile paradigm, not engineering or operations, but every core team function
Rely on postponement
Postpone firmware decisions to allow for multiple User Interface options; make your final choice when you pack in a local distribution center
Also postpone low-risk parts of the project and work on the high-risk items first
General Conclusions From the Study
The vocabulary of Agile software development with its “Scrum” and “Scrum Masters” and “Sprints” can create the sense that Agile is a private club for the initiated. Our research suggests, however, that its most effective aspects are more cultural than procedural and its methods may be modified and applied to any team endeavor.
This is evident in the Agile Manifesto itself. The Manifesto’s authors declare that they value…
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Despite the word “software” in the second statement, in principle, none of these values speak to software development alone. If hardware and mixed programs wish to reap the benefits of close collaboration with customers, and the ability to adapt to changes in requirements or other market conditions, what they need is a bridge from the unique landscape of software to that of hardware.
Organizations can build this bridge by…
Embracing a culture of team empowerment and trust
Mixing hardware and software engineers on the same cross-functional team
Communicating frequently with customers and with each other
Accepting the inevitability of change
As a result, hardware and other development programs might begin to produce the type of results our Agile respondents reported, including:
Shortening of internationalization from 11 months to 1 month
Reducing time to release by a factor of four
Shaving 40-50 percent out of product development cycle time