Introduction to the combined

Application of Agile & Safety

in Automotive Software
Development

German Electrical and Electronic Manufacturers’ Association

Imprint
Introduction to the combined Application of Agile & Safety in Automotive Software Development
Publisher:
ZVEI - German Electrical and Electronic
Manufacturers’ Association
Electronic Components and Systems and
PCB and Electronic Systems Divisions
Lyoner Strasse 9
60528 Frankfurt am Main, Germany
Phone: +49 69 6302-276
Fax: +49 69 6302-407
E-mail: [email protected]
www.zvei.org
Responsible:
Dr. Stefan Gutschling, ZVEI

Februar 2021
While every care has been taken to ensure the accuracy of this document, ZVEI assumes no liability for the
content. All rights reserved. This applies in particular to the storage, reproduction, distribution and transla-
tion of this publication.
Table of Contents

1 About this Document 4

1.1 Motivation 4
1.2 Target Audience 4
1.3 Scope 4
1.4 Prerequisites for Combining Agile & Safety 4
2.1 Agile Values, Principles, Methods and Practices 5
2.2 Possible Misunderstandings Regarding “Agile Software Development“ 5

2 Introduction to Scrum and ISO 26262 5

2.3 Scrum 6
2.4 Agile Scaling 6
2.5 Functional Safety 7
2.6 ISO 26262 – Functional Safety of Road Vehicles 7
2.7 Interrelationship between Scrum and ISO 26262 8

3 Workflow 10
3.1 Scrum Workflow 10
3.2 ISO 26262 Safety Life Cycle 10
3.3 Challenges 11
3.4 Solutions 12
4.1 Scrum Roles 13
4.2 ISO 26262 Roles 13
4.3 Challenges 13
4.4 Solutions 13

4 Roles 13

5 Artifacts 16
5.1 Scrum Artifacts 16
5.2 ISO 26262 Artifacts 16
5.3 Challenges 16
5.4 Solutions 16
6.1 Refactoring 17
6.2 Pair Programming 17
6.3 Continuous Integration 17

6 Other Agile Practices 17

6.4 User Stories 18

7 Recommendations for Audits/Assessments 19

8 References to other Documents 20

9 Participating Companies 21
1 About this Document

1.1 Motivation ISO 26262 only mentions the handling of configu-

The future value of automobiles will undoubtedly be ration and calibration data quite briefly and Scrum
created through software. Whereas software contrib- does not describe data handling approaches at all.
utes about 10 percent of the added value today, it
is expected to rise to 40 percent by 2020 (Morgan Also, agile system development as well as security
Stanley Research, 2016). Software and the relevant aspects will also not be discussed here. As the impor-
electronic control units are paramount for enabling tance of both areas is expected to grow, they may be
trends in the automotive industry, such as auto- included in future considerations of combining agile
mated driving, connected car and electric mobility. and safety.
With an average modern high-end car compromising
up to 100 million lines of code, managing software 1.4 Prerequisites for Combining
development efficiently, while adhering to all safety Agile & Safety
related issues have grown highly in importance. For combining agile and safety in the institution
of question, two prerequisites must be met for the
Traditional methods applied for organizing software application to be suitable.
development (e.g. planning the whole project from
start to end) may not provide the flexibility needed 1. A suitable quality management system must
for handling innovation. have already been established within the
institution. In an automotive context, ASPICE
In contrast, agile principles can stimulate efficient Level 2 is an appropriate reference for process
organization and planning of software development, maturity for software development.
also in a functional safety context. 2. If agile methods is to be introduced in an
organizational unit that already develops
1.2 Target Audience safety-related software, a suitable functional
This document targets people with experience in safety management system and development
either functional safety or agile software devel- and engineering approach for safety-related
opment in the automotive industry. Furthermore, software must have already been established
this document can be of relevance to anybody who (e.g. suitably performed process, method and
is familiar with quality management systems. It is tool enhancement regarding development of
important to note, that a functional quality manage- safety-related embedded software in accord-
ment system must already be established as a pre- ance with the applicable ASIL).
requisite for an agile & safety application.
Furthermore, it is highly recommended that all rel-
1.3 Scope evant employees either have experience with both
This document describes how agile practices can be function safety and agile methods
combined with the functional safety standard ISO
26262 when developing safety-related automotive
embedded software. As such, the discussed ISO
26262 requirements are primarily focused on part 2
“Safety Management” and considerations on part 6
“Product Development at the Software Level”, part 8
on “Supporting Processes” and part 9 on “ASIL-ori-
ented and Safety-oriented Analyses”. Scrum, its
workflow and roles, will be detailed as an agile
method in combining agile with safety due care.

In this document, we will focus on software develop-

ment, knowing that an already large and increasing
part of function development is data-driven.

4
2 Introduction to Scrum and ISO 26262

2.1 Agile Values, Principles, Meth- Agile Methods

ods and Practices Most agile methods are derived in alignment with
The term agile was popularized by the Manifesto for the values and principles of the manifesto for agile
Agile Software Development by a team of seventeen software development. The agile methods Scrum and
software developers in 2001. As mentioned earlier, Kanban are nowadays the most commonly known.
motivation for adaptive software development arose This document will discuss Scrum, its workflow and
from difficult and cost-intensive solutions when application in a safety context in detail.
faced with spontaneous changes and requirement.
The agile manifesto outlines four fundamental val- Agile Practices
ues and complements those with twelve additional Agile practices are descriptors of best practices
principles. that support the implementation of agile software
development. These can cover various areas such
Values and Principles as requirements, modelling, coding and testing. In
The agile manifesto is based on the following four combination, these agile practices enable the imple-
core values: mentation of the different agile methods. Due to the
1. Individuals and interactions over processes and large number of different agile practices, a selection
tools. of them are outlined in this document and will be
2. Working software over comprehensive docu- discussed in detail in chapter 6:
mentation. • Refactoring
3. Customer collaboration over contract negoti- • Pair programming
ation. • Test driven development
4. Responding to change over following a plan. • Continuous integration
• User stories
The four core values are supplemented by twelve
principles that offer further clarification on agile 2.2 Possible Misunderstandings
practices: Regarding “Agile Software Develop-
1. Customer satisfaction by early and continuous ment“
delivery of valuable software. Parallel to the comprehensive agile methods and
2. Welcome changing requirements, even in late practices, it is not uncommon that some agile
development. concepts are vaguely understood or even misinter-
3. Working software is delivered frequently (weeks preted. Some misunderstandings are cleared up in
rather than months). this section.
4. Close, daily cooperation between business
people and developers. “Agile means that you don´t have to follow any
5. Projects are built around motivated individuals, processes.“ The application of agile development
who should be trusted. practices in automotive requires suitable develop-
6. Face-to-face conversation is the best form of ment processes that are well-defined and monitored
communication (co-location). strictly. In order to enable agility, it should be pos-
7. Working software is the principal measure of sible to improve them easily and quickly. The pro-
progress. cesses should be defined in such a way that all teams
8. Sustainable development, able to maintain a are able to adapt and improve their individual way
constant pace. of working as long as no other teams are concerned.
9. Continuous attention to technical excellence
and good design.
10. Simplicity – the art of maximizing the amount
of work not done – is essential.
11. Self-organizing teams.
12. Regular adaptation to changing circumstance.

5
„Agile only plans short-term.“ The combination of a determined to facilitate development teams to
rough long-term and a detailed short-term planning deliver working software within few weeks. To ena-
provides the necessary outlook just like traditional ble this objective, their management framework
planning but also reduces waste in case of plan Scrum defi nes three distinct roles and describes an
changes. iterative, incremental development process (https://
www.scrum.org/resources/scrum-guide). As an agile
„Agile needs no documentation.“ Documentation method, Scrum is primarily an attitude towards
is reduced to the necessary minimum, e.g. for ena- relationships between employees, managers and
bling maintenance and customer guidance. Docu- customers. This attitude is also refl ected in the ter-
mentation intended just for short-term knowledge minology of Scrum, with its origins being borrowed
transfer is replaced by close human interaction. from rugby. In rugby, Scrum describes the situation
when the ball is introduced into the play. Players
„Agile has no automotive application.“ All subject from both teams are packed closely together in a cir-
matter activities necessary for compliance with cular formation, attempting to gain as much ground
quality and safety standards can be included like as possible. Translated to the management frame-
all other tasks. In fact, quality and safety can be work, it is supposed to symbolize the coherence of
improved by an agile working mode, e.g. because the Scrum team and the adherence to rigid roles
suitably applied agile approaches can ensure a con- and processes. The Scrum workfl ow and its roles are
stantly high-quality level and usually supports early described in detail in the following chapters.
verifi cation or even validation.
2.4 Agile Scaling
„Agile can’t handle unforeseen requirement Agile practices and their benefi ts have traditionally
changes.“ During an implementation iteration, been enjoyed by small, co-located teams, as agile
requirements should not be changed, but agile prac- practices were originally designed for a small team
tices enable very late requirement changes without size. To leverage these good results in larger organi-
rework. This enables fast adaptation to changed zations and more complex environments, agile prac-
market needs. tices must be scaled. To meet challenges, including
the integrating of non-development activities, dif-
2.3 Scrum ferent agile scaling frameworks have been proposed
Scrum is a management approach to support the by experts. These agile scaling frameworks are
management of a cross-functional team, especially applied to large projects with multiple cross-func-
in an environment for software development. Jeff tional teams. In the automotive industry the most
Sutherland and Ken Schwaber, inventors of the commonly used frameworks are LeSS and SAFe.
Scrum development management process, were

Figure 1: LeSS overview diagram (source: The LeSS Company B.V.)

6
Figure 2: Full SAFe confi guration (source: ©Scaled Agile, Inc.)

2.5 Functional Safety 2.6 ISO 26262 – Functional Safety

The topics of safety and risk have been growing in of Road Vehicles
importance in the public eye, as the number of elec- To meet functional safety requirements and develop
trical, electronic and programmable systems have according to state of the art, it is reasonable to
been increasing exponentially to satisfy the demand develop according to established international
for more automated and electrifi ed functionalities. standards. These serve as proper basis for argument
These range from essential vehicle functions such during product liability cases by providing evidence
as steer-by-wire and brake-by-wire to more complex that all reasonable functional safety objectives were
features such as connected car and highly auto- satisfi ed. ISO 26262 is an international standard,
mated driving. Hazards resulting from malfunction- which covers the functional safety of electrical and
ing behavior of E/E systems caused by contained electronic systems of series production road vehicles.
hard- and software, fall under the defi nition of func-
tional safety. ISO 26262 includes guidance to mitigate risks from
systematic failures and random hardware failures by
To warrant functionally safe products from a legal providing appropriate requirements and processes.
perspective, product development and its related ISO 26262 provides an automotive safety life cycle
safety aspects are expected to be developed accord- by addressing the safety-related aspects of devel-
ing to state of the art. For instance, under the Ger- opment activities and work product and an auto-
man product liability act the following is mandatory: motive-specifi c risk-based approach to determine
“The duty of replacement by the manufacturer is integrity levels. These integrity levels are referred
eliminated only, if the error could not have been to as Automotive Safety Integrity Levels (ASIL). ASILs
detected according to state of the art in science and are used to specify applicable requirements of ISO
technology at the time of bringing the device into 26262 to avoid unreasonable residual risk. These
market” (Product Liability Act, §1 Cl. 2, Cypher 5). are further supplemented by requirements for ver-
State of the art in science and technology is defi ned ifi cation, validation and confi rmation measures to
by established standards, current products on the ensure a suffi cient level of safety.
market and other literature, such as papers and
publications.

7
 1. Vocabulary

2. Management of functional safety

3. Concept phase 4. Product management at the system level

7. Production,
12. Adaptation of 5. Product 6. Product operation, service
ISO 26262 for development at development at and
motorcycles the hardware level the software level decomissioning

8. Supporting processes

9. Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

10. Guidelines on ISO 26262

11. Guidelines on application of ISO 26262 to semiconductors

Figure 3: Source Structure of ISO 26262: 2018 (source: Elektrobit Automotive)

Figure 3 below shows the structure of ISO 26262. It does not however specify in what ways these require-
consists of twelve parts and is based upon a V-model ments must be met. Agile methods support to meet
as a reference process model for the different phases ASPICE collaboration-related requirements by, for
of product development. The “V” represents the example. assigning roles and facilitating interaction
interconnection between parts 3, 4, 5, 6, 7 and 12. between stake holders. Figure 4 shows the interrela-
tionship between functional safety, ASPICE and agile
For application of agile software development in this case the agile method Scrum.
approaches, part 2 on “Management of functional
safety”, “part 6 on ‘Product development at the soft- Scrum, as seen in Figure 4, can support meeting
ware level”, part 8 on “Supporting processes”, and ASPICE requirements regarding Project Management
part 9 on “ASIL-oriented and safety-oriented analy- and therefore also assists in meeting corresponding
ses” are of primary relevance. requirements in ISO 26262.

2.7 Interrelationship between

Scrum and ISO 26262
ISO 26262 mentions Automotive SPICE® (ASPICE) as
a means to achieve a working quality management
and to establish suitable basic software development
processes (QM to ASIL D). ASPICE is a framework for
improving and evaluating processes within the auto-
motive industry. ASPICE targets repeatable project
success through suffi cient process quality. ASPICE

8
Agile ASPICE Functional Safety
System Engineering Process Group (SYS)
SYS.1
Requirements Elicita�on
1. Vocabulary

SYS.2 SYS.5
System Requirements Analysis System Qualifica�on Test
2. Management of functional safety

SYS.3 SYS.4 - System Integra�on and

System Architectural Design Integra�on Test 3. Concept phase 4. Product management at the system level
7. Production,
SWE.1 - So�ware
So�ware Engineering Process Group (SWE) SWE.6 12. Adaptation of 5. Product 6. Product operation, service

Supports Supports
Requirements Analysis So�ware Qualifica�on Test ISO 26262 for development at development at and
motorcycles the hardware level the software level decomissioning
SWE.2 SWE.5 – So�ware Integra�on
So�ware Architectural Design And Integra�on Test

SWE.3 – So�ware Detailed SWE.4 –

Design and Unit Configura�on So�ware Unit Verifica�on 8. Supporting processes

9. Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

Suppor�ng Process Group (SUP)
SUP.1 SUP.4 SUP.4 SUP.7 10. Guidelines on ISO 26262
Quality Assurance Verifica�on Joint Review Documenta�on

SUP.8 SUP.9 SUP.10 11. Guidelines on application of ISO 26262 to semiconductors

Configura�on Management Problem Resolu�on Mgmt. Change Request Management

Figure 4: Interrelationship between Functional Safety, Automotive SPICE®, and Scrum (source: Elektrobit Automotive)

Scrum Supports Compliance to ASPICE ASPICE Compliance Supports Compliance to ISO

In one sprint (nearly) all ASPICE process areas may 26262
be processed. This makes it possible to assess and ISO 26262 part 8 (“Supporting processes”) demands
improve the process maturity regularly after each the usage of confi guration and change manage-
sprint in the project. Thus process changes can ment. ASPICE is explicitly mentioned as an example
almost immediately be tested in the project regard- of a possibly applicable standard in this context.
ing improvement impact and efforts. This increases
quality, effi ciency and acceptance of the resulting ISO 26262 part 3 (“Concept phase”) describes how
processes. As ASPICE does not assess the theoretical technical risks are classifi ed according to so called
processes, but their practical application in a project, Safety Integrity Levels (ASIL) or “QM”. QM indicates
the acceptance of a defi ned process by the project that quality processes are suffi cient to manage the
team is essential for achieving a good ASPICE rating. identifi ed risk. For risks classifi ed with an ASIL,
requirements from ISO 26262 come on top of the
Doing all activities related to one function in a very normal quality processes. Therefore software devel-
short time frame within one team makes it much opment compliant to ASPICE can be considered as
easier to keep, for example. requirements, design, the necessary basis for compliance with ISO 26262.
implementation and tests consistent and to link
them in a traceable way, which is a central require-
ment of ASPICE.

9
3 Workflow

Daily Scrum Meeting

Impediment
Product backlog Sprint goal backlog Usable Software

Sprint backlog

Figure 5: Scrum Workflow (source: Elektrobit Automotive)

3.1 Scrum Workflow

Scrum is one of the most widely applied agile meth-
Backlog
ods. Scrum describes an iterative, incremental devel- Retrospective Preparation
opment process. The Scrum process is illustrated
below in Figure 5.

In the initial step, the role of the product owner lists

a priority of user stories, which are coherent require-
ments for the overall software product. This set of Sprint Sprint
user stories is referred to as the product backlog. All Review Planning
following goals and tasks are pulled from the prod-
uct backlog. A subset of these user stories is pulled in
each iteration, referred to as a sprint. For each sprint, Daily
usually with a fixed duration of one to four weeks, a Scrums
sprint goal is defined during the sprint planning. The Figure 6: The Iterative Process of Scrum (source: Elektrobit Automotive)

subset of user stories during each sprint is called the

sprint backlog. The development team should meet 3.2 ISO 26262 Safety Life Cycle
the requirements set by the sprint goal and ide- ISO 26262 describes a safety life cycle of auto-
ally deliver a usable software product at the end of motive E/E systems. The safety life cycle consists
each sprint. The development team is continuously of three phases, from the product idea to its final
assisted by the Scrum master, who manages the pro- decommissioning, in which all relevant safety activ-
cess and eliminates all occurring obstacles along the ities are embedded in. The three individual phases
way. Daily Scrum meetings are held, primarily for are divided in Figure 7 and are classified as “Con-
the development team to interchange and discuss cept phase”, “Product development” and “After the
what has been done so far, what is planned until release for production”. All phases of ISO 26262
the next daily Scrum meeting and what impediments require defining persons, departments and organi-
they have come across. Daily Scrum meetings also zations responsible for the individual safety activities
give the product owner the possibility to stay up to and the confirmation that the items under consider-
date and answer questions when required. ations are developed in accordance with ISO 26262.
The concept phase initiates the safety life cycle.
Figure 6 shows the iterative Scrum development The objective of the concept phase is to define and
management process. Each sprint concludes with a describe the functionality of the item, its dependen-
sprint review, where the accomplished user stories cies and interactions with the environment and other
are demonstrated. The development team receives items. Adequate understanding of the item func-
feedback from the product owner and all present tionality then supports the completion of activities
stakeholders. During the subsequent Scrum ret- in subsequent phases. Central to the concept phase
rospective, the development team, assisted by the is the hazard analysis and risk assessment (HARA).
Scrum master, reflects upon the achievements of the The HARA is a method to identify and categorize
sprint and discusses commitments to improve the potential vehicle-level hazards due to malfunction-
next sprint. A new sprint follows, by pulling new user ing behavior of the item and formulate safety goals
stories from the product backlog. This cycle contin- to prevent or mitigate the hazardous events.
ues until the final software product can be delivered.

10
2-5 Overall safety management
2-6 Project dependent
safety management 3-5 Item definition

2-6 Impact analysis at

the item level

6-6 Hazard analysis and

risk assessment

3-7 Functional safety

concept

4 Product development at the Allocation

External Control-
system level to other
measures lability
technologies
2-6
5 Product 6 Product
Confirmation
development development
measures
at the at the
hardware level software level

2-6 Release for

production
2-7 Safety management regarding
production, operation, service and
decommissioning
7-6 Production In the case of a
7-5 Planning for modification,
production, back to the
operation, service appropriate Outside the item
and decommissioning 7-7 Operation, service
and decommissioning lifecycle phase Inside the item

Figure 7: Source ISO 26262 Lifecycle (source: Elektrobit Automotive)

The product development phase of the safety life This does not contradict with the requirements of ISO
cycle offers guidance on the product development 26262 as long as it can be ensured that each sprint
and the corresponding functional safety activities at is based on adequately mature input work products
the system level, the hardware level, and the soft- needed for the development of safety-related soft-
ware level. ware and that the resulting software is used in a
suitable way considering the achieved level of safety
Functional safety confirmation measures are per- maturity. Therefore, no software that is suitable for
formed to provide additional evidence for the vehicle testing may be generated in preliminary
achievement of functional safety by the item and its sprints.
elements during the development phase.
Working increments delivered with every sprint
3.3 Challenges may achieve a certain functionality, however from
Scrum and Scrum sprints with a fixed duration of one a safety perspective all increments must also fulfill
to four weeks are based on an iterative approach. corresponding safety requirements. Thus besides
At first glance, it may seem that Scrum sprints are offering working software, additional effort is
not easily matched with the hierarchically modeled required to also achieve the required level of safety
structure of ISO 26262. The major objective at the with each sprint.
end of each sprint is to deliver working software.

11
3.4 Solutions Additionally, both Scrum and ISO 26262 support
To maintain an organization-wide safety culture, a maturity model with corresponding maturity lev-
additional safety activities and mechanisms can be els. Maturity levels define a degree of completion.
included in the product backlog (e.g. definition of By introducing a maturity model, efforts regarding
the required minimum safety maturity depending safety can be divided into maturity levels and dis-
on the intended use of the software, such as vehi- tributed over multiple sprints. The necessary quality
cle testing on proving ground versus testing on and maturity of work products (e.g. software, docu-
public roads). By suitably integrating safety aspects ments, and, if applicable, hardware) to meet safe-
into the backlog and the implemented software, a ty-related due care, can be achieved with suitable
Scrum-based development management supports “Definition of Done” and the corresponding accept-
adherence to safety requirements. A dynamic sprint ance criteria (acceptance review).
backlog also welcomes changing requirements,
even in late development phases, unless there is Detected safety issues are included into the backlog,
an unreasonable negative impact on safety. From prioritized and solved in sprints using a risk-based
a Scrum perspective, teams must be aware that no approach. A subset of all safety requirements may
unrestricted usable software product may be gener- be postponed and implemented later depending on
ated in early sprints during a product development. factors such as milestones defined by stakeholders
Therefore, project planning must not be reduced to (e.g. customer or yourself) or required safety matu-
the planning of each sprint, but must consider the rity of the software depending on the intended use
milestones of the entire project. of the product. It is not necessary to achieve full
safety maturity at the end of each sprint.

12
4 Roles

4.1 Scrum Roles 4.2 ISO 26262 Roles

Scrum defines three roles with distinctive responsi- ISO 26262 primarily defines the safety manager
bilities, the product owner (PO), the development (SaM) role. The safety manager is responsible for
team (DT), and the Scrum master (SM). Together planning and coordinating the functional safety
these roles form the Scrum team (ST). activities in the development phase (i.e. define and
maintain the safety plan and monitor the progress
The product owner is responsible for the product of the safety activities against the safety plan). The
backlog. Based on product functionality, the product safety manager ensures adherence to ISO 26262.
owner determines the requirements, formulates, and
provides a uniform view of the final product and its For product development at software level the safety
intended use. The product owner is responsible for activities include:
providing and maintaining the product backlog and • Development or refinement of software safety
for periodization of the contained product require- requirements.
ments (e.g. user stories) to maximize satisfaction of • Development and analyses of the software
all relevant product stakeholders. After each sprint, architectural design.
the product owner may change the priorities and • Development and implementation of the soft-
functions, as well as accept or reject the delivered ware units.
functionalities (e.g. implemented user stories). • Software integration at different integration
levels.
The development team is responsible for product • Verification across the development cycle.
implementation by using suitable technologies (e.g. • Activities to ensure confidence in used software
software). A Scrum development team, comprised of tools.
4 to 10 self-organizing members, realizes the final • Applicable functional safety confirmation
product using an incremental approach. The devel- measures.
opment team adheres to the tasks set during each
sprint backlog to achieve the goal of each develop- 4.3 Challenges
ment cycle. The development team is responsible Merging safety aspects with Scrum faces two chal-
for carefully executing the development activities lenges. The first is to ensure that the Scrum team is
required, to provide the defined product in time and adequately aware of the safety-relevant due care for
quality considering the state of the art for the tech- each Scrum role. Secondly, the question arises how
nologies used (e.g. state of the art for software engi- the role of the safety manager (or its tasks) can be
neering). The work results of the development team addressed in Scrum.
are demonstrated regularly to the product owner
and other relevant stakeholders. 4.4 Solutions
Handling of Roles
The Scrum master is responsible for Scrum process For safety-related due care, each Scrum role must
adherence. The Scrum master assumes a supportive additionally cover the following tasks:
role for the team, by ensuring readiness and produc- • Product owner:
tivity of the team. The Scrum master further facili- • Ensures that the product backlog also
tates close collaboration between roles and functions contains the required safety-related content
and coaches the team when necessary. To keep the (e.g. technical safety requirements allocated
team goal-oriented and on course, the Scrum master to software or corresponding DIA elements).
clears up impediments and protects the team from • Requests achievement of functional safety
interference on the way. for the developed product in accordance
with ISO 26262 and the applicable state of
A definition of Scrum including a more detailed the art for the subject matter (e.g. vehicle
description of Scrum roles/events/artifacts is given domain).
by the “Scrum Guide” (https://www.scrum.org/ • Provides the required infrastructure and
resources/scrum-guide). resources for a safety-related development.
• May also be assigned the role of the safety
manager.

13
• Development team: • Scrum master:
• Considers higher effort for the development • Supports adherence to safety-related due
of safety-related products in its effort esti- care (e.g. considering the DIA and require-
mation (e.g. additional effort for imple- ments of ISO 26262-2 or ISO 26262-6 for
menting safety measures). the development of safety-related software).
• May also include a dedicated safety man- • Ensures the timely provisioning of the
ager as development team member. required infrastructure and resources for a
• Performs the development with the required safety-related development.
due care (e.g. considering the DIA and • May also be assigned the role of the safety
requirements of ISO 26262-2 or ISO manager.
26262-6 for the development of safety-re-
lated software). The safety manager must also reflect suitable agile
• Ensures that the applied development practices when defining the safety plan. These are:
processes, methods and tools or design and • Supplement the “Definition of Done” with safe-
coding guidelines are suitable (e.g. consid- ty-related content.
ering the requirements of ISO 26262-6, ISO • Support the product owner in the creation of
26262-8, ISO 26262-9). safety-related backlog.
• Informs the safety manager and product • Coordination with other stakeholders (e.g. with
owner about the achievement of func- OEM or suppliers according to DIA).
tional safety for each sprint based on the • Coordination of the required additional func-
corresponding objectives (e.g. set of safety tional safety confirmation measures.
requirements to be implemented that are
required for the intended use of the gener-
ated product version).

14
 Combining Roles Figure 10 illustrates a larger Scrum project. A full-
There are multiple different ways to combine the time safety manager is part of the Scrum team.
ISO 26262 roles with the Scrum roles. The combina-
tion is largely affected by how the role of the safety A constellation of multiple Scrum teams is shown in
manager is handled. It is important to note that the Figure 11. One full-time safety manager is support-
safety manager does not have to be organizationally ing multiple Scrum teams. Within each Scrum team,
independent from the team. the relevant members must have suitable safety
expertise.
Figure 9 shows a Scrum team in which the role of
the safety manager is done part-time. The part-time
role of the safety manager can be assumed by either
combining it with the product owner, Scrum master,
or a member of the development team.

Product owner
PO

Scrum master
SM

Safety manager
SaM

Development team
DT

Scrum team
ST
Figure 8: Legend for the following fi gures (source: Elektrobit Automotive)

Small team/complexity Larger team/complexity Mul�ple teams

ST1

PO SM DT
ST ST

PO SM DT PO SM SaM DT SaM

PO SM DT
ST2
Figure 9: Small project/complexity (source: Elektrobit Automotive) Figure 10: Larger project/complexity (source: Elektrobit Automotive) Figure 11: Project with multiple teams (source: Elektrobit Automotive)

15
5 Artifacts

5.1 Scrum Artifacts 5.3 Challenges

• Product backlog 1. Differentiation necessary between safety-re-
• Sprint backlog lated and non-safety-related content of artifacts
• Task board (e.g. ASIL attributes for requirements).
• Sprint result 2. Additional artifacts for achieving functional
• Definition of Done (DoD) safety.
3. Additional planning and tracking of safety
5.2 ISO 26262 Artifacts artifacts and safety measures.
Depending on the scope of the development and 4. Agile artifacts often don’t match traditional
the project setup multiple instances of work prod- types of documents (e.g. word document), and
ucts/ artifacts may be needed (e.g. for application are fine granular information instead (e.g.
software or basic software and/or operating system single requirement or tickets).
contained in an ECU).
5.4 Solutions
General Documents, e.g.: 1. Tagging of backlog content as safety-relevant
• Safety plan (e.g. assigning ASIL to content).
• Change management plan 2. Consideration of safety activities in DoD.
• Configuration management plan 3. Employed tools must support the linking of
• Documentation of the software development items and offer different perspectives for base
environment, e.g. modelling and coding guide- lining, versioning and traceability.
lines 4. Generated documents must be feasible and
• Documentation guidelines suitable (e.g. for the creation of the safety
• Documentation management plan case).

Specifications and Designs, e.g.:

• Software safety requirement specification
• Software architectural design specification
• Software unit design specification
• Configuration or calibration data specification

Implementation, e.g.:
• Software unit implementation (e.g. as source
code or binaries)
• Embedded software with calibration data

Analysis at the Software Architectural Level,

e.g.:
• Dependent failures analysis report
• Safety analyses report

Verification, e.g.:
• Software verification specification
• Software verification report

Further reports, e.g.:

• Software tool criteria evaluation report
• Software tool qualification report
• Functional safety assessment report for software
• Functional safety Aaudit report for evaluated
software development
• Release for production report for the embedded
software with calibration data

16
6 Other Agile Practices

6.1 Refactoring 6.2 Pair Programming

Abstract Abstract
Refactoring is the process of restructuring existing Pair programming is an agile software development
code without changing its external behavior. Refac- technique in which two programmers work together
toring is intended to improve nonfunctional attrib- at one workstation. One, the driver, writes code while
utes of the software. Advantages include improved the other, the observer or navigator, reviews each
code readability and reduced complexity; these can line of code as it is typed in. The two programmers
improve source-code maintainability and create switch roles frequently.
a more expressive internal architecture or object
model to improve extensibility [source: https:// Assessment of the Agile Practice from a Func-
en.wikipedia.org/wiki/Code_refactoring]. tional Safety Perspective
• The development of errors is prevented early,
Assessment of the Agile Practice from a Func- and the development of intelligible and efficient
tional Safety Perspective code is supported.
1. Refactoring also offers benefits regarding • While reviewing, the observer also considers
the reduction of safety risks in safety-related the “strategic” direction of the work, coming up
projects through: with ideas for improvements and likely future
• Easier maintenance  supports avoidance problems to address. This is intended to ensure
of systematic faults. that the driver stays focused on the “tactical”
• Higher performance  supports fulfillment aspects of completing the current task, using the
of safety timing constraints. observer as a safety net and guide.
• Less prone to errors  overarching goal of • Pair programming may replace or reduce the
safety. need for reviews during development.
• Lower degree of complexity  supports • The suitability of pair programming must be
avoidance of systematic faults and simplifies considered when defining the verification
testability. approach in accordance with ISO 26262.
2. As part of the iterations, reviews of software
architecture, detailed design, and code should References:
be performed regularly. • [8], chapter 16
3. Refactoring should be a deliberate, docu- • [3], Part 6: Table 7, Methods for software
mented team decision. verification
4. Basis for decisions must be:
• Analysis of the impact of the intended refac- 6.3 Continuous Integration
toring regarding safety. Abstract
• Project-Risk-Analysis: Continuous Integration (CI) is a development prac-
In a safety context more effort regarding doc- tice that requires developers to integrate code into a
umentation, testing, etc. is required in com- shared repository several times a day. Each check-in
parison with QM-software. Automated tests is then verified by an automated build, allowing
with high coverage help limit the additional teams to detect problems early.
work. The earlier refactoring is employed in
a project, the smaller is the resulting effort, By integrating code regularly, you can detect errors
as safety requirements do not have to be met quickly, and locate them more easily [source:
during early product phases (“Fit for pur- https://en.wikipedia.org/wiki/Continuous_integra-
pose”). tion#cite_note-:0-1 resp. https://www.thoughtworks.
5. In case refactoring increases the safety risks, com/continuous-integration].
refactoring must not be performed.
Example: Due to time constraints, sufficient
verification and validation after the refactoring
cannot be ensured:
• Refactoring and incremental reviews do not
replace complete reviews.

Reference: [9]

17
Assessment of the Agile Practice from a Func-
tional Safety Perspective
• The tool chain used for continuous integration
must be evaluated regarding tool confidence
level as well as qualified if applicable.
• Tool chain users must be sufficiently qualified.
• Software from continuous integration may not
be directly released for production, additional
measures are necessary.
• Results from continuous integration can be
given earlier into test (e.g. HIL/SIL test).
• Test during development, not at the end of a
project => Under time pressure (e.g. when close
to SOP), it cannot happen that tests are reduced
to save time.
• Continuous integration improves development
efficiency.
• Automated testing as part of Continuous Inte-
gration supports ISO 26262 as long as suitable
tools are used.

Reference: [8]

6.4 User Stories

Abstract
Epics and User Stories as rough functional descrip-
tions (high level requirements) are helpful for early
and iterative planning and negotiation. Detailed
requirements have to be defined additionally.

Assessment of the Agile Practice from a Func-

tional Safety Perspective
• At least at the end of a sprint, detailed require-
ments must be documented and linked with test
cases and implementation.
• With respect to requirements, safety-related
agile development does not differ basically from
agile automotive development with ASPICE.

Reference: [8]

18
7 Recommendations for Audits/Assessments

Involve auditors/assessors early and carry out assess-

ments alongside the project, especially if it´s the first
agile safety-related project in the company. It is safe
to assume that auditors and assessors have little
understanding of agile practices, as these practices
are not established widely.

A good time for a first feedback from an auditor/

assessor could be when the agile safety-related pro-
cess has been defined. Even though agile develop-
ment strives for early feedback, feedback must not
be reduced to functionality that is experienceable
and from the end user only.

Development in short iterations has the big advan-

tage, that the whole process can be assessed at any
time of the project, as each iteration uses the whole
process. In projects using a sequential process or
long iterations (e.g. sample phases), an assessment
during a project can only assess the process steps
that were used up to this time (e.g. in the imple-
mentation phase, the validation process can only be
assessed theoretically).

19
8 References to other Documents

1. Agile Principles and ISO 26262 (ZVEI):

https://agile.zvei.org/agilitaet-in-branchen/
agile-in-automotive/

2. Agile in Automotive: Pocket Guide Scrum

(Kugler Maag)

3. ISO 26262:2018

4. VDA Guideline “Agile Collaboration”

5. https://www.scrum.org/resources/scrum-guide

6. https://www.scaledagileframework.com/

7. https://less.works/

8. Kent Beck: Extreme Programming

9. Martin Fowler: Refactoring

10. Martin Fowler: Continuous Integration

11. Agile Alliance - Agile Glossary:

https://www.agilealliance.org/agile101/
agile-glossary/

20
9 Participating Companies

Elektrobit Automotive GmbH

Endress+Hauser SE+Co. KG

Hella GmbH & Co. KGaA

Infoteam Software GmbH

Innoventis GmbH

Kugler Maag CIE GmbH

Robert Bosch GmbH

21
 Source: Manuel faba - Fotolia.com / Nikolai Sorokin - Fotolia.com / Jeanette Dietl - Fotolia / Daniel Ernst - Fotolia

ZVEI - German Electrical and Electronic

Manufacturers’ Association
Lyoner Strasse 9
60528 Frankfurt am Main, Germany
Phone: +49 69 6302-0
Fax: +49 69 6302-317
E-mail: [email protected]
www.zvei.org