Hardware Development with Scrum - dummies

Hardware Development with Scrum

By Mark C. Layton

Many similarities exist between implementing scrum in software and hardware projects. You might hear pushback that the differences between the two products are too great; scrum can’t work with both. Not true. The basis of scrum is that if you can encapsulate the work to be done and prioritize it against other work, you can use scrum to your immense benefit.

A key element with hardware projects and scrum is to focus on feedback, early and often, just like with manufacturing. You may not have as much to work with at the beginning, but keep moving in that direction. Keep producing workable increments at the end of each sprint, and what you have to show customers and stakeholders will grow. And it’ll do so with their feedback incorporated.

In hardware projects, change is inevitable, too. You’ll be better served to accept the fact and turn it into an advantage. Denial will get you nowhere. Fortunately, change in hardware project design and development is totally workable and practical.

If you can find a way to discover defects and problems early on, it will save you time, money, and hassle. With waterfall, testing was left until the end. After having read so much about scrum by now, I’m sure that you can see how incredible that seems. Why test only at the end when you can test all along the way and find and resolve defects early?

Scrum forces more timely integration between firmware and software. Scrum helps break down functional silos and gets engineers working together to solve problems, rather than crashing together later as they discover problems.

In the daily scrum, which is no more than 15 minutes a day, coordination of what’s been done, what’s going to be done, and what impediments are in the way can be achieved. This should happen within teams and between them wherever dependencies exist.

In projects where the number of members exceeds a dozen or so, when adopting scrum, it is common practice to split into smaller teams so that each team is within the 7 +/– 2 range. Each scrum team has their daily scrum, and one member from each of the roles on each of the teams then meets for a coordinating daily scrum called a scrum of scrums. The format is the same as individual scrum team daily scrums. The value is that direction, dependencies, and impediments get identified and coordinated and resolved daily.

Open source hardware is a gift to scrum and engineering as a whole. As open source submissions increase, organizations will be able to more quickly and creatively implement existing designs, frameworks, and architectures that will get their product to market more quickly.