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

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Maybe

    by Chris Goldsbury,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If by hardware project we mean "chip design" or "motherboard design" then the big blocker is manufacturing runs to create those things in an agile fashion. It's expensive and time consuming to do an initial run so there is a high premium on getting it right up front. If by hardware project we mean "designing and building a new rack in our clean room" then I think this could easily be done via agile.

  • Re: Maybe

    by Bryan Morris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hey Chris:

    I collaborate with Neil Johnson on the AgileSoC site. Specifically, for Neil's comments, they are referring to ASIC & FPGA development. The agile approach is definitely possible since there is pre-manufacturing verification -- all done in simulation systems. For FPGAs a release is actually similar to software where a 'load' can be placed onto a FPGA (and this can be done many times on the same FPGA similar to EEPROM in that respect). Neil and I both think adopting the iterative approach where the "release" is an incrementally increasing functional system (in simulation) that can be proven correct through passing tests, metrics (e.g., code and functional coverage), etc.

    As well, some of the same front-end design techniques e.g., TDD work quite well in ASIC/FPGA development. Especially, as the Non-Recurring Engineering (NRE) costs for a newish generation ASIC can easily exceed $1M, and the development cycle is anywhere from 9 months to 2 years.

    -- Bryan

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT