Is Agile hardware development a pipe dream or a reality? Well... that really depends on how you view Agile, and how closely you adhere to your chosen methodology. The key to the entire matter is how you interpret the Agile Manifesto. It's a short, masterfully written document that can apply to hardware development with the correct interpretation. It's an unusually short read, so lets take a quick look at it to determine what can translate to hardware development. Because hardware projects can vary dramatically based on application, we'll use a small video player as an example. We'll also use the most popular Agile methodology, SCRUM, to discuss Pros and Cons.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The most important sentence, as it applies to hardware, is the final one. Unfortunately, it is also the one that is least often referred to. It gives one a sense that this is a list of guidelines, not a set of rules. It also implies that items on the left and right are not mutually exclusive. This allows for a much wider interpretation that can be applied to non-software projects.
Individuals and interactions
over processes and tools:
Stressing individuals and interactions is, in my opinion, the single most important benefit of Agile in a hardware project. For too long, hardware (and software) engineers were subject to long checklists that they had to fill out before moving to the next step. These checklists were beneficial to management, but tended to slow the pace of development to a crawl. Too much time was spent feeding the process beast, leaving too little room for creativity and innovation.
SCRUM puts a heavy stress on product teams. In a hardware environment, this represents a welcome shift in daily interactions. Hardware engineers are accustomed to being given a list of requirements, then told to implement them exactly as specified. Interactions with the rest of the team were limited to "did you implement this feature correctly". Now, interactions can include early feedback about how the design can be modified to improve the product. This is especially beneficial in a startup environment, where you are unlikely to have a large team of hardware experts working on the design. Often, your hardware engineer is the only one who can tell you when you have violated the laws of physics. You'll want that information as early as possible.
The one caveat here is that there are processes and tools absolutely necessary for a successful hardware product. There are specific events in the hardware development cycle that require certain processes be followed, and tools are the only way to do that efficiently. For example... It's time to fabricate an alpha PCB for your video player. You will need to make sure that obvious mistakes in part numbering, PCB layout, and device availability don't lead to a needless failure. Your hardware engineer will want to go through the formal process of validating the design using any and all available tools. Only then can the design be turned over to a manufacturer. Failure to perform this task can be seen as malpractice, and your engineer knows this.
Working software (or hardware... my substitution)
over comprehensive documentation:
This is the aspect of Agile that causes the most consternation among hardware engineers, and is also the most controversial. First of all, there are events in the hardware development cycle that simply must
include comprehensive documentation. Let's use the example of building your alpha video player again... Before you can get anything manufactured, you will need to supply a comprehensive Bill Of Materials (BOM) to your manufacturer. Anything incomplete will be rejected, or result in an incomplete device. You will also need a complete mechanical drawing. Again... anything incomplete will be rejected. There is no way around this. A certain amount of comprehensive documentation is essential to working hardware.
Having said all of this, I do not believe that the Agile Manifesto is an attempt to eliminate all documentation. It's more of an attempt to eliminate unwarranted
documentation. Anyone who lived through the bad old days of DOD-STD-2167A
would naturally have an adverse reaction to reams of paper generated for the purpose of checking a box on a form. The one and only project I was involved with that attempted to comply with this standard was a nightmare of bureaucracy. (Case in point: It took nearly a year to write a bookshelf full of required documentation... and coding couldn't start until it was complete.) Taken in this spirit, it is an easy matter to trim back the amount of paperwork in a hardware project. It can be limited to what is necessary for physical realization of the product, and need not include large design documents that nobody will ever read.
Next is the concept of "working hardware". SCRUM addresses this by instituting sprints. A sprint is a one to three week iteration
in which a feature is added, and a working product is released. The major problem here is that it can be horribly inefficient to iterate through most hardware designs simply to add a feature. If you don't plan for major features in advance, you will end up re-designing everything... often. Let's use the example of the video player again. A customer has requested that you add a video recording feature. Sounds reasonable, doesn't it? Well... no. Your CPU is inadequate for the job, and you don't have enough memory. You will have to re-design from scratch. Maybe the request is more simple... I want to be able to view 4K video. Again... re-design from scratch.
While it is possible to find a hardware group that adheres to SCRUM-style sprints
, most hardware development has no chance of following them. Many tasks just take too long to fit within a sprint. While it's possible
to account for them, all of the methods that have been proposed to me have been very un-Agile, or have only covered very specific projects. On this point, SCRUM just gets in the way.
over contract negotiation:
For entrepreneurial startups, this doesn't usually apply. In the case of hardware, you are more likely to target a market than an individual customer. To me, it's an obvious improvement that affects hardware and software alike, but only in specific cases.
Responding to change
over following a plan:
Responding to change vs. following a plan for a hardware project is not a binary decision. It's more of a sliding scale that starts to the left, then progresses toward the right as product release approaches. Early in development, design changes are relatively simple to implement. Changing a feature, or adding a new one, can be done in short order with minimal expense. However, as the product progresses, changes become increasingly difficult, and have a much greater impact on budget and schedule. Once you get to the beta hardware stage, you are effectively stuck with "following a plan".
The reasons for this are simple. Software changes can be made independently, then integrated into the product at will. In the case of hardware, making changes may require you to back up a few steps and re-work a large fraction of your design. If a change happens after or just prior to release, it can also nullify your product's certification, and require you to spend many weeks re-certifying your design.
Agile concepts can be applied to hardware development, but they require a common sense interpretation to be successful. If you throw away your one-size-fits-all methodology and stick with the basic concepts, there is a lot that Agile has to offer in the hardware world.
General references to web sites or pages that would not result in an SEO-friendly link (i.e. www.example.com/index) are allowable. All tags will be automatically stripped