The first scenario that you picture when you hear “Scrum” is, most of the time, a small development team that work on a modern app in a sort of small and informal environment with almost no rules (I am exaggerating a bit… perhaps).
This is a pretty common cliché, somewhat easy to debunk. But what do you picture when you hear “Scrum… for hardware”? Scrum is usually associated to software development so perhaps you could think that I meant “Lean” and not Scrum. Actually I really meant to say Scrum.
Don’t get me wrong. Lean is a great approach to manufacturing. It minimizes variance (i.e. waste) and therefore improves cost and quality. On the other hand it can be counterproductive if applied to achieve change or innovation. There is always a trade-off between innovation, which is a form of variance, and the cost needed to support the change.
Lean is not the right tool to support innovation. It is a great tool, but not if you, sometimes, value waste.
A growing number of companies are successfully adopting Scrum as the framework to deliver innovative hardware projects. There are many factors behind this choice. Rapid prototyping, learn and adapt from early feedback are a couple of them.
A company famous for its application of Scrum to hardware development is SAAB. They run Scrum to build the multi-role strike fighter SAAB Gripen JAS-39. It is a well know success story of Scrum, adopted to develop hardware and software, that is running for more than ten years.
There are a handful of practices that can be leveraged, regardless whether you work on software or hardware.
Make your work visible is one of them. In that way, the issues become also visible and you will be able to unveil hidden delays. Ideally, all the work should be visible in order to enable the whole Company to benefit from this approach. You will also be able to avoid bad surprises. Nobody will be able to say “I didn’t see that coming”.
This is a very easy practice to implement. Even if you are not following a cadence (i.e. sprints) it is fairly easy to set-up a physical or virtual board to enable visual management. Moreover, it it a great help for prioritization.
With the right prioritization and the stress level under control thanks to reduced changing priorities or unclear goals, the team can focus on perhaps the most valuable practice of Scrum: “inspect and adapt”. Work to get early feedback from your customers and improve the way you run your daily operations. A hardware project can benefit as well from faster feedback thanks to mock-ups and prototypes. A common scenario is to use simulators to enable prototyping for the hardware product.
To make Scrum work, it is key that the impediments are identified early and removed quickly. With the help of the visual management you can make clear that the sprint is at risk by highlighting the issue and make it easier to escalate it. After all the upper management wants the development team to be fast so it is only fair to ask them for help. There should be in place a lean and well understood mechanism to escalate issues and solve big dilemmas without making it sound an emergency every time. I am not talking about processes (they might help), I am talking about a mind-set always ready to tackle the issues. A mind-set always ready for feedback.
Last but not least, work at a sustainable pace. If all the teams start the four-week sprint the same day and follow the same length it becomes easy to synchronize the Company around the same “heart beat”. Change management will follow just as a natural consequence. It is also worth measuring the velocity (just counting the cards is a starting point) to understand what your “sustainable pace” mean.
Sometimes, it seems that using Scrum for a hardware project contradicts the rules that have been established over the years of successful adoption of the framework for software projects. Obviously, hardware and software projects have significant differences in their nature and this has to be taken into account when adopting Scrum.
One of the most striking differences is that a software project is capable of deliver usable features over time whereas an hardware project delivers its value at the end i.e. we don’t have a potentially shippable product at the end of each sprint.
There are many challenges when developing hardware, but none of them should stop you from trying Scrum for your project. It is a safe bet to consider hardware projects to run in a highly regulated environment, where physical safety plays a critical role and where the cost of failure can be very high.
Another challenge is to implement agile estimating (e.g. using poker estimate to quickly determine the rough size of a story in points or t-shirt sizes) because there is little overlap of skills and therefore discussing about estimates to gain a better understanding of the work ahead is pointless. The specialization skills needed by the team members to work on a hardware project set them apart therefore not all members are always able to challenge or contribute to the story estimate.
The high diversification of specialization skills makes it also difficult to do pairing or swarming because only a few members could have the skill-set needed to collectively work on the critical story that is not progressing at the velocity we would like to see.
As written on hundreds of other blogs, Scrum is not a silver bullet that solves all the issues you might encounter during your project, but you should definitely be open an try it also if your product involves a considerable amount of hardware.
There are many success stories of Scrum being implemented for software and hardware projects therefore I encourage you to give it a try.