Scrum in Hardware Guide Draft
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 (www.ScrumGuides.org) 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.
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.
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 ScrumColombia.org, 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.