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.
4
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 15 Description Use Case (2) .................................................................................................. 85
Table 16 Description Use Case (3) .................................................................................................. 87
Table 17 Description Use Case (4.A) ............................................................................................... 89
Table 18 Description Use Case (4.B) ............................................................................................... 92
Table 19 Description Use Case (5) .................................................................................................. 94
Table 20 Description Use Case (6) .................................................................................................. 97
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
10
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
I. General Description
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).
III. Obligations/Responsibilities
The Proxy Product Owner represents the “one face to the customer”. He is respon-
sible for the complete product.
IV. Skills
Technical Skills:
• Good knowledge of the agile method (e.g. Scrum)
• Good knowledge of the software technology
• 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), test 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)
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
I. General Description
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.
III. Obligations/Responsibilities
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:
• 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 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
I. General Description
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.
III. Obligations/Responsibilities
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 the agile method (e.g. Scrum)
• Good knowledge of product, technology and the market
• Good knowledge of necessary development technologies and methods
Example in case of SW system:
• Good knowledge of the software technology
• Good knowledge of embedded software development and automotive tech-
nologies (e.g. operating systems, AutoSAR)
• Good knowledge of software development tools
32
• 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 Role is closely related to the classical role of a Project Manager.
3.1.5 Safety Owner
Illustration 9 Safety Owner
I. General Description
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
III. Obligations/Responsibilities
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
I. General Description
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.
III. Obligations/Responsibilities
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
I. General Description
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.
III. Obligations/Responsibilities
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
I. General Description
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.
III. Obligations/Responsibilities
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
I. General Description
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
III. Obligations/Responsibilities
• 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
Not defined by any of the frameworks 1)
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
Not defined by any of the frameworks 2)
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
Each contractual part-
ner separately
Mutual access of the
contractual partners
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.
II. Relevance for the collaboration
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)
II. Relevance for the collaboration
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.
II. Relevance for the collaboration
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
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
I. General Description (not collaboration-specific)
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
II. Relevance for the collaboration
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
II. Relevance for the collaboration
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
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
I. General Description
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).
II. Relevance for the collaboration
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
Linked Aligned Combined
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:
Each contractual part-
ner separately
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:
Each contractual part-
ner separately
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:
Mutual access of the
contractual partners
Loca-
tion/Storage
Each contractual part-
ner separately
Each contractual part-
ner separately/Mutual
access of the contrac-
tual partners can be de-
fined
Mutual access of the
contractual partners /
Common instance at
the contracting entity
can be defined
3.2.2.2 MVP
Illustration 23 MVP
I. General Description
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).
II. Relevance for the collaboration
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
Linked Aligned Combined
Ownership/
Update Pro-
cess
Contracting entity Contracting entity Contracting entity
Loca-
tion/Storage
Each contractual part-
ner separately
Each contractual partner
separately/mutual access
of the contractual part-
ners can be defined
Mutual access of the
contractual part-
ners/common instance
at the contracting entity
can be defined
53
3.2.2.3 Collaboration Agreement
Illustration 24 Collaboration Agreement
I. General Description
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)
II. Relevance for the collaboration
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
Linked Aligned Combined
Ownership/
Update
Process
Contracting entity Contracting entity Contracting entity
Location/Stor-
age
Common instance at
the contracting entity
Common instance at the
contracting entity
Common instance at
the contracting entity
54
3.2.2.4 Vision
Illustration 25 Vision
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
Linked Aligned Combined
Ownership/
Update
Process
Contracting entity Contracting entity Contracting entity
Location/Stor-
age
Each contractual part-
ner separately
Common instance at the
contracting entity
Common instance at
the contracting entity
3.2.2.5 Epic
Illustration 26 Epic
I. General Description (not collaboration-specific)
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)
II. Relevance for the collaboration
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
Linked Aligned Combined
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:
Each contractual part-
ner separately
At the level of the over-
all product:
Contracting entity
At the level of the sub-
product delivered by a
contractor:
Mutual access of the
contractual partners
Contracting entity
Linked Aligned Combined
Location/Stor-
age
Each contractual part-
ner separately
Mutual access of the
contractual
partners
Common instance at
the contracting
entity
3.2.2.6 User Story
Illustration 27 User Story
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
I. General Description (not collaboration-specific)
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.
II. Relevance for the collaboration
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
• Collaboration Product Owner
• Proxy Product Owner
• 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 Collaboration Level: Aligned
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
• Collaboration Product Owner
• Proxy Product Owner
• 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: Iteration review (SAFe)
64
Illustration 31 Collaboration review in the aligned collaboration
3.3.4 Collaboration Level: Aligned
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:
• Collaboration Product Owner
• Proxy Product Owner
• Chief Agile Masters
III. Frequency: Agreed iteration
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:
• Collaboration Product Owner
• Chief Agile Master
• Quality Assurance Owner (both companies)
66
III. Frequency: Agreed iteration
IV. Mapping to existing frameworks: Product Increment Planning (SAFe)
Illustration 33 Collaboration planning in the combined collaboration
3.3.6 Collaboration Level: Combined
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
• Collaboration Product Owner
• Chief Agile Master
• Quality Assurance Owner (both companies)
• Safety Owner (both companies)
67
III. Frequency: Agreed iteration
IV. Mapping to existing frameworks: Iteration review (SAFe)
Illustration 34 Collaboration review in the combined collaboration
3.3.7 Collaboration Level: Combined
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
III. Frequency: Agreed iteration
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)
• Proxy Product Owner
(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)
• Proxy Product Owner
(Tier)
• Product Owner (OEM,
Tier)
• Chief Product Owner
(OEM, Tier)
• Agile Master (OEM,
Tier)
• Quality Owner (OEM,
Tier)
• Safety Owner (OEM,
Tier)
• Agile Team (OEM,
Tier)
• Function Owner (OEN,
Tier)
• Project manager (Tier,
commercial)
• Agile Servant Leader
(OEM, Tier)
• Product Owner (OEM
or
Tier)
• Chief Product Owner
(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)
• Agile Servant Leader
(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
• common product back-
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
Separate Infrastructure
• Engineering Environment
Common Infrastructure
• common requirements
management tool
• common (public) back-
log
• Exchange Infrastructure
(effort reduction)
(Delivery, Test, Defect)
Separate Infrastructure
Common Infrastructure
• 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.
Step Name Main Task Hints
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.
Step Name Main Task Hints
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
development partners
(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
Table 15 Description Use Case (2)
Criteria Description
Number and role of the
development partners
One client (e.g. OEM), one supplier (SW Engineering Service Provider)
The cooperation includes the following work packages:
• SW development
• SW module test
Number and role of the
development partners
The client is system responsible. The ESP is responsible for SW engi-
neering processes of ASPICE for the SW modules he develops.
Description of the devel-
opment product and sys-
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
Description of the pro-
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).
Local separation of the
development partners
(national, international,
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.
Complexity of the devel-
opment and for the nec-
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.
Development duration
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
(e.g. maturity of the prod-
uct)
C-sample for limited and selected pre-users. The client expects the
ESP to deliver on time and with the required quality.
Use Case 2 Recommendation
• 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
Table 16 Description Use Case (3)
Criteria Description
Number and role of the
development partners
One client (e.g. OEM), more than two suppliers (SW development
companies)
The cooperation includes the following work packages:
• 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.
Description of the devel-
opment product and sys-
tem context of the prod-
uct
The Automotive ECU will be integrated into a new system, in which
the interfaces are not completely specified.
Description of the process
environment (phases,
norms and guidelines)
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.
Description of the process
environment (phases,
norms and guidelines)
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.
Local separation of the
development partners
(national, international,
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.
Complexity of the devel-
opment and for the nec-
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
(e.g. maturity of the prod-
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
Use Case 3 Recommendation
• 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.
• Linked is not suitable in this scenario.
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)
Criteria Description
Number and role of the
development partners
One client (e.g. OEM), more than one supplier (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-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)
Description of the pro-
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.
Local separation of the
development partners
(national, international,
project site, …)
The supplier(s) can define the development locations individually.
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
Complexity of the devel-
opment and for the nec-
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 duration
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)
Criteria Description
Number and role of the
development partners
One client (e.g. OEM), more than one supplier (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-func-
tions which the supplier(s) develops, the suppliers are responsible
for the SW engineering processes of ASPICE.
Description of the devel-
opment product and
system context of the
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.
Local separation of the
development partners
(national, international,
project site, …)
The supplier(s) can define the development locations individually.
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.
Complexity of the devel-
opment and for the nec-
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 duration
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
(e.g. maturity of the prod-
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
Table 19 Description Use Case (5)
Criteria Description
Number and role of the
development partners
One client (e.g. OEM, different departments), one system supplier (in-
cludes 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/3 and the SW engineering processes of ASPICE.
Description of the de-
velopment product and
system context of the
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.
Description of the pro-
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
Local separation of the
development partners
(national, international,
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.
Complexity of the devel-
opment and for the nec-
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 duration
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.
• Linked is not suitable in this scenario.
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
Table 20 Description Use Case (6)
Criteria Description
Number and role of the
development partners
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
Description of the devel-
opment product and sys-
tem context of the prod-
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.
Description of the pro-
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.
Local separation of the
development partners
(national, international,
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.
Development duration
The serial development & industrialisation phase from POC to SOP
is planned within 24 months.
Goal of the project
(e.g. maturity of the prod-
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
Principles Benefit Actions
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
Principles Benefit Actions
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 (?)
• Agile Master (OEM,
Tier)
• Quality Product Owner
(OEM, Tier)
• Safety Product Owner
(OEM, Tier)
• Agile Teams (OEM, Tier)
• Function Owner
• Project manager (Tier,
for commercial issues)
• Agile Entrepreneur
(OEM, Tier)
• Chief Product Owner
(OEM)
• Product Owner (Tier)
• Proxy Product Owner
(?)
• Agile Master (OEM,
Tier)
• Quality Product Owner
(OEM, Tier)
• Safety Product Owner
(OEM, Tier)
• Agile Team (OEM, Tier)
• Function Owner
• Project manager (Tier,
for commercial issues)
• Agile Entrepreneur
(OEM, Tier)
• Product Owner (OEM or
Tier)
• Agile Master
• Quality Product Owner
• Safety Product Owner
• Agile Teams (shared)
• Function Owner
• Agile Entrepreneur
(OEM, Tier)
Artifacts • supplier delivers ready-
to-use software pack-
ages
• each party has its own
backlog
• deliveries of the defined
scope
• common product back-
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
development partners
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)
Description of the process
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
Development duration
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)
Linked Aligned Combined
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: Not suitable for this use-case, No common development for the development scope
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
Restriction: Not suitable for this use-case, No common development for the development scope
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: 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: 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
Restriction: Not suitable for this use-case, No common development for the development scope
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
Restriction: Not suitable for this use-case, No common development for the development scope
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: 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: 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
Restriction: Not suitable for this use-case, No common development for the development scope
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
Restriction: Not suitable for this use-case, No common development for the development scope
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: Not suitable for this use-case, No common development for the development scope
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
Restriction: Not suitable for this use-case, No common development for the development scope
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)
LinkedScope and objectives
Input
AlignedScope and objectives
Input
CombinedScope and objectives
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
Description of the development product and system context of the product
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
Description of the process environment (phases, norms and guidelines)
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: Common prioritisation within common backlog and better synchronisation with client process. Challenges: No specific
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
Complexity of the development and for necessary project organisation Development duration
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: - Common backlog simplifies high
complexity.- Common prioritisation at a level
enables reaching milestones. Challenges: No specific
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
requirements is easily achievable.- Less alignment effort due to shared
artefacts, enables MVP Challenges: No specific
111b
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 (3)
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
Output
AlignedArtefacts
Output
CombinedArtefacts
OutputNumber and role of the development partners Location separation of the partners (national, international, project site, …)
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: No specific Challenges: Maintain ASPICE demanded traceability in a manual manner. no common tools
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
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: - 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
Description of the development product and system context of the product
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: 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: - 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
- More simple alignment due to simpler or less workflows already at architecture level Challenges: No specific
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
Description of the process environment (phases, norms and guidelines)
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: 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 enables function testing at system level 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: - 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
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
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
Complexity of the development and for necessary project organisation Development duration
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
Restriction: No specific Opportunities: - Common backlog simplifies high
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: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. Challenges: No specific
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
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 (4A)
Description„Joint SW development project with multiple partners, functionality of feature is distributed on multiple ECUs (new platform)“
LinkedScope and objectives
Input
AlignedScope and objectives
Input
CombinedScope and objectives
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), 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
development that requires close collaboration
- Synchronisation on iteration cadence is feasible even for multiple partners
Challenges:No specific
Restriction: No specificOpportunities: - Benefit from common ceremonies in
SW development that require close collaboration
- 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
Description of the development product and system context of the product
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: No specificChallenges: No specific
Restriction: No specificOpportunities: - Benefit from common ceremonies/
tools in SW development that requires close collaboration considering system interfaces
Challenges: No specific
Restriction: No specificOpportunities: No specificChallenges: 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
Description of the process environment (phases, norms and guidelines)
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
common tools is difficult due to frequent deliveries
- Achieve official releases every sprint by manual alignment
- 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
common backlog tools is difficult due to frequent deliveries
- Achieve official releases every sprint by partially manual alignment
- Change workflow and employees‘ mindset from classical to agile in parallel to the common development
Restriction: No specificOpportunities: - 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: 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
Complexity of the development and for necessary project organisation Development duration
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
- 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)
- 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
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
111e
Use Case (4B)
Description„Joint SW development project with multiple partners, functionality of feature is distributed on multiple ECUs (new platform)“
LinkedScope and objectives
Input
AlignedScope and objectives
Input
CombinedScope and objectives
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), 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
Restriction: No specific Opportunities: - 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
Restriction: No specific Opportunities: - Multiple dev partners are
synchronised by one common backlog
- 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: - Benefit from common ceremonies in SW
development that re iteration cadence is feasible even for multiple partners Challenges: No specific
Restriction: No specific Opportunities: - Benefit from common ceremonies in
SW development that require close collaboration
- Synchronisation is feasible for multiple 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 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
Description of the development product and system context of the product
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: 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: - 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: 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
Description of the process environment (phases, norms and guidelines)
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: Client prioritisation within common backlog for better synchronisation with client process. Challenges: No specific
Restriction: No specific Opportunities: Client prioritisation within common backlog for 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 enables function testing at system level 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: - 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.
- 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
Complexity of the development and for necessary project organisation Development duration
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
Restriction: No specific Opportunities: - Common backlog simplifies handling
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: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. Challenges: No specific
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
- 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
artefacts, enables MVP Challenges: No specific
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
111f
Use Case (5)
Description„Mixed Classic and Agile Development“
LinkedScope and objectives
Input
AlignedScope and objectives
Input
CombinedScope and objectives
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, 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:
- Breaking down common cross-discipline backlog to the discipline-specific backlogs
Restriction: No specific Opportunities: - Consistency by one common
cross-discipline backlog Challenges:
- Breaking down common cross-discipline backlog to the discipline-specific backlogs
Restriction: No specific Opportunities: No specific Challenges: Maintain ASPICE demanded traceability in a manual manner. no common tools
Restriction: No specific Opportunities: - Benefit from common ceremonies in
development that requires close collaboration
- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners Challenges: No specific
Restriction: No specific Opportunities: - Benefit from common ceremonies in
development that requires close collaboration
- 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: 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
Description of the development product and system context of the product
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
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
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
Restriction: No specific Opportunities: - Benefit from common ceremonies/
tools in system development that requires close collaboration considering vehicle interfaces
- More simple alignment due to simpler or less workflows already at architecture level Challenges: No specific
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
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
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
Description of the process environment (phases, norms and guidelines)
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: No specific Challenges: No specific
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: No specific Challenges: Align the artefacts, due to frequent deliveries
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
Complexity of the development and for necessary project organisation Development duration
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
Restriction: No specific Opportunities: - Common backlog simplifies handling
of high complexity.- Common prioritisation at the vehicle
level enables passing of client milestones. Challenges: No specific
Restriction: No specific Opportunities: - Common backlog simplifies handling
of high complexity.- Common prioritisation at the vehicle
level enables passing of 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: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. 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
Restriction: No specific Opportunities: No specific Challenges: No specific
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
artefacts, enables MVP Challenges: High effort for CI on vehicle level
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 (6)
Description„HW / Mechatronic development project using agile principles/methods“
LinkedScope and objectives
Input
AlignedScope and objectives
Input
CombinedScope and objectives
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 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
Restriction: No specific Opportunities: - Consistency by one common
cross-discipline backlog - Multiple dev partners are
synchronised by one common backlog Challenges:
- Breaking down common cross-discipline backlog to the discipline-specific backlogs
- Scope is only aligned at the end of each iteration due to new functionality and architectural changes
Restriction: No specific Opportunities: - Consistency by one common
cross-discipline backlog - Multiple dev partners are
synchronised by one common backlog
- Exchange of Requirements, in a common development Challenges:
- Breaking down common cross-discipline backlog to the discipline specific backlogs
Restriction: No specific Opportunities: No specific Challenges: Maintain ASPICE demanded traceability in a manual manner. no common tools
Restriction: No specific Opportunities: - Benefit from common ceremonies in
development that requires close collaboration
- Synchronisation on iteration cadence (not necessarily every sprint) is feasible even for multiple disciplines and partners Challenges: No specific
Restriction: No specific Opportunities: - Benefit from common ceremonies in
development that requires close collaboration
- 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 keep separated backlogs aligned
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 integration and deployment system Challenges: No specific
Description of the development product and system context of the product
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
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
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
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
Restriction: No specific Opportunities: - Benefit from common ceremonies/
tools in system development that requires close collaboration considering vehicle interfaces
- More simple alignment due to simpler or less workflows already at architecture level Challenges: No specific
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
Description of the process environment (phases, norms and guidelines)
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
Restriction: No specific Opportunities: No specific Challenges: - Alignment of the artefacts without
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
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
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 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
Complexity of the development and for necessary project organisation Development duration
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
Restriction: No specific Opportunities: - Common backlog simplifies handling
of high complexity.- Common prioritisation at a vehicle
level enables the passing of client milestones. Challenges: No specific
Restriction: No specific Opportunities: - Common backlog simplifies handling
of high complexity.- Common prioritisation at a vehicle
level enables the passing of 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: Regular prioritisation within the development teams. (Tools/Ceremonies) enables MVP and fast defect correction. 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
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
artefacts, enables MVP Challenges: CI at the vehicle level difficult and probably not even reasonable
111g
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
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
1 General Aspects/Project Scope
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
1 General Aspects/Project Scope
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
3 Artefacts Feedback/Comments
21. Architecture:
Which “traditional” documents are to be
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:
Which “traditional” documents are to be
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:
Which “traditional” documents are to be
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
3 Artefacts Feedback/Comments
24. Configuration Management:
Which “traditional” documents are to be
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
131