Agile Hardware - Support from a Surprising Source

“Agile development may be suitable for software development, but for hardware development we have to use something more formalized and waterfall just works for this”.

Some time ago I stumbled across the above comment. I can’t disagree more.

 

I have electrical engineering background and for two decades I have been involved with embedded systems development. I have never seen a specification being complete nor frozen before the design for electronics. To me that’s completely irrational idea. Further, I have yet to witness a project during which changes, and/or discovery, did not affect the pcb and mechanical co-design. Fast-paced iterative process models fit the challenge much better than up-front plan-driven. I have been lucky to work for more than a decade with people who think the same (at least on this topic).

Software development domain faced the same challenge and answered with Agile software development. But based on my own observation, product development is very similar ball game – despite the engineering discipline. Yet, in hardware development domain it is still not so rare to hear comments like above and for some reason waterfall mindset prevails.  This leads us to the main point of this post. Actually flexible hardware development is supported by a very surprising source; the authors that are cited to “demand the waterfall process model”!

To begin with, of course we, members of agile community, know that the original "waterfall paper" by Winston Royce actually argued against using waterfall approach (link).

Second, the N&N paper, which inspired Scrum framework for software development, did not talk about software development. The case projects developed copiers, cameras and cars. And this was decades ago, when these products were not that software intensive either (link).

Further, PMI’s PMBOK is not that exclusive either. It presents the waterfall approach, but only as one alternative process model. As equally considerable alternatives the guide presents models with overlapping phases and iterative approach.

Finally, Stage-Gate process model introduced to us by Robert Cooper has gone through several generations since its first introduction in 1986 and has continuously moved towards recommending the fast paced iterative development. However, the very first edition already recommended iterative, collaborative approach;

“…parallel marketing and operations activities are also undertaken. For example, market-analysis and customer-feedback work continue concurrently with the technical development, with customer opinion sought on the product as it takes shape during development. These activities are back-and-forth or iterative, with each development result – for example, rapid prototype, working model, or first prototype – taken to the customer for assessment and feedback”.

After this brief review, I summarize the situation to be exactly like the case with misunderstanding of Winston Royce’s paper but on a larger scale. People read the material to find what they want to find. Beauty is in the eye of the beholder. Or they skip reading altogether, and just go with their hard-wired mental model. As an example, several years ago I had a presentation with quotes from a process manual of a very large enterprise. The quotes were 100% supportive to agile development. I presented this to a room full of project managers and PMO directors. I asked if they knew from where the quotes were. None was able to answer. I asked who had read the complete process manual, their own by the way. None had. Despite this, they were very consistent in arguing that the very manual “demanded waterfall”.

This would be funny, if only it wasn’t true.

Incremental and iterative models are recommended for hardware development in the literature. For some reason, the adaptation rate seems much higher in software development domain. I think it is worth checking what actually made agile software development methods so popular in the industry and is there something to be learned for the system development domain. Yes, software development has certain characteristics increasing the flexibility, but my belief is that this is not the whole picture. Further, in systems development the product development challenges are shared between the engineering disciplines and it would be beneficial to have a shared approach to development.

Luckily, there’s been signs of more and more people getting interested in transforming the agile development knowledge from software development domain to system development domain (containing for example electronics and mechanical engineering), f.ex (link)

Knowledge about iterative hardware development exists, but learning together between the domains can’t hurt anyone. Agile Alliance has just recently initiated a program for Agile Engineering aiming at this (link)