Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun. Agil zu sein, bedeutet für uns: Wir orientieren uns an den Werten und Prinzipien des agilen Manifests. Agilität beginnt im Kopf…!

1. Agilität im Systems Engineering –
geht das?
Susanne Mühlbauer
REConf 2014

2. Agilität hat erstmal
nichts mit dem
Entwicklungsgegenstand zu tun

3. Agil zu sein, bedeutet für uns:
Wir orientieren uns an den Werten
und Prinzipien des agilen Manifests.

4. Was bedeutet „Agil“ für Sie?
Eine weitere
Vorgehens-
weise
Paradigmen-
wechsel /
Transition
Wohin schlägt der Zeiger in Ihrer Organisation?

5. Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und Anforderungen
2. Systems Engineering
3. Beispiele
1. Agil/ Scrum und Assessments
2. Lastenheft und Traceability
4. Fazit

6. © HOOD GmbH
Werte
Prinzipien
Agiles Manifest

7. Agile Manifesto - Values
Individuals and Interactions over processes and tools
Working software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

8. Prinzipien des Agilen Manifests
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

9. © HOOD GmbH
Werte
Prinzipien
Agiles Manifest
Bekannte Praktiken
Praktiken
Scrum, Kanban,
XP, Crystal, …
Ihre eigene...?

10. The new new development game
10
Harvard Business Review
January-February 1986
1986
Systeme

11. Theorie X - der Mensch ist unwillig
Linda Rising
Theorie Y - der Mensch ist engagiert
Agiles Mindset/ Haltung
Command & Control Transparenz & Vertrauen
Kontrolle ist gut – Vertrauen ist besser
ZielBegabung Scheitern Anstrengung
Douglas McGregor, 1969

12. kompliziert
kompliziert
System- und SW-Entwicklung ist komplex
Anforderungen
unbekanntbekannt
Technologie
bekannt unbekannt
einfach
Chaos
komplex
The Stacey Diagram,
Ralph Stacey

13. Freiheitsgrade und Vorgaben – je nach Aufgabe
kompliziert
kompliziert
Anforderungen
unbekanntbekannt
Technologie
bekannt unbekannt
einfach
Chaos
komplex
The Stacey Diagram,
Ralph Stacey
Chaos
„Gibt es hierfür eine Lösung?“
„Prototyping“
Einfache Aufgabe
„Lösung ist bekannt“
Anforderungsspezfikation
Anforderungen
Komplizierte Aufgabe
„Lösung kann mit Sorgfalt
erarbeitet werden“
Anforderungsspezfikation
Zeitdruck
Komplexe Aufgabe
„Niemand kennt die Lösung“
„Agile“

14. So ist die Realität
14
Zu langsam
Geht bei uns nicht

15. So ist die Realität
15
Zeitdruck

16. Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware

17. Die sieben Verschwendungen in
der Software-Entwicklung
• Halbfertige Arbeit
(Partially Done Work)
• Extra Features
• Wieder-Erlernen (Relearning)
• Übergaben (Handoffs)
• Ständiges Wechseln der Aufgaben
(Task Switching)
• Verzögerung (Delays)
• Fehler (Defects)
(Lean SW Development, Poppendieck)
Die sieben Verschwendungen in der Software-Entwicklung

18. Verschwendung in phasenorientierten Vorgehen
18
Halbfertige
Arbeit
Übergaben
Fehler

19. Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und Anforderungen
2. Systems Engineering
3. Beispiele
1. Agil/ Scrum und Assessments
2. Lastenheft und Traceability
4. Fazit

20. Systems Engineering
Systems Engineering
HW
Engineering
Mechanical
Engineering
Electrical
Engineering
SW-
Engineering
Embedded
SW
Enterprise
SW
• Viele Schnittstellen zum
Gesamtsystem
• Interdisziplinäre Themen
• Ausschuss ist teuer
• Integrationstests sind teuer
• Simulation/ simulierbare Systeme
und Komponenten ermöglichen
laufende (Integrations-) Tests

21. Was ist „Lean Systems Engineering“ ?
Systems
Engineering
Lean
Thinking
Lean
Systems
Engineering
Interdisziplinäre
Ingenieurstätigkeit
in komplexen
Entwicklungsprojekten
Schaffen von Wert
Vermeiden von
Verschwendung
Basierend auf:
http://www.lean-systems-engineering.org/downloads-products/lean-enablers-for-managing-
engineering-programs/

22. Wann ist eine Aktivität wertvoll?
1. Eine Aktivität ist wertvoll, wenn…
 … der Kunde dafür zahlt, und
 … sie Information/Material umwandelt bzw.
Unklarheiten minimiert, und
 … sie gleich beim ersten Mal einen definierten Nutzen bringt
2. Eine Aktivität ist nicht wertvoll, aber notwendig, wenn…
 … sie aktuell keinen Wert erzeugt, aber
 … sie erforderlich ist (z.B. aus juristischen Gründen)
3. Eine Aktivität ist Verschwendung (Waste), wenn sie…
 … keinen Wert für Kunden erzeugt, und nicht notwendig ist
Basierend auf:
http://www.lean-systems-engineering.org/downloads-products/lean-enablers-for-managing-
engineering-programs/

23. Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware
1, 2 oder 3?

24. Kleine Schritte - Fangen Sie mit einem beherrschbaren kleinen Umfang
an
24
Starten Sie in der SW-
Entwicklung
Mit einer möglichst
stabilen HW-
Komponente
Nutzen Sie Simulation
Suchen Sie ein Projekt/ Umfeld, in dem folgendes möglich scheint
Ein interdisziplinäres
Team
Verständnisvolle
Schnittstellenpartner
Integrieren Sie so oft
wie möglich

25. Weitere Synchronisationspunkte schaffen
25
Synchronisieren/
Integration
Starten Sie in der SW-
Entwicklung
Mit einer möglichst
stabilen HW-
Komponente
Nutzen Sie Simulation
Kleine Schritte: Fangen Sie mit einem beherrschbaren kleinen
Umfang an

26. Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und Anforderungen
2. Systems Engineering
3. Beispiele
1. Agil/ Scrum und Assessments
2. Lastenheft und Traceability
4. Fazit

27. Agil/ Scrum und Assessments (z.B. CMMI oder Spice)
• Reifegradmodelle zeigen auf,
was benötigt wird um einen
Reifegrad zu erfüllen
• Sie schreiben nicht das „Wie“
vor
• Assessoren brauchen ggf.
eine Übersetzung
• Es hilft, Assessoren früh
einzubinden

28. Agil/ Scrum und Assessments (z.B. CMMI oder Spice)
CMMI SG1 Manage Requirements Agile/ Scrum
REQM SP1.1 Develop an understanding with the
requirements providers on the meaning
of the requirements
Product Owner
Conversation, User Story
Backlog Refinement Session
Product Backlog Items in Status “Ready”
Planning Event
REQM SP1.2 Obtain commitment to requirements
from project participants
Backlog Refinement Session
Product Backlog Items in Status “Ready”
Planning Event
REQM SP1.3 Manage changes to requirements as they
evolve during the project
Product Backlog, Embrace Change
Review Event
REQM SP1.4 Maintain Bidirectional Traceability of
Requirements
User Story ID, Commit Messages
Definition of “Done”
REQM SP1.5 Ensure that project plans and work
products remain aligned with
requirements
Architektur- und Produktvision
Release Burndown
Daily Standup
Product Backlog
Review Event
Wenn notwendig,
integrieren Sie die
Informationen in
vorgegebene
Templates

29. Requirements -
Engineering
Requirements -
Engineering
Auftraggeber Auftragnehmer
?
Soft
ware

30. Lastenheft agil umsetzen
30
Architekturvision Produktvision
• Aufwandstreiber
identifizieren
• Architekturtreiber
identifizieren
• Schnittstellen identifizieren
• Key Features identifizieren
• Key Features priorisieren
Initiales Backlog
Feature 1
Feature 2
Feature 3
Feature …

31. Lastenheft agil umsetzen
31
Architekturvision Produktvision
• Aufwandstreiber
identifizieren
• Architekturtreiber
identifizieren
• Schnittstellen identifizieren
• Key Features identifizieren
• Key Features priorisieren
Initiales Backlog
Feature 1
Feature 2
Feature 3
Feature 1
Bearbeitungsreihenfolge
Funktionalität
und Architektur
Funktionalität
und Architektur
Umsetzung starten
Weiter ausdetaillieren
und dabei erworbenes
Wissen einarbeiten

32. Sprint
Fokus auf Dokumentation
Implementierung Code
Designanforderungen Designdoku
Systemanforderungen Systemdoku
Kundenanforderungen fachliche DokuWarum/ Ziel
Was
Wie
Stakeholder/ Leser/
Autor
User
Story
Sprint
Planning
Produkt-/
System-
Dokumentation
Traceability
Traceability

33. Auf allen Ebenen:
• Motivation, Beweggründe
• Optionen,
Entscheidungen/
Trade-Offs
• grober Überblick
• Detailinformation
• Benutzerhandbuch
• Fachliche Architektur
• Szenarien/ fachliche
Use Cases
• Testfälle, z.B. User
Acceptance Tests
• Nachweise
• …
Siehe auch Agile Testing Quadrant, Lisa Crispin
• Designprinzipien
• Schichtenmodell
• Frameworks
• Coding Guidelines
• Branching-/ Merging
Konzept
• …
• Technische Architektur
• Schnittstellen
• Nicht-funktionale
Anforderungen
• Testfälle, z.B. funktionale
Tests, Performance Tests
• Nachweise
• …
• Code
• Inline-Doku
• Testfälle, z.B. Unit Tests
• Modelle –> Reverse
Engineering
• …
Nachhaltige Artefakte
Unterschiedliche
Stakeholder/ Leser/
Autor
Langfristig relevantes
Wissen
Sofort nutzbares
Wissen
Fokus auf Wert und
Vermeidung von
Verschwendung

34. Inhaltsverzeichnis
1. Was bedeutet eigentlich Agil?
1. Werte, Prinzipien, Praktiken
2. Haltung/ Mindset
3. Komplexität und Anforderungen
2. Systems Engineering
3. Beispiele
1. Agil/ Scrum und Assessments
2. Lastenheft und Traceability
4. Fazit

35. Requirements -
Engineering Testing
Soft
ware
Interdisziplinäre Teams - die Inseln müssen zusammenwachsen
Dokumentation
Doku
Integration
Normen
Architektur

36. 36
Es ist eine Reise

37. Partnerschaftliche Zusammenarbeit
37
Vertrauen
Respekt
Offenheit
Fokus
und…

38. 38
Mut

39. Agilität beginnt
im Kopf…!

40. Susanne.Muehlbauer@HOOD-Group.com
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www.Agile-by-HOOD.com
Susanne Mühlbauer
Agile Coach

41. Agile-by-HOOD ist ein Angebot der HOOD GmbH.
HOOD konzentriert seine agilen Aktivitäten in Agile-by-HOOD
Agilität erleben: Jeden Tag gemeinsam einen Mehrwert schaffen. Ein Umdenken beginnt, neue
Ideen sind gesät und und ein mutiger Schritt ist gewagt.
Seit mehr als 25 Jahren berät und unterstützt HOOD erfolgreich seine Kunden bei der
Entwicklung komplexer Software und Systeme durch Requirements Engineering-Prinzipien.
Mit der Marke Agile-by-HOOD bündelt HOOD das Angebot im agilen Umfeld und macht somit
einen weiteren konsequenten Schritt zur zielgerichteten Unterstützung von Organisationen, die
entweder bereits agil arbeiten oder sich vorgenommen haben, in Zukunft ihre Entwicklung auf
Scrum, Kanban oder ähnliche Vorgehensweisen umzustellen.
HOOD kann dabei auf langjährige Erfahrungen im Agile Coaching und fundierte Expertise im
Requirements Engineering zurückgreifen, um große Unternehmen beim Umstieg von klassischer
auf agile Vorgehensweise zu begleiten. Das Thema agil-skaliert ist uns ein besonderes Anliegen -
wir verstehen auch die Entwicklung komplexer Produkte und Systeme mit vielen Teams und
großen Organisationen.