Agile Beyond Software

Agile beyond software

I recently attended a meeting of the Silicon Valley Agile Leadership Network on the topic Agile Beyond Software.

The speaker was Jeanne Bradford, her talk was based on her experience developing customized Agile processes for hardware companies.

She was not presenting a process that can be adopted as-is by a large number of hardware companies in the way that Scrum can be adopted by software companies.

At the start, Jeanne said that people doing Agile software might find their “heads exploding” when working with hardware teams. She also said that interest is building in adapting Agile concepts to tangible products, meaning hardware, and that it is important for an organization to have allegiance to the product development goals, not the development process.

75% of the Agile Manifesto can apply to hardware as well as to software.

Some issues that need to be overcome:

  • Silos within the overall product teams
  • Integration (HW/SW) points usually not well planned
  • Hardware component lead times
  • Material supply risks (can vendor supply sufficient quantities)
  • Supplier qualification processes

Successful product teams use only a few tools. For hardware teams:

  • Sprints
  • More product prototype iterations (contrary to standard practice of minimizing prototyping costs)
  • Simulation/emulation
  • Local build

Key points:

  • Agile requires stronger team skills than Waterfall. It introduces a sense of urgency.
  • Getting a company to stop using waterfall complexly was often not feasible.
  • Hardware teams are more complex than software teams, with people responsible for manufacturing, supply chain, supplier selection and qualification, etc.
  • Agile magnifies cross-functional issues.
  • Sprints are 4-8 weeks long, typically.
  • User stories aren’t as effective as in software. The speaker suggested “boundary conditions,” in effect design goals that must be met for the product to be shippable. Boundary conditions seem to be like constraints or performance goals in Scrum, and apply to the entire product.
  • For one of her client’s teams, the product owner was an industrial designer.
  • Sprint goals aren’t always demonstrable hardware development, due to such issues as latency in getting prototype parts or qualifying a component supplier. Instead, goals can include progress to program goals, e.g. vendor qualification.
  • The project is managed to eliminate any out of boundary situation.
  • Burndown charts become “deliverable hit rates”
  • Marketing is the last to be trained on a hardware Agile process. Important to do a pilot with “the sharpest” marketing person.

I did not hear any discussion about who sets product goals or sprint-by-sprint user feedback, in the sense that the product owner does on a software Agile team. Those points appear to be external to the processes designed by the speaker’s company.

All this leads me to think that Agile for hardware is

  1. worth watching
  2. still evolving
  3. less likely to be standardized any time soon due to the range of hardware products and required engineering and manufacturing skills
  4. not something we are likely to encounter very often in the near future.


Learn More

If you would like to learn more about Product Management role in an Agile environment, take our new training course: Agile for Product Managers and Product Owners, available in-person or as an online course.

Download the first two chapters of Agile Excellence for Product Manager here:

Meet the Author

Phil Burton is a Principal Consultant and Senior Trainer for the 280 Group. His projects have covered the entire product life cycle and Phil has expertise in product definition, launch, messaging and positioning, collateral creation, competitive analysis and Agile methodologies.

Phil Agile Product Management Changes

Phil Burton
Senior Principal Consultant and Trainer

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *