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
  • Self-organized 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:

  1. Shortening of internationalization from 11 months to 1 month
  2. Reducing time to release by a factor of four
  3. Shaving 40-50 percent out of product development cycle time

Software Development Process

Agile Transformation