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!
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.
In-sprint dependencies
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 |
How the adaptations work
High Level Plan
- 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
Commitment Point
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.
Focus Point
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.
Team competency diversity
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.
Experts within and outside the team
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.
