Scrum is commonly adopted in software product development. It comes as no surprise that other business areas show interest in using it. However, until recently, creating physical products using iterative approach seemed to be impossible. But the landscape has changed and the adaptive hardware development is gaining popularity.
Recently we’ve joined several other coaches, trainers and leaders on Scrum for Hardware training. The course was led by Joe Justice, founder of Wikispeed and President of Scrum@Hardware at Scrum.inc who’s my huge respect. It was a great session with a lot of insights and ‘a-ha’ moments, but I’d like to focus here on my most important observation.
We’ve been there before
“Agile is already happening in Hardware development” said one of the managers responsible for Saab Gripen fighter development. For me, it looks like we’re back to where Software has been in the 1990s. On the one hand there are companies that are excelling Agile Hardware Product Development and don’t even imagine working in any other way. On the other hand most other firms haven’t even heard about it and when they do, their reaction is disbelief followed by “it won’t work here”. It seems that these companies are struggling with exactly the same problems Software had twenty years ago.
Scrum in Hardware is already happening
We were lucky to see numerous examples of rapid hardware product development.
The Wikispeed team, led by Joe Justice, is capable of delivering a new version of the road-certified car every week. Note the ‘new version’ words - it’s not another instance of an existing product assembled according to a predefined procedure, but a car with potentially different suspension, engine or the entire body.
Another great example is Solar Roof developed by 3M and Tesla. It took them five weeks from idea to installation on houses. The product is not just generating energy, but it is also more durable and competitive on price compared to regular roofs. And looks great.
However, the product I was most impressed by is a Saab Gripen fighter. It’s developed by four thousand people in short, 3-weeks iterations, tested and integrated at the end of every sprint. And its costs are about 18% of F-35, which is being developed with a traditional approach.
Five reasons, why Scrum for Hardware is difficult
Above examples are great, but for most companies moving to Agile Hardware Development won’t be quick or easy. After the discussions I had with others I see five main obstacles to companies transformation. And if you’ve been to software development in the 90s and 2000s you’ll see exactly the same patterns we had there.
1. Monolith Architecture
Most of the products are developed in monolith architecture. Changing one piece of product requires changes in all other parts. In software, we’ve solved it by object-oriented architecture, modularity, stable interfaces and encapsulation. The same is now happening for hardware products. There’s also a growing list of reusable components speeding up the development process, such as Raspberry PI, available on the market.
2. Current development and testing practices and tools
Hardware development takes ages compared to how software is done. Testing is often done at the end of product development and leads to delays and last-minute fixes. Agile development requires rapid prototyping using simple tools, including 3d printers that are easily available for the team. It also asks for test automation by CAD simulations and tests performed by programmable tools and robots. Of course, that requires time and money, but on highly competitive market delivery time is one of the critical factors of the product success.
3. Current structure and processes
In many companies, even the purchase of a new part can take months. Just by addressing bottleneck of internal processes these firms can significantly improve their time to market. There’s a lot of waste in current development processes, including handoffs, narrow specializations, decisions made by people far away from problems, phase-gate approach and yearly budgeting process. A lot of time is lost on over-processing, reporting, redundant documentation, multitasking and context switching caused by a large number of products being developed in parallel. Last, but not least individual targets and performance appraisals prevents cooperation and teamwork.
4. Mental models
If the points above weren’t enough, the biggest obstacles are inside us. Our mental models question the need for change. We often hear sentences like “we can do it right for the first time”, “we don’t have time to experiment”, “we can’t fail”, “it needs to be perfect to be shown to the customer”, or “people are resources” and “my role defines me”. Only by addressing these models by training, coaching and support, we can hope for a change.
5. Fear of the unknown
The biggest challenge however, is the fear of the unknown. People used current methods for decades and are afraid when someone asks them to forget anything they learned so far and start something completely different. If, instead of support from coaches and managers, they’re still having old targets and are measured individually, their reaction most likely will be fear, visualized by “it won’t work here, because...”. Job safety, not role safety, is necessary for any successful change.
It’s a long road ahead of us.
“Agile has crossed the chasm” said recently to me Lyssa Adkins. Yes, I can fully agree that it’s true for Software development, but we’re not even to early adopters in Hardware. And Hardware development is at least ten times bigger than Software market. So the revolution is coming, no matter if your company is ready for it or not.
If you'd like to learn more about Scrum outside Software development, please check our Case Study from Scrum in Sales and Customer Support teams.