Using agile methods in the automotive industry is currently a widely discussed topic. In comparison to other industries, it took the automotive industry rather long to realize that they needed to change the way they developed software. In the past, reliance upon the V-cycle/Waterfall model was the norm. According to this model, the customer (in theory) knows all of his requirements (often several thousand), gives them to a development team (either internally or externally), who then take several month or even years to implement it. Sounds simple, right?
Well, not exactly. If you look closely you will find that there are several issues with this approach. Firstly, customers usually don’t know all of their requirements right from the beginning (even if it is the 10th Sunroof, Head-Up Display or Body Controller they are requesting). Secondly, the technical complexity of these systems is growing constantly, making it impossible to control using conventional methods. Thirdly, this technical complexity necessitates that a large number of people become involved in the system’s development, which in itself can lead to confusion and complications. Because of this, it can be concluded that software development, also in the automotive domain, has become a complex journey in which nobody knows in the beginning where it will exactly end up (check my post about complexity).
So how is it possible to fit flexible and even unpredictable work into an environment where everything is about planning and control? Since automotive is a highly regulated area with lots of standards (ASPICE, Functional Safety,..) agile methods cannot not be applied as easily as in other fields like web development. While a lot of people even argue that it is not possible at all, I strongly disagree. The key is to focus on the values rather than focussing on the methods.
In my last job, I worked as process and quality manager in the software department of an automotive supplier. In this role I had the chance to act as a coach to the development team and introduce agile methods. My main goal was the make work more enjoyable for everyone involved by reducing wasteful work, improving productivity and making sure that the team was proud of the software it delivered to the customer.
With some experience using Scrum, my team started with a similar concept that had been customized to fit automotive micro-controller development. Based on given structures with strong silos for requirements management, software development and testing, the first goal was to reduce feedback time. Using iterations for synchronization effectively reduced feedback time from weeks or even months to just days. Simply this increase in communication between silos resulted in everyone getting involved in requirement reviews. Due to a better view of the overall value chain, this in turn led to real collaboration, a reduction of wasteful effort, and much better product quality.
Even if agile practices cannot be implemented as written, it can make all the difference in the world to simply focus on all of the various people involved and their interactions with each other.