My last blog post was about teams that only become really agile through experience. Today, the focus is on the challenges that agility brings to engineering.
Almost 20 years after the Agile Manifesto, agile software development has become widely accepted. It is no longer about whether, but only about best practices in detail and agile scalability. The success and ease of use of task boards, for example, have led to agile procedures also finding enthusiastic users outside software development where tasks are processed in a team.
This finally led to the increasingly intensively discussed question of whether physical products could also be developed more efficiently with an agile approach.
Why?
For many years, there have been established product development processes that have reached great maturity and support successful development. Why abandon them and take on the risks of a completely new approach?
The more unclear the requirements on the product are and the less known the technology to be used, the less suitable classical project management methods are, because they are very strongly forward-planning. It is precisely this tendency to start projects despite initially incomplete requirements that we are increasingly observing. Digitization and new technologies require new business models or new technological capabilities. This speaks for an agile approach, as it was invented to deal with ambiguity and not-yet-knowledge.
Is that even possible?
The decisive question here is: Are agile methods from software development at all suitable for mastering the challenges of “classical” product development? In contrast to software, physical products are developed with a much greater division of labour. The production of faulty components causes high consequential costs and the validation depends on physical prototypes. It is not possible to present a new, functioning and potentially deliverable stand every two weeks. Solutions for such problems require a creative further development of the known agile process models. A very simple example: The teams of different domains use different sprint durations. While the software team delivers every 2 weeks, the mechanics team delivers every 6 weeks. It is important to synchronize the sprints so that a common increment is achieved every 6 weeks.
The challenge
The challenge of introducing agile methods is therefore twofold: On the one hand, it is necessary to adapt the agile methods from software development to the conditions in product development. On the other hand – and this brings me back to my previous contribution – a lot of agile experience is needed to successfully make such adjustments. In order to resolve this contradiction, one should bring together the pioneers who dare to venture into new territory with experienced “agilicans” who master their craft in software development. Mutual learning and sharing of knowledge leads to a better mastery of product development under rapidly changing conditions.