Scrum and other agile methodologies have established themselves as a project management framework in software development. Working on large IT projects, I have come to appreciate the transparency that agile methods provide: everyone involved in the development process always has up-to-date information on how the project is progressing. Therefore, the right things are done on time.

I have been a project manager in the IT sector for almost 15 years. In the last 1.5 years, I have been involved for the first time in projects developing firmware for biotechnology laboratory equipment. This experience has shown me that scrum is also very well suited for such projects, as long as you keep a few things in mind.

Prioritising what you do is the key to success

The starting point for a firmware project is similar to any other software project: there is a set of functionalities that need to be implemented in the software, and a window of time to do it.

When working with an agile model, you can always focus on either the most business-critical functionality or the most difficult things that will require a lot of testing. Agile development allows you to react flexibly to changes during the project and to implement all the most essential functionalities without stretching the project schedule.

One important cornerstone of agile development is the smooth collaboration of the team. Scrum’s ideology of open knowledge sharing and problem solving together leads to good results in the world of firmware development as well. The more each team member is aware of what the others are doing, the faster it is to see problems and find solutions. This inevitably leads to a higher quality end result and perhaps a faster product.

Despite the active dialogue, the team must have a designated person responsible for monitoring the implementation of the priorities set and for taking decisions requiring a rapid response.

MVPs are not created overnight – attention to testing

Scrum is characterised by the aim to achieve the minimum viable product (MVP) as quickly as possible. In the world of hardware, it takes less time to get the finished software to the end customer, because the device itself plays as important a role in the development process as the software being developed for it. The latter cannot be used if the device is not used. Thus, not every development version of the firmware can be updated for the customer immediately.

Testing such a product requires, above all, an in-depth understanding of the end user’s needs. It is also important to ensure that both software and hardware testing is started early enough, as testing at the wrong time can lead to a significant stretch in the project schedule.

Let’s imagine a situation where the final testing of a product reveals the need for a change, which also results in the need to replace the device’s circuit board. It takes several weeks to obtain a new part from the manufacturer, which delays the final launch of the product under development. This situation could have been avoided by more careful prioritisation of implementation and planning of testing. In hardware/software projects, it should always be possible to anticipate the point beyond which no more ‘big and deep’ problems will occur.

Is Scrum suitable for the manufacturing of the device itself?

In the same context, I was able to observe an experiment in which the product development team working on the device itself adopted Scrum processes. The experiment involved people working in mechanics, optics and electronics.

During this period, the multidisciplinary team met regularly for reviews and the dialogue clearly developed cooperation within the team. Problems were identified earlier and possible solutions were discussed together. At the same time, the agile approach allowed for the development of practices to better support the team’s work.

The experiment showed that Scrum can also benefit non-software development teams. I hope to learn more about this topic in future projects.