Agile Hardware Development

 

Agile Hardware Development

  HARDWARE-PROCESS “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, such as IT Operations and Production support, where they provide the benefits Agile is known for. Agile Hardware implementations can be put in place by using the same framework 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 hardware products, 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 process. An example of the overall flow of development, for hardware product that contains a software component, is illustrated in the figure: hardware vs. software   Info WHITEPPR HTRAINING The standard Scrum practices apply throughout. Each Team has a designated Scrum Master, Product Owner, and set of Team members. The usual “Scrum ceremonies” 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. The hardware 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.