Embedded meets IT

Developing automotive embedded software using agile methodologies and SAFe

The traditional V-model development process has worked well for a long time. But projects based on this approach reach their limits when it comes to complex software systems for autonomous, connected driving. So is this approach completely wrong now? The answer is both yes and no.

Software for connected, autonomous vehicles is never finished. It is continuously updated over the air. This has consequences for the development. It is very difficult to assess project complexity in advance. Even creating a detailed specification of the development goal can be challenging in some fields. Development teams are essentially “driving by sight” and if they come up against technical difficulties or new aspects when using traditional methods, they often have to move a few steps back in the process – and that means taking their colleagues and suppliers back with them.

Faced with similar dilemmas, the world of IT resorts to agile methodologies: prototypes are created in short sprints and immediately reviewed and approved by the customer. The Scaled Agile Framework (SAFe) provides a methodology toolbox for scaling agile working methods across all levels of product development. The only question is whether this also works for the high safety requirements in the automotive sector.

Figure 1: The Stacey Matrix created by Ralph Douglas Stacey classifies problems according to the complexity of the requirements and knowledge of the technology.

The right tool

There is no one “right way” of doing things in software development. The less that is known about the requirements and technology at the start of a project, the more important it is to have flexible tools. Nobody would reach for a hammer if they were still unsure whether they would be dealing with nails or screws. The same applies to development methods: their usefulness only becomes clear once the task is known (Fig. 1).

Dave Snowden’s Cynefin Framework (Fig. 2) helps project planners make an initial assessment. For simple tasks, where the relationship between cause and effect is obvious, planners can let themselves be guided by the “best practice” approach. In contrast, complicated tasks require analyses of the principles of cause and effect or the application of expert knowledge in order to find a “good practice” approach. This good practice approach has become the standard method for automotive development projects based on the V-model.

In the case of complex problems, the relationship between cause and effect can often only be understood in retrospect – it cannot be fully described at the start of the project. When introducing new technologies, developers therefore proceed experimentally in short cycles. This incremental approach with agile working methods and SAFe is becoming a popular choice in development projects for autonomous, connected vehicles. The final level in Snowden’s framework is that of chaotic problems. If the relationship between cause and effect is not discernible, developers have to proceed by trial and error, continuously adjusting their methods to get the situation under control. This is the approach taken in a crisis.

Figure 2: The Cynefin Framework shows how different problems require different approaches.

Summing up this aspect, the question of which approach will achieve the goal fastest depends primarily on the type of problem. In the real world, tasks change and technological expertise increases steadily, so the chosen methods need to be flexible enough to ensure the focus remains on the goal.

Focus on the goal

When it comes to developing complex vehicle systems with unknown technologies, agile methodologies make it possible to work toward the development goal in incremental steps. Throughout this process, it is important not to lose sight of the overall goal and the planned milestones. The decisive factor at all stages is the added value for the customer.

The incremental approach and immediate review and approval of prototypes by the customer make it possible to change course whenever necessary. All decisions are made within the team, including the distribution and prioritization of all tasks. Maximum transparency and mutual trust are therefore essential in order to plan projects efficiently, prioritize tasks correctly and ultimately come up with the best technical solution.

The Scaled Agile Framework (SAFe) is a set of organization and workflow patterns that support agile development methodologies, including Kanban, DevOps, Scrum and customer/user-centricity as well as Big Room or Product Increment (PI) planning. This latter method offers everyone involved the opportunity to bring together all their ideas and visions in one (virtual) room in order to agree on a common route forward that best aligns with these ideas and visions. This approach serves to dovetail product management and development.

Experience gained during implementation

ETAS has been using agile methodologies of software development for almost a decade. Their gradual introduction was driven by the adoption of new technologies. The first teams began working with the new approach in 2011 following an initial heatmap-based analysis of benefits. They quickly understood and adopted the agile methodologies and the number of successful projects steadily increased. In 2014, agile methodologies were implemented by additional teams in the fields of embedded systems and hardware development. Since 2017, ETAS has also been using SAFe for the step-by-step scaling of cross-team collaboration and the coordination of development work.

One of the keys to the new methodology’s success was that the heads of the various groups and departments supported and actively promoted it right from the start. Yet there were also challenges. The pilot groups soon realized that there was no longer any intrinsically right or wrong approach. The most promising method for each specific problem had to be reassessed in each individual case. The Stacey Matrix and the Cynefin Framework provided useful assistance in this context, making it easier to classify the problems and reach a shared understanding. Heated discussions about the right method to choose belonged to the past.

Initially, the teams sought their own individual ways of creating and optimizing solutions, which led to redundancies in the portfolio: components with similar functionalities were developed and brought to market multiple times, which prompted confusion among customers, pushed up maintenance costs, and hindered product interoperability. To remedy this, ETAS developed the Solutions principle in 2014. ETAS defines Solutions as functionalities that are based on the interplay be-tween multiple products and components. Each Solution solves at least one customer problem. Interoperability of the individual products is essential. PI planning meetings proved to be an indispensable part of implementing this principle, leading to a strong focus on common goals and prompting tangible changes in working methods and a significant boost in motivation.

Figure 3: The two basic structures in an organization can be compared to a skeleton and muscles.

Further important findings

In addition to the technical complexity, there was a consider-able need for coordination between the projects, which have to take into account a multitude of dependencies and inter-actions between products in the ETAS portfolio. Interoperability creates added value for customers, so the decision was taken to make these dependencies easier to manage and control. This requires optimum embedding of agile working methods within the organizational framework. The DevOps automation approach is ideally suited to achieve this: it uses shared incentives, processes, and development tools to facilitate more effective collaboration between the Development, IT Administration (Operation), and Quality Assurance (QA) teams.

Process optimization and process digitization are closely interlinked. The operational organization that creates value – including value for the customer – and the supporting organizational structure are inseparably linked, much like the muscles and bones that comprise the human musculoskeletal system (Fig. 3). The introduction of agile methodologies therefore sets in motion a holistic transformation (Fig. 4). This is by no means an automatic process. One tried-and-tested way to help counter frustration and doubts is by assigning well-connected associates as facilitators. A clear commitment from management and defining clear responsibilities are also essential prerequisites.

Figure 4: Numerous areas are involved in organizational development.

Summary: a positive outcome

Ten years after the introduction of agile working methods, the outcome has been positive. Planning reliability and customer satisfaction have noticeably improved. Using the new working model, we are continuing to meet essential safety requirements as required by ASPICE and ISO 26262. Increased productivity, higher associate satisfaction, and greater reliability confirm that we are on the right track. Our approach is seen as setting a pioneering course within the Bosch Group and in the world of SAFe. And the fact that we are putting our agile methodology into practice is additionally attractive in the highly competitive market for skilled workers. This benefit offers further encouragement to hold our course as we make our agile way into the connected future.

Authors

Richard Mutschler is Chief Chapter Lead Agile Leadership and Head of Lean Agile Center of Competence & Solution Train Engineer at ETAS GmbH.

Oliver Trost is Chief Chapter Lead in the field of product management at ETAS GmbH.

Jürgen Crepin is Senior Marketing and Communications Manager at ETAS GmbH.

Embedded meets IT Download