Scrum beyond software - Some clues on Scrum in the hardware and mechatronics development

1. Scrum is based on organisational patterns, which were also used by hardware development teams in the 1980s/1990s. For example:. Honda City 1981 and Canon AE-1 in 1978. The basic principles were formulated in the article on Scrum written by Hirotaka Takeuchi and Ikujiro Nonaka, which was published in the Harvard Business Review in 1986: The New New Product Devlopment Game. Thanks to the fathers of Scrum the framework is so light and lean that it can be applied to product development of any kind. Thus one will not find the word „software“ in the two standard definitions of Scrum: Scrum Guide and Agile Atlas.
2. Scrum could evolve rapidly through the pressure to innovate, which exists in the IT and software environment. Little by little Scrum finds his way (back) into the other areas such as hardware development. At best, you will find the expert knowledge of software and hardware combined in a team. And so there are examples to learn from:

• Scrum at Soplar - The Scrum team develops industrial facilities and works closely with the small-series production together. 
• Wiki Speed - A very exciting open source development project for a 1.5 liter car. Still far away from the everyday industrial use but it could be an outstanding source for collecting insights.

3. The most important arguments in favour of Scrum are usually found in the response to the questions "What can it bring us?" And "What does it cost to implement it?". The more complex the task is, the more productive and innovative the cross-functional Scrum teams are as compared to the rigid phase-oriented teams. In the software development there are uncountable many examples and a tremendous wealth of experience that demonstrate this added value [1]. Because of this experience we also know that the way to get there is often very rocky (which is unfortunately often kept secrete), and thus we’ve switched over to the topic „Cost“. The development team is challenged to use new development practices, as an essential principle of Scrum is to deliver early and regularly in order to create transparency about the progress. Software is virtual and seems to suit this approach very well. Hardware on the other hand seems to be too expensive to throw it away in a minute cycle as software developers sometimes do, if they use test-driven development. Once hardware developers are challenged by the Scrum framework, they quickly realize that they also can develop and test a lot virtually as software teams do. One can say that the meaning of the source code for a software developer is comparable to that of the model in the CAD application for a hardware developer. And productive use of some new software can sometimes be much more expensive as many hardware products are. Again, software and hardware development are closer than many think. However hardware developers have much to invent yet. While a software specialist can decide between hundreds of open source and commercial tools, all of which were developed to support agile work, or at any time find information about Agile practices in the network and in the community, a hardware developer have to rely on the creativity and skills of his own and his colleagues. The larger outlay in a Scrum implementation, however, is to find an answer to the question, how to deal with the transparency, created through Scrum. Because Scrum calls to transform the resulting transparency consistently through constant checking and adjusting the product and the workflow in an added value for the customer. Impediments that now work against a Scrum  team have nothing to do with software or hardware development but with the development of the organisation itself. And many organizations and in particular the management are (still) not ready for that. Without active support and coaching from the outside the initial euphoria of the development team won’t last long. We know that well from the software development and like to spare the hardware colleagues.

More on the subject: Can you use Scrum for construction projects?

[[1] Case Studies bei der ScrumAlliance