“Hardware development” refers to the development of specifications for devices that are intended to be manufactured. Agile processes are not limited to the world of software development. They can be applied in other contexts, like Agile hardware developments projects for IT Operations and Production support, where they provide the benefits this amazing processes is known for.
Agile Hardware implementations can be put in place by using the same framework and project management tools as our typical Agile Software Development transformations. Start off with assessing the organization’s current state, then move to planning and preparing by and putting together a transition backlog, start execution with training and coaching, spread the cultural shift with change management and maintain and scale the transformation.
How to Apply Agile to Hardware:
For software products, new and usable features appear steadily over time, which are aggregated to form a newly-released product. For Agile hardware development, we do not produce a steady flow of usable features, causing some product features become usable late in the development cycle. However, the deliverables can still be developed and tested throughout the cycle, and this is the key point. This enables the continuing scope adjustment and refinement needed to hit planned shipment dates with the best possible value. More specifically, it enables a Scrum project management process.
An example of the overall flow of development, for hardware product that contains a software component, is illustrated in the figure:
The standard Scrum practices apply throughout. Each Team has a designated Scrum Master, Product Owner, and set of Team members. The usual “Scrum ceremonies” and project management tools of Backlog Grooming, Sprint Planning, Daily Stand-Up, Review, and Retrospective are held.
While the day-to-day experience of software development is very similar from one Sprint to the next, this is not the case for hardware development. Agile hardware development work progresses through qualitatively-distinct phases, as illustrated in the diagram. Thus while the hardware teams continue to build and test deliverables in Sprints, the nature of those deliverables commonly changes over time.