“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)
