© vda qmc gelbband 2020 | entwurf - free version | ... · the idea of variable scope is to only...

AGILE COLLABORATION

VDA Version 1.0 [draft]

Status December 2019

1st Edition July 2020

Online-Download-Document

Agile Collaboration

VDA Version 1.0 [draft]

Status December 2019

1st Edition July 2020

Online-Download-Document

ISSN 0943-9412

Release: Online document July 2020

Copyright 2020 by

Verband der Automobilindustrie e. V. (VDA)

Qualitäts Management Center (QMC)

Behrenstraße 35, 10117 Berlin

3

Exclusion of Liability

The Association of the German Automotive Industry (VDA) recommends its mem-

bers to apply the following guideline.

VDA volumes are recommendations available for general use. Anyone applying

them is responsible for ensuring that they are used correctly in each case.

This VDA volume takes into account state of the art technology, current at the time

of issue. Implementation of VDA recommendations exempts no one of responsibil-

ity for their own actions. In this respect, everyone acts at their own risk. The VDA

and those involved in VDA recommendations shall bear no liability.

If errors or the possibility of misinterpretation are found while using VDA recom-

mendations, please inform the VDA immediately so that any faults can be cor-

rected.

Copyright

This publication including all its parts is protected by copyright. Any use outside

the strict limits of copyright law is not permissible without the consent of VDA and

is liable to prosecution. This applies in particular to copying, translation, microfilm-

ing and the storing or processing in electronic systems.

Translations

This publication is also issued in other languages. The latest status must be re-

quested from VDA.

5

Table of contents

1 Introduction ............................................................................................................................... 11

1.1 Target group and scope of this document .................................................................... 11

1.2 Additional topics not described in this document ......................................................... 12

1.3 Agile Values and Principles ......................................................................................... 12

1.4 Environment of the agile collaboration ......................................................................... 13

1.5 Automotive Standards and Regulations ....................................................................... 14

2 Levels and Prerequisites of Agile Collaboration ........................................................................ 16

2.1 Levels of the Agile Collaboration ................................................................................. 16

2.2 Prerequisites for successful Agile Collaboration .......................................................... 18

3 Elements of the agile collaboration (Common Language) ........................................................ 24

3.1 Roles ........................................................................................................................... 25

3.2 Artifacts ....................................................................................................................... 42

3.3 Ceremonies ................................................................................................................. 60

3.4 Agile Development Toolchain/Infrastructure ................................................................ 68

4 Installing Agile Collaboration ..................................................................................................... 72

4.1 Levels .......................................................................................................................... 72

4.2 Phases ........................................................................................................................ 76

5 Collaboration Use Case ............................................................................................................ 83

5.1 Use Case (1) SW development at client only ............................................................... 83

5.2 Use Case (2) SW development by client and 1 other party .......................................... 85

5.3 Use Case (3) SW development by n parties on 1 ECU ................................................ 87

5.4 Use Case (4.A) SW development with multiple partners and multiple ECUs (model

update) ........................................................................................................................ 89

5.5 Use Case (4.B) SW development with multiple partners and multiple ECUs (new

platform) ...................................................................................................................... 91

6

5.6 Use Case (5) Mixed Classic and Agile Development ................................................... 94

5.7 Use Case (6) Hardware/ Mechatronic development project using agile principles ...... 96

6 Additional Hints ......................................................................................................................... 99

7 Appendix 1 .............................................................................................................................. 100

8 Appendix 2 – Agile Collaboration Summary ............................................................................ 104

9 Appendix 3 – Agile Collaboration Matrix .................................................................................. 110

10 Appendix 4 – Agile Collaboration Checklist ............................................................................. 112

11 Appendix 5 - Glossary ............................................................................................................. 120

7

List of tables

Table 1 Roles in context of the different Agile Frameworks .............................................................. 41

Table 2 Work products in the context of the different Collaboration Levels ...................................... 42

Table 3 Product in the context of the different Collaboration Levels ................................................. 51

Table 4 MVP in context of the different Collaboration Levels ........................................................... 52

Table 5 Collaboration Agreement in context of the different Collaboration Levels ............................ 53

Table 6 Vison in context of the different Collaboration Levels .......................................................... 55

Table 7 Epics in the context of the different Collaboration Levels ..................................................... 56

Table 8 Overview mapping Agile Artefacts for existing Frameworks ................................................ 58

Table 9 Description of the Agile Collaboration Levels ...................................................................... 73

Table 10 Description Agile Collaboration Steps in the Initiation Phase ............................................. 77

Table 11 Description of Agile Collaboration Steps from Kick-Off until Project End (part 1) ............... 80

Table 12 Description of Agile Collaboration Steps from Kick-Off until Project End (part 2) ............... 81

Table 13 Description of Agile Collaboration Steps in the closure phase ........................................... 82

Table 14 Description Use Case (1) .................................................................................................. 83



Table 17 Description Use Case (4.A) ............................................................................................... 89

Table 18 Description Use Case (4.B) ............................................................................................... 92



Table 21 Agile Manifest and Principles in the Perspective of Close Collaboration (Part 1) ............. 100

Table 22 Agile Manifest and Principles in the Perspective of Close Collaboration (Part 2) ............. 101

Table 23 Automotive Development Projects in context to the development phases ....................... 104

Table 24 Automotive Development Projects in the context of contract phases ............................... 105

Table 25 Automotive Development Project Phases ........................................................................ 106

8

Table 26 Agile Collaboration within Product Development Projects ............................................... 107

Table 27 Collaboration stages of Agile Collaboration ..................................................................... 109

Table 28 Agile Collaboration Checklist ........................................................................................... 112

List of Illustrations

Illustration 1 Stacey Matrix ............................................................................................................... 13

Illustration 2 Overview Levels of Collaboration ................................................................................. 17

Illustration 3 Prerequisites for initiating an agile collaboration .......................................................... 18

Illustration 4 Overview roles in the agile collaboration ...................................................................... 25

Illustration 5 Product Owner ............................................................................................................. 26

Illustration 6 Proxy Product Owner ................................................................................................... 27

Illustration 7 Chief Product Owner .................................................................................................... 29

Illustration 8 Product Owner ............................................................................................................. 30

Illustration 9 Safety Owner ............................................................................................................... 32

Illustration 10 Quality Assurance Owner .......................................................................................... 34

Illustration 11 Chief Agile Master ...................................................................................................... 36

Illustration 12 Agile Master ............................................................................................................... 37

Illustration 13 Sprint Goal ................................................................................................................. 42

Illustration 14 Definition of Ready ..................................................................................................... 43

Illustration 15 Definition of Done ...................................................................................................... 43

Illustration 16 Product Backlog ......................................................................................................... 45

Illustration 17 Sprint Backlog ............................................................................................................ 46

Illustration 18 Impediment Backlog .................................................................................................. 46

Illustration 19 Taskboard .................................................................................................................. 47

Illustration 20 Burndown Chart ......................................................................................................... 48

Illustration 21 Release Burndown Chart ........................................................................................... 48

9

Illustration 22 Product ...................................................................................................................... 50

Illustration 23 MVP ........................................................................................................................... 51

Illustration 24 Collaboration Agreement ........................................................................................... 53

Illustration 25 Vision ......................................................................................................................... 54

Illustration 26 Epic ............................................................................................................................ 55

Illustration 27 User Story .................................................................................................................. 56

Illustration 28 Express Ticket ........................................................................................................... 57

Illustration 29 Regular status meeting in the linked collaboration ..................................................... 61

Illustration 30 Collaboration planning in the aligned collaboration .................................................... 62

Illustration 31 Collaboration review in the aligned collaboration........................................................ 64

Illustration 32 Collaboration retrospective in the aligned collaboration .............................................. 65

Illustration 33 Collaboration planning in the combined collaboration ................................................ 66

Illustration 34 Collaboration review in the combined collaboration .................................................... 67

Illustration 35 Collaboration retrospective in the combined collaboration .......................................... 68

Illustration 36 Prerequisites for initiating an agile collaboration (see also illustration 4) .................... 72

Illustration 37 Collaboration Levels .................................................................................................. 72

Illustration 38 Agile Collaboration in Project Life Cycle ..................................................................... 76

Illustration 39 Agile Collaboration Steps in the Initiation Phase [1] ................................................... 76

Illustration 40 Agile Collaboration Steps [1-3] ................................................................................... 79

Illustration 41 Agile Collaboration during performance phase ........................................................... 81

Illustration 42 Agile Collaboration during closure phase ................................................................... 82

11

1 Introduction

1.1 Target group and scope of this document

Disruptive technologies are having a rapid impact on the automotive industry by

decreasing the barriers to entry. Dealing with increasing complexity and being able

to react more flexibly in volatile markets is becoming more and more important. As

the speed of change will continue a growing number of, companies are transform-

ing towards agility as this has been proven to be a smart answer to today's VUCA

environment. As automotive companies see the benefit in working agile internally -

the motivation to profit from these benefits by using it beyond company borders is

increasing. Even though the benefits may be obvious, creating an agile interface or

rather - collaborating in an agile framework - can cause some challenges, which

definitely gives rise to the need for a guideline.

The VDA recommendation provides a blueprint on how an agile collaboration

across company borders could work, while considering that the basic understand-

ing and the intensity may vary. The vision for this guide is to equip the partners (cli-

ent, contractor) with a toolbox, common language and practical use cases, as well

as techniques, to enable better results in such a collaboration model.

This handbook targets people from the automotive industry who already have ex-

perience in basic agile development methods. In addition to basic experience with

agile methods, there are many other enablers that are helpful in the implementa-

tion of agile collaboration such as an agile mindset among the participating part-

ners (e.g. trust, customer orientation, a "fail fast"-approach, ...) and tools and pro-

cesses for Continuous Integration and Continuous Deployment (CI/CD). This hand-

book is not an exhaustive collection of enablers, prerequisites and best practices

for agile working. Rather, it focuses on agile collaboration across company borders.

This handbook is divided into five chapters. After the introduction, the second

chapter provides an overview on the levels of agile collaboration. Hints on enablers

and success factors are given in the second chapter. The third chapter introduces

the elements of an agile collaboration. The aim is to guide the users of existing

frameworks or methodologies through the needs of an agile collaboration by char-

acterising possible roles, ceremonies, artifacts and required infrastructure. While

12

the first chapters ensure a common understanding and language for performing an

agile collaboration, the fourth chapter explains how to install such a collaboration

model. The description is based on a phase model which illustrates the steps to be

followed from initiation until closure. The fifth chapter describes possible use cases

to illustrate the application of the collaboration level and to provide guidance for

future practitioners on how to use the described toolbox.

1.2 Additional topics not described in this document

• Agile collaboration is clearly described in this document. However, the inten-

tion and scope of this document is not to cover contracting issues, especially

• Legal aspects

• Development costs and other costs associated with the development

• Intellectual property

• Market access

• Responsibility for working results

• The description of agile collaboration in this document does not include a

• Basic introduction to agile methods

• Any recommendation concerning special agile frameworks (e.g. SAFe, LeSS,

Scrum of Scrums, …).

1.3 Agile Values and Principles

The word "agile" for this kind of working mode was chosen to indicate that the

overall focus lies in having shorter response times to change and in adapting the

project target more easily. For that reason, all agile methods aim for closer collabo-

ration, shorter feedback loops, and a focus on a minimal set of features at a time. In

today’s complex world, being more flexible becomes more important in order to

stay competitive. Therefore, companies in the automotive industry see the need to

change their organisations accordingly.

The agile values and principles defined in 2001 by a group of software experts aim

for a scenario in which collaboration and flexibility is achieved in an optimal way.

Still, the collaboration and the "perfect" product are not the only aims of a com-

pany. They still need to protect intellectual property to safeguard their business, for

example. They still need to protect their organisation from other companies that

might misuse the trust that is needed for optimal collaboration. They still need to

13

comply with standards and rules that may impede the optimal collaboration sce-

nario.

So ultimately, the interpretation of the agile values and principles in inter-com-

pany collaboration within the automotive industry (see appendix 1) is a guide for

improving collaboration. Nevertheless, realistic implementation will depend on

the given environment, which will be addressed in the collaboration levels in

chapter 2.

1.4 Environment of the agile collaboration

The client-contractor relationship in an agile mode is not useful in all situations.

The agile cooperation cannot be the magic key for solving all issues currently seen

in the Tier1/Supplier relations and in difficult project situations.

Under certain project conditions, the need for the "traditional" relationship is still

evident. The Stacey Matrix is useful for describing these scenarios.

Illustration 1 Stacey Matrix

SIMPLE: Everyone knows what to do

COMPLICATED: New technology of new

product

COMPLEX: New technology and new

product or rough idea, no one

knows what to do or how to

do it

CHAOTIC: Neither requirements nor

technology known

Having end-to-end responsibility for each partner supports the agile way of work-

ing.

14

If an agile inter-company collaboration is reasonable, this can still only be the sec-

ond step in your company’s agile transition. Depending on the level of agile collab-

oration, we recommend having established

• A willingness to provide a professional handling with transparency

• Customer orientation as an important value

• end-to-end responsibility as a basis for the project organisation

• Understanding of the importance of prioritisation of work packages

• Acceptance of agile roles and responsibilities

• Respect for effort estimations and planning from team level

• Handling of project scheduling via scope adaptions rather than defer-

ence of quality measures, for example

• A willingness to actively contribute and provide appraisals in regular

reviews

• Retrospectives as method for continuous improvement

• Management support to complete improvement activities

• Methods for handling standards along with agile methodology

• Knowledge of using "agile" tools

Further details on the required agile capabilities are described in Chapter 4 as part

of the negotiation on the common way of working.

Otherwise, there are no prerequisites in a sense of blockers which would make ag-

ile collaboration impossible.

1.5 Automotive Standards and Regulations

The following standards and regulations need to be in place and evidence needs to

be provided appropriately in both automotive projects and agile collaboration. The

provided solutions comply with the following standards.

Automotive SPICE® is an automotive-specific variant of SPICE based on the

ISO/IEC 330xx family of standards. It focuses on the process and the process capa-

bility.

ISO 26262:2018 defines a comprehensive methodology on how to assure functional

safety.

15

ISO/PAS 21448:2019 “Road vehicles -- Safety of the intended functionality (SOTIF)”

defines a methodology to assure the absence of unreasonable risk due to hazards

resulting from functional insufficiencies of the intended functionality or by reasona-

bly foreseeable misuse by persons.

ISO/SAE 21434 “Road vehicles – Cybersecurity engineering” is currently under de-

velopment.

16

2 Levels and Prerequisites of Agile Collaboration

This chapter introduces different levels of Agile Collaboration between the parties

(client and contractor). These levels are necessary to distinguish the different levels

of skills, know-how and 'soft' requirements (i.e. mutual trust) necessary to success-

fully implement an Agile Collaboration. The levels of Agile Collaboration refer to in-

creasing intensity and scope, not to growing maturity. Therefore, these levels must

not be mixed up with the levels of maturity or assessment models.

Furthermore, this chapter describes necessary prerequisites for a successful instal-

lation of an Agile Collaboration.

2.1 Levels of the Agile Collaboration

This handbook proposes 5 different levels of collaboration.

1. “Classical” Collaboration

2. “Linked” Collaboration

3. “Aligned” Collaboration

4. “Combined” Collaboration

5. “Embedded” Collaboration

To get a first idea about these scenarios, please refer to the following image.

17

Illustration 2 Overview Levels of Collaboration

In the "Classical" collaboration, each party uses its own agile methods and prac-

tices without any dedicated exchange according to agile principles and methods. It

is therefore not part of this handbook.

The "Linked" collaboration level is limited to a regular review/re-prioritization of the

requirements. Although new requirements can be defined during the ongoing pro-

ject. This is in line with the agile value "variable scope". The teams are still inde-

pendent and there is no common PI/Sprint backlog.

With the "Aligned" collaboration level, the partners are already using one common

backlog system and they prioritize the backlog(s) of the teams together. This

means that the collaboration level also covers the area of Project Management.

The "Combined" collaboration level entails stronger integration among the parties.

Besides the common requirement definition/re-scoping, the common backlog

management and development is done together. This means that the teams use

one common repository and integration platform (CI/CD).

In the "Embedded" collaboration level, the contractor’s manpower is under full con-

trol of the client. The client provides development resources/know-how only. The

complete management of these resources is handled by the client. This level of col-

laboration is not part of this handbook since there is no need for additional collab-

oration-specific practices regarding project management or development. The pro-

ject organization within an "Embedded" collaboration can be treated like a project

organization within one company.

18

The proposed levels shall serve as an orientation and basis for the upcoming chap-

ters. However, a specific collaboration among parties may have characteristics from

"in-between" the proposed levels.

For a detailed description of the levels "Linked", "Aligned" and "Combined", please

refer to Chapter 4.

2.2 Prerequisites for successful Agile Collaboration

Illustration 3 Prerequisites for initiating an agile collaboration

2.2.1 Transparency

Direct insight into the current project status is crucial if the contractor and client

synchronise and integrate deliveries regularly.

The client and contractor often want greater transparency of the project´s develop-

ment status.

Regular status reports are already state of the art, mostly from the contractor to the

client.

Transparency will remove a certain filter of information, so that all parties immedi-

ately see what is ongoing.

19

Benefit

The transparency of the project status involves all stakeholders in real time.

All parties are always up-to-date and aware of problems and can be easily in-

volved easier in troubleshooting.

Furthermore, the client knows about current actions from the contractor and

vice versa.

This ultimately reduces the coordination and communication effort on both

sides.

Risks

However, transparency can tempt the client to intervene early.

In difficult situations, he could overrule in a way that impedes, rather than helps

with, solving problems.

With good project progress, he could deduce that estimations were too defen-

sive and thus demand more content for the same time in the next iteration.

Furthermore, total transparency easily reveals intellectual property.

2.2.2 Direct Communication

Communication per ticket-system, emails or documents can become a bottleneck

in projects.

This applies if direct communication is forbidden or only takes place via a third per-

son.

Clients often request direct access to developers or to have developers on site.

Benefit

Without doubt, direct communication has many advantages such as in the require-

ments elicitation phase or in defect analysis. The more familiar you are with stake-

holders, the easier it is to clarify things in face-to-face discussions. In particular,

the often-observed problem of clients delivering requirements late could be han-

dled with such an approach.

20

Risks

Direct communication requires disciplined employees. Quietly introduced change

requests or small changes that lead to major defects are a major risk here. This

means if employees are asked to change something, project management and in

consequence requirements, architecture and testing must be involved.

This risk is amplified if the contractor is still responsible for delivering a certain

scope within a certain milestone.

2.2.3 Deliver frequently

Early and frequent delivery, integration, test and immediate feedback is the most

powerful method of agile methodology. Nevertheless, this working mode is difficult

to accomplish internally and even worse, most clients are not prepared to provide

regular feedback on deliveries when the project is in an early stage.

In such cases, the benefit of delivering early is completely gone.

Typically, the customer wants to minimise risk. For that reason, he would like to test

results early and ensure that, once delivered and approved, functions are not af-

fected by subsequent regressions.

Benefit

With intermediate results, the client can sense the project progress in a real in-

termediate product. If there are any deviations from what he intended to receive,

he can take action.

The contractor detects defects early and fixing defects becomes much easier.

The delta to the last delivery is small, the development team only deals with

changes that have occurred since the last delivery. That means the source of the

defect is easier to locate and fix. Defects do not then accumulate until a much

later delivery, thereby paving the way to a smoother release.

Finally, this leads to regular integration and risk mitigation, which ultimately

moves the contractor release date closer to the client SOP, because this long

defect removal phase shrinks or even vanishes. In consequence, this measure

reduces effort spent and makes it unnecessary to include a large time buffer at

21

the end of the project.

Risks

It is often unusual to create complete functions with each increment and there-

fore difficult to accomplish in the automotive industry. Before agreeing on fre-

quent deliveries with the client, make sure the contractor’s development depart-

ment is able to do this.

This includes an efficient release process, high automation of tests, staged test

levels and efficient test execution. Delivery must become a regular action.

It is useful to investigate and to discuss the difference between a delivery and a

formal release. Where the client tests the deliveries, the release can only occur

after testing.

Another risk is that the client must provide early feedback on the delivery. This

means he must be able to run proper testing and provide resources and a ma-

ture infrastructure.

If the loop is not closed, the overhead invested into frequent delivery turns into

waste instead of value.

When the feedback reveals defects, it is crucial to dedicate time and resources

towards fixing them immediately and to not defer them for the sake of new fea-

tures. Both sides must agree to remove their defects immediately. This means

defects from the contractor as well as defects in the integrated system.

Multiple deliveries tempt the client to create new ideas that enter the backlog as

changes. It is important that the overall plan remains achievable. Also see next

chapter.

2.2.4 Variable Scope

So far, most of the projects we have had in the automotive industry have been pro-

jects with a fixed scope.

The client defines in detail, what he wants to have at the end of the project and in-

cludes this input in the contract.

This means every detailed change leads to a change in the contract and requires

negotiation and re-planning.

22

The idea of variable scope is to only roughly describe the required functionality in

the contract. The contractor is still responsible for delivering a working product at

the end of the project. At the same time, the client and contractor may exchange

details of the solution at a technical level without changing the contract.

Variable scope does not mean that no scope is defined in the contract. The con-

tract must state what the client requires at the end of the project. Variable scope

means that the client and contractor produce and adapt the details of the project

scope together during the iterations phase. The client is able to insert or replace

functions, the contractor adapts the backlog accordingly by adding estimations and

making the effort on architectural changes transparent.

Depending on the project type and the degree of research, fixing the scope of a

multi-year project is difficult. If the client must pay for changes, negotiation, grant-

ing a new budget and other activities slow down the process and the general de-

velopment. Typically, the contractor is then able to charge extra since the client is

somehow locked to the contractor.

Benefit

In the fixed price scenario, the project manager always needs the expert to esti-

mate the change. Since change requests bring income, he ranks them high and

removes the expert from his daily work with more or less impact on the current

work. This generates delay.

In the variable scope scenario, the change management process is still needed,

even if it is executed in a different way compared to a conventional project

setup. In a fully agile working mode, the change management process merges

into the planning, ranking and refinement process.

With this more flexible change request process, the client can react to market

changes, new technologies or competitor behavior. Moreover, if he sees that all

required features have already been implemented, he could decide to introduce

the product to the market earlier and update it afterwards, or even complete the

project earlier with fewer features.

23

Risks

Agreeing on variable scope does not mean that no change management pro-

cess is needed. You need to keep track of changes in the initial rough scope

and agree on the impact of introducing changes. Furthermore, mark clearly

on the document who introduced the change - the client or the contractor.

This directly leads to the topic of “milestones and content for the mile-

stones”. It must be clear who is in charge of the content that is to be imple-

mented and by when. This means if fixed scope is agreed in the contract, the

contractor must take care and clearly communicate and confirm the impact

of changes.

If the client has more control over the backlog, it must be clear that he can

only change the features and content of the project. Dropping quality or

compliance with standards for the benefit of features is not acceptable and

must be regulated in the contract.

Again, the client cannot fully control the backlog. The technical base devel-

opment tasks for each feature must be reflected in the backlog in any way.

Ultimately, the contractor remains responsible for delivering a working prod-

uct at SOP. Therefore, the contractor is responsible for including and ranking

required tasks in the backlog.

Finally, the contractor must take care not to become a pure service provider.

The backlog is the place for negotiating the project content. The contractor is

still responsible for estimations, realisation knowledge and its own project

management.

24

3 Elements of the agile collaboration

(Common Language)

The intention is to guide users of existing agile frameworks or methodologies

through the needs of an agile collaboration.

An agile collaboration is performed by individuals and teams with specific classical

or agile roles. They interact by using agile ceremonies and exchange artifacts or

work products.

Standard roles, ceremonies, or artifacts which are not affected by the agile collabo-

ration aspects are not described here but can be implemented by each collaborat-

ing party corresponding to the project's needs.

Roles, which will be necessary in future due to regulatory constraints of the auto-

motive industry, should be implemented in the agile collaboration.

Chapter 3.1 defines a minimal set of roles needed for the agile collaboration as-

pects, which can be mapped to the standard agile roles of each specific agile

framework or roles existing in a classical organisational setup.

The requirements towards the relevant artifacts or work products, as well as rec-

ommendations regarding their ownership and storage, can be found in chapter 3.2.

The ceremonies relevant for the information exchange and interaction at the col-

laboration level are described in chapter 3.3.

Chapter 3.4 gives an overview of the common infrastructure which is needed for

the exchange of the artifacts, in particular if a continuous integration or deploy-

ment environment is intended to be used.

25

3.1 Roles

Illustration 4 Overview roles in the agile collaboration

The following structure is used for describing the roles below:

I. GENERAL DESCRIPTION

The roles are described under the focus of AGILE Collaboration.

II. AUTHORISATION

III. OBLIGATIONS/RESPONSIBILITIES

Of course, additional elements need to be added in the application environ-

ment.

IV. SKILLS

Technical Skills

Other Skills

V. HINTS

Additional hints that are useful for better understanding the role or its imple-

mentation (e.g. 'Role is typically assigned to a classical role)

26

3.1.1 Collaboration Product Owner

Illustration 5 Product Owner

I. General Description

The role of the Collaboration Product Owner is occupied by the client. This role is

required for Linked Collaboration and Aligned Collaboration types. It represents the

customer wishes and “lives” for the vision. The Collaboration Product Owner is re-

sponsible for profit & loss and legal compliance, e.g. for product liability, for the un-

dertaking. This responsibility depends on the specific organisational setup and

might be part of the Agile Servant Leader role. It balances the aspects of the agile

organisation in living the agile values and principles with the needs of a classical

organisation and the legal aspects of a company (e.g. mandatory reporting of a

stock company, formal aspects, etc.).

II. Authorisation

The Collaboration Product Owner defines the vision of the product and further de-

velops it (together with the Proxy Product Owner) as the project develops.

III. Obligations/Responsibilities

He assures the communication between the Proxy Product Owner(s) of the in-

volved parties. He is responsible for the complete product.

IV. Skills

Technical Skills:

• Good knowledge of the agile method (e.g. Scrum)

• Good knowledge of the software technology

27

• Good knowledge of embedded software development and automotive tech-

nologies (e.g. operating systems, AutoSAR)

• Good knowledge of software development tools

• Knowledge of development (all disciplines), testing and integration processes

Other Skills:

• Visionary thinking

• Planning and organisation

• Ability to take initiative

• Ability to analyse technical and organisational problems

• Communication skills and language skills (English)

V. Hints

The Collaboration Product Owner hands over his vision to the Proxy Product Owner

at the beginning of the project. The Epics as well as the Backlog will be refined in

periodic consultations with the Proxy Product Owner.

The Role has a close relationship to the classical role of a Product Manager.

3.1.2 Proxy Product Owner

Illustration 6 Proxy Product Owner


The Proxy Product Owner is the equivalent of the Collaboration Product Owner and

is occupied by the contractor. The role is required for Linked Collaboration and

Aligned Collaboration types. The Proxy Product Owner is responsible for profit &

loss and (full) legal aspects, e.g. for product liability, for the undertaking. This re-

sponsibility depends on the specific organisational setup and might be part of the

28

Agile Servant Leader role. He balances the aspects of the agile organisation in liv-

ing the agile values and principles with the needs of a classical organisation and

the legal aspects of a company (e.g. mandatory reporting of a stock company, for-

mal aspects, etc.).

II. Authorisation

He focuses on the product’s vision and develops it together with the Collaboration

Product Owner. He transfers the requirements from the client to the internal team

of Product Owner(s).


The Proxy Product Owner represents the “one face to the customer”. He is respon-

sible for the complete product.

IV. Skills

Technical Skills:






• Knowledge of development (all disciplines), test and integration processes

Other Skills:






29

V. Hints

The Proxy Product Owner gets the vision from the Collaboration Product Owner at

the beginning of the project. The Epics as well as the Backlog will be refined in pe-

riodic consultations with the Collaboration Product Owner.

The Role is closely related to the classical role of a Product Manager.

3.1.3 Chief Product Owner(s)

Illustration 7 Chief Product Owner


The role of the Chief Product Owner is (only) required in a scaled agile organisation

with more than one Agile Team which works jointly on one development project or

system (as the role of the Agile Master/Chief Agile Master). The role of the Chief

Product Owner can be also implemented as a small team (e.g. Product Manage-

ment, Architect, Quality Assurance, and Agile Master at a specific scaling level).

Remark: Not all scaling frameworks propagate this role – see table in chap-

ter 3.1.11 Mapping for well-established Frameworks

II. Authorisation

He sets the prioritisation of the backlog tasks for the defined development project

or system so that targets can be properly met.

He defines Epics and User Stories (at a meta-level) for the Product Owners within

his scope, including corresponding acceptance criteria.


He describes it and is responsible for the fulfilment of all requirements as well as

30

the profitability. He is responsible of the decomposition of the product into individ-

ual elements. He plans the product releases together with the Product Owners.

IV. Skills

Technical Skills:

• Good knowledge of the agile method (e.g. Scrum) and scaling of agile frame-

works

• Good knowledge of product, technology, systems engineering and the mar-

ket

• Good knowledge of necessary development technologies and methods

• Knowledge of development (all disciplines), testing and integration

processes

Other Skills:






V. Hints

The Role is closely related to the classical role of a Project Manager (at a scaled

level).

3.1.4 Product Owner

Illustration 8 Product Owner

31


The Product Owner imparts the vision and requirements that are derived from it to

the agile team. His focus is on the product. He

• creates and continuously maintains the Product Backlog by adding, deleting,

refining and prioritising requirements

• organises the Product Backlog into incremental releases

II. Authorisation

He sets the prioritisation of the backlog tasks so that targets can be met properly.

He defines specific acceptance criteria for the User Stories.


He describes it and is responsible for the fulfilment of all requirements as well as

the profitability.

He plans the product releases. He is responsible for the defined parts of the prod-

uct.

He involves the Safety Owner as well as the Quality Assurance Owner so that safety

and quality related topics are addressed in a timely manner.

IV. Skills

Technical Skills:


• Good knowledge of product, technology and the market

• Good knowledge of necessary development technologies and methods

Example in case of SW system:





32

• Knowledge of development (all disciplines), testing and integration processes

Other Skills:






V. Hints

The Role is closely related to the classical role of a Project Manager.

3.1.5 Safety Owner

Illustration 9 Safety Owner


The Safety Owner acts as an expert. He joins the Development Team(s) that is

working on a product which is affected by safety requirements. He is mainly spe-

cialised in Functional Safety (of the ISO 26262).

He collaborates with the Product Owner (e.g. during refinement and prioritisation

of the backlog) to ensure that safety-related activities are conducted in a timely

manner.

II. Authorisation

He can add safety-related user stories to the backlog of the Development Team(s).

He can reject the release of the product in case of safety-related open issues.

33


He is responsible for supporting the Development Team(s), so that all functional

safety-relevant aspects are observed. Due to the support with the interpretation,

detailing and prioritisation of the Product Backlog, he is responsible for complying

with the functional safety requirements, as well as the demands on quality during

development.

IV. Skills

Technical Skills:

• Good (technical) knowledge of safety, typically functional safety according to

ISO 26262

Other Skills:

• Assertiveness for prioritisation and implementation of functional safety re-

quirements

V. Hints

The Safety Owner participates in the Sprint Planning and Sprint Reviews.

Typically, several Development Teams can share the Safety Owner.

Relation to the Functional Safety Manager role (according to ISO 26262):

• The role of the Safety Owner can be assigned to a person who already has

the Functional Safety Manager role assigned.

• Depending on the size of the agile project/collaboration, there might be more

than one person who act as Functional Safety Managers/Safety Owners for

the teams. The Safety Owner role at the collaboration level is assigned to the

person who takes care of the overall coordination of the topic.

34

3.1.6 Quality Assurance Owner

Illustration 10 Quality Assurance Owner


The Quality Assurance Owner acts as an expert. He joins the Development Team(s)

that is working on a product which is affected by specific quality assurance re-

quirements, typically ASPICE. He represents the independent quality assurance to

implement the quality requirements, development processes and quality methods.

He collaborates with the Product Owner (e.g. during refinement and prioritisation

of the backlog) to ensure that Quality Assurance activities for processes and work

products are conducted in a timely manner.

II. Authorisation

He can add quality assurance-related user stories to the backlog of the Develop-

ment Team(s).

He can reject the release of the product in case of quality assurance related open

issues.


He is responsible for supporting the Development Team(s), so that all quality assur-

ance-related aspects are observed. Due to the support with the interpretation, de-

tailing and prioritisation of the Product Backlog, he is responsible for complying

with product assurance during the development.

35

IV. Skills

Technical Skills:

• Good knowledge of quality assurance, typically within ASPICE.

Other Skills:

• Assertiveness for prioritisation and implementation of quality assurance re-

quirements

V. Hints

Especially necessary in projects with Automotive SPICE requirements. The Quality

Assurance Owner participates the Sprint Planning and Sprint Reviews.

Typically, the Quality Assurance Owner can be shared by several Development

Teams.

Relation to the Quality Manager role (according to ISO 9001):

• The role of the Quality Assurance Owner can be assigned to a person who

already has the Quality Manager role assigned.

• Depending on the size of the agile project/collaboration, there might be more

than one person who act as Quality Managers/Quality Assurance Owners for

the teams. The Quality Assurance Owner role on the collaboration level is as-

signed to the person who takes care of the overall coordination of the topic.

36

3.1.7 Chief Agile Master

Illustration 11 Chief Agile Master


The role of the Chief Agile Master is (only) required in a scaled agile organisation

with more than one Agile Team which works jointly on one development project or

system (as the role of the Product Owner/Chief Product Owner).

II. Authorisation

Can intervene in case of deviations in the collaboration method at a multi-team

level.

Can escalate open issues within either a scaled project organisation or a line or-

ganisation.


He is responsible for the application of the agile principles, processes and behav-

iour at the multi-team/organisational level.

He is responsible for the removal of impediments within the product development

of the project or system.

He is responsible for optimising the output at the multi-team level by utilising retro-

spectives.

He facilitates all meetings (e.g. Iteration Planning, Iteration Review, and Iteration

Retrospective) at the multi-team level.

IV. Skills

Technical Skills:

Other Skills:

37

• Expert in scaled agile methods

• Educated explicitly as a Chief Agile Master

• Facilitation and coaching skills

• Emphatic, systemic view on organisation and teams

V. Hints

Must be independent from the agile team, therefore the technical skills are seen as

second priority.

3.1.8 Agile Master

Illustration 12 Agile Master


The Agile Master is the coach and mentor of the Agile Team.

II. Authorisation

Can intervene in case of deviations in team performance and collaboration method

Can escalate open issues within either the scaled project organisation or line or-

ganisation.


He always demonstrates a high degree of self-motivation and self-control in the

team. He is responsible for the application of the agile principles, processes and

behaviour in the team.

He is responsible for the removal of impediments within the product development

of the team.

38

He is responsible for optimising the output of the development team by further de-

veloping the Agile Team, methods and processes.

He facilitates all meetings (agile ceremonies) of the Agile Team.

IV. Skills

Technical Skills:

Other Skills:

• Expert in agile methods and educated explicitly as an Agile Master

• Facilitation skills

• Emphatic, systemic view on organisation and teams

V. Hints

Should be ideally independent from the agile team, therefore the technical skills

are seen as second priority.

3.1.9 Development Team


The Development Team consists of the dedicated professionals who can develop

and test a Story, Feature, or component. The Dev Team typically includes software

developers and testers, engineers, and other dedicated specialists required to com-

plete a vertical slice of functionality.

The Development Team should have an end-to-end responsibility for the delivery of

the vertical slices of functionality. This may include the responsibility for deploying

the functionality even to the customer vehicle.

II. Authorization

• Estimation

• Pull of Stories into Sprint Planning

• Breakdown of Stories into Tasks

39

• Decision regarding HOW Stories, Features, or components are implemented

• Performing Team Retrospective and optimising the Team’s processes


• Define, build and test the solution

• Quality of the deliverables

• Demonstrating the results

IV. Skills

V. Hints

The Development Team could be extended by the following roles, forming the “Ag-

ile Team”

• Agile Master

• Product Owner

• Safety Owner (if applicable)

• Quality Assurance Owner (if applicable)

3.1.10 Interfaces to the classical organisation

These roles are seen as part of the organisational transformation, mindset change

and setup and therefore not as part of the collaboration model. Nevertheless, agile

behaviour is a prerequisite for a real agile collaboration. These roles are not the fo-

cus of this document.

3.1.11 Agile Servant Leader

Protector and Translator. Actively promotes self-organisation of the team by chang-

ing his own habits. Facilitator and role model by living the agile values and princi-

ples. Establishes these principles in his own area of influence and responsibility.

Conveys meaning. Develops vision and strategy and evolves the organisational ar-

chitecture accordingly.

40

3.1.12 Project Manager

This role is seen as part of the classical organisation and can be mapped to roles

described above. Coordination with Collaboration/Proxy Product Owner towards

the non-agile parts of the organisation. Cooperation for the systematic prioritisation

of the backlog to ensure the mid and long-term planning, e.g. the milestone plan-

ning of a classical organisation.

3.1.13 Project Steering Committee/Escalation Board

Project Steering Committee/Escalation Board can be useful, especially when deci-

sions are needed since the involved organisations of the agile collaboration have a

different understanding of how to proceed or escalate topics to higher-level man-

agement. This role is part of the classical organisation and thus not further de-

scribed within this document.

3.1.14 Mapping for well-established frameworks

The following table maps roles of this chapter to well-established scaling frame-

works. However, other scaling frameworks do exist, but the authors of this docu-

ment created the mapping for the selection below.

41

Table 1 Roles in context of the different Agile Frameworks

Role

Framework SAFe Nexus LeSS Scrum at Scale

Collaboration Prod-

uct Owner

Not defined by any of the frameworks 1)

Proxy Product

Owner


Product Owner Product

Owner

Product

Owner

LeSS: Product

Owner

LeSS Huge: Area

Product Owner

Product Owner

Chief Product

Owner(s)

Product

Mgmt.

Not defined LeSS: Not defined

LeSS Huge: Product Owner

Chief

Product

Owner

(CPO)

Safety Owner Not defined by any of the frameworks 2)

Quality Assurance

Owner


Agile Master Scrum Master

Chief Agile Master Release Train

Engineer

(RTE)

One of the

Scrum Mas-

ters within the

Nexus. Not a

specific role.

Not defined 3) Scrum of

Scrums

Master

(SoSM)

Development Team Dev Team

Interfaces to the

classical organiza-

tion

Not defined

1) Important role for the agile collaboration; role needs to be established in addition or responsibilities and au-

thorities are assigned to an existing role

2) Important role to implement ASPICE and FuSa requirements; role needs to be established in addition

3) Does not necessarily need to be established

42

3.2 Artifacts

3.2.1 Work Products following the standard descriptions

These attributes are valid for the following work products:

Table 2 Work products in the context of the different Collaboration Levels

Linked Aligned Combined

Ownership/

Update Pro-

cess

Each contractual part-

ner separately

Mutual access of the

contractual partners

Contracting entity

Location/Stor-

age


ner separately



Common instance at

the contracting entity

3.2.1.1 Sprint Goal

Illustration 13 Sprint Goal

I. General Description (not collaboration-specific)

The Sprint Goal describes the goal of the current Sprint. The aim is for the agile

team to have a clear and shortly formulated course for the Sprint. This improves the

whole understanding and shall raise the level of self-accountability and individual

decision making of the team in terms of the overall success. The Sprint Goal will be

formulated by the Product Owner and adjusted during the Sprint Planning.

II. Relevance for the collaboration

For the Collaboration Levels Aligned and Combined, the Sprint Goals of all teams

are visible for all involved parties. The Sprint Goals of all teams must match the

43

common goals of the entire activity and interdependences must be handled explic-

itly.

3.2.1.2 Definition of Ready (DoR)

Illustration 14 Definition of Ready

I. General Description (not collaboration-specific):

The Definition of Ready describes how good the User Stories are described and

understood and what conditions are to be fullfilled so that they can be chosen for

the Sprint. The Definition of Ready will be used during the Backlog Refinement. Ba-

sically, it will be defined by the agile team, which incorporates it with the Product

Owner, Quality Product Owner and Safety Owner. Adjustments are possible as the

project develops. The goal is a better description of characteristics that accepts an

entire Sprint Planning.


For the Collaboration Levels Aligned and Combined, the Definition of Ready of all

teams are visible for all involved parties. The Definitions of Ready of all teams must

be aligned so that all teams can start their iterations with a comparable confidence

level.

3.2.1.3 Definition of Done (DoD)

Illustration 15 Definition of Done

44

I. General Description (not collaboration specific)

The Definition of Done is a checklist with (partial) results that belong to completion

of a Feature. Basically, it is defined by the agile team in cooperation with the Prod-

uct Owner, Quality Product Owner and Safety Owner at the beginning of a project.

Adjustments are possible as the project develops. The goal is to get a description of

characteristics that allow an entire Sprint Planning. The Definition of Done can be

generic for all Epics/User Stories of the project. Additional aspects can also be

considered in the Definition of Done for specific Epics/User Stories. The Definition

of Done helps the agile team to define the number and range of activities for a

Sprint. The Definition of Done cannot be changed during a Sprint. During the

Sprint Review, the Definition of Done helps the Product Owner to make a decision

in terms of accepting the Sprint results.

Note: The Definition of Done must also comprise all quality related and non-func-

tional aspects to comply with the state-of-the-art product development, i.e. de-

pendability (incl. reliability), functional safety, cyber security, EMC, and human-ma-

chine-interaction. Since there is a natural area of conflict between covering a mini-

mal set of state-of-the-art requirements and providing a maximum set of fea-

tures in an iteration on the one hand, and, on the other hand, a conflict between

long-term top-down planning of milestones and short-term bottom-up planning of

iterations, it is crucial to explicitly express the agreed trade-off in the Definition of

Done. Most of those DoD criteria shall be automated to keep the DoD feasible in

daily work. This is also one reason why the Definition of Done can evolve over a

project’s lifetime when getting closer to a release. The acceptance criteria and the

required development process and release steps are much more extensive, strin-

gent and rigid for artifacts which are intended for series production compared to

prototypes (also see Product, MVP and Epic)


For the Collaboration Levels Aligned and Combined, the Definition of Done of all

teams are visible for all involved parties. The Definitions of Done of all teams must

be aligned so that the expected quality of the deliverables is predictable, and the

integration of the deliverables is ensured.

45

3.2.1.4 Product Backlog

Illustration 16 Product Backlog

I. General Description (not collaboration specific):

The Product Backlog is a sorted list of the Epics and User Stories. Its content must

not be seen as finalised since User Stories can always change as the project devel-

ops. It contains all required Epics and User Stories for each current time. Over time,

entries can be changed, added or removed. The Product Owner is responsible for

the prioritisation of the entries according to business use, estimated risk and con-

tinuous maintenance of the Product Backlog. The status of existing entries in the

Product Backlog will be evaluated within the Backlog Refinements. Dependencies

will be identified and new entries will be assessed. The prioritised Product Backlog

is the basis for the release plan, where the allocation to customer releases, devel-

opment cycles and, as circumstances require, to different agile teams are docu-

mented.


For the Collaboration Levels Aligned and Combined, the Product Backlogs of all

teams are visible for all involved parties. The Product Backlogs of all teams must

match the common goals of the entire activity and interdependences need to be

handled explicitly. All Product Backlogs need to be synchronised regarding their

content as well as their prioritisation (i.e. which deliverables are expected in which

order of iteration and which Epics or User Stories are likely to be deprioritised. See

also Epic and User Story)

46

3.2.1.5 Sprint Backlog

Illustration 17 Sprint Backlog


The Sprint Backlog will be drawn up at the beginning of the Sprint and defines re-

alistic goals for the current and the following Sprint. It is a list of Use-Cases that

notably shows the agile team the tasks within the Sprint. All involved tasks need to

be fullfilled in order to implement the agreed User Stories. The Product Owner de-

fines the order of the User Stories in the Sprint Backlog. The agile team decides

how many User Stories will be contained in the current Sprint.


3 For the Collaboration Levels Aligned and Combined, the Product Backlogs of all

teams are visible for all involved parties. The Product Backlogs of all teams

need to match the common goals of the entire activity and interdependences

need to be handled explicitly. All Product Backlogs are to be synchronised re-

garding their content and their prioritisation (i.e. which deliverables are ex-

pected in which iteration and which Epics or User Stories are likely to be depri-

oritised). Since the teams decide on the amount of User Stories pulled into the

Sprint Backlog of the current Sprint, a re-alignment after a first Sprint Planning

might be needed to avoid mismatches between the planning of the teams. (See

also Epic and User Story)

3.2.1.6 Impediment Backlog

Illustration 18 Impediment Backlog

47


The Agile Master publicly collects all obstructions of work in a list. All occurred im-

pediments and tasks to resolve them and their current status are contained. The

Impediment Backlog is updated on a daily basis.


For the Collaboration Levels Aligned and Combined, the Impediment Backlogs of

all teams are visible for all involved parties. The Impediment Backlogs of all

teams might need to be synchronised regarding their content, as well as their pri-

oritisation (i.e. which impediments are expected to be resolved in which order or it-

eration and which impediments are likely to be deprioritised and will therefore

stay).

Note: Impediment Backlogs might comprise individual-related data (e.g. names,

also related to parts of the organisation outside of the projects). Such data might

need de-personalisation before being accessed by another company.

3.2.1.7 Taskboard

Illustration 19 Taskboard


The Taskboard is an overview that combines the Sprint Backlog with the User Sto-

ries and the tasks, which were first defined in the Sprint Planning 2.

The Taskboard visualises for the whole agile team the planned tasks for a Sprint,

who shall perform which tasks and the current status of the tasks (To Do, in pro-

gress, done).

The Taskboard will be updated by the agile team in the Daily Standup.

48


For the Collaboration Levels Aligned and Combined, the Taskboards of all teams

are visible for all involved parties. There is no need for explicit alignment or syn-

chronisation of the Taskboards, but teams with interdependences can get early in-

dications in case of deviation from the Sprint plan. Also, conflicts regarding shared

resources can become obvious.

Note (for Aligned and Combined Collaboration): Taskboards might show individual-

related data (e.g. names). Such data might need de-personalisation before being

accessed by another company.

3.2.1.8 Burndown Chart (Release and Sprint)

Illustration 20 Burndown Chart

Illustration 21 Release Burndown Chart

I. General Description (not collaboration specific)

Burndown Charts record the progress of the team, which is compared to ready or

delivered functionality. The x-axis shows the days of the current Sprint (Sprint

Burndown Chart) and the y-axis shows the work (e.g. in Story Points).

The Sprint Burndown Chart is updated daily by the agile team and is, therefore,

very simple. If every developer of the agile team estimates his remaining effort, the

accuracy improves daily.

In a Release Burndown Chart, the milestones according to the Release Planning

will, therefore, be recorded according to the advance of the project.

Using the Burndown Charts, it is possible to derive trends and prognoses.

49


For the Collaboration Levels Aligned and Combined, the Burndown Charts of all

teams are visible for all involved parties. There is no need for explicit alignment or

synchronisation of the Burndown Charts, but teams with interdependences can get

early indications in case of deviation from the Sprint plan.

Note: All kinds of metrics or KPIs (as well as measurement methods, interpreta-

tions, thresholds, etc.) need to be defined and agreed on during the initiation phase

of the collaboration (see Chapter 4).

3.2.1.9 Velocity Chart


The Velocity Chart describes the ability of a team to fulfil different complex tasks

within a certain time.

The guess (e.g. Story Points) of a Sprint are summed up and the results about the

actual Sprints will be shown as a graphic or in a chart. The goal is to improve the

guesses, this means the commitment of the agile team to the Product Owner.

The valuation is also used to assess the improvement of processes and procedures

within the agile team.


For the Collaboration Levels Aligned and Combined, the Velocity Charts of all

teams are visible for all involved parties. There is no need for explicit alignment or

synchronisation of the Velocity Charts, but the overall estimation on higher levels of

the activity (e.g. also mid-term and long-term-planning) can be adjusted based on

this information.

Note: All kinds of metrics or KPIs (as well as measurement methods, interpreta-

tions, thresholds, etc.) have to be defined and agreed during the initiation phase of

the collaboration (see Chapter 4).

50

3.2.2 Work products following some specific descriptions

The following work products have individual attributes:

3.2.2.1 Product

Illustration 22 Product


In context with this document, the product is the item delivered to the customer.

This does not need to be the whole vehicle and can also be a part such as an ap-

plication for operating vehicle functions or a control device development. In agile

product development, customer-oriented characteristics of a product are key. How-

ever, in the figurative sense, a releasing authority (e.g. ISO) can also be a customer

in the sense of the above-mentioned definition (e.g. for functional safety), for ex-

ample.

The term "Product" can be used for the entire product (e.g. at the OEM level), but it

can also refer to a part of this (product delivered by a supplier). These two levels

need to be clearly distinguished since some properties can be different on the dif-

ferent levels. Also, the acceptance criteria and the required development process

and release steps are much more extensive, stringent and rigid for a Product which

is intended for series production compared to prototypes (See also Definition of

Done).


For all Collaboration Levels, the definition of the term "Product" is very important

and always context-specific. Therefore, the agreement on what is called the "Prod-

uct" is crucial to the entire endeavour. This needs to be ensured by the contracting

entity.

51

Table 3 Product in the context of the different Collaboration Levels


Ownership/

Update

Process

Product/specification of

the product at the level

of the overall product:

Contracting entity

Sub-product/specifica-

tion of the sub-product

delivered by a contrac-

tor:


ner separately




Contracting entity




tor:


ner separately




Contracting entity




tor:



Loca-

tion/Storage


ner separately


ner separately/Mutual

access of the contrac-

tual partners can be de-

fined


contractual partners /

Common instance at


can be defined

3.2.2.2 MVP

Illustration 23 MVP


MVP (Minimum Viable Product): The MVP is the first minimal viable iteration of a

product to present it as a beta-version or prototype especially to potential investors,

business partners or selected customers. The possibly fast and easily created prod-

uct’s goal is to get feedback about the marketability and market acceptance of the

new product as early as possible. This feedback will flow into further development

or products that are not accepted by the market will not be followed up on.

52

As for "Product", there can also be different levels of delivery for “MVP” and these

need to be distinguished. Furthermore, the acceptance criteria and required devel-

opment process and release steps are also much more extensive, stringent and

rigid for an MVP which is intended for series production compared to prototypes

(also see Definition of Done).


For the all Collaboration Levels, the definition of the MVP is very important and al-

ways context-specific. Therefore, the agreement on what is called the MVP is cru-

cial to the entire endeavour and closely linked to the synchronisation of the Prod-

uct Backlogs. All MVPs within the activity need to be aligned. This shall be ensured

by the contracting entity.

Table 4 MVP in context of the different Collaboration Levels


Ownership/

Update Pro-

cess

Contracting entity Contracting entity Contracting entity

Loca-

tion/Storage


ner separately

Each contractual partner

separately/mutual access

of the contractual part-

ners can be defined


contractual part-

ners/common instance

at the contracting entity

can be defined

53

3.2.2.3 Collaboration Agreement

Illustration 24 Collaboration Agreement


Results of the discussion on the collaboration mode and project setup. It may vary

in content and depth depending on the chosen collaboration model.

It should contain some minimum elements as described in "checklist" (see Check-

list appendix)


There is only one Collaboration Agreement between two collaboration partners in-

dependent of the Collaboration Level. All Collaboration Agreements within the ac-

tivity need to be aligned (but do not need to show the same Collaboration Levels).

This shall be ensured by the contracting entity.

Table 5 Collaboration Agreement in context of the different Collaboration Levels


Ownership/

Update

Process


Location/Stor-

age

Common instance at


Common instance at the

contracting entity

Common instance at


54

3.2.2.4 Vision

Illustration 25 Vision


The vision describes the fundamental product idea and summarises the different

characteristics of the product. Product Owner(s) develop the vision, with the aim of

inspiring the agile team. The vision is a super ordinated target to catch the involved

parties of a project at an emotional level while providing the common theme of a

project at the same time.

The vision describes the following aspects:

• Which customers the product is for

• What the benefits are for the customer

• Which characteristics of the product are significant

• Difference to competitive products

• Product Owner(s) develop the vision further, as the project develops.


There should be only one overall Vision shared by all collaboration partners inde-

pendent of the Collaboration Level. This needs to be ensured by the contracting

entity.

55

Table 6 Vison in context of the different Collaboration Levels


Ownership/

Update

Process


Location/Stor-

age


ner separately

Common instance at the

contracting entity

Common instance at


3.2.2.5 Epic

Illustration 26 Epic


The Epic is placed over the User Story and covers several coherent User Stories. An

Epic roughly describes the requirements on the product. Epics describe tasks that

are implemented later on. Most of the time, those need to be more detailed later

on, and implementation occurs after working out a better understanding for func-

tionality.

Epics include both functional as well as non-functional requirements! (also see

Definition of Done)


For the Collaboration Levels Aligned and Combined, the Epics of all teams (like all

other items on the Product and Sprint Backlogs) are visible for all involved parties.

The Epics of all teams need to match the common goals of the entire activity and

interdependences need to be handled explicitly. All Epics need to be synchronised

56

regarding their content and also regarding their prioritisation (i.e. which delivera-

bles are expected in which order or iteration and which Epics or User Stories are

likely to be deprioritised). (also see Product Backlog and Sprint Backlog)

Table 7 Epics in the context of the different Collaboration Levels


Ownership/

Update Pro-

cess

At the level of the over-

all product:

Contracting entity

At the level of the sub-

product delivered by a

contractor:


ner separately

At the level of the over-

all product:

Contracting entity

At the level of the sub-

product delivered by a

contractor:



Contracting entity


Location/Stor-

age


ner separately


contractual

partners

Common instance at

the contracting

entity

3.2.2.6 User Story

Illustration 27 User Story


From the user’s perspective, a User Story describes the intended result. The follow-

ing questions shall be answered: Who? (role), What? (application requirement),

57

Why? (use). Note that the customer (user) is meant with WHO, and not the devel-

oper or the implementer. The User Story does not replace the requirement specifi-

cation, but shall be seen as the input for it. The User Stories are roughly defined by

Product Owner(s) and are further developed with the agile team. These granular

working packages are the basis for the features at the Product Backlog.

A good User Story is based on the INVEST principle: Independent, Negotiable, Val-

uable, Estimable, Sized appropriately and Testable.


For the Collaboration Levels Aligned and Combined, the User Stories of all teams

(like all other items on the Product and Sprint Backlogs) are visible for all involved

parties. The User Stories of all teams need to match the common goals of the entire

activity/iteration and interdependences need to be handled explicitly. All User Sto-

ries need to be synchronised regarding their content as well as their prioritisation

(i.e. which deliverables are expected in which order or iteration and which Epics or

User Stories are likely to be deprioritised). (See also Product Backlog and Sprint

Backlog)

Same attributes as Epic.

3.2.2.7 Express Ticket (Fast Lane)

Illustration 28 Express Ticket


As the Sprint develops, no changes or new features are allowed for the Sprint

Backlog or any other disruptions to the agile team. An exception are Express Tick-

ets, which result from a parallel running testing phase (Sprint) and have urgent and

prioritised interceptions of identified mistakes. The agile team decides if an Express

58

Ticket can be accomplished in the course of the current Sprint. The tasks that re-

sult from the Ticket will be inherited into the Sprint Backlog and the tasks will be

re-prioritised and removed from the Sprint Backlog.


For the Collaboration Levels Aligned and Combined, the Express Tickets (as with all

other items on the Sprint Backlogs) of all teams are visible for all involved parties.

The Express Tickets of all teams might need to be synchronised regarding their

content but particularly regarding their prioritisation (i.e. which Express Tickets are

expected to be resolved in which order or iteration and which Express Tickets are

likely to be deprioritised and therefore shifted to the next iteration).

Same attributes as Epic.

3.2.2.8 Mapping for existing Frameworks

The following table maps the artifacts described in this chapter to existing scaling

frameworks.

x = Artifact is also used with the same or comparable definition in the respective

framework

- = Artifact is not used in the respective framework (but can be added as supple-

ment)

Table 8 Overview mapping Agile Artefacts for existing Frameworks

SAFe

(on ART Level)

Nexus

(Nexus Level)

LeSS

(not LeSS huge)

Scrum at Scale

(SoS-Level)

Sprint Goal Roadmap and vi-

sion as input for

PI planning

Set of Sprint

Goals/Nexus

Sprint Goal

x (Only at Scrum

Team Level)

Definition of

Ready

- x x (x)

Definition of

Done

x x x x

59

Product Backlog x x x x

Sprint Backlog Program backlog Nexus Sprint

Backlog

x x

Impediment

Backlog

- (Risk board de-

veloped during

the PI Planning)

Not explicitly but

results from the

Nexus retrospec-

tive are followed

up: "Appropriate

representatives

from each team

meet again to

discuss any ac-

tions needed

based on shared

challenges to

provide bottom-

up intelligence"

"organisational

improvement

backlog"

(part of the)

backlog of the

SoS Team

SAFe

(on ART Level)

Nexus

(Nexus Level)

LeSS

(not LeSS huge)

Scrum at Scale

(SoS-Level)

Task board Kanban Board

on PI Level

not explicitly not explicitly not explicitly

Burndown Chart not explicitly

(Program pre-

dictability meas-

ure)

not explicitly not explicitly "require metrics

that will be de-

cided upon by

the separate SM

and PO organi-

sations"

Velocity Chart not explicitly

(Program pre-

dictability meas-

ure)

not explicitly not explicitly "require metrics

that will be de-

cided upon by

the separate SM

and PO organi-

sations"

Product x x x x

MVP x "potentially re-

leasable inte-

grated incre-

ments at least by

the end of every

Sprint"

"potentially ship-

pable increments

of product at the

end of every

Sprint"

"potentially ship-

pable increments

of product at the

end of every

Sprint"

60

Collaboration

Agreement

Commit-

ment/confidence

Vote

not explicitly not explicitly scrum values

(commitment as

basis)

Vision x - - x

Epic Feature/enabler - - -

User Story Feature/enabler "Product Backlog

Item"

- -

Express Ticket

(Fast Lane)

- - - -

3.3 Ceremonies

The following structure is used for describing the ceremonies below:

COLLABORATION LEVEL: The corresponding collaboration level is named here

CEREMONY: Each collaboration ceremony has its own title

DESCRIPTION: Description of the meeting purpose and additional remarks

INVOLVED ROLES: The collaboration roles (see chapter 3.1) attending the cere-

mony.

FREQUENCY: Ceremony frequency

MAPPING TO EXISTING FRAMEWORKS: There are many known frameworks for

working in a scaled setup. Comparable meetings are listed here

3.3.1 Collaboration Level: Linked

3.3.1.1 Ceremony: Regular status meeting

I. Description

Collaboration Product Owner and Proxy Product Owner review and reprioritise the

61

requirements based on local backlogs. Furthermore, early feedback on deliveries is

requested. The meeting takes place on demand whenever needed as within the

linked collaboration, teams work independently.

II. Involved roles:

• Collaboration Product Owner

• Proxy Product Owner

• Further roles on demand (e.g. Safety Owner, Quality Assurance Owner, Chief

Agile Masters)

III. Frequency: On demand

IV. Mapping to existing frameworks: There is no such meeting in existing frame-

works

Illustration 29 Regular status meeting in the linked collaboration

62

3.3.2 Collaboration Level: Aligned

3.3.2.1 Ceremony: Collaboration Planning

I. Description

The purpose is to coordinate all agile teams for the next iteration based on the

aligned priorities within the public backlogs of each company. The teams summa-

rise the work as a set of committed iteration goals and team members commit to

the work to be done within the public backlogs. Iteration goals and scope are to be

reviewed and aligned with the collaboration product owner. Refined backlogs are

strongly recommended.

II. Involved roles



• Chief Agile Masters

• Quality Assurance Owner (both companies)

• Safety Owner (both companies)

• Team members (both companies)

III. Frequency: Agreed iteration

IV. Mapping to existing frameworks: Product Increment Planning (SAFe)

Illustration 30 Collaboration planning in the aligned collaboration

63


3.3.3.1 Ceremony: Collaboration Review

I. Description

The delivered team increments are to be reviewed at the end of the iteration. The

public backlogs are to be reviewed. The public backlogs are to be adjusted based

on assessed progress for the next iteration.

II. Involved roles






• Team members (both companies)


IV. Mapping to existing frameworks: Iteration review (SAFe)

64

Illustration 31 Collaboration review in the aligned collaboration


3.3.4.1 Ceremony: Collaboration Retrospective

I. Description

The agile teams align the results of the iteration and provide feedback to each

product owner. The product owners conduct a retrospective that is moderated by

chief agile master(s) and transfer the feedback back to the companies.

II. Involved roles:





IV. Mapping to existing frameworks: Iteration retrospective (SAFe)

65

Illustration 32 Collaboration retrospective in the aligned collaboration

3.3.5 Collaboration Level: Combined

3.3.5.1 Ceremony: Collaboration Planning

I. Description

The purpose is to coordinate all agile teams for the next iteration. The collaboration

Product Owner guides the scoping and decides on priorities. Team members com-

mit to the work to be done derived from the common backlog. The teams summa-

rise the work as a set of committed iteration goals. The prerequisite is a refined

common backlog.

II. Involved roles:


• Chief Agile Master


66


IV. Mapping to existing frameworks: Product Increment Planning (SAFe)

Illustration 33 Collaboration planning in the combined collaboration


3.3.6.1 Ceremony: Collaboration Review

I. Description

At the end of the iteration, the delivered team increments are to be reviewed. The

common backlog is to be adjusted based on the assessed progress for the next it-

eration.

II. Involved roles


• Chief Agile Master



67


IV. Mapping to existing frameworks: Iteration review (SAFe)

Illustration 34 Collaboration review in the combined collaboration


3.3.7.1 Ceremony: Collaboration Retrospective

I. Description

The agile teams align the results of the iteration jointly and provide feedback to the

product owner who comes up with action points for the teams.

II. Involved roles

• Teams (both companies)

• Chief agile master

68


IV. Mapping to existing frameworks: Iteration retrospective (SAFe)

Illustration 35 Collaboration retrospective in the combined collaboration

3.4 Agile Development Toolchain/Infrastructure

To succeed in an agile development environment, to master the dynamics of agile

projects and to be able to handle the diversity of artifacts with their complex rela-

tionships, it is necessary to use a consistent toolchain and infrastructure that opti-

mally supports project roles in dealing with processes and artifacts and helps with

implementation of the agile principles (iterative, learning, reactive).

3.4.1 Elements of an agile Development Toolchain/Infrastructure

Elements of such a tool chain are:

• Software Development Kit

• Process Toolchain

• Continuous Delivery Pipeline

69

3.4.1.1 Software Development Kit

The SDK is a collection of tools and rules that helps the developer to develop soft-

ware for a specific platform (middleware, operating system, hardware).

A unified SDK creates equal conditions for all developers and facilitates compli-

ance with product/project specifications by generating product/project-defined

standard interfaces, for example.

In addition to an editor and compiler, tools should be integrated into the develop-

ment environment that handle the build management process uniformly for the

project/product.

The unified integration of tools for white box unit testing, code coverage, and static

code analysis will result in early software error detection.

3.4.1.2 Process Toolchain

The Process Toolchain typically supports processes along the software develop-

menting process from requirements definition to integration and deployment of the

software components on the target platform. Supported processes include require-

ments management, change management, test management, version management,

quality management, etc.

For agile collaboration, it is also important to choose tools that are particularly suit-

able for supporting agile methods.

Such a collaboration toolset supports:

• The documentation and communication of knowledge and the exchange of

knowledge between the teams

• The definition of requirements and management of requirements and derived

tasks as a backlog

• The scheduling of Epics, User Stories and Tasks for the Sprints of an agile

development process

• Monitoring and Reporting (Burn-Down-Chart, Release Prediction, …)

70

3.4.1.3 Continuous Delivery Pipeline

A Continuous Delivery Pipeline enables on-demand delivery of software via an au-

tomated software production line, where the steps build, test, and deploy are con-

catenated as part of a tool-based release workflow.

The Continuous Delivery Pipeline includes the concepts:

• Continuous integration

• Continuous delivery

• Continuous deployment

Continuous integration

Continuous integration describes the process of continuously building, integrat-

ing and testing software components and provides timely feedback on the sta-

tus of the software and whether the quality requirements have been met.

If you want to take advantage of an agile approach with iterative planning and

development, CI is essential. Otherwise, you will not be able to benefit from the

effect of early problem detection.

The more frequently software is integrated, the better the support of the agile

approach.

An efficient CI process can only be achieved via an appropriate toolchain and

infrastructure in which the process of building, integrating, testing and report

creation is done automatically.

Ideally, the continuous integration process is triggered each time the developer

checks a new software version into the version management (several times a

day).

Continuous delivery and continuous deployment

Continuous Deployment is the goal and describes the automated end-to-end

provisioning of the software to the customer.

Continuous Delivery is an evolutionary step toward Continuous Deployment and

71

includes a final manual release step before the software goes live. A quality au-

thority can still decide not to transfer the software to productive operation.

Continuous deployment requires a very high level of quality of the automated

delivery pipeline.

3.4.2 Agile Collaboration and the recommendation of a common toolchain/infra-

structure

The level of collaboration affects the need for a common toolchain.

In agile projects with intensive and close cooperation, such a toolchain can be

made available for shared use on a common infrastructure (e.g. cloud).

Goals of such a common Toolchain/Infrastructure are:

• Increase in the transparency of all project stakeholders through centralized

availability of project artifacts and project progress reports and metrics

• Error prevention such as through using the same libraries, interface defini-

tions from the corresponding repositories (avoids redundancy)

• Faster reaction times

• Better traceability

• Simpler SW version

• Better compliance with the rules

• …

The closer the collaboration level between OEMs and suppliers, the more important

it is to set up and use a common infrastructure.

Especially when the goal is to provide software to the vehicle end-to-end (over the

air) via a continuous deployment process, the use of a common continuous delivery

pipeline infrastructure is recommended.

The benefit for each Collaboration Level is shown in Chapter 4.1.

72

4 Installing Agile Collaboration

Prerequisite for initiating an agile collaboration:

Illustration 36 Prerequisites for initiating an agile collaboration (see also illustration 3)

4.1 Levels

Please remember the first definition of the agile collaboration levels introduced in

chapter 2 of this document.

Illustration 37 Collaboration Levels

Now take a look at the more detailed description of the different agile collaboration

levels.

73

Table 9 Description of the Agile Collaboration Levels

Charac-

teristics Linked Collaboration Aligned Collaboration

Combined Collabora-

tion

Description

of project

scope and

project ob-

jectives

• The linked collabora-

tion is based on a

regular refinement

and priorisation at

the requirements

level.

• New requirements

can be defined dur-

ing the ongoing pro-

ject. This is in line

with the agile value

"variable scope".

• No common product-

and increment back-

log. The teams are

independent.

• The aligned collabora-

tion is at the require-

ments and project lev-

els.

• The partners use one

common backlog sys-

tem and prioritise the

backlog(s) of the in-

dependent teams to-

gether.

• Alignment/synchroni-

sation is done at the

iteration level.

• The combined collab-

oration is done at the

requirements, project

and engineering lev-

els.

• Synchronisation dur-

ing the iteration,

meaning that the

teams use a common

backlog, one reposi-

tory and one integra-

tion process (CI/CD).

Roles • Collaboration Prod-

uct-Owner (OEM)


(Tier)

• Product Owner

(OEM, Tier)

• Chief Product Owner

(OEM, Tier)

• Agile Master (OEM,

Tier)

• Quality Owner (OEM,

Tier)

• Safety Owner (OEM,

Tier)

• Agile Teams (OEM,

Tier)

• Function Owner

(OEM, Tier)

• Project manager

(Tier, commercial)

• Agile Servant Leader

(OEM, Tier)

• Collaboration Product

-Owner (OEM)


(Tier)

• Product Owner (OEM,

Tier)


(OEM, Tier)


Tier)

• Quality Owner (OEM,

Tier)

• Safety Owner (OEM,

Tier)

• Agile Team (OEM,

Tier)

• Function Owner (OEN,

Tier)

• Project manager (Tier,

commercial)


(OEM, Tier)

• Product Owner (OEM

or

Tier)


(OEM or Tier)

• Agile Master (OEM or

Tier)

• Quality Owner (OEM

or Tier)

• Safety Owner (OEM or

Tier)

• Agile Teams (shared)

• Function Owner (OEM

or Tier)


(OEM, Tier)

74

Character-

istics

Linked Collaboration Aligned Collaboration Combined Collaboration

Artifacts • common problem reso-

lution management

(later in the project)

• separate product back-

log

• separate iteration back-

logs

• milestone deliverables

(ready-to-use (software)

packages)

• common problem resolu-

tion management

• common product back-

log

• separate iteration back-

logs

• regular intermediate de-

liverables

(ready-to-use (software)

packages)

• common problem reso-

lution management


log

• common iteration back-

logs

• continuous integra-

tion/validation/delivery

(components, models

source (code))

Ceremonies • common refinement of

requirements

• separate planning, re-

view and retrospective

ceremonies

• common refinement of

requirements

• common prioritization of

prod. backlog

• iteration planning, review

and retrospective sepa-

rately

• (Collaboration Product

Owner participation pos-

sible)

• commonly manage/prior-

itise defects

• common planning/re-

view ceremonies

• common retrospective

• commonly manage/pri-

oritise defects

75

Characteris-

tics Linked Collaboration Aligned Collaboration Combined Collaboration

Infrastruc-

ture

and work-

flows

Separate Infrastructure

• Engineering Environment

• Individual ticket/defect

tracking tool

Common Infrastructure

• common requirements

management tool (possi-

ble)

• no further common tool-

ing/infrastructure


• Engineering Environment


• common requirements

management tool

• common (public) back-

log

• Exchange Infrastructure

(effort reduction)

(Delivery, Test, Defect)



• sharing the same tool-

ing at both sides

or

• seamless integration of

different tool chains

Agreements • requirements must be

available early

• prompt feedback and

defect management on

deliveries

• high maturity of deliver-

ables must be ensured

• deliverables can be fully

tested

• high test coverage by

automated tests

• prompt feedback on de-

liverables

• Prioritisation must con-

sider the architectural

view (maintainability,

stability, performance ...)

• defect removal with high

priority

• fixed scope for each

Sprint: after Sprint plan-

ning and agreement,

supplier controls back-

log

• Agreed architecture

must be maintained

• time-and-material con-

tract

• plan for the iteration

has priority

• impediments are openly

communicated

• IP parts are black box

contributions

• parts added as black

box ready to use

76

4.2 Phases

There have four phases of an agile collaboration been identified.

Illustration 38 Agile Collaboration in Project Life Cycle

4.2.1 Initiate the agile collaboration

Target of this first phase is to understand the organisation’s capability regarding

agile cooperation and agile methods.

Based on the understanding of the individual’s situation, a common understanding

of the situation and the cooperation shall be developed. This common understand-

ing shall be documented on a contractual basis.

Illustration 39 Agile Collaboration Steps in the Initiation Phase [1]

77

Table 10 Description Agile Collaboration Steps in the Initiation Phase

Step

No. Step Name Main Task Hints

1 RFQ/General Assessment Analyse the cooperation

scenarios and discuss

them proactively (Collabo-

ration/Clarification Meet-

ing).

Use the defined Agile Col-

laboration Levels and Char-

acteristics as a reference for

the first internal clarification

meetings and meeting cus-

tomer/ supplier.

2 Assessments (Stand-

ards/Agile)

Assessment of the individ-

ual Situations

(every company for itself)

Use synchronised check-

list for the assessment

• internal Resource Situa-

tion (are the needed skills

available)

• IT infrastructure available

• Legal Aspects

• Collaboration Checklist

3 Definition Collaboration

Level

Establish first Draft of the

Agile Collaboration Matrix

-

(Start and Goal of the Col-

laboration).

• Customer/supplier should

bring their proposal to

identify fist gaps and to

get a better common un-

derstanding.

• Use Collaboration Matrix.

4 Collaboration Meeting Common understanding

and derived decisions are

the precondition for a

successful cooperation.

Decide together on the

targeted agile stage.

Describe the planned

road-map to reach the

defined goal in the Agile

Collaboration Matrix.

• Use the defined Agile Col-

laboration Levels and

Characteristics as a refer-

ence for the agreements.

• Coordinate/schedule all

necessary measures to

reach the intended collab-

oration level.

• Plan the derived measures

to achieve the intended

level.

• Plan all necessary training

and coaching measures

together.

78

Step

No. Step Name Main Task Hints

5 Agile Collaboration Ma-

trix

Define the cooperation

scenario.

Decide/agree on the evo-

lution of the cooperation.

• Use Collaboration Matrix

6 Collaboration Agreement Define the Agreement in

writing and fix the retro-

spectives and the escala-

tion steps/level.

• No predefined fall back

planning but clear defini-

tion of escalation path in

case of deviations.

• Focus on retrospective

and derived counter

measures to improve the

collaboration.

• Define the governance

structure to work effi-

ciently in solving the im-

pediment backlog (de-

rived from the collabora-

tion retrospective).

• This governance structure

depends on the chosen

scaling approach (e.g.

SAFe, LESS).

• Which role has which em-

powerment and can de-

cide on what?

• Consider the classical ap-

proach with the structure

of the committees.

79

4.2.2 Establish the agile collaboration

Once the project collaboration has been initiated and fixed with a collaboration

agreement, the project can start.

It is very important to pay a lot of attention to the agreed number of first Sprint(s) of

the project’s setup phase and to finish the initial phase with a detailed retrospective

to identify the collaboration issues at the cooperation level.

Focus should not be the product, but it should be the right usage of the agile meth-

ods.

Focus should be a common understanding of the prioritisation of the backlog and

the evaluation of the velocity.

Illustration 40 Agile Collaboration Steps [1-3]

80

Table 11 Description of Agile Collaboration Steps from Kick-Off until Project End (part 1)

Step

No.

Step Name Main Task Hints

1 Project Kick off Establish a communica-

tion path, understanding

AGILE at the top level.

Presentation and review

of the defined escalation

process.

• How to handle Project

Steering/Escalation

Board, driven by the line

organisation and the re-

spective committee

structure?

• Is there a common un-

derstanding of the ex-

pectations/roles? (e.g.

can we not do this with-

out the role of an agile

master)

2 Initial Phase (first

Sprints)

Apply the committed ag-

ile rules and roles as

agreed (trust).

Install measures to track

and to assure the correct

performance of the Initial

phase.

Metrics to track volume,

timing and Integration

steps should be estab-

lished.

• The initial phase provides

the basis for further de-

velopment.

3 Retrospective of the ini-

tial phase

Cooperation retrospec-

tive and the correspond-

ing governance structure

Performance review

• Do the teams meet the

expected performance

requirements?

(e.g. expected velocity,

other expectations of

contract parties)

81

4.2.3 Perform the agile collaboration

The objective of this phase is to now develop the product based on the agreed and

refined agreements (see phase: "Establishing the agile collaboration").

It is still important to fulfil the agile methods approach and to not only look at the

products’ maturity growth (during the review), but also at the ongoing agile collab-

oration at a process level (retrospective).

Illustration 41 Agile Collaboration during performance phase

Table 12 Description of Agile Collaboration Steps from Kick-Off until Project End (part 2)

Step

No.


1 Development Phase Development phase, based

on the worked-out Epics,

User Stories and product

backlog from the initial

phase.

Collaboration according to

agreed collaboration level.

Update of collaboration

success according to the

result(s) of the retrospec-

tives which are carried

out during the develop-

ment phase.

in

parallel

Realignment and regu-

lar retrospectives

Adapt/realign the develop-

ment process based on ret-

rospective findings

"Standard" Retrospective

with focus on the develop-

ment team.

"Cooperation" Retrospective

with focus on the coopera-

tion process.

Participants of the "Coop-

eration Retrospective" as

defined in the Collabora-

tion Agreement.

(e.g. Project Steering/Es-

calation Boards// defined

committee structure)

82

4.2.4 Close the agile collaboration

The objective of this phase is to perform a common Lessons Learned/Project retro-

spective.

Not only the project result ("Standard Retrospective") should be part of this phase,

but the cooperation also has to be explicitly reviewed ("Cooperation Retrospec-

tive").

Illustration 42 Agile Collaboration during closure phase

Table 13 Description of Agile Collaboration Steps in the closure phase

Step

No.


1 Final Retrospective at

Project end

Lessons Learned and de-

rived actions for the next

cooperation

83

5 Collaboration Use Case

This chapter describes very specific use cases of collaboration in the automotive

industry, each representing a typical scenario, that differ in product complexity,

number of involved partners and basic requirements such as ASPICE level and

ASIL classification.

According to the detailed evaluation in Appendix 7, each use case is followed by a

recommendation on which collaboration level from chapter 4 fits best and a short

summary of the evaluation. The reader can use that evaluation to determine an ap-

propriate collaboration level for his own specific situation.

Within the following use cases the terms “client” and “supplier” are used. Client

can be either an OEM or a supplier (e.g. 1st tier) that works together with a supplier

(e.g. 1st tier or a 2nd tier).

5.1 Use Case (1) SW development at client only

User Story

As aclient, I want to work with a supplier on an ECU project without having all re-

quirements fixed at the beginning so that I can best serve my customers in chang-

ing market environments.

Characteristics

Table 14 Description Use Case (1)

Criteria Description

Number and role of the

development partners

One client (e.g. OEM), one supplier (e.g. 1st tier). The supplier deliv-

ers HW and SW

The cooperation includes the following work packages:

• SW development of the ECU

• HW development of the ECU

84

• The supplier is responsible for SYS.3/4 and SWE.1-SWE.6 of

ASPICE

Description of the devel-

opment product and sys-

tem context of the product

Automotive ECU will be integrated into an existing system, in which

the interfaces are already specified)

Description of the process

environment (phases,

norms and guidelines)

The Concept Phase is already ongoing and will be finished within

the next two months. The collaboration should start within the next

two months with the milestone start of series development.

The development schedule has four main Milestones: Start of series

development (SoD), function complete (FC), production pre series

with Note 1 (series quality) ECUs and SOP. Between SoD and FC,

the development of SW and HW will be carried out in an agile

framework with development Sprints. One Sprint is three weeks

long.

The development includes safety relevant functions with ASIL

Level A.

The client asks the supplier to fullfill ASPICE.

Between SoD and FC, the suplier has defined five official Releases.

Main expected functionality of ECU for the Releases will be defined

4 weeks before the prior release reaches the delivery milestone.

Local separation of the


(national, international,

project site, …)

As a system developer and system supplier can define the develop-

ment locations individually. The client expects one main project con-

tact as the communication interface.

Complexity of the devel-

opment and for the nec-

essary project

organisation

The ECU is based on an existing one, which is already in series.

The client expects new functions and better performance. For re-

quirements engineering, SW development and testing the supplier

plans 4 teams.

Development duration

Development time from SoD till FC is scheduled for 18 months and

an additional 12 months for industrialisation.

Goal of the project

(e.g. maturity of the prod-

uct)

Note 1. The client expects the delivery of the ECU System in time,

cost, quality and scope.

Use Case 1 Recommendation

• The recommendation is either aligned or linked collaboration.

85

• For example, separate development on the supplier and client side supports

the linked collaboration model, whereas early feedback on results and trac-

ing between client and supplier results supports the aligned collaboration

model.

• Combined is not suitable.

5.2 Use Case (2) SW development by client and 1 other party

User Story

As a client, I want to work with a software development company on a joint soft-

ware project without having all requirements fixed at the beginning so that I can

best serve my customers in changing market environments.

Characteristics





One client (e.g. OEM), one supplier (SW Engineering Service Provider)


• SW development

• SW module test



The client is system responsible. The ESP is responsible for SW engi-

neering processes of ASPICE for the SW modules he develops.



tem context of the prod-

uct

Automotive ECU will be integrated into a new system where the inter-

faces are not final.

Description of the pro-

cess environment

(phases, norms and

guidelines)

Phase 1: concept phase. 6 months until concept confirmation mile-

stone and start of series development.

The client plans a public demonstrator 2 months before the end of

phase 1.

Phase 2: 6 months from the start of series development until delivery of

86


cess environment

(phases, norms and

guidelines)

(continued)

first systems to a limited number of pre-users.

Phase 3: Industrialisation

The collaboration should start within the next four weeks. The concept

development team from the client is already working on the system in-

cluding SW.

The development schedule has five main Milestones: start of coopera-

tion, availability of public demonstrator, start of series development,

availability of pre-series, availability of series.

The whole development will be carried out in an agile framework with

development Sprints of two weeks.

The development includes safety relevant functions with ASIL

Level A.

The client asks the cooperation partner to fullfill ASPICE.

For the client, each Sprint result should be useable for official use by

the client (official release).




project site, …)

The client has defined a development area for the ESP close to the cli-

ent development centre. For communication, the client expects one

main project contact and further contacts within each development

team.

The ESP can organise the project team according to their own stand-

ard but must guarantee agile development and an agile mindset.



essary project

organisation

The system and its functions are completely new.

Because of the ambitious timeframe, the ESP needs to develop and

test the SW modules in different teams.


The development time from the start of the cooperation (phase 1) until

the start of the industrialisation (phase 3) is 12 months. The duration of

industrialisation is not defined. Currently, phase 3 is not part of the

collaboration request.

Goal of the project


uct)

C-sample for limited and selected pre-users. The client expects the

ESP to deliver on time and with the required quality.


• The recommendation is combined collaboration because development is car-

ried out jointly by the client and supplier, which requires intensive collabora-

tion.

87

• Aligned is possible with the weakness of a lower validation frequency than in

combined.

• Linked is not suitable in this scenario.

5.3 Use Case (3) SW development by n parties on 1 ECU

User Story

As a client, I want to be more involved in the SW design and development for

one ECU. Therefore, I want to work with multiple dedicated software develop-

ment companies for different modules (and maybe SW integration). I can also

take over some of these work packages myself.

Characteristics





One client (e.g. OEM), more than two suppliers (SW development

companies)


• SW development

• SW module test

The client is responsible for the system (ECU). For the SW modules

which the supplier(s) develops, the supplier(s) are responsible for

SW engineering processes of ASPICE.




uct

The Automotive ECU will be integrated into a new system, in which

the interfaces are not completely specified.




Concept Phase is already finished, and the Series Development

Phase has started recently. The cooperation should start as soon as

possible with an Initial phase for one release. If the cooperation be-

tween all involved parties is successful, the collaboration will con-

tinue until the function complete milestone has been reached.

88

The development schedule has six main Milestones: Start of series

development (SoD) [already passed], three official integration steps

(releases), function complete (FC), pre series and SOP. Between SoD

and FC, the SW is developed in an agile framework with develop-

ment Sprints. One Sprint is three weeks long.




The SOPs of the different vehicles are time-shifted.

The development includes safety relevant functions with ASIL Level

D.

The client asks the involved suppliers to fulfil ASPICE.

Between SoD and FC, the client has defined three official releases,

as well as currently not scheduled and counted releases in between

(depends on SW quality, test campaigns and management re-

quests). For each Sprint, the client prioritises the tickets in the over-

all backlog. After each Sprint the SW modules from the suppliers are

integrated by the client. The suppliers shall deliver fully documented

and tested SW modules.




project site, …)

The supplier(s) can define the development locations individually.

The client has development locations for this ECU development in

three different countries with different time zones. The client ex-

pects one main project contact from each supplier as a communica-

tion interface.



essary project

organisation

The ECU is new and the system with sensors and actors is new as

well. A lot of functions are located in different ECUs (distributed

functions). The ECU with the SW modules from the suppliers will be

integrated in different vehicle architectures.

Because of the absolute number of functions and expected test

cases the project needs more than one development team at each

supplier.

Development duration Development time from SoD until FC is scheduled for 12 months.

Goal of the project


uct)

From C-sample until the milestone function complete (FC) is

reached, the client expects delivery of the ECU System in time, cost,

quality and scope.

89


• The recommendation is combined collaboration.

• There is a common development between the client and one or two suppli-

ers, which requires intensive collaboration.

• Aligned is possible with the weakness of lower validation frequency than in

combined.


5.4 Use Case (4.A) SW development with multiple partners and multiple ECUs

(model update)

User Story

As a client I want to implement a feature based on multiple sub-functions that

run on multiple ECUs. Development for model update.

The partners in the project can have their own business interest; they do not

necessarily need to collaborate in a hierarchical client-supplier-relationship.

Characteristics

4-A: Existing System and Feature, Model Update only

Table 17 Description Use Case (4.A)




One client (e.g. OEM), more than one supplier (SW development

companies)


• SW development

• SW module test

• SW integration and SW system test

The client is responsible for the main feature. For the SW sub-func-

tions which the suppliers develop, the suppliers are responsible for

the SW engineering processes of ASPICE.

90

Description of the de-

velopment product and

system context of the

product

Automotive ECUs, already integrated (interface and/or architecture

modifications possible)


cess environment

(phases, norms and

guidelines)

No concept phase due to model update (care), only. The collabora-

tion should start as soon as possible. The suppliers are already

known from earlier projects. But the previous collaboration was not

necessarily agile.

The client plans a function update for a model update in the field.

The functionality of the system needs to be updated because of

changed customer requirements and updates on customer devices.

The update will be launched in the series production after MVP is

reached and functions are successfully verified and validated - no

later than 9 months after SoD. After first MVP, the development is

continued to further implement customer experience functions.

The development schedule has the following main milestones: Start

of development (SoD) [already passed], release for official produc-

tion and quality validation (no later than 3 months before SOP),

pre-series and SOP. Between SoD and the official release, the de-

velopment of SW will be carried out in an agile framework with de-

velopment Sprints. One Sprint is two weeks long.

Description of the

process environment

(phases, norms and

guidelines)

The development includes safety relevant functions.

The client asks the involved suppliers to fullfill ASPICE.

Between SoD and official production release, there are no defined

scheduled, official Releases. The client expects a SW delivery every

two weeks. For each Sprint, the client prioritises the tickets in the

overall backlog. After each Sprint, the SW modules from the suppli-

ers are integrated and validated in the different ECUs by the client.

Errors are documented in the client’s ticket system. The suppliers

must deliver fully documented and tested SW modules.




project site, …)


The client has concentrated their own development at one develop-

ment location. The client expects one main project contact from

each supplier as a communication interface.

91



essary project

organisation

The ECUs are already integrated and in series. An update of the HW

is not planned. The main feature is located in different ECUs (dis-

tributed functions).

Because of the absolute number of sub-functions and expected test

cases, the project needs more than one development team at each

supplier.


Development time from SoD until SOP is scheduled with a maxi-

mum of 9 months. The collaboration time may be extended for the

development of additional features.

Goal of the project

(e.g. maturity of the

product)

As soon as possible availability of series SW (MVP). The client ex-

pects the delivery of the ECU System in cost, quality and time.

Scope (MVP) will be defined during an initial phase.

Use Case 4a Recommendation

• Strong recommendation for combined collaboration.

• Development is joint between the client and multiple suppliers, which re-

quires intensive collaboration.

• Linked and aligned is not suitable in this scenario.

5.5 Use Case (4.B) SW development with multiple partners and multiple ECUs

(new platform)

User Story

As a client I want to implement a feature by multiple sub-functions that run on

multiple ECUs. Unlike use case 4-A, a new platform will be developed. The part-

ners in the project can have their own business interest; they do not necessarily

need to collaborate in a hierarchical customer-supplier-relationship.

Characteristics

4-B: New Feature and System, new platform development

92

Table 18 Description Use Case (4.B)




One client (e.g. OEM), more than one supplier (SW development

companies)


• SW development

• SW module test

• SW integration and SW system test

The client is responsible for the main feature. For the SW Sub-func-

tions which the supplier(s) develops, the suppliers are responsible

for the SW engineering processes of ASPICE.


opment product and


product

Automotive ECUs, to be integrated into a modified system (interface

and/or architecture modifications necessary)

Description of the

process environment

(phases, norms and

guidelines)

The cooperation should start as soon as possible. The suppliers are

already known from earlier projects. But the previous cooperation

was not necessarily agile.

Phase 1: Concept phase. 6 months until concept confirmation mile-

stone and start of series development. 1 month before end of phase

1, the client is planning to be part of an international congress and

to demonstrate a first prototype.

Phase 2: Start of series development until function complete confir-

mation.

Phase 3: Industrialisation

The functionality of the system needs to be developed due to new

customer requirements, new customer devices and new vehicle

electric/ electronic platform.

Description of the

process environment

(phases, norms and

guidelines)

The development schedule has the following main milestones: Start

of concept development [already passed], start of cooperation

[SoC], end of concept development and start of series development

[SoD], end of series development with milestone function complete

and release for official production and quality validation (no later

than 9 month before SOP), pre-series and SOP. Between SoC

and official release, the SW is developed in an agile framework with

93

development Sprints. One Sprint is two weeks long. Until SoD, the

client defines the MVP for SOP together with the suppliers.

The development includes safety relevant functions.

The client asks the involved suppliers to fulfil ASPICE.

The client expects a SW delivery every two weeks (each Sprint). For

each Sprint, the client prioritises the tickets in the overall backlog.

After each Sprint, the SW modules from the suppliers are integrated

and validated in the different ECUs by the client. Errors are docu-

mented in the client’s ticket system. The suppliers shall deliver fully

documented and tested SW modules. After SW module integration,

integration and system testing, the client decides if the release will

be used as an official release or as engineering release only.




project site, …)


The client has concentrated their own development at one develop-

ment location. The client expects one main project contact from

each supplier as a communication Interface. The client is planning

to install a common repository.



essary project

organisation

The HW (ECUs) will be developed and integrated in the new E/E

platform in parallel. An update of the HW is planned in Integra-

tion Levels (I-Level) that have already been defined. Many features

are spread over different ECUs (distributed functions).

Because of the absolute number of sub-functions and expected test

cases, the project needs more than one development team at each

supplier.


Development time from SoC until SOP is scheduled with a maxi-

mum period of 24 months. After SOP, the suppliers shall offer devel-

opment support for bug fixing.

Goal of the project


uct)

Availability of verified and validated series SW (MVP) until SOP in

cost, quality and time. Establishing an agile collaboration between

the client and several SW suppliers.

Use Case 4b Recommendation

• Strong recommendation for combined collaboration.

• There is common development between customer and multiple suppliers,

which requires intensive collaboration.

94

• Linked and aligned is not suitable in this scenario.

5.6 Use Case (5) Mixed Classic and Agile Development

User Story

As a client, I am in a transitionary phase. Not all parties within a project use ag-

ile development methods, but I want to apply agile methods in some parts to

benefit from them. Depending on the setup, either classic or agile methods

could be in the lead.

Characteristics





One client (e.g. OEM, different departments), one system supplier (in-

cludes mechanics, HW and SW)


• Mechanical development of a new system

• HW development for a new ECU

• SW development

• SW test

• System integration

• System validation in vehicle

The client is responsible for the vehicle and system interface. For the

system which the supplier develops, the supplier is responsible for

SYS.2/3 and the SW engineering processes of ASPICE.

Description of the de-

velopment product and


product

Automotive powertrain system (e.g. transmission, E-motor, HV bat-

tery). System needs to be integrated into a vehicle (interfaces not fi-

nally specified).

Description of the

process environment

Concept Phase is ongoing and will be finished within the next month.

Next milestone is concept confirmation. After this milestone, the

series development Phase will start. The collaboration should start as

soon as possible. With the concept-confirmation milestone, a virtual

95

(phases, norms and

guidelines)

Description of the

process environment

(phases, norms and

guidelines)

(continued)

system and virtual vehicle validation is requested from the client. If

the milestone is passed successfully, the project will be continued

until SOP.

The product development process (PDP) is the standard classic PDP

of the client. The PDP already includes a number of integration levels

for the integration, validation and release of all mechatronics sys-

tems. The time between two Integration levels is approximately 3

months.

The series development ends with the milestone function complete

(FC) and 100% of released parts for series purchasing. During series

development, the client scheduled several virtual validation mile-

stones.

For presentation usage (show cases) and for real system validation

usage, several hardware parts are to be developed. Currently, no full

vehicle build is planned during the series development phase until

milestone FC.

The SOPs of the vehicle are already fixed according to the Standard

PDP.


cess environment

(phases, norms and

guidelines)

The development includes safety relevant functions with ASIL Level

D.

The client asks the involved parties to fullfill ASPICE.

Between the official releases, the client has informed the involved

parties that releases which are currently not scheduled or counted

are possible (depends on SW quality, test campaigns and manage-

ment requests). The client expects regular SW updates for their own

system tests.

Especially for SW development, the client works according to agile

principles. For mechanics and HW, the use of agile principles de-

pends on the experience of the involved parties. A minimum of one

development team at the client will work with a classic process. Each

involved party must deliver sufficiently documented and tested deliv-

erables.

Until the last official release (integration level) before milestone func-

tion complete, the client will have the opportunity to define and prior-

itise the functionality of the system (SW functions) for first SOP

(MVP). The design freeze for the mechanical system will be approxi-

mately 9 months earlier.

96




project site, …)

The supplier can define the development location(s) individually. The

client has concentrated their own development at one development

location. The client expects for each sub-project part one main pro-

ject contact as a communication Interface and one contact for the

whole project.



essary project

organisation

The system is new (mechanics, HW and SW). The system has multiple

interfaces to other systems in the vehicle. Many functions are located

in different ECUs (distributed functions).

Because of the different sub-projects, the absolute number of func-

tions and expected test cases, the project needs more than one de-

velopment team at the supplier.


Development time from start of cooperation (in concept phase) un-

til SOP is approximately 36 months.

Goal of the project

(e.g. maturity of the

product)

C-sample short-term after milestone FC. The client expects the deliv-

ery of the system in time, cost, quality and scope.

Use Case 5 - Recommendation

• Recommendation for aligned collaboration.

• The common planning supports this use case.

• Effort for establishing and maintaining the common development of com-

bined collaboration creates more effort than it brings benefits.


5.7 Use Case (6) Hardware/Mechatronic development project using agile

principles

User Story

As a client, I want the right product for my production in time, quality and

budget to assure a planned SOP and financial success. I want to be confident

from the start of the project that my supplier is always on track and flexible

enough to implement upcoming and necessary products, as well as interface

adaptions, to get the optimum product to satisfy my customers’ needs.

97

Characteristics





One client (e.g. OEM), one supplier, several suppliers for mechani-

cal prototypes and tools.

The development project environment consists of:

• Co-development between client and supplier regarding inter-

faces and technical feasibility between product and car

• Multiple suppliers are responsible for the production of proto-

types and test parts according to the design of the supplier

• Another supplier is responsible for the design and production

of tools for test and series production




uct

Several prototypes at defined different maturity levels for necessary

test cases in prototype cars to pass client internal regulations as

well as international norms.

“Ready-to-integrate” product with a high share of moving parts for

the just-in-sequence delivery at the client’s plant starting at SOP.

Specifications & Interfaces for Mechanics, HW, SW already defined

but not final. 24 months to SOP.


cess environment

(phases, norms and

guidelines)

Concept Phase is already ongoing and will be finished within the

next two months. The collaboration should start within the next two

months with the Milestone start of series development.

The development schedule has five main Milestones:

Start of series development (SoD), concept finished, development

finished, SOP, project finished. Between SoD and development fin-

ished, the SW and HW are developed in an agile framework with

development Sprints. One Sprint is two weeks long.

The client ask the supplier to fullfill ASPICE and ISO26262.

Between SoD and development finished, the client has defined five

official Releases for product and production validation.




project house, …)

client and supplier are located in the same country but several hun-

dred km apart. The client expects one main project contact person,

as well as direct contacts, at expert levels for fast exchange. For the

98

implementation of the product, the client wants a representative

from the supplier side.

The supplier and the sub-suppliers are located regionally.

The production site of the supplier is located in Europe.

Complexity of the develop-

ment and for the neces-

sary project

organisation

HW & SW for the product are standard “off the company´s shelf”

modules. Their adaptation to the client’s specifications is a major

part of the project.

The challenge is to steer the interdisciplinary core team to reach the

different product maturity levels.

The cross-functional (agile) development team at the supplier con-

sists of mechanical design, simulation, systems engineering, test

engineer, prototype building, operations and quality.

This cross-functional (agile) development team comprises 8 people,

with an overall project team of 15 people, depending on the project

need.

The project representative steers additional internal resources on

demand, as well as the external sub-suppliers for parts and tools.


The serial development & industrialisation phase from POC to SOP

is planned within 24 months.

Goal of the project


uct)

Note 1 (series quality)

Use Case 6- Recommendation

• Recommendation for aligned collaboration.

• A common planning of work as well as synchronisation is supporting this

Use Case.

• Combined could also have benefits but probably hard to realize. Effort for es-

tablishing and maintaining a common development environment creates

more effort than it brings benefits.

• Linked is not suitable in this scenario due to missing alignment of backlog in

complex environment.

99

6 Additional Hints

The illustrated use cases in this handbook sketch the typical development projects

of the past years. But markets and technologies change the automotive industry

disruptively.

The number of sensors in cars is growing steadily. In some cases, a few high-per-

formance computers centralise the processing of up to 100 ECUs with unchanged

real time and safety requirements. A disproportional growth of software in cars is

leading to high dynamics in system development, integration and testing. The inter-

connection of cars with the Internet and external services is extending the meaning

of ‘system’ far beyond the automobile.

In some areas we see that the system development will not end with SOP. Addi-

tional functions will be developed, delivered and activated over the air while the car

is already in use. This mechanism will increase the number of variants with de-

pendent optional modules. Validation and testing will then become drastically more

complex.

Many development projects are not confined to the car itself. Further peripherals

such as charging stations and mobile apps, etc. are being developed and require

proper interfacing, while standards are not yet available for aligning producers and

varying country standards.

Finally, the automotive industry is no longer independent, and collaboration with

technology companies will become a competitive advantage. They are used for

faster and more dynamic development cycles and still need guidance to fulfil auto-

motive quality standards.

Those changes will require closer collaboration across companies for development,

integration, validation and testing. The authors hope that the collaboration models

and use cases in this handbook offer enough guidance for future scenarios.

100

7 Appendix 1

Agile Manifest and principles in the perspective of close collaboration

Table 21 Agile Manifest and Principles in the Perspective of Close Collaboration (Part 1)

Values Benefit Actions

Individuals and Interactions

Over

Processes and Tools

Regularly reflect on collabo-

ration and implement the

beneficial improvement ac-

tions rather than fixing inter-

company collaboration pro-

cesses upfront.

Communication, whenever

it´s necessary, not when the

process dictates it (e.g. Ap-

provals, using the results).

Working Software Over

Comprehensive Documenta-

tion

Looking at the results itself

creates more confidence

than looking only at docu-

mentation about the results.

Consume intermediate re-

sults immediately instead of

piling them up for later pro-

cess steps.

Customer Collaboration Over

Contract Negotiation

Instead of wasting time in

defining what you do not

know, define the way of de-

termining the ongoing project

scope.

Define in e.g. a SOW as col-

laboration agreement with

rights/duties rather than a fix

list of requirements.

Responding to Change Over

Following a Plan

Avoid wasting time on esti-

mates and long-term detailed

planning. Instead, focus on

short-term planning in detail.

Handle change requests as

late as possible instead of es-

timating and planning them

upfront. Maybe they will

change again later on or

even drop out of scope.

101

Table 22 Agile Manifest and Principles in the Perspective of Close Collaboration (Part 2)

Principles Benefit Actions

Our highest priority is to sat-

isfy the customer through the

early and continuous delivery

of valuable software.

All project stakeholders see

intermediate results early and

often during development

and can react to develop-

ment, deviating from expec-

tations.

Deliver regular results in a

form that the customer can

judge, verify and validate.

Welcome changing require-

ments, even late in develop-

ment. Agile processes har-

ness change for the custom-

er's competitive advantage.

Enables customers to adapt

the developed target during

long-term development to

changing market needs and

technical innovations even

throughout the whole deliv-

ery chain.

Reduce the effort for change

requests. Detailed planning

only within a short-term

range, rough planning (rank-

ing) over the long term.

Deliver working software fre-

quently, from a couple of

weeks to a couple of months,

with a preference for the

shorter timescale.

a. Continuous delivery ena-

bles early feedback on inter-

mediate results.

b. It enables the integration

and testing of deliverables

very early on rather than get-

ting feedback only months

later.

c. It enables the synchroniza-

tion of development across

company borders with a high

tact rate.

Enable development among

companies to focus on deliv-

ering complete features.

Align short-term planning

among companies.

Businesspeople and develop-

ers must work together daily

throughout the project.

Seeing businesspeople as

customers and developers as

suppliers. This principle

drives ongoing management

of expectations throughout

the project.

Regular and structured meet-

ings with development and

businesspeople for planning

and review.

Build projects around moti-

vated individuals. Give them

the environment and support

they need, and trust them to

get the job done.

Focus on the technical solu-

tion rather than customer/

supplier interests. The people

across companies shall work

together to find the best so-

lution.

Enable individuals through-

out companies to get their

job done instead of impeding

daily work by intercompany

regulations and financial in-

terests.

102


The most efficient and effec-

tive method of conveying in-

formation to and within a de-

velopment team is face-to-

face conversation.

Direct communication is

much easier if developers

across companies work on

the same topic at a time. This

means that the synchronisa-

tion of work packages ena-

bles direct communication.

Enable direct communication

between developers across

companies.

Working software is the pri-

mary measure of progress.

Real testable results are a

much more reliable progress

report than artificial progress

reports in PowerPoint.

Enable a development project

to deliver complete features

as real testable results.

Agile processes promote sus-

tainable development. The

sponsors, developers, and

users should be able to

maintain a constant pace in-

definitely.

Focus on the technical solu-

tion rather than customer/

supplier interests. The people

across companies shall work

together to find the best so-

lution.

Align all parties to contribute

to result creation and regular

outcomes.

Continuous attention to tech-

nical excellence and good

design enhances agility.

Adapting software with the

focus on code maintainabil-

ity enables future adaptions

with less effort. An agree-

ment between customer and

supplier on these principles

leads to a win -win situation

on both sides.

Changes in design also need

a high priority against fea-

tures to ensure the maintain-

ability of the software (out-

put).

Simplicity--the art of max-

imising the amount of work

not done--is essential.

Seldom executed software

parts that still cause mainte-

nance and verification effort

are not implemented, which

saves effort in the long run.

Make sure the reason for im-

plementation is understood. If

not, question the need for

implementation.

The best architecture, re-

quirements and designs

emerge from self-organising

teams.

Close collaboration even over

company borders, unfiltered

from high level negotiations,

lead to better software solu-

tions.

Enable communication

among the technical experts

without interference from

PM, sales and purchasing

departments. Good solutions

will not manifest under cost

pressure.

103


At regular intervals, the team

reflects on how to become

more effective, then tunes

and adjusts its behaviour ac-

cordingly.

Experiences from collabora-

tion can be incorporated into

the internal continuous im-

provement process.

104

8 Appendix 2 – Agile Collaboration Summary

OEM/ Tier product development projects

The following table describes typical automotive product development projects

from concept to series development.

Table 23 Automotive Development Projects in context to the development phases

Charac-

teristics

Ad-

vanced/Con-

cept

Development

Base

Development

Series –

New Tec

Development

Series –

Update

Development

Develop-

ment

purpose

Prove the feasi-

bility in principle

Reusable solu-

tion/proof of mass

prod. capability

Product/mass

prod. capable

product

Produced prod-

uct updated for

the MY

Expected

result

Innovative tech-

nical concept to

solve new re-

quirements

Basic concept to

solve the require-

ments known

Adaption of Base

Dev. results to fi-

nal solution

Requirements

clearly defined.

No new technol-

ogy

Product

innovation

Complete new

technology/algo-

rithm

Concept might be

outcome of the

adv./concept

phase

New func-

tion/technology

first time in mass

production

Update of well-

understood func-

tions

Develop-

ment

environ-

ment

Expensive/com-

plex dev. envi-

ronment

Define a standard

development envi-

ronment/process

Standard devel-

opment environ-

ment/process

Development en-

vironment/pro-

cess as used for

series start

Develop-

ment

parties

Often with

two/more part-

ners

University/insti-

tutes (could) be

involved

One or no partner Strong OEM/Tier1

cooperation

Mostly one part-

ner, 2nd source for

complex products

more seldom

Update done by

originally selected

serial supplier

105

Charac-

teristics

Ad-

vanced/Con-

cept

Development

Base

Development

Series –

New Tec

Development

Series –

Update

Development

IP/Result

usage

Results often

published in pa-

pers/conferences

Result is IP from

OEM or TIER

1/TIER n

Result is IP from

OEM or TIER

1/TIER n

Result is IP from

OEM or TIER

1/TIER n

Process

Quality

No systematic

Quality Plan-

ning/Assurance

Quality measures

as for

series usage

Quality measures

for

series usage

Quality measures

as for

series usage

Product

Quality

Functionality ap-

proved

Design validated

> ASPICE SWE.6

fully?

> SYS4/SYS.5

partly?

Product validated

> ASPICE SYS.5

Product validated

> ASPICE SYS.5

Product

require-

ments

Requirements

evolve during de-

velopment

Requirements de-

fined, but becom-

ing more precise

in dev.

Requirements

precisely known;

only minor adap-

tions

Requirements

precisely known;

very few adap-

tions

Product development contracting process

The following table describes the typical phases of contracting automotive product

development projects.

Table 24 Automotive Development Projects in the context of contract phases

Phase Phase description OEM activities Tier activities

Collabora-

tion Re-

quest

Initial request for a prod-

uct development collabo-

ration project

Issue RFQ for product de-

velopment (Business Case

and project type)

• Initial assessment of

the RFQ and involve-

ment of internal stake-

holders

• Assessment of devel-

opment process quality

requirements, such as

Automotive SPICE and

ISO 26262 relevance

106

Phase Phase description OEM activities Tier activities

Collabora-

tion Pro-

posal

Evaluation of potential col-

laboration

Review Collaboration Pro-

posal

Propose potential Collabo-

ration Type and Collabora-

tion Level

Collabora-

tion Agree-

ment

Confirm collaboration

agreement

Define and confirm appropriate

(1) Collaboration Type and

(2) Collaboration Level,

as well as Collaboration Measures to be taken to

(a) Start the collaboration and

(b) Close the collaboration successfully.

Collabora-

tion Con-

tract

Contract product develop-

ment collaboration project

Contract Collaboration Agreement (containing regula-

tions such as Business Case, Collaboration Type, Col-

laboration Level, i.e., Roles, Artifacts, Ceremonies,

Tools, Communication, Acceptance Criteria…)

Product development project life cycle

The following table describes the typical phases within automotive product devel-

opment projects.

Table 25 Automotive Development Project Phases

Life-cycle

phase

Advanced/Con-

cept

Development

Base

Development

Series –

New Tec

Development

Series –

Update

Development

Project

kick-off

Develop-

ment Phase

Project

finalisation

Collaboration Types

The following table describes types of agile collaboration within product develop-

ment projects.

107

Table 26 Agile Collaboration within Product Development Projects

Character-

istics Linked Collaboration Aligned Collaboration

Combined

Collaboration

Description

of scope and

objectives

• OEM requests still by

traditional OEM require-

ment specifications

• Supplier has responsi-

bility for solution

• Like teams within the

same company

Roles • Chief Product Owner

(OEM)

• Product Owner (Tier)

• Proxy Product Owner (?)


Tier)

• Quality Product Owner

(OEM, Tier)

• Safety Product Owner

(OEM, Tier)

• Agile Teams (OEM, Tier)

• Function Owner


for commercial issues)

• Agile Entrepreneur

(OEM, Tier)


(OEM)

• Product Owner (Tier)


(?)


Tier)


(OEM, Tier)


(OEM, Tier)

• Agile Team (OEM, Tier)

• Function Owner


for commercial issues)


(OEM, Tier)

• Product Owner (OEM or

Tier)

• Agile Master



• Agile Teams (shared)

• Function Owner


(OEM, Tier)

Artifacts • supplier delivers ready-

to-use software pack-

ages

• each party has its own

backlog

• deliveries of the defined

scope


log

• agreed iteration

scope/deliverables

• scope and deliverables

for the iteration

• tasks and test of the

next iteration

• common build, integra-

tion, source code control

Ceremonies • request early feedback

from the OEM on deliv-

eries in a mature system

• common prioritisation

of tasks

• common refinement of

the backlog

• intensive communica-

tion necessary

• common planning and

review ceremonies

• commonly manage/ pri-

oritise defects

• common planning, re-

view and retrospective

108

Character-

istics Linked Collaboration Aligned Collaboration

Combined

Collaboration

Tools • infrastructure to share

information

• shared ticket/defect

tracking system

• length of the iteration

• manage all defects in a

ticket system

• common source CM, CI,

validation sys.

Workflow • asynchronous work of

both parties

• alignment at the re-

lease or milestone level

• define a full change

management process

• aligned schedule for

integration/test

• aligned planning and

review method

Agreements

• technical OEM repre-

sentatives must be

available to clarify

open questions

• communication tech-

niques

• availability of stake-

holders

• deliverables can be

fully tested

• the maturity of deliver-

ables is high

• automated test cover-

age is high

• short-term feedback

on deliverables

• defect removal with

highest prioritisation

• fixed scope: supplier

controls backlog

• Time-and-Material

contract

• plan for the iteration

has priority

• impediments are

openly communicated

• IP parts are black box

contributions

• parts added as black

box ready to use

Collaboration Stages

The following table describes the stages of agile collaboration within product de-

velopment projects. Note: it is assumed that higher stages contain lower level char-

acteristics, unless stated explicitly otherwise.

109

Table 27 Collaboration stages of Agile Collaboration

Character-

istics

Stage 0

Agile Tools

Stage 1

Agile Teams

Stage 2

Agile Project

Stage 3

Agile Joint

Venture

Scope • OEM or Tier

• SW develop-

ment

• OEM or Tier

• Any engineering

discipline (SW,

HW, ME, Sys)

• OEM and Tier

• Any project and

sub-project

• Any organisa-

tional function

Methods,

Practices,

Frameworks

• Ticketing

• CI

• Scrum, Kanban • CD

• SAFe, LeSS,

Nexus

110

9 Appendix 3 – Agile Collaboration Matrix

In this appendix, the Use Cases from chapter 5 are linked with the collaboration

levels from chapter 3. The result is a matrix with information on possible re-

strictions, opportunities and challenges for each use case criteria linked to the dif-

ferent collaboration level criteria.

How to use the collaboration matrix

1. Identify the most fitting Use Case for your specific col-

laboration situation in chapter 5 and find that Use Case

in the matrix. Only the horizontal block for this Use Case

is relevant.

2. Explaining the matrix

a. Rows: Each Use Case includes four different aspects of

collaboration and development product, described in

four lines in the matrix, derived from the descriptions in

chapter 5

b. Columns: The columns are grouped in three vertical blocks of develop-

ment input, execution and output per iteration.

Each block is evaluated according to the three collaboration levels

linked, aligned and combined. The cell’s text explains the specific re-

strictions, challenges and chances which led to the evaluation shown

as colour code.

i. If there are more opportunities than chal-

lenges, the matrix field is coloured green.

Linked Aligned Combined Linked Aligned Combined Linked Aligned Combined

Scope and

objectives

Scope and

objectives

Scope and

objectives

Workflow

Tools

Ceremonies

Workflow

Tools

Ceremonies

Workflow

Tools

Ceremonies

Artefacts Artefacts Artefacts

Input Input Input Execution Execution Execution Ouptut Output Output

Use Case (1)

Description

Numer and roe of the


Location seperation of the

partners (national,

international, project house, …)

One customer (OEM), one supplier (1st tier), the Tier delivers HW

and SW

The collaboration includes the follow ing w ork packages:

- SW development of the ECU

- HW development of the ECU

- The supplier is responsible for SWE 1-6 and SYS 2-4 of Aspice

As a system developer and system supplier the Tier 1 can

define the development locations individually. The OEM expects

one main project contact as a communication interface.

Description of the

development product and

system context of the product

Automotive ECU, to be integrated into an existing system

(interfaces already specif ied)


environment (phases, norms

and guidelines)

Concept Phase is already ongoing and w ill be f inished w ithin the

next tw o months. The collaboration should start w ithin the next

tw o months w ith the milestone start of series development.

The development schedule has four main Milestones: Start of

series development (SoD), function complete (FC), production

pre-series w ith Note 1 ECUs and SOP. Betw een SoD and FC, the

development of SW and HW w ill be carried out in an agile

framew ork w ith development sprints. One sprint is three w eeks

long.

The development includes safety-relevant functions w ith ASIL

Level A.

The OEM asks the Tier 1 to fulf ill ASpice Level 3.

Betw een SoD and FC, the OEM has defined f ive off icial

Releases. Main expected functionality of ECU for the Releases

w ill be defined 4 w eeks before the Prior release reaches the

delivery milestone.

Complexity of the

development for the

necessary project

organisation


The ECU is based on an existing one w hich is already in series.

The OEM expects new functions and better Performance. For

requirements engineering, SW development and testing f irst

estimation from Tier 1 calculate approximately w ith 4 teams.

Development time from SoD until FC is scheduled w ith 18

months. Additional 12 months for industrialisation.

Note 1 (series quality).The OEM expects the delivery of the ECU

system in time, cost, quality and scope.

One ECU with flexible features, SW delivered by

one 1st Tier (SW development at 1st tier only)

Use Case (1)


Workflow

Tools

Ceremonies

Workflow

Tools

Ceremonies

Workflow

Tools

Ceremonies

Execution Execution Execution

Restriction: No specif ic

Opportunities: Tier1 w orks by

his established processes,

because of his responsibility

Challenges: No specif ic

No need for in-depth common

w orkflow s because Tier1

w orks independently from the

OEM w ith a limited process

interface to the OEM

Restriction: No specif ic

Opportunities: Less effort for

common tool introduction and

benefit from active prioritisation

project due to simple project

setup

Challenges: Establish common

w orkflow w ithout being

beneficial for collaboration

Conduct remote ceremonies or

travel

Handle security in different

company infrastructures

Restirction: Not suitable for this

use-case, No common

development for the

development scope

111

ii. If there are more challenges than opportunities, the individual

matrix field is coloured red.

iii. If there are no specific opportunities or challenges or balanced

ratings, the field is coloured grey.

c. The resulting recommendation from chapter 5 is an average of all cells

for this Use Case.

d. Compare, whether this scenario fits as described or if it requires an

adaption and new evaluation.

For details, please refer to the separate matrix in this handbook.

111a

Use Case (1)

Description„One ECU with flexible features, SW delivered by one supplier (SW development at supplier side only)“

LinkedScope and objectives

Input

AlignedScope and objectives

Input

CombinedScope and objectives

Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Execution

AlignedArtefacts

Execution

CombinedArtefacts

ExecutionNumber and role of the development partners Location separation of the partners (national, international, project site, …)

One client (OEM), one supplier (1st tier). The supplier delivers HW and SW The collaboration includes the following work packages: - SW development of the ECU - HW development of the ECU - The supplier is responsible for SWE 1-6 and SYS 2-4 of Aspice As a system developer and system supplier the supplier can define the development locations individually. The client expects one main project contact as a communication interface.

Restriction: No specific Opportunities: No specific Challenges: No specific Only two parties, Only supplier develops clear project scope

Restriction: No specific Opportunities: No specific Challenges: Implementation of shared backlog without big benefits.

Restriction: Not suitable for this use-case, No common development for the development scope

Restriction: No specific Opportunities: supplier works by his established processes, because of his responsibility Challenges: No specific No need for in-depth common workflows because supplier works independently from the client with a limited process interface to the client

Restriction: No specific Opportunities: Less effort for common tool introduction and benefit from active prioritisation project due to simple project setup Challenges: Establish common workflow without being beneficial for collaboration Conduct remote ceremonies or travel Handle security in different company infrastructures


Restriction: No specific Opportunities: No specific Challenges: No specific Development on supplier side only

Restriction: No specific Opportunities: Common backlog and PR system enables early feedback Challenges: No specific


Description of the development product and system context of the product

Automotive ECU, to be integrated into an existing system (interfaces already specified) Restriction: No specific Opportunities: No specific Challenges: No specific Scope clearly defined upfront


Restriction: Not suitable for this use-Case, No common development for the development scope

Restriction: No specific Opportunities: No specific Challenges: No specific No need for in-depth common workflows because of clear specification No common ceremonies in the system context needed

Restriction: No specific Opportunities: No specific Challenges: Aligning on existing tools, especially with legacy tooling Limited complexity No need for in-depth common workflows because of clear specification No common ceremonies in the system context needed





Description of the process environment (phases, norms and guidelines)

Concept Phase is already ongoing and will be finished within the next two months. The collaboration should start within the next two months with the milestone start of series development. The development schedule has four main Milestones: Start of series development (SoD), function complete (FC), production pre-series with Note 1 ECUs and SOP. Between SoD and FC, the development of SW and HW will be carried out in an agile framework with development sprints. One sprint is three weeks long. The development includes safety-relevant functions with ASIL Level A. The client asks the supplier to fulfill ASpice Level 3. Between SoD and FC, the client has defined five official Releases. Main expected functionality of ECU for the Releases will be defined 4 weeks before the Prior release reaches the delivery milestone.

Restriction: No specific Opportunities: No specific Challenges: No specific The client defines process along certain milestones. No more frequent synchronisation beneficial


Restriction: Not suitable for this use-Case, No common development for the development scope

Restriction: No specific Opportunities: No specific Challenges: No specific No need for in-depth common workflows because supplier works independently from the client with limited process interfaces to the supplier No common ceremonies in system context needed

Restriction: No specific Opportunities: Support traceability requirements (e.g. ASPICE) Benefit from active prioritisation project supporting the client system requirements. Challenges: No specific No need for in-depth common workflows because supplier working independently from client with limited process interface to client





Complexity of the development and for necessary project organisation Development duration

The ECU is based on an existing one which is already in series. The client expects new functions and better Performance. For requirements engineering, SW development and testing first estimation from supplier 1 calculate approximately with 4 teams. Development time from SoD until FC is scheduled with 18 months. Additional 12 months for industrialisation. Note 1 (series quality).The client expects the delivery of the ECU system in time, cost, quality and scope.

Restriction: No specific Opportunities: No specific Challenges: No specific Limited complexity No challenging development time No challenging goals

Restriction: No specific Opportunities: No specific Challenges: No specific Limited complexity No challenging development time No challenging goals

Restriction: Not suitable for this use case, No common development for the development scope

Restriction: No specific Opportunities: No specific Challenges: No specific Low complexity, Low challenging schedules/goals

Restriction: No specific Opportunities: Less effort for common tool introduction due to simple project setup Challenges: Establish common workflow without being beneficial for collaboration Low complexity, Low challenging schedules/goals


Restriction: No specific Opportunities: No specific Challenges: No specific Low complexity No challenging environment No challenging goals

Restriction: No specific Opportunities: No specific Challenges: No specific Low complexity No challenging environment No challenging goals


Matrix Use Cases and Collaboration Levels

The cell colors indicate how the collaboration level fits to the specific Use Case situation.

Red: Having drawbacksWhite: No specific benefits or drawbacksGreen: Having benefitsThe cell colors indicate

Use Case (2)

Description„Joint SW development project“ (SW development by client and 1 other party)


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts

OutputNumber and role of the development partners Location separation of the partners (national, international, project site, …)

One client (OEM), one supplier (Tier) (SW Engineering Service Provider) The collaboration includes the following work packages: - SW development - SW module test The client is system responsible. For the SW modules which the supplier develops; the supplier is responsible for SWE 1-5 of ASpice. The client has defined a development area from the supplier close to the client‘s development centre. The client expects one main project contact as a communication Interface and the possibility of having a minimum level of direct communication to further the communication interfaces of each development team. The supplier can organise his project team according to his own standards, but he has to guarantee agile development and agile mind setting.

Restriction: No specific Opportunities: No specific Challenges: Alignment of client and supplier scope, because of common SW development

Restriction: No specific Opportunities: Exchange of SW- Requi-rements, in a common SW-develop-ment Challenges: Scope is only aligned at the end of each iteration

Restriction: No specific Opportunities: Exchange of SW- Requi-rements, in a common SW-develop-ment Challenges: Scope is only aligned at the end of each iteration

Restriction: No specific Opportunities: Exchange of SW-Requirements, in a common SW-development Challenges: No specific

Restriction: No specific Opportunities: No specific Challenges: Maintain ASPICE demanded traceability in a manual manner. no common tools

Restriction: No specific Opportunities: Low effort due to two partners only. Benefit from common ceremonies in SW development that requires close collaboration Challenges: Conduct remote ceremonies or travel Workflows are easier because backlog alignment is easier with the client being close to supplier

Restriction: No specific Opportunities: No specific Challenges: Keep separated backlogs aligned

Restriction: No specific Opportunities: No specific Challenges: No specific Number of partners is manageable

Restriction: No specific Opportunities: SW only. Synchronisation of partners is easily achievable. Challenges: No specific


Automotive ECU, to be integrated into a new system (interfaces not final) Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client and supplier)

Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client and supplier)

Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client and supplier)

Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client, supplier)

Restriction: No specific Opportunities: No specific Challenges: Hard to handle dynamic system environment

Restriction: No specific Opportunities: No specific Challenges: No specific Partially separated ceremonies/tooling from system

Restriction: No specific Opportunities: No specific Challenges: Keep separated backlogs aligned, due to high dynamic of a new system

Restriction: No specific Opportunities: SW only. Alignment of changing requirements is easily manageable. Challenges: No specific

Restriction: No specific Opportunities: SW only. Alignment of changing requirements is easily manageable. Challenges: No specific


Phase 1: concept phase. 6 months until concept confirmation milestone and start of series development. 2 months before end of phase 1, the client is planning a public demonstrator. Phase 2: Start of series development until delivery of first systems to a limited number of pre-users [6 months] Phase 3: Industrialisation The cooperation should start within the next four weeks. The concept development team from the client is already working on the system, including SW. The development schedule has five main Milestones: Start of cooperation, availability of public demonstrator, start of series development, availability of pre-series, availability of series. The whole development will be carried out in an agile framework with development sprints. One sprint is two weeks long. The development includes safety-relevant functions with ASIL Level A. The client asks the cooperation partner to fulfill ASpice Level 2. For the client each sprint result should be useable for official use by the client (official release).

Restriction: No specific Opportunities: No specific Challenges: Common prioritisation, planning and integration along a complete agile development process on client side

Restriction: No specific Opportunities: Common prioritisation within common backlog and better synchronisation with client process. Challenges: No specific



Restriction: No specific Opportunities: No specific Challenges: - Alignment of the artefacts without

common tools is difficult due to frequent deliveries

- Achieve official releases every sprint by manual alignment

Restriction: No specific Opportunities: Regular alignment on single source in common product backlog. Challenges: - Alignment of the artefacts with only

common backlog tools is difficult due to frequent deliveries

- Achieve official releases every sprint by partially manual alignment

Restriction: No specific Opportunities: No specific Challenges: Align the artefacts, due to frequent deliveries

Restriction: No specific Opportunities: Automatic alignment due to single source in common product backlog. Challenges: No specific

Restriction: No specific Opportunities: Automatic alignment due to single source. Challenges: No specific


The system is complete new with complete new functions, too. Because of the ambitious timeframe, the supplier has to develop and test the SW Modules in different teams. Development time from start of cooperation (phase 1) until start of industrialisation (phase 3) is 12 months. The duration of industrialisation is not defined. Currently the phase 3 is not part of the collaboration request. C-sample for limited and selected pre-users. The main focus of the client is that the supplier delivers the SW modules in time and quality.

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and supplier scope, because of common SW development, complexity and strong dependencies - Reaching milestones without intensive alignment of scope

Restriction: No specific Opportunities: - Common backlog simplifies high

complexity.- Common prioritisation at a level

enables reaching milestones. Challenges: No specific







Restriction: No specific Opportunities: No specific Challenges: - Strong alignment for MVP and defect

correction due to complexity needed- Meet the timeframe due to longer

synchronisation time because of missing tool support/ceremonies for alignment

Restriction: No specific Opportunities: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. Challenges: No specific

Restriction: No specific Opportunities: No specific Challenges: - Keep separated artefacts aligned, due

to high dynamic of a new system- Time-consuming alignment activities.

Strong alignment for MVP needed

Restriction: No specific Opportunities: - SW only. Alignment of changing

requirements is easily achievable.- Less alignment effort due to shared

artefacts, enables MVP Challenges: No specific

Restriction: No specific Opportunities: - SW only. Alignment of changing



111b



Use Case (3)

Description„One ECU with flexible features, SW delivered by one supplier (SW development at supplier side only)“


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts


One client (OEM), more than two suppliers (SW development companies) The cooperation includes the following work packages: - SW development - SW module test The client is system (ECU) responsible. For the SW modules which the supplier(s) develops. The supplier(s) are responsible for SWE 1-5 of ASpice. The supplier(s) can define the development locations individually. The client has development locations for this ECU development in three different countries with different time zones. The client expects one main project contact from each supplier as a communication interface.

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and multiple

suppliers scope, because of common SW development across multiple time zones

- Synchronise overall backlog from client to suppliers

Restriction: No specific Opportunities: - Multiple dev partners are

synchronised by one common backlog

- Exchange of SW- Requirements, in a common SW-development Challenges:

- SW development in common teams across different time zones


Restriction: No specific Opportunities: - Benefit from common ceremonies in SW

development that requires close collaboration

- Synchronisation on iteration cadence is feasible even for multiple distributed partners Challenges:

- Conduct remote ceremonies or travel


development that require close collaboration

- Synchronisation at least on iteration cadence is feasible even for multiple distributed partners Challenges:

- Conduct ceremonies remotely or travel - Fulfilling collaboration workflow with

virtual teams Locating complete teams in one location brings an additional chance for combined collaboration

Restriction: No specific Opportunities: - Benefit from common ceremonies in

SW development that require close collaboration

- Synchronisation at least on iteration cadence is feasible even for multiple distributed partners Challenges:

- Conduct ceremonies remotely or travel

- Fulfilling collaboration workflow with virtual teams Locating complete teams in one location brings an additional chance for combined collaboration

Restriction: No specific Opportunities: No specific Challenges: Integration and Testing of deliveries from several partners in different time zones/locations

Restriction: No specific Opportunities: No specific Challenges: Integration and Testing of deliveries from several partners in different time zones/locations

Restriction: No specific Opportunities: SW only. Synchronisation of all partners is supported by common CI/CD system Challenges: No specific


Automotive ECU, to be integrated into a new system (interfaces not specified, final) Restriction: No specific Opportunities: No specific Challenges: Keep separated backlogs aligned to the client master backlog, due to high dynamic of a new system

Restriction: No specific Opportunities: SW only. Alignment of changing requirements is easily achievable. Challenges: No specific



Restriction: No specific Opportunities: - Benefit from common ceremonies/tools

in SW development that requires close collaboration considering system interfaces

- More simple alignment due to simpler or less workflows already at architecture level Challenges: No specific

Restriction: No specific Opportunities: - Benefit from common ceremonies/

tools in SW development that requires close collaboration considering system interfaces


Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client, suppliers)

Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client, suppliers) If client works at system integration level in an agile manner, one can leverage from advantages of aligned collaboration on system level

Restriction: No specific Opportunities: No specific Challenges: regular validation of external system interfaces (Outside dev-Teams client, suppliers) If client works at system integration level in an agile manner, one can leverage from advantages of aligned collaboration on system level


Concept Phase is already finished and the Series Development Phase has started recently. The cooperation should start as soon as possible with an Initial phase for one release. If the cooperation between all involved parties is successful, the cooperation will be continued until function complete milestone. The development schedule has six main Milestones: Start of series development (SoD) [already passed], three official integration steps (releases), function complete (FC), pre-series and SOP. Between SoD and FC the development of SW will be carried out in an agile framework with development sprints. One sprint is three weeks long. The SOPs of the different vehicles are time-shifted. The development includes safety relevant functions with ASIL Level D. The client asks the involved suppliers to fulfil ASpice Level 2. Between SoD and FC, the client has defined three official releases and in between currently not scheduled and counted releases (depends on SW quality, test campaigns and management requests). For each sprint the client will prioritise the tickets in the overall backlog. After each sprint, the SW modules from the suppliers are integrated by the client. The suppliers need to deliver fully documented and tested SW modules.

Restriction: No specific Opportunities: No specific Challenges: Following client backlog prioritization, planning and integration along a complete agile development process

Restriction: No specific Opportunities: Client prioritisation within common backlog for better synchronisation with client process. Challenges: No specific




Restriction: No specific Opportunities: Regular alignment on single source in common product backlog enables function testing at system level Challenges: - Alignment of the artefacts with only



Restriction: No specific Opportunities: - Regular alignment on single source

backlog enables function testing at system level

- Common tools enable efficient regular alignment on single source backlog and on common work products. Challenges: Align common workflow in parallel to the common development



- Common tools enable efficient regular alignment on single source backlog and on common work products. Challenges: Align common workflow in parallel to the common development

Restriction: No specific Opportunities: No specific Challenges: Align the artefacts, due to frequent deliveries - Regular testing of function comprised by deliverables from multiple suppliers due to less synchronised development

Restriction: No specific Opportunities: Automatic alignment due to single source in common product backlog enables function testing at system level Challenges: No specific

Restriction: No specific Opportunities: Automatic alignment due to single source enables function testing at system level - CI/CD minimises risk and effort for releases for milestones Challenges: No specific


The ECU is new and the system with sensors and actors is also new. Many functions are located in different ECUs (distributed functions). The ECU with the SW modules from the suppliers will be integrated in different vehicle architectures. Because of the absolute number of functions and expected test cases, the project needs more than one development team at each supplier. Development time from SoD till FC is scheduled with 12 months. C-sample until milestone function complete (FC).The client expects the delivery of the ECU System in time, cost, quality and scope.

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and suppliers

scope (based on client master backlog), because of common SW development, complexity and strong dependencies

- Achieving milestones without alignment of scope

- technical synchronisation because of reuse in multiple vehicle models


complexity.- Client prioritisation at one level

enables achieving milestones. Challenges: No specific

Restriction: No specific Opportunities: No specific Opportunities: - High effort for alignment of MVP

and defect correction due to complexity needed

- Meet the timeframe due to longer synchronisation time because of missing tool support/ceremonies for alignment


Restriction: No specific Opportunities: - Alignment during sprint reduces risks to

achieve MVP, new complex functions and fast defect correction

- Less alignment effort due to common ceremonies/tools

- Meet the timeframe due to tool supported short feedback loops for interface changes and adaptations (source code)

- ECU system responsible within the agile team reduces effort for alignment Challenges: Handle multiple sites in different time zones supplier aligns to client processes to enable collaboration on Architecture level despite supplier‘s responsibility of SWE 1-5

Restriction: No specific Opportunities: - Alignment during sprint reduces

risks to achieve MVP, new complex functions and fast defect correction - Less alignment effort due to common ceremonies/tools - Meet the timeframe due to tool supported short feedback loops for interface changes and adaptations (source code) - ECU system responsible within the agile team reduces effort for alignment Challenges: Handle multiple sites in different time zones supplier aligns to client processes to enable collaboration on Architecture level despite supplier‘s responsibility of SWE 1-5

Restriction: No specific Opportunities: No specific Challenges: - Keep separated artefacts aligned, due to high dynamic of a new system - Time consuming alignment activities. Strong alignment for MVP needed

Restriction: No specific Opportunities: - SW only. Alignment of changing requirements is feasible. - Less alignment effort due to shared artefacts, enables MVP Challenges: No specific

Restriction: No specific Opportunities: - SW only. Alignment of changing requirements is easily achievable. - Less alignment effort due to shared artefacts, enables MVP Challenges: No specific

111c



Use Case (4A)

Description„Joint SW development project with multiple partners, functionality of feature is distributed on multiple ECUs (new platform)“


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts


One client (OEM), more than one supplier (Tier) (SW development companies)The cooperation includes the following work packages:- SW development- SW module test- SW integration and SW system test (client)The client responsible for the main feature. For the SW sub-functions which the supplier(s) develops. The supplier(s) are responsible for SWE 1-5 of ASpice.

The suipplier(s) can define the development locations individually. The client has concentrated its own development at one development location. The client expects one main project contact from each supplier as a communication interface.

Restriction: No specificOpportunities: No specificChallenges: - Alignment of client and multiple

suppliers‘ scope, because of common SW development

- Synchronise overall backlog from client and suppliers

Restriction: No specificOpportunities: - Multiple dev partners are

synchronised by one common backlogChallenges: - No specific

Restriction: No specificOpportunities: - Multiple dev partners are

synchronised by one common backlog- Exchange of SW- Requirements, in a

common SW-developmentChallenges: - No specific

Restriction: No specificOpportunities: No specificChallenges: Maintain ASPICE demanded traceability in a manual man-ner.

no common tools

Restriction: No specificOpportunities: - Benefit from common ceremonies in SW


- Synchronisation on iteration cadence is feasible even for multiple partners

Challenges:No specific

Restriction: No specificOpportunities: - Benefit from common ceremonies in


- Synchronisation is feasible for multiple partners

- Leverage the concentrated client development location

Challenges:- No specific

Restriction: No specificOpportunities: No specificChallenges: Integration and Testing of deliveries from several partners

Restriction: No specificOpportunities: No specificChallenges: Integration and Testing of deliveries from several partners

Restriction: No specificOpportunities: SW only. Synchronisation of all partners is supported by common CI/CD systemChallenges: No specific


Automotive ECUs, already integrated (interface and/or architecture modifications possible) Restriction: No specificOpportunities: No specificChallenges: Keep separated backlogs aligned to the client master backlog for possible modification

Restriction: No specificOpportunities: SW only. Alignment of changing requirements is easily achievable.Challenges: No specific

Restriction: No specificOpportunities: SW only. Alignment of changing requirements is easily achievable.Challenges: No specific

Restriction: No specificOpportunities: No specificChallenges: No specific


Restriction: No specificOpportunities: - Benefit from common ceremonies/


Challenges: No specific


Restriction: No specificOpportunities: - client works on system integration level in an agile manner, one can leverage from advantages of aligned collaboration at a system levelChallenges: No specific

Restriction: No specificOpportunities: - client works on system integration level in an agile manner, one can leverage from advantages of combined collaboration at a system levelChallenges: No specific


No concept phase because of model update (care) only. The cooperation should start as soon as possible. The supplier(s) are already known from earlier projects. But the previous cooperation was not necessarily agile.The client plans function update for a model update in the field. The functionality of the system has to be updated because of changed requirements and updates on client‘s devices.The update will launched in the series production after MVP is reached and function(s) are successfully verified and validated, no later than 9 months after SoD. After first MVP, the development will be continued to implement further client experience functions.The development schedule has the following main milestones: Start of development (SoD) [already passed], release for official production and quality validation (no later than 3 months before SOP), pre-series and SOP. Between SoD and official release, the development of SW will be carried out in an agile framework with development sprints. One sprint is two weeks long.The development includes safety relevant functions.The client asks the involved suppliers to fulfil ASpice Level 2.Between SoD and official production, release has defined no fixed scheduled official Releases. The client expects a SW delivery every two weeks. For each sprint the client will prioritise the tickets in the overall backlog. After each sprint the SW modules from the supplier (s) will be integrated and validated in the different ECUs by the client. Errors will be documented in the ticket system from the client. The supplier(s) have to deliver fully documented and tested SW modules.

Restriction: No specificOpportunities: No specificChallenges: Following client backlog prioritisation, planning and integration along a complete agile development process

Restriction: No specificOpportunities: Client prioritisation within common backlog for better synchronisation with client process.Challenges: No specific

Restriction: No specificOpportunities: Client prioritisation within common backlog for better synchronisation with client process.Challenges: No specific

Restriction: No specificOpportunities: No specificChallenges: - Alignment of the artefacts without



- Change workflow and employees‘ mindset from classical to agile in parallel to the common development

Restriction: No specificOpportunities: Regular alignment on single source in common product backlog enables function testing at system levelChallenges: - Alignment of the artefacts with only



- Change workflow and employees‘ mindset from classical to agile in parallel to the common development

Restriction: No specificOpportunities: - Regular alignment on single source


- Common tools enable efficient regular alignment on single source backlog and on common work products.

Challenges: Change workflow and employees‘ mindset from classical to agile in parallel to the common development

Restriction: No specificOpportunities: No specificChallenges: Align the artefacts, due to frequent deliveries- Regular testing of function

comprised by deliverables from multiple suppliers due to less synchronised development

Restriction: No specificOpportunities: Automatic alignment due to single source in common product backlog enables function testing at system levelChallenges: No specific

Restriction: No specificOpportunities: Automatic alignment due to single source enables function testing at system level- CI/CD minimises risk and effort for

releases for milestonesChallenges: No specific


The ECUs are already integrated and in series. An update of the HW is not planned. The main feature is located in different ECUs (distributed functions). Because of the absolute number of sub-functions and expected test cases, the project needs more than one development team at each supplier.

Development time from SoD till SOP is scheduled within a maximum period of 9 months. The collaboration time may be extended for the development of additional features.

As soon as possible availability of series SW (MVP). The client expects the delivery of the ECU System in cost, quality and time. Scope (MVP) will be defined during an initial phase.

Restriction: No specificOpportunities: No specificChallenges: - Alignment of client and supplier

scope (based on client master backlog), because of common SW development and dependencies

- Reaching milestones without intensive alignment of scope

- Integrated SW must have series quality

- Maintain high quality for possible earlier SOP

Restriction: No specificOpportunities: - Common backlog in alignment with

client problem resolution systemChallenges: - Integrated SW must have series

quality- Maintain high quality for possible

earlier SOP

Restriction: No specificOpportunities: - Common backlog simplifies high

complexity.- Client prioritisation at one level

enables reaching milestones.Challenges: - Integrated SW must have series

quality- Maintain high quality for possible

earlier SOP

Restriction: No specificOpportunities: No specificChallenges: - High effort for alignment of MVP and

defect correction to maintain required quality

- Meet the timeframe due to longer synchronisation time because of missing tool support/ceremonies for alignment

Restriction: No specificOpportunities: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction.Challenges:- Alignment with industrialisation process

in agile context

Restriction: No specificOpportunities: - Alignment during sprint reduces risks

to achieve MVP with required quality and fast defect correction


- Meet the timeframe due to tool supported short feedback loops for interface changes and adaptations (source code)

- Using client central development location

Challenges: - Alignment with industrialisation

process in agile context

Restriction: No specificOpportunities: No specificChallenges: - Keep separated artefacts aligned,

due to possible earlier SOP- Time consuming alignment activities.

Strong alignment for MVP(SOP) needed

Restriction: No specificOpportunities: - SW only. Alignment of changing

requirements is feasible.- Less alignment effort due to shared

artefacts, enables MVPChallenges: - Maintain SOP quality level due to

possible earlier SOP by manual integration

Restriction: No specificOpportunities: - SW only. Alignment of changing

requirements is easily achievable.- Less alignment effort due to shared artefacts, enables MVP (SOP) in required qualityChallenges: No specific

111d



111e

Use Case (4B)

Description„Joint SW development project with multiple partners, functionality of feature is distributed on multiple ECUs (new platform)“


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts


One client (OEM), more than one supplier (Tier) (SW development companies) The cooperation includes the following work packages: - SW development - SW module test - SW integration and SW system test The client is responsible for the main feature. For the SW sub-functions which the supplier(s) develops. The supplier(s) is responsible for SWE 1-5 of ASpice. The supplier(s) can define the development locations individually. The client has concentrated its own development at one development location. The client expects one main project contact from each supplier as a communication Interface. The client is planning to install common repository.

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and multiple

suppliers‘ scope, because of common SW development

- Synchronise overall backlog of client and suppliers


synchronised by one common backlog Challenges:

- Scope is only aligned at the end of each iteration due to new functionality and architectural changes



- Exchange of SW- Requirements, in a common SW-development

Challenges: - No specific



development that re iteration cadence is feasible even for multiple partners Challenges: No specific



- Synchronisation is feasible for multiple partners



Restriction: No specific Opportunities: No specific Challenges: Manual integration and testing of deliveries from several partners

Restriction: No specific Opportunities: No specific Challenges: Manual integration and testing of deliveries from several partners

Restriction: No specific Opportunities: Synchronisation of all partners is supported by common CI/CD system Challenges: No specific


Automotive ECUs, to be integrated into a modified system (interface and/or architecture modifications necessary)

Restriction: No specific Opportunities: No specific Challenges: Keep separated backlogs aligned to the client master backlog, due to high dynamic of a new system

Restriction: No specific Opportunities: Alignment of changing requirements is easily achievable. Challenges: No specific

Restriction: No specific Opportunities: Alignment of changing requirements is easily achievable. Challenges: No specific






Restriction: No specific Opportunities: No specific Challenges: No specific

Restriction: No specific Opportunities: - client works at system integration level in an agile manner, one can leverage from advantages of aligned collaboration at the system level Challenges: No specific

Restriction: No specific Opportunities: - client works at system integration level in an agile manner, one can leverage from advantages of combined collaboration at the system level Challenges: No specific


The cooperation should start as soon as possible. The supplier(s) are already known from earlier projects. But the previous cooperation was not necessarily agile. Phase 1: Concept phase. 6 months until concept confirmation milestone and start of series development. 1 month before end of phase 1 the client is planning to be part of an international congress and to demonstrate a first prototype. Phase 2: Start of series development till function complete confirmation. Phase 3: Industrialisation The functionality of the system has to be developed because of new requirements, new devices and new vehicle electric/ electronic platform. The development schedule has the following main milestones: Start of concept development [already passed], start of cooperation [SoC], end of concept development and start of series development [SoD], end of series development with milestone function complete and release for official production and quality validation (no later than 9 months before SOP), pre-series and SOP. Between SoC and official release, the development of SW will be carried out in an agile framework with development sprints. One sprint is two weeks long. Until SoD the client will define together with the suppliers the MVP for SOP. The development includes safety-relevant functions. The client asks the involved suppliers to fulfil ASpice Level 2. The client expects a SW delivery every two weeks (each sprint). For each sprint the supplier will prioritise the tickets in the overall backlog. After each sprint the SW modules from the suppliers will be integrated and validated in the different ECUs by the supplier. Errors will be documented in the ticket system from the client. The supplier(s) have to deliver full documented and tested SW modules. After SW module integration, integration and system test the client will decide, if the release will be used as an official release or as engineering release only.

Restriction: No specific Opportunities: No specific Challenges: Following client backlog prioritisation, planning and integration along a complete agile development process






Restriction: No specific Opportunities: Regular alignment on single source in common product backlog enables function testing at system level Challenges: - Alignment of the artefacts with only





- Common tools enable efficient regular alignment on single source backlog and on common work products.

- Using common concept phase to develop a common workflow for series development. Challenges: No specific

Restriction: No specific Opportunities: No specific Challenges: Align the artefacts, due to frequent deliveries - Regular testing of function

comprised by deliverables from multiple suppliers due to less synchronised development

Restriction: No specific Opportunities: Automatic alignment due to single source in common product backlog enables function testing at system level Challenges: No specific

Restriction: No specific Opportunities: Automatic alignment due to single source enables function testing at system level - CI/CD minimises risk and effort for

releases for milestones Challenges: No specific


The HW (ECUs) will be developed and integrated in the new E/E platform in parallel. An update of the HW is planned in already defined Integration Levels (I-Level). A lot of features are located in different ECUs (distributed functions). Because of the absolute number of sub-functions and expected test cases the project needs more than one development team at each supplier. Development time from SoC till SOP is scheduled with in maximum 24 month. After SOP the suppliers have to guarantee a development support for bug fixing. Availability of verified and validated series SW (MVP) till SOP in cost, quality and time. Establishing of agile collaboration between client and a number of SW supplier(s).

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and suppliers

scope (based on client master backlog), because of common SW development, complexity and strong dependencies

- Reaching milestones without intensi-ve alignment of scope

Restriction: No specific Opportunities: - Common backlog simplifies handling

of high complexity.- client prioritisation on a system level

enables passing client milestones. Challenges: No specific


of high complexity.- Client prioritisation on a system level

enables passing client milestones. Challenges: No specific

Restriction: No specific Opportunities: No specific Challenges: - High effort for alignment of MVP and

defect correction due to complexity needed


Restriction: No specific Opportunities: - Alignment during sprint reduces

risks to achieve MVP, new complex functions and fast defect correction


- Reduced effort due to tool supported short feedback loops for interface changes and adaptations (source code)

- ECU system responsible within the agile team reduces effort for alignment Challenges: No specific

Restriction: No specific Opportunities: No specific Challenges: - Keep separated artefacts aligned,

due to high dynamic of a new system

- Time consuming alignment activi-ties. Strong alignment for MVP needed

Restriction: No specific Opportunities: - Alignment of changing

requirements is feasible.- Less alignment effort due to

shared artefacts, enables MVP Challenges: No specific

Restriction: No specific Opportunities: - Alignment of changing requirements

is easily achievable.- Less alignment effort due to shared




111f

Use Case (5)

Description„Mixed Classic and Agile Development“


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts


One client (OEM, different departments), one system supplier (includes mechanics, HW and SW) The cooperation includes the following work packages: - Mechanical development of a new system - HW development for a new ECU - SW development - SW test - System integration - System validation in vehicle The client is responsible for the vehicle and system interface. For the system which the supplier develops, the supplier is responsible for SYS 2-4 and SWE 1-6 of ASpice. The supplier can define the development location(s) individually. The client has concentrated his own development at one development location. For each sub-project part, the client expects one main project contact as a communication interface and one contact for the whole project.

Restriction: No specific Opportunities: - client supports requirements

specification in cross-discipline backlog refinements Challenges:

- Having a cross-discipline aligned client backlog

- Alignment of client and suppliers scope across disciplines

- Breaking down common cross-discipline backlog to the discipline-specific backlogs

Restriction: No specific Opportunities: - Consistency by one common

cross-discipline backlog Challenges:



cross-discipline backlog Challenges:





- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners Challenges: No specific



- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners

- Leverage the concentrated client development location Challenges:

- No specific

Restriction: No specific Opportunities: No specific Challenges: Manual integration and testing of deliveries from several disciplines and partners


Restriction: No specific Opportunities: Synchronisation of all disciplines and partners is supported by common CI/CD system Challenges: No specific


Automotive powertrain system (e.g. Transmission, E-Motor, HV battery). System has to be integrated into a vehicle (interfaces not specified, final)

Restriction: No specific Opportunities: - supplier has possibility to work at

the system level in an agile manner because the client provides a cross-discipline backlog Challenges:

- Keep separated backlogs aligned to the client master backlog due to the complexity of the developed system

- Get informed on system/interface changes at the vehicle level from client side

Restriction: No specific Opportunities: - Common backlog enables alignment

of changing requirements - Supplier has possibility to work at the

system level in an agile manner because the Client provides a cross-discipline backlog

- Structured backlog input at the vehicle level Challenges: Handle complexity in one common backlog


of changing requirements - supplier has possibility to work at the

system level in an agile manner because the client provides a cross-discipline backlog


Restriction: No specific Opportunities: No specific Challenges: Hard to handle definition of interfaces to vehicle environment

Restriction: No specific Opportunities: Benefit from common ceremonies/tools in system development that requires close collaboration considering vehicle interface Challenges: No specific


tools in system development that requires close collaboration considering vehicle interfaces


Restriction: No specific Opportunities: - client integrates flexibly at the vehicle level, one can leverage from advantages of close collaboration at the vehicle level (e.g. improved quality, early defect detection, risk reduction) (see UC-process description) Challenges: No specific




Concept Phase is ongoing and will be finished within the next month. Next milestone is concept confirmation. After this milestone the series development Phase will start. The cooperation should start as soon as possible. With the concept confirmation milestone, a virtual system and virtual vehicle validation is requested from the client. If the milestone is passed successfully, the project will be continued until SOP. The product development process (PDP) is the standard classic PDP from the client. The PDP already includes a number of integration levels for the integration, validation and release of all mechatronics systems. The time between two Integration levels is approximately 3 months. The series development ends with the milestone function complete (FC) and 100% of released parts for the series purchasing. During series development, the client scheduled a number of virtual validation milestones. For presentation usage (show cases) and for real system validation usages, a number of HW parts have to be produced. Currently no full vehicle build is planned during the series development phase until milestone FC. The SOPs of the vehicle are already fixed according to the Standard PDP. The development includes safety-relevant functions with ASIL Level D. The client asks the involved parties to fulfil ASpice Level 2. Between the official releases, the client has informed the involved parties that releases that are not currently scheduled or counted (depends on SW quality, test campaigns and management requests) are possible. The client expects regular SW updates for their own system tests. Especially for the SW development, the client will work according to agile principles. For mechanics and HW, the usage of agile principles depends on the experience from the involved parties in working according to agile. A minimum of one development department at the client will work with a classic process. Each involved party will have to deliver sufficiently documented and tested delivery items. Until the last official release (integration level) before milestone function complete, the client will have the possibility to define and prioritise the functionality of the system (SW functions) for first SOP (MVP). Design freeze for mechanical systems will be approximately 9 months earlier.

Restriction: No specific Opportunities: No specific Challenges: Following client backlog prioritisation, planning and integration across multiple disciplines in complete agile development process - High effort to align with

stakeholders across disciplines

Restriction: No specific Opportunities: Less synchronisation effort for common prioritisation within a common backlog across disciplines Challenges: High effort to align with stakeholders across disciplines

Restriction: No specific Opportunities: Less synchronisation effort for common prioritisation within a common backlog across disciplines Challenges: High effort to align with stakeholders across disciplines


Restriction: No specific Opportunities: Regular alignment on single source in common product backlog enables function testing at the vehicle level Challenges: No specific

Restriction: No specific Opportunities: - Regular alignment on single source in

common product backlog enables function testing at the vehicle level Challenges:

- high effort for establishing closer collaboration for collaboration at the vehicle level only

- high effort for establishing combined collaboration with no guarantee that the project will continue


Restriction: No specific Opportunities: Automatic alignment due to single source in common product backlog enables function testing at the vehicle level Challenges: No specific

Restriction: No specific Opportunities: Automatic alignment due to single source enables function testing at the vehicle level Challenges: CI at te vehicle level difficult and probably not even reasonable Due to loose coupling of SW across ECU boundaries, there is no benefit of common SW repositories.h


The system is new (mechanics, HW and SW). The system has multiple interfaces to other systems in the vehicle. Many functions are located in different ECUs (distributed functions). Because of the different sub-projects, the absolute number of functions and expected test cases the project needs is noticeably more than one development team at the supplier. Development time from start of cooperation (in concept phase) until SOP is approximately 36 months. C-sample short-term after milestone function complete. The client expects the delivery of the system in time, cost, quality and scope.

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and supplier

scope (based on client master backlog), because of common development, complexity and strong dependencies

- Reaching milestones without intensive alignment of scope


of high complexity.- Common prioritisation at the vehicle

level enables passing of client milestones. Challenges: No specific


of high complexity.- Common prioritisation at the vehicle

level enables passing of client milestones. Challenges: No specific




Restriction: No specific Opportunities: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. Challenges: High effort to establish combined collaboration without any further benefits



is feasible.- Less alignment effort due to shared

artefacts enables MVP Challenges: No specific



artefacts, enables MVP Challenges: High effort for CI on vehicle level



Use Case (6)

Description„HW / Mechatronic development project using agile principles/methods“


Input


Input


Input

LinkedWorkflow

Execution

AlignedWorkflow

Execution

CombinedWorkflow

Execution

LinkedArtefacts

Output

AlignedArtefacts

Output

CombinedArtefacts


One client (OEM), one main supplier (1st Tier), several supplier for mechanical prototypes and tools. The development project environment consists of: - Co Development between client and main supplier regarding interfaces and technical feasibility

between product and car- Multiple supplier(s) are responsible for the production of prototype and test parts according to the

design of the main supplier- Another suplier is responsible for the design and production of tools for test and serial production The Client and main supplier are located in the same country but several hundred km apart. The client expects one main project contact person as well as direct contacts on expert levels for fast exchange. For the implementation of the product the client wants a representative from the main supplier aside. The main supplier and the sub suppliers are located regional. The production site of the main supplier is located in Europe.

Restriction: No specific Opportunities: - The client supports requirements

specification in cross-discipline backlog refinements Challenges:

- Alignment of client and supplier scope, because of common development

- Synchronise overall backlog from client/mainsupplier and suppliers


cross-discipline backlog - Multiple dev partners are

synchronised by one common backlog Challenges:


- Scope is only aligned at the end of each iteration due to new functionality and architectural changes


cross-discipline backlog - Multiple dev partners are


- Exchange of Requirements, in a common development Challenges:

- Breaking down common cross-discipline backlog to the discipline specific backlogs




- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners Challenges: No specific



- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners



Restriction: No specific Opportunities: No specific Challenges: Manual integration and testing of deliveries from several disciplines and partners keep separated backlogs aligned


Restriction: No specific Opportunities: Synchronisation of all disciplines and partners is supported by common integration and deployment system Challenges: No specific


A number of prototypes at defined different maturity levels for necessary test cases in prototype cars to pass the clients internal regulations as well as international norms. „Ready to integrate“ product with a high share of moving parts for the just-in-sequence delivery at the clients plant starting at SOP. Specifications & Interfaces for Mechanics, HW, SW already defined but not final. 24 months to SOP.

Restriction: No specific Opportunities: - supplier has possibility to work at the

system level in an agile manner, because the client provides a cross-discipline backlog Challenges:

- Keep separated backlogs aligned to the client master backlog, due to the complexity of the developed system

- Get informed on system/interface changes at the vehicle level from client side



system level in an agile manner, because the client provides a cross-discipline backlog




system level in an agile manner, because the client provides a cross-discipline backlog


Restriction: No specific Opportunities: No specific Challenges: Hard to handle definition of interfaces to vehicle environment

Restriction: No specific Opportunities: Benefit from common ceremonies/tools in system development that requires close collaboration considering vehicle interface Challenges: No specific


tools in system development that requires close collaboration considering vehicle interfaces


Restriction: No specific Opportunities: - client integrates flexibly at the vehicle level, one can leverage from advantages of close collaboration at the vehicle level (e.g. improved quality, early defect detection, risk reduction) (see UC-process description) Challenges: - Regular validation of external

system interfaces- Keep separated artefacts aligned,

due to high dynamic

Restriction: No specific Opportunities: - client integrates flexible at the vehicle level, one can leverage from advantages of close collaboration at the vehicle level (e.g. improved quality, early defect detection, risk reduction) (see UC-process description) Challenges: No specific regular validation of external system interfaces

Restriction: No specific Opportunities: - client integrates flexible at the vehicle level, one can leverage from advantages of close collaboration at the vehicle level (e.g. improved quality, early defect detection, risk reduction) (see UC-process description) Challenges: No specific regular validation of external system interfaces


Concept Phase is already ongoing and will be finished within the next two months. The cooperation should start within the next two months with the Milestone start of series development. The development schedule has five main Milestones: Start of series development (SoD), concept finished, development finished, SOP, project finished. Between SoD and development finished the development of SW and HW will be carried out in an agile framework with development sprints. One sprint is two weeks long. The client asks the main supplier to fulfil ASpice Level 2 and ISO26262. Between SoD and development finished the client has defined five official Releases for product and production validation.

Restriction: No specific Opportunities: No specific Challenges: Following client backlog prioritisation, planning and integration across multiple disciplines in complete agile development process - High effort to align with stakeholders

across disciplines Restriction: No specific Opportunities: No specific Challenges: Common prioritisation and planning and integration along a complete agile development process on client side

Restriction: No specific Opportunities: Less synchronisation effort for common prioritisation within a common backlog across disciplines Challenges: High effort to align with stakeholders across disciplines Restriction: No specific Opportunities: Common prioritisation within common backlog and better synchronisation with client process. Challenges: No specific

Restriction: No specific Opportunities: Less synchronisation effort for common prioritisation within a common backlog across disciplines Challenges: High effort to align with stakeholders across disciplines Restriction: No specific Opportunities: Common prioritisation within common backlog and better synchronisation with client process. Challenges: No specific


common tools is difficult

Restriction: No specific Opportunities: Regular alignment on single source in common product backlog enables function testing at the vehicle level Challenges: No specific


in common product backlog enables function testing at the vehicle level Challenges:

- high effort for establishing closer collaboration for collaboration at the vehicle level only


Restriction: No specific Opportunities: Automatic alignment due to single source in common product backlog enables function testing at the vehicle level Challenges: No specific

Restriction: No specific Opportunities: Automatic alignment due to single source enables function testing at the vehicle level Challenges: CI at the vehicle level difficult and probably not even reasonable


HW & SW for the product are standard „off-the-company´s shelf“; adaptation to the clients‘ specification is a major part of the project. The challenge is to steer the interdisciplinary core team to reach the different product maturity levels. The cross-functional (agile) development team at the first supplier consists of mechanical design, simulation, systems engineering, test engineering, prototype building, operations and quality. This cross-functional (agile) development team comprises 8 people, with an overall project team of 15 people, depending on the project need. The project representative steers additional internal resources on demand as well as the external sub suppliers for parts and tools. The serial development & industrialisation phase from POC to SOP is planned within 24 months. Note 1 (series quality)

Restriction: No specific Opportunities: No specific Challenges: - Alignment of client and supplier

scope (based on client master backlog), because of common development, complexity and strong dependencies

- Reaching milestones without intensi-ve alignment of scope


of high complexity.- Common prioritisation at a vehicle

level enables the passing of client milestones. Challenges: No specific


of high complexity.- Common prioritisation at a vehicle

level enables the passing of client milestones. Challenges: No specific




Restriction: No specific Opportunities: - Regular prioritisation within the

development teams. (Tools/Ceremonies) enables MVP and fast defect correction.

- Less alignment effort due to common ceremonies/tools Challenges: High effort to establish combined collaboration without any further benefits

Restriction: No specific Opportunities: No specific Challenges: - Keep separated artefacts aligned,

due to high dynamic of a new system

- Time-consuming alignment activities. Strong alignment for MVP needed


requirements is feasible.- Less alignment effort due to

shared artefacts enables MVP Challenges: No specific


is easily achievable.- Less alignment effort due to shared

artefacts, enables MVP Challenges: CI at the vehicle level difficult and probably not even reasonable

111g



112

10 Appendix 4 – Agile Collaboration Checklist

By using this appendix, the collaboration parties can check how deeply they have

installed agile methods and principles within their company and projects, which are

in focus of the agile collaboration.

Name(s) of OEM/Customer/Partner

1 Representative(s)

Functional Area:

Name(s) of Tier 1/Supplier/Partner 2

Representative(s)

Functional Area:

Table 28 Agile Collaboration Checklist

1 General Aspects/Project Scope

and Objectives

Feedback/Comments

1. General collaboration level/project type:

OEM and 1st tier supplier collaboration on

an ECU project or Joint SW development

project?

(Refer to Chapter 5 Collaboration Use

Cases)

2. Agile Values & Principles:

Well-known and applied by all partners?

(Refer to Chapter 2.2 Prerequisites for suc-

cessful Agile Collaboration)

3. Agile Goals:

What is the goal that the partners wanted

to achieve by applying agile (methods)?

113


and Objectives

Feedback/Comments

4. Agile Experience:

Describe used agile methods and tools and

duration/extent of usage (all departments

involved in the upcoming project)?

Are Project Management, Purchasing and

Quality also involved in the agile activities?

5. Planned collaboration level:

Linked Collaboration or

Aligned Collaboration or

Combined Collaboration

(Refer to Chapter 2 Levels and Prerequi-

sites of Agile Collaboration)

6. Collaboration agreement:

Accepted by all parties to describe the ag-

ile collaboration in detail?

(e.g. as part of/appendix to the contract)?

7. System borders/scope of common develop-

ment:

Are the functional parts (e.g. at the block

diagram level) which are the subject of the

common agile development identified (e.g.:

a common/central CI system or

parts available as source code or only bi-

nary/ libs)?

8. Non-SW discipline collaboration:

Agile collaboration planned for non-SW

disciplines e.g. System Eng., Electrical Eng.,

Mechanical Eng.

9. Fixed boundary conditions:

Are the Schedule (integration milestones),

budget and overall effort fixed by a con-

tract?

Basis for the contract: fixed prize or other

(agile) contract types?

114


and Objectives

Feedback/Comments

10. Product responsibility:

Who has the overall product responsibility?

11. Source code sharing:

Is sharing of source code required?

Regulations for source code and binaries

sharing available (IP clarification)?

API between Source code and binaries

(e.g. platforms) defined?

Debugging concept for binaries in a com-

mon CI system defined (e.g. SW Integrator

available onsite)?

12. Intellectual Property (IP):

IP brought in by one party or generated

during the project - how to handle it?

Also see black box parts or binary deliver-

ies

13. Delivery scenario:

Container (e.g. PDX) for the deliveries de-

fined?

Maturity stages for deliveries commonly

defined?

14. Warranty:

Which party has the overall responsibility in

case of warranty issues?

15. Agile Startup:

Is an introduction phase of agile/agile col-

laboration planned after the project start

(e.g. common introduction steps, training,

coaching or lessons learned)?

115

2 Roles Feedback/Comments

16. Agile Roles:

Are the agile roles defined?

(e.g. Product Owner, Agile Master)

Used only by one or by all partners?

17. Derived agile Roles:

Shall (common) roles be derived from the

collaboration level to be used?

18. Classic Roles:

Are classical roles planned?

(e.g. SW Project Mgr.),

19. Project Steering/Escalation Board:

Is the proceeding for escalations beyond

the agile collaboration defined and is the

respective Project Steering Board/Escala-

tion Board defined?

3 Artefacts Feedback/Comments

20. Requirements Management:

Which “traditional” documents are to be

generated (commonly): e.g. System Re-

quirements Specification or Software Re-

quirements Specification?

Planned implementation of traceability for

common parts (tools, IDs…)?

Link from traditional elements (Features,

Requirements) to agile elements

(e.g. EPICS, User Stories, Tasks)

Common RM tooling (e.g. DOORS) re-

quired?

116


21. Architecture:


generated (commonly): e.g. System Archi-

tectural Design, Software Architectural De-

sign, Software Detailed Design?

Planned implementation of traceability for

common parts (tools, IDs…)?

Common design tooling (e.g. Rhapsody)

required?

Common design guidelines (e.g. MISRA)

required?

22. Continuous Integration:


generated (commonly): e.g. Software Inte-

gration Strategy, Software Integration Test

Strategy?

Is the target CI level (level 1-n) and the

characteristics (e.g. trigger: developers,

gated or qualified commit) defined?

Common CI tooling (e.g. Jenkins, JIRA and

Git) required?

23. Testing:


generated (commonly): Test Plan (incl. test strategies at all levels), Test

Specification (on all test level)?

Common/aligned test systems required

(e.g. integrated Build Verification Test, Unit

Test, Integration Test, Continuous Func-

tional Test as part of a common CI system)

Common test tooling (e.g. for test case de-

sign and test management) required?

117


24. Configuration Management:


generated (commonly) e.g.:

Configuration Management (Version Man-

agement) Plan, Problem Mgmt. Plan,

Change Mgmt. Plan?

Common branch strategy required e.g. for

feature development (background: no

merge at lib level)? Common CM tooling

(e.g. Git, Github) required for source code?

Common CM tooling required for docu-

ments?

4 Ceremonies Feedback/Comments

25. Organisational level of agile:

What is the level of agile that is intended in

teams or at the project level?

26. Usage of same methods:

Shall the partners use the same agile

method

(e.g. Scrum, Kanban, SAFe )?

27. Usage of same tools:

Shall the partners use the same agile tool

infrastructure and/or DB?

28. Common Cadence:

Shall the partners use the same cadence

(e.g. team level: bi-weekly Sprints or pro-

ject level: 3-month increments)?

29. Common Agile Roles:

Shall common roles derived from the col-

laboration level be used e.g. Collaboration

Product Owner, Proxy Product Owner …?

118

5 Quality Feedback/Comments

30. ASPICE e.g. CL x required for the projects:

Is a joint Agile vs. ASPICE concept (incl.

process management) in focus (e.g. to

reach CL x together in this project)?

Are the relevant Q-departments involved in

the agile collaboration model?

Are ASPICE assessments planned for this

project?

31. Process Reviews by OEM:

Are Process Reviews planned during the

project life cycle?

Are the agile aspects considered in the re-

view checklist?

32. Independent QA personal:

Requirements available for QA, a common

QA function (e.g. Quality Product Owner)

for the scope of collaboration?

33. QA tools:

Common QA tooling required?

34. Aligned Checks/Guidelines:

Common/aligned MISRA requirements de-

fined?

Common coding guidelines defined?

Common Gate criteria for CI Systems?

Common definition of Definition of Done

(DoD) required?

6 External Partners Feedback/Comments

35. Other partners:

Other partners beside the contractor par-

ties involved in the project?

How are they involved in the agile collabo-

ration?

119

6 External Partners Feedback/Comments

36. Agile consultancy framework:

Are external consultancies defined for

building a common framework for the agile

collaboration between the partners?

37. Identification of agile consultancy:

Preferences for external consultancies

(training or coaching) to build up a com-

mon agile understanding.

7 Project Specific Extensions Yes No Comments

1. <Add project specific ques-

tions & extensions here>

120

11 Appendix 5 - Glossary

Introduction

This glossary summarises the terms in the context of agile development in short

conceptual descriptions. The aim is to create a common understanding of es-

sential terms within an agile team and at the interface to organisations and part-

ners in the context of collaboration in agile and hybrid projects.

Agile Master

The Agile Master is the coach and mentor of the team. He moderates the Daily-

Standup as well as the retrospective. He is responsible for the application of the

agile principles, processes and behaviour in a team. As coach and mentor, he

always ensures a high degree of self-motivation and self-control in the team. His

tasks are:

• Organising meetings

• Guaranteeing the collaboration of teams without any interferences

• Removing all impediments during product development

• Watching and validating the advances and status

• Optimising the output by further developing the agile team, methods and

processes

• He is a methodology expert and educated explicitly as an Agile Master.

Agile Servant Leader

The Agile Servant Leader represents the non-agile part of the company with

profit/loss responsibility and full legal responsibility, e.g. for product liability, for

the undertaking. He supports the agile organisation in living the agile values and

principles, and balances these aspects with the needs of a classical organisation

and the legal aspects of a company (e.g. mandatory reporting of a stock com-

pany, formal aspects, etc.).

121

Burndown Chart (Release and Sprint)

Burndown Charts record the progress of the team, which is compared to ready

or delivered functionality. The x-axis shows the days of the current Sprint (Sprint

Burndown Chart) and the y-axis shows the work (e.g. in Story Points).

The Sprint Burndown Chart is updated daily by the agile team and is, therefore,

very simple. If every developer of the agile team estimates his remaining effort,

the accuracy improves daily.

In a Release Burndown Chart, the milestones are according to the Release Plan-

ning and are, therefore, recorded according to the advance of the project.

Trends and prognoses can be derived from the Burndown Charts.

Chief Agile Master

In scaled agile organisations, the role of the Agile Master must be implemented

at all relevant levels (as the role of the Product Owner/Chief Product Owner).

Chief Product Owner(s)

The role of the Chief Product Owner is required in a scaled agile organisation

with more than one Agile Team. The role of the Chief Product Owner can also

be implemented as a small team (e.g. Product Management, Architect, Quality

Assurance, and Agile Master at a specific scaling level).

Collaboration Product Owner

The role of the Collaboration Product Owner is occupied by the client. The role

is required for Linked Collaboration and Aligned Collaboration types. He repre-

sents the customer’s wishes and “lives” for the vision. The Collaboration Product

Owner defines the vision of the product and further develops it (together with

the Proxy Product Owner) as the project develops. He ensures communication

among the (Chief) Agile Masters of the involved parties.

The Collaboration Product Owner hands over his vision to the Proxy Product

Owner at the beginning of the project. The Epics, as well as the Backlog, will be

refined in periodic consultations with the Proxy Product Owner.

122

Daily Standup

The Daily Standup’s purpose is that the team plans its activities for the day on

the basis of the Sprint Backlog, and communicates the status of the tasks that

have already started and are completed. It identifies and discusses any impedi-

ments, which will be entered into the Impediment Backlog.

Definition of Done

The definition of done is a checklist with (partial) results that belong to the com-

pletion of a Feature. Basically, it is defined by the agile team in collaboration

with the Product Owner, Quality Product Owner and Safety Product Owner at

the beginning of a project. Adjustments are possible as the project develops.

The goal is to create a description of characteristics that allow entire Sprint

Planning.

The definition of done helps the agile team to define the number and range of

the activities for a Sprint. The definition of done cannot be changed during a

Sprint.

During the Sprint Review, the definition of done helps the Product Owner to

make decisions in terms of acceptance of the Sprint results.

Definition of Ready

The definition of ready describes how good the User Stories are described and

understood, and what conditions are to be fullfilled so that they can be chosen

for the Sprint. The definition of ready will be used during the Backlog Refine-

ment. Basically, it is defined by the agile team, which incorporates the Product

Owner, Quality Product Owner and Safety Product Owner. Adjustments are pos-

sible as the project develops. The goal is a better description of characteristics

that accepts an entire Sprint Planning.

A typical sign is that the description is based on the INVEST principle:

• Independent

• Negotiable

• Valuable

123

• Estimable

• Sized appropriately

• Testable

Epic

The Epic is placed over the User Story and covers several coherent User Stories.

An Epic roughly describes the requirements on the product. Epics describe

tasks that are implemented later on. Most of the time, they need to be more de-

tailed later on, and implementation starts after developing a better understand-

ing for functionality.

Estimation Meeting

The goal of the meeting is that the team gets to know the content of the Product

Backlog, which is prioritised by the Product Owner, and to get a better under-

standing of the product by assessing the stories. During the meeting, the team

members assess the range of functions of the stories. If necessary, the stories

will be broken down into smaller, useful parts.

Express Ticket (Fast Lane)

As the Sprint develops, no changes or new features are allowed for the Sprint

Backlog, nor are any other disruptions to the agile team. An exception are Express

Tickets, which can result from a parallel running testing phase (Sprint), for ex-

ample, and have urgent and prioritised interceptions of identified mistakes. The

agile team decides if an Express Ticket in the course of the current Sprint can be

edited. The tasks that result from the Ticket will be inherited in the Sprint Backlog

and the tasks will be re-prioritised and removed from the Sprint Backlog.

Impediment Backlog

The Agile-Master publicly collects all obstructions to work in a list. All occurred

impediments and tasks to resolve them and their current status are contained.

The Impediment Backlog is updated on a daily basis.

124

MVP

MVP (Minimum Viable Product): The MVP is the first minimal viable iteration of

a product to be presented as a beta version or prototype, especially to potential

investors, business partners or selected customers. The possibly fast and easily

created product’s goal is to get feedback about the marketability and market

acceptance about the new product as early as possible. This feedback will flow

into further development - or products that are not accepted by the market will

not be followed up on.

Product

In context with this document, the product is the item that is delivered to the

customer. But this does not need to be the whole vehicle. This can also be a

part such as an application for operating vehicle functions or a control device

development. In agile product development, the customer-oriented characteris-

tics of a product are key. However, in the figurative sense, a releasing authority

(e.g. CARB), for example, can also be a customer in the sense of the above defi-

nition (e.g. OBD).

Product Backlog

The Product Backlog is a sorted list of the Epics and User Stories. Its content

must not be seen as finalised because User Stories always can change as the

project develops. It contains all required Epics and User Stories at each current

time. But entries can be changed, added or removed.

The Product Owner is responsible for the prioritisation of the entries according

to business use, estimated risk and continuous maintenance of the Product

Backlog.

The status of existing entries in the Product Backlog will be evaluated within the

Backlog Refinements. Dependencies will be identified and new entries will be

assessed.

The prioritised Product Backlog is the basis for the release plan, where the allo-

cation to customer releases, development cycles and, as circumstances require,

to different agile teams is documented.

125

Product Owner

His focus is on the product. He describes it and is responsible for the implemen-

tation of all requirements, as well as profitability. The Product Owner imparts the

vision and the requirements which are derived from this to the agile team. He

guides the prioritisation of the tasks so that targets can be fullfilled properly.

He supports the Collaboration Product Owner/Proxy Product Owner in develop-

ing (and further developing) the vision and in defining the Epics (and, if neces-

sary, the User Stories).

Project Manager

With an agile collaboration, the Project Manager focuses on financial, legal, and

contractual aspects of the collaboration. In hybrid projects he is responsible for

synchronising agile and non-agile sub-projects, such as Hardware, Tooling, Me-

chanics, etc.

Proxy Product Owner

The Proxy Product Owner is the equivalent to the Collaboration Product Owner

and is occupied by the contractor. The role is required for Linked Collaboration

and Aligned Collaboration types. He focuses on the product’s vision and devel-

ops it together with the Collaboration Product Owner. He transfers the require-

ments from the client to the internal team of Product Owner(s).

The Proxy Product Owner represents the “one face to the customer”. The Proxy

Product Owner gets the vision from the Collaboration Product Owner at the be-

ginning of the project. The Epics, as well as the Backlog, are refined in periodic

consultations with the Collaboration Product Owner.

Quality Assurance Owner

Representing independent quality assurance to implement the quality require-

ments, development processes and quality methods. The Quality Assurance

Owner makes sure that the quality requirements are included in the Backlog

and related requirement descriptions exist. I.a: The Quality Assurance Owner

participates the Sprint Planning and Sprint Reviews.

126

This is particularly necessary in projects with Automotive SPICE requirements.

Retrospective

After the Sprint Review, follows the Retrospective. Without any invitation, the

Retrospective is restricted to the agile team with Product Owner and Agile Mas-

ter. The goal is to achieve the highest possible degree of transparency in terms

of identifying the improvement potential of the joint working progress. This in-

cludes a reflection on the external influences and general conditions, the moti-

vation of the team and the chance to work self-reliantly. The basis for imple-

menting the Retrospective are four questions: “What was positive”, “What was

negative”, “What should absolutely be retained” and “What needs to be

changed”. Prioritised measures are adopted into the Sprint Backlog or Impedi-

ment Backlog for the following Sprint.

Safety Product Owner

The Safety Product Owner also acts as an expert. He joins the project team that

is working on projects with requests on functional safety. He is mainly special-

ised in functional safety (of the ISO 26262). He is responsible for supporting the

agile team so that all Functional Safety-relevant aspects are observed. Due to

the support with the interpretation, detailing and prioritisation of the Product

Backlog, he is responsible for complying with functional safety, as well as the

demands on quality during development.

He supports the team with the safety analysis and updates the safety proofs.

The Safety Product Owner takes part in the Sprint Reviews and the retrospec-

tives.

SAFe, LeSS, Nexus, Scrum of Scrums, Nexus

Frameworks which describe how Agile can be applied to larger projects/organi-

sations. Scrum is one of the first agile methodologies which focuses on agile at

"team" level and has limited guidance on scaling it up. This limitation was cho-

sen and elaborated on in the SAFe, LeSS, Nexus, Scrum of Scrums and Nexus

frameworks.

127

Sprint Backlog

The Sprint Backlog is drawn up at the beginning of the Sprint and defines real-

istic goals for the current and following Sprint. It is a list of Use-Cases that nota-

bly shows the agile team the tasks within the Sprint. All involved tasks are to be

fullfilled in order to implement the agreed User Stories. The Product Owner de-

fines the order of the User Stories in the Sprint Backlog. The agile team decides

how many User Stories will be contained in the current Sprint.

Sprint Goal

The Sprint Goal describes the goal of the current Sprint. The goal is that the ag-

ile team has a clear and concisely formulated course for the Sprint. This im-

proves overall understanding and shall raise the degree of self-responsibility

and individual decision making of the team in terms of the overall success. The

Sprint Goal is formulated by the Product Owner and adjusted during Sprint

Planning.

Sprint Planning

Sprint Planning can be separated into two parts - Sprint Planning Meeting 1 and

Sprint Planning Meeting 2.

Sprint Planning Meeting 1 (Refinement):

• The Meeting can be understood as an analysis. The goal is that the agile

team really understands what the customer functionally expects from the

product. At the end of the Planning, the team is to decide on its own how

much it will develop in a single Sprint.

• The results are Sprint Backlog, requirements, User Acceptance Tests and

Level of done (achievable grade of completion).

Sprint Planning Meeting 2:

• The Meeting can be understood as the design of the Sprint. The goal is that

the agile team really understands how to implement the planned functionali-

ties.

128

• The results are clear ideas such as how the Features of the Backlog are to be

implemented and, therefore, which tasks (activities) are necessary.

Sprint Review

The agile team presents its completed Backlog Sprints entries to the Product

Owner (Chief Product Owner). He is to do carry out a review and check the

achievements of the Sprint Goal. If necessary, the Product Owner is supported

by the Safety Product Owner and Quality Product Owner. Unfulfilled tasks will

be discussed and assessed.

Taskboard

The Taskboard is an overview that combines the Sprint Backlog with the User

Stories and the tasks, which were initially defined in the Sprint Planning 2. The

Task board visualises for the whole agile team the planned tasks for a Sprint,

who is to complete which tasks and the current status of the tasks (To Do, in

progress, done). The Taskboard is updated by the agile team in the Daily

Standup.

User Story

From the user’s perspective, a User Story describes the intended result. The fol-

lowing questions shall be answered: Who? (role), What? (application require-

ment), Why? (use). Note that the customer (user) is meant with WHO, and not

the developer or the implementer. The user story does not replace the require-

ment specification but shall be seen as the input for it.

The User Stories are roughly defined by Product Owner(s) and are further devel-

oped with the agile team. These granular working packages are the basis for the

features at the Product Backlog.

A good User Story has the following characteristics:

• Independent from other User Stories

• Negotiable in detail

• Valuable

• Assessable

129

• Testable

• Simple, short, precise

VUCA

VUCA is an acronym for: Volatility, Uncertainty, Complexity and Ambiguity. The

intention of this acronym is to express that today’s world is volatile, uncertain,

complex and ambiguous and that, consequently, other methods (e.g. agile) than

the plan driven approaches need to be in place to deal with VUCA.

Velocity Chart

The Velocity team describes the ability of a team to fullfill different complex

tasks within a certain time period.

The guess (e.g. Story Points) of a Sprint are summed up and the results of the

current Sprints are shown as a graphic or in a chart. The goal is to improve the

guesses, which means commitment of the agile team to the Product Owner.

The valuation is also used to assess the improvement of processes and proce-

dures within the agile team.

Vision

The vision describes the fundamental product idea and summarises the different

characteristics of the product. Product Owner(s) develop the vision with the aim

of inspiring the agile team. The vision is a super ordinated target to catch the in-

volved parties of a project at an emotional level, while providing the common

theme of a project at the same time.

The vision describes the following aspects:

• Which customers is the product for

• What are the benefits for the customer

• Which characteristics of the product are significant

• Difference to competitive products

• Product Owner(s) develop the vision further as the project develops

130

Reference:

Verband der Automobilindustrie e.V. (VDA)

Qualitäts Management Center (QMC)

Behrenstraße 35, 10117 Berlin

Telephone +49 (0) 30 89 78 42-235, Fax +49 (0) 30 89 78 42-605

e-mail: [email protected], Internet: www.vda-qmc.de

© vda qmc gelbband 2020 | entwurf - free version | ... · the idea of variable scope is to only...

Documents