BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Can Agile Development Work in Hardware Projects?

Can Agile Development Work in Hardware Projects?

Leia em Português

This item in japanese

Bookmarks

The question of Agile in hardware development has been raised by a number of commentators recently.
Neil Johnson wrote an EETimes article: Agile hardware development – nonsense or necessity?

He poses the question:

Should there be debate when it comes to applying agile in hardware development? Might the values and principles that guide agile software teams similarly guide SoC [System on Chip] teams; or are the differences between these two disciplines too great?

He continues the article with a discussion of the values from the Agile Manifesto (www.agilemanifesto.org) and how they underlie the Agile approach to software development. He then poses the question – can this work for hardware development? He says:

For anyone that views hardware development as being a creative process, it is hard to deny the values of the manifesto are directly applicable. But embracing a set of values is obviously not enough. At some point, abstract values have to translate into practice. Luckily, software teams have created a number of practices that embody agile values, many of which can be ported directly to hardware development.

He acknowledges the differences necessary between software and hardware development approaches, and encourages hardware teams to embrace the Agile practices which can work in the hardware space.

He uses the continuous delivery practice from Agile software as an example:

One ... practice of particular note is the practice of early and continuous deployment to customers. For many agile software teams continuous deployment is absolutely critical to their success. Unfortunately, its applicability in hardware development–or lack thereof–tends to be used to discredit agile altogether. For ASIC development in particular, continuous deployment is obviously not realistic; but one practice not being realistic should not be used to dismiss the entire suite of practices. No agile software team perfectly characterizes agile development; no hardware team could be expected to do so either.

He concludes with a call for change in hardware focused organisations:

Change happens in hardware development. Regardless of whether it’s due to changing specifications, employee turnover, team dynamics or new technology there is no avoiding it. The teams that drop their “Dilbert manifestations of make-work and arcane policies” for a better rounded, refocused and more humane view of hardware development captured by the manifesto will turn that change into an advantage. Teams that don’t will be left to complete the futile exercise of fitting a square peg–defined process–into the round hole that is modern day hardware development.

Larry Maccherone  recently wrote in a similar vein about the Top 10 questions when using Agile on hardware projects

He provides a list of questions and his answers to help guide decision making about the application of Agile approaches in hardware projects:

  1. Are Agile practices and processes effective when conducting non-software projects (firmware, electronic, mechanical, etc.)?
  2. What adjustments need to be made to make to the Scrum process framework work well for these projects?
  3. What adjustments need to be made to our expectations around minimal marketable feature, emergent design, and thin vertical slices?
  4. What adjustments to our expectations need to be made around user stories?
  5. What about prioritizing user stories strictly by value to the end user?
  6. Should user stories be our only tool for requirements management?
  7. But user stories are not even an official requirement of Scrum so why shouldn’t we just use our traditional requirements practices?
  8. What about when we need to send a board (or prototype part) out for manufacturing and it will not be done within an iteration?
  9. What about dependencies and critical path analysis?
  10. Maybe we don’t need continuous critical path analysis, but we still have specialists that are not permanently dedicated to the team. How do we deal with that?

For each question he provides a short answer followed by a discussion on practical approaches to address the potential mismatch and how to address them.


Can Agile practices be used in hardware development, and what changes are needed to make them work?

Rate this Article

Adoption
Style

BT