Scrum for Hardware development

Can Scrum be used for Hardware development? How can I apply agile to Hardware delivery? Does Scrum work for Hardware teams?

We have heard these questions alot and pride ourselves on knowing the answer: Yes you can apply Scrum to hardware delivery, and this guide will help you understand how.

Over decades of working with Hardware teams, MEQIFY has honed its unique approach to adapting the Scrum Framework for hardware teams and delivery. It’s assumed in this guide that you’re familiar with the basic Scrum framework.

If you’re working in a Hardware team and want to use Scrum, you should attend MEQIFY’s Scrum for hardware course, but until then this guide should help you understand more about how Scrum works for Hardware delivery!

Photo of hardware being developed during Meqify's scrum for hardware course

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:

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.

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’.

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 challengeadaptation to Scrum
Medium to long term external dependencies and procurement wait timesHigh Level Plan
In-sprint dependenciesCommitment point
In-sprint delivery of valueFocus Point
Specialist skills and expertiseTeam competence diversity

Experts within and outside the team

How the adaptations work

Photo of hardware being developed during Meqify's scrum for hardware course
  • The High Level Plan represents medium and long-term hard commitments or dependencies, such as; procurement wait times or contract fulfillment
  • To gauge size and detail, the plan should fit on one presentation slide comfortably
  • The Product Owner is responsible for its creation but the whole team is accountable – therefore the team should be creating this together

If in-sprint (short term) dependencies are uncovered during Sprint Planning e.g. physical access to a lab or test rig, then it may be that the Sprint Plan cannot be committed to by the team. The Commitment Point is a check-in with the Team 1-2 days after Sprint Planning to either commit to the plan, or replan a sprint that the team can commit to delivering.During Sprint Planning the team will agree what actions need to be taken in those two days to attempt to resolve the dependency. Of course, any tasks planned for the Sprint that would be unaffected by the dependency and are still valuable can be worked on in those two days, but there is a temporary priority to resolve the dependency and commit to the sprint.

Towards the end of the sprint the Focus Point is a specific check-in with the team regarding sprint progress and focus on the sprint goal. If many sprint items are ‘almost’ done or are likely to be by the end of the sprint, but none complete, then the team needs to refocus on completing the items essential to the sprint goal. The Focus Point should support value being delivered in the sprint, rather than ending a sprint with many things almost done.

In Scrum we want cross-functional teams that can do all the work required to deliver a product. For Hardware this can often be more difficult. We strive for Hardware teams that can create at least 80% of the product. Otherwise, the amount of dependencies faced by the team increase risk, coordination and wastage (time, effort, productivity). This also means we want ‘T-Shaped’ team members; they have skills in a broad range of areas that overlap with others’ in the team as well as deep specialist skills.

Internal ’Experts’ in the team:

If one of your team members is an Expert who needs to advise other teams or areas of the organisation in their role, still keep all their work and capacity transparent to the team (yes, include it in the backlog as needed!), they are still part of the team.

External experts temporarily needed in the team:

Depending on the flow of work required from an external Expert, you can invite them fully into the team for a sprint (or more, as needed). The same as above applies if having them for a sprint. At the least, they should be in Sprint Planning, Review and Retrospective for whatever amount of work is needed from them in the Sprint.

We can support you

Want to know more about Scrum for Hardware delivery? Get in touch with us or join our next Scrum for Hardware course.