Why do we need to adapt Scrum for hardware delivery?
Scrum was designed for Software teams. While it’s a flexible framework, Hardware delivery poses a set of challenges that are not often experienced by Software teams:
Medium to long term external dependencies and procurement wait times
Hardware often requires sourcing parts, agreeing contracts with suppliers, and waiting for the delivery of those parts. They may need to collaborate on the design specification of these parts with the supplier, and ensure the quality of received parts. Hardware teams may also have to seek external certifications and so ship items, wait for testing, and receive back items during a project.
These challenges are fairly unique to Hardware. Software teams seldom need to procure and wait for the supply of a physical item in order to proceed with delivery.
Short term dependencies, such as access to a specific laboratory or measurement setup, are frequently faced by Hardware teams. These short-term dependencies can also include temporary reliance on a specialist skill from outside the team.
In-sprint delivery of value
Hardware teams can often struggle to complete a given task in the sprint and therefore deliver value each sprint. Often many tasks will be ‘almost done’.
Specialist skills and expertise
Hardware products often require a much broader range of specialist skills. This poses a challenge for achieving a cross-functional team that can independently do all of the work required.
How we adapt Scrum for hardware challenges
MEQIFY has, through experience and working with their customers, developed several adaptations and additions to the Scrum framework to counter the challenges faced by Hardware delivery:
|Hardware challenge||adaptation to Scrum|
|Medium to long term external dependencies and procurement wait times||High Level Plan|
|In-sprint dependencies||Commitment point|
|In-sprint delivery of value||Focus Point|
|Specialist skills and expertise||Team competence diversity
Experts within and outside the team