Agile Hardware: Lessons Preview
By: Kevin Thompson, Ph.D., CSP, PMI-ACP
The word most people would expect to follow “Agile” is “Software,” not “Hardware,” but we are finding that the Agile techniques pioneered in software development can work for hardware development, as well.
This should not be a surprise. While Agile processes were first developed and labeled as such for use in Software development, proponents of Agile techniques have long declared that “Agile” can be used in other areas as well.
Yet evidence for this proposition is weak. The Scrum framework for Agile development has been an enormous success for the world of software development, but no other field has seen anything like the explosion of Agile techniques. That’s not to say that nothing else Agile exists—Kanban has made some inroads into IT operations, customer support departments, and DevOps—but nothing like the astonishing success of Scrum for software development has been seen elsewhere.
That may be about to change.
In late 2013, I embarked on a journey of discovery, teaming up with John Carter (TCGen) and Scott Elliott, Ph.D. (TechZecs) to conduct pioneering research in the area of Agile Hardware development. John and Scott had the hardware-development background I lacked, while I had more experience in the Agile realm. Together, we reasoned, we should know enough to figure out what Agile Hardware development should be.
We were right.
After a year and a half of research, including interviewing people at nearly 20 companies that developed hardware and software systems, we had learned a great deal. We learned that hardware companies were beginning to introduce isolated Agile techniques into their development processes. Examples included:
- Dividing time into short cycles, or Sprints, for planning purposes
- Planning with ‘sticky notes on a wall’
- Using modified Burndown charts to track count of remaining Tasks in schedule
- Ranking features by value
- Overlapping the prototyping of circuit boards to deal with long fulfillment cycles
Perhaps the most important things we learned were that (A) companies were starting to think along these lines, but (B) no company had anything resembling an official, end-to-end Agile process.
The results were both frustrating and exciting. Frustrating, because the guidance we’d gotten from our interviews was much sketchier than I’d expected. Exciting, because I realized the field was wide open for defining a new Agile process.
While the interviews were useful for understanding the current state of hardware development, my partners’ deep knowledge of the nuts and bolts of hardware development was critical in working out how to define this new process. We had many discussions about the assumptions and constraints that characterized hardware development, and by the time we’d finished analyzing our interview data, the outlines of Agile Hardware started to become clear for me.
The result was nothing like I’d expected.
What did I expect? What was the result?
