Scrum in Hardware Guide

  |   Agile, Uncategorized, Xtreme Manufacturing   |   10 Comments

This guide is an early release draft.  Please add any suggestions for improvement in the comments.


This guide serves to define Scrum in Hardware with specific technical practices and patterns to achieve rapid releases and short iterations in Hardware. Any company can utilize this guide and confirm their implementation on Scrum in Hardware along with clear steps to do it better. This document refers to Scrum as defined in the Scrum Guide ( without tailoring or modification.

Scrum in Hardware

Agile projects focus on releasing early and often, and harnessing change for the customer’s advantage, even late in development. How could we possibly afford to do this in hardware?! This guide is composed entirely of production projects and team practices, including highly regulated industries, and may be used for organization structure or re-structuring.

Uncertainty in hardware projects

Hardware projects have more material costs involved and tend to have a higher risk of sunk cost and cost of change. Those increase during the lifecycle of the project and inversely relate to the uncertainty in the project. We reduce the cost to make change, even late in development, through modularity, flexible mass production tooling, few materials which are compatible with the fastest and most flexible tooling available to us, and minimalist (elegant) design.

Stubs and Mock-Ups

Prototypes help the team gain an overall understanding of the product, handle interfaces and test assumptions. Using the first draft of the production intent interfaces with prototypes as early as possible maximizes learning and minimizes risk. We recommend teams building stubs of each module that will be connected in sprint one.




The final product should be producible in one week. This allows for weekly review by any interested stake holders and compliance officials to reduce risk, which deprecates the need to divide a hardware project into phases for risk reduction. In cases where the technology to do this does not yet exist nor in a team, we can split into modules which quarantine long-lead, complex, or highly regulated areas. The way of dividing a hardware project ‘slicing’ is important. It should be possible for each team to test assumptions about their module without depending on other teams. E.g. testing the wind resistance of a car exterior works better when only one team owns and works on the exterior. Modules can also be used to separate the areas with the longest test and certification cycles so that other areas may be iterated and approved more quickly.

Continuously Integrate

We can only ship a module if it passes all tests after being plugged into all the other modules in our system. As software projects speed up by automating the integration, hardware teams have tremendous speed advantages if they also automate the integration of what multiple teams produce. This likely means automated robots, and may mean a flexible team of craftspeople ready to plug various teams’ outputs together and run through a prepared checklist of integration tests.


Interface design

Interfaces should be designed in a reusable way. Fragile or elaborate interfaces with many steps to connect or disconnect discourages experimentation. Further they should be planned with at least 10x capacity of what is needed. This does add weight and size at the boundary between modules. In exchange, the speed of iterating the entire system increases. This allows us to more than make up this weight and size gain while building in room for growth in our finished product which is The most expensive to change.

Test and Data Driven Development

Development should be designed in way to test assumptions (test driven development). Hardware test cases can be written. With IoT and sensor technology data about almost every behavior of hardware parts can be measured and should be used to continuously improve.


Team members should collaborate, be co-located and pair at least per module. The fastest teams we observe have clear tests to pass, a very quick feedback loop to validate new ideas against those tests, and are willing to work collaboratively and outside their core expertise.

Working product at the end of each Sprint

The ultimate test of having Scrum in Hardware work is if you have a working product at the end of each Sprint.

Joe Justice is President at Scrum Inc. and the founder and CEO of Team WIKSIPEED. Joe’s work includes collaboration with Bosch, Microsoft, Toyota, Amazon, 3M, Ford, Boston Scientific, QuintilesIMS, Chevrolet, MIT, HP Labs, the founder of Xerox Park, among hundreds of others, to ship products and services in one week sprints or less.

Team WIKISPEED is an international manufacturer of road legal automobiles with operations in 23 countries and a 1 week new model introduction cycle; open source, collaborative building products, like road legal cars, like Wikipedia editors update articles.

Fabian Schwartz is the founder of, CEO of CASMENA Executive Development and SBS Management Consultants.

William Newing is the founder of Pink Cherry Blossom consulting firm and Product Owner of the WIKISPEED Lynnwood, WA, USA factory.

Chris Wallace is a professional Scrum Coach, Consultant, and Product Owner of the WIKISPEED Burleson, TX, USA factory.

Mary Michael Justice is the Scrum Master of WIKSIPEED corporate, assembled the first Scrum team at the company, and removes impediments to happiness or velocity from the top management level.

This document is copyright 2017 Joe Justice. It is available to be used anywhere without modification.

  • Brandon Richardson | Mar 11, 2019 at 1:44 AM

    Hi, this is all very inspiring! I am curious/confused about one thing though – the focus on modularity is at odds with other scaled scrum methodologies such as LeSS (these are intended for software though, so i guess there may not be a 1-1 relationship). Specifically, the goal-post for software scrum teams is to make them feature oriented as opposed to component/module oriented. Do you think it will be possible in the future to make hardware teams feature oriented vs Module oriented? This would require incredible flexibility and speed of integration, test, and build technologies and practices. Great work!

  • J. Michael Hayes | Oct 3, 2018 at 11:36 PM

    When you talk about having a “working product” at the end of each sprint, what does that really mean in a hardware environment?
    Is it a complete product that is ready to ship to a customer,
    is it a product that is ready to be qualified (I work in a highly regulated environment, so this is an important distinction),
    is it ready for interface testing,
    does it mean you have a working prototype,
    or is it environment dependent?

    The other issue I am having with hardware development is the sprint or iteration cycle times. I can break down a lot of things, but some of the basic products that I have built in my projects take weeks or months just for the fabrication cycle alone. I suppose you could make that a single sprint or a set of sprints, however it seems like something that would need to be adjusted given the specialized equipment and talent that is sometimes needed to produce some products. And you would not have a working product at the end of each cycle. I am trying to gain a better understanding of how you would align large or complex hardware to the sprint cycle or if it makes more sense to face reality and extend sprints when fabrication or testing just takes that long to complete.

    What are the options for dealing with this type of issue?

  • Agile bzw. Scrum in der Hardware Entwicklung – Projektmanagement Blog | Mar 29, 2018 at 1:15 PM

    […] WIKISPEED ist ein überaus cooler Case. Hier wird kollaborativ und auf methodischer Basis von Scrum ein Auto konstruiert und gebaut (Video). […]

  • Diane Adams | Oct 19, 2017 at 2:06 PM

    Hi Joe,

    I will review in more detail as soon as I can and thank you for asking. My initial reaction is this is great if intended for practioners, but if that is not the only audience, it may be helpful to consider all the potential customers/end users you may want to reach. Will this resonate with each customer type?

    For example, if looking at this wiki site, if I’m a CIO, what would capture my attention at the beginning to read all the way to the end? maybe an initial section “Why Scrum in Hardware”. This may not fit with your overall scope and objectives, as an ITIL shop I always have to put on how to sell/market to my customers.

    Will review more thoroughly soon and update my thoughts.

  • Alex | Oct 4, 2017 at 6:37 AM

    Is this guide still alive and in progress?
    Scrum in HW is a hot topic for us and if so I might be able to activate our HW PO to contribute

    • Chris Wallace | Oct 10, 2017 at 3:46 AM

      It is still very much alive and in progress. We need to incorporate some of the input from other members of Team WIKISPEED. Any input you would like to offer would be much appreciated.

      • Montserrat Anglès | Jan 31, 2020 at 6:58 PM

        Hi Joe, I’ve was looking for scrum in hardware electronics development. With mechanics,I get the idea, but in electronics development is very difficult for me to extrapolate it. It would be greate if electronics design examples exist (like images of the plane) but referred e.g. to an electronic module which has to control wipers, central locking, lamps, warning lights and gateway car communications…

  • Paolo Sammicheli | Jul 11, 2017 at 1:37 PM

    Hi Joe,

    The interface design chapter could be improved. I remember these principles from your trainings, I think they could be stated as a list, like this:
    1) Define the modules of your product (each module assolve some responsibilities, Avoid to have responsibilities divided across modules as much as possible. Ie: chassis is one module because we want aerodynamic responsibility in one module)
    2) Define the interfaces between modules, and leave space for growth (I’m not sure about the 10x suggestion, but yeah, make it way bigger than needed)
    3) Define those interfaces for being easily plug and play. (It shouldn’t be painful to change the module because of the interface.)
    4) For each interface, if there are risks in one of the two modules involved, place an adapter (ie: modules you buy from others)

  • Diane Adams | Jun 13, 2017 at 10:25 PM

    Hi Chris!

    I am speaking in a symposium next week (internal J&J Coaches & Scrum Masters) and I will be happy to provide feedback after the session using the key messages from this presentation

  • Borrador de: Guía Scrum en Hardware - Scrum Colombia | Jun 2, 2017 at 4:43 PM

    […] Scrum in Hardware Guide Draft […]

Post A Comment