Agile Entwicklung physischer Produkte · Reduzierung von Risiken im Projekt Optimierung der Qualität ... Anwendung 22.10.2018 10 Agile Entwicklung physischer Produkte ... Rollen

22.10.2018

Agile Entwicklung physischer Produkte Historie, Vorteile, Framework, Besonderheiten, Transformation

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Agile Konzepte entstanden in den 80er Jahren in physischen Produktentwicklungsprojekten

22.10.2018 Agile Entwicklung physischer Produkte 2

Die Entwicklung konkreter agiler Methoden geht zurück auf die Veröffentlichung von

im Harvard Business Review in 1986 “The New New Product Development Game”

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Im Prozess und voneinander

lernen

Überlappung von Phasen

Selbst- Organisierende

interdisziplinäre Teams

Vertrauen und

Fehlerkultur

Organisationales Lernen

Flexible Anforderungen

Die Erfolgsfaktoren der untersuchten Entwicklungsprojekte physischer Produkte wurden als der „Rugby Approach“ oder „Moving the SCRUM Downfield” bekannt


Erfolgs- faktoren

Quelle: The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, Januar-Februar 1986

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Anfang der 2000er Jahre wurden diese agilen Konzepte zum Scrum Guide weiterentwickelt

24.9.2018 Dirk Meißner | Konferenz Agile@Hardware | Frankfurt Klassikstadt 4

Historisch geht Scrum auf die US-amerikanischen Software-Entwickler Jeff Sutherland und Ken Schwaber zurück Beide standen Mitte der 1990er Jahre vor der Frage, wie sich die Produktion von Software effizienter gestalten ließe 2001 veröffentlichten Jeff Sutherland und Ken Schwaber das agile Manifest und pflegen seither den Scrum Guide

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Scrum ist heute die bedeutendste agile Methode auch im non-IT Bereich

22.10.2018 Agile Produktentwicklung 5

0% 20% 40% 60% 80% 100%

Lean Startup

Design Thinking

Lean

Kanban

Scrum

Welche Bedeutung haben die jeweiligen Methoden für Ihren Bereich?

zentrale Bedeutung für meinenTätigkeitsbereich

wird für meinenTätigkeitsbereich neben anderenMethoden genutzt

geringe Beduetung in meinemTätigkeitsbereich

keine Bedeutung in meinemTätigkeitsbereich

keine Angabe

Quelle: 3. Studie über Erfolg und Anwendungsformen von agilen Methoden , Hochschule Koblenz, Prof. Dr. Ayelt Komus, 240 Antworten für non-IT http:/www.status-quo-agile.de

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2


Geänderte Rahmenbedingungen erfordern neue Führungsstile und Arbeitsmethoden

Volatile

Uncertain

Die Veränderungsgeschwindigkeit nimmt kontinuierlich zu

Die Vorhersehbarkeit nimmt ab

Complex

Ambiguous

Probleme sind nicht mehr linear bei mehrfach verbundenen Variablen

Die Realität ist unscharf

Stable

Secure

Easy

Explicit

Das Umfeld verändert sich nur langsam

Die Vorhersehbarkeit ist gegeben

Probleme sind relativ einfach und Lösungen bekannt

Die Realität ist eindeutig

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Beweggründe für die Nutzung agiler Methoden


31%

35%

42%

47%

61%

0% 10% 20% 30% 40% 50% 60% 70%

Optimierung der Planbarkeit

Optimierung des Produktwertes

Reduzierung von Risiken im Projekt

Optimierung der Qualität

Optimierung der Produkteinführungszeit

Warum hat sich Ihr Unternehmen dazu entschlossen mit agilen Methoden zu arbeiten?

Quelle: 3. Studie über Erfolg und Anwendungsformen von agilen Methoden , Hochschule Koblenz, Prof. Dr. Ayelt Komus, 784 Antworten http:/www.status-quo-agile.de

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

komplex

kompliziert

Agile Methoden reagieren auf die gestiegene Veränderungsgeschwindigkeit und Unsicherheit in komplexen Bereichen mit adaptiver Planung und empirischer Prozesskontrolle

Was

? (A

nfor

deru

ngen

)

Wie ? (Technologie)

unkl

ar

unbe

kann

t kl

ar

beka

nnt

etabliert neu

chaotisch

einfach

Transparenz

Überprüfung Anpassung

Stacey-Matrix Empirische Prozesskontrolle

Reduktion von Unsicherheit durch

empirische Prozesskontrolle

Agiles Projekt


Original: Strategic management and organisational dynamics, the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002Ralph D. Stacey, Adaptiert: Dirk Meißner

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

5 Gründe für die Überlegenheit agiler Produktentwicklung


Erfüllen der Kundenbedürfnisse in einer volatilen Welt durch regelmäßiges direktes Feedback von Kunden und Stakeholdern

Gesteigerte Effizienz durch das Entfernen von Hindernissen und kontinuierliche Verbesserung

Hohe Effektivität und Wertsteigerung durch konsequente Priorisierung

Hohe Transparenz durch festgelegte Ereignisse und offene Informationen

Kürzere Time-to-Market und Terminverlässlichkeit durch fokussiertes Arbeiten, Team-Commitment und schnelle Entscheidungen

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Das Scrum-Framework kommt bei der Entwicklung physischer Produkte ohne Anpassungen zur Anwendung


Stakeholder Product Owner Development Team Scrum Master

Product Vision

Sprint Backlog

Sprint Planning 2

Artefact Event

Sprint 1-4 weeks

15 min

Product Backlog

Daily Scrum

Product Backlog Refinement

Sprint Planning 1

Sprint Retrospective

Product

Sprint Review

Product Increment

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Case Study 1: Gesamtfahrzeugentwicklung e-LKw

22.8.2018 Webinar - Agile Development of Physical Products 11

Unmöglicher Vorstandsauftrag

Realisierung in 24 statt 60 Monaten

Falls wir es schaffen, dann nur als Scrum Pilot

1 PO, 1 SM 10 Entwickler

aus unterschiedlichen Hierachieebenen

Sprint-Länge 4 Wochen

ProjektplanungKonzept

ProduktgestaltungSerieneinführung

Konzept-freigabe

Produkt-freigabeEntwicklungs-

freigabe

Projekt-genehmigungProjekt-

start

Projektmanagement

Design-to-Cost

Validierung

Anforderungsmanagement

Konstruktion

Musterbau

Qualitätsmanagement

Einkauf

Fertigungsplanung

Produktion

Serie

Lastenheft-freigabe

M2

Projekt-genehmigung

M3

Pflichtenheft-freigabe

M4

Konzept-freigabe

M5

Vorabserien-freigabe

M6

Pilotserien-freigabe

M8

Produkt-freigabe

M9

Projektab-schluss

M10

Entwicklung-freigabe

M7

Projekt-start

M1Erlaubnis zur

Verschlankung des PEP

Agile Zusammenarbeit mit Entwicklungs-

dienstleister

Minimal Reporting-

effort

Entscheider sind wöchentlich

auf der Projektfläche

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Case Study 2: Agile Transformation der gesamten Entwicklung


Agile Awareness im Vorstand Januar 2016

Schritt 1 Produktfamilie als Scrum Pilot

April 2016

1 PO, 1 SM

Hydraulik, Mechanik, Firmware, Elektronik

Kanban TeamPlattform und Technologie

Kanban TeamHardware

Kanban TeamPrüffeld

Scrum TeamKompaktpumpen

Scrum TeamAntriebe

Scrum TeamSysteme

ScrumMaster Master

Agile CoachSync Team

Schritt 2 Umstellung des gesamten

Bereichs Pumpensysteme und Antriebe

bis September 2017 3 Scrum Teams, 3 Kanban Teams

an einem Standort

Begleitendes Team- und

Einzelcoaching

Schritt 4 Rollout außerhalb der Entwicklung

ab Juli2018


Advantages Kürzere Entwicklungszeiten Besseres Erfüllen marktseitiger Anforderungen durch Hohe Transparenz Offener Umgang mit Problemen Verringerung der technischen Schuld

Schritt 3 Rollout auf

alle Standorte bis März 2018

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Case Study 3: Skaliertes Scrum zur Entwicklung einer eCar Produktfamilie


Ankündigung der agilen

Transformation durch den CEO Sep 16

Das eCar Projekt eignete sich perfekt wegen der hohen

Komplexität

Scrum Teams wurden in Wellen implementiert

4 50 seit Jan 17


Vorteile Kürzere Reaktionszeiten Bessere Erfüllung der Kundenanforderungen by Hohe Transparenz Interdisziplinäre Zusammenarbeit Schneller Entwcheidungen

Ein cross-funktionale Team entwickelte einen zielführenden

skalierten Ansatz Nov 16 – Jan 17

PO SM

PO PO PO PO PO

PLAS Scrum Team

PO

PO SM

PO PO PO PO PO

PLQ Scrum Team

PO

PO SM

PO PO PO PO PO

PLED Scrum Team

PO

PO SM

PO PO PO PO PO

PLD Scrum Team

PO

PO SM

PO PO PO PO PO

PLC Scrum Team

PO

PO SM

PO PO PO PO PO

PLM Scrum Team

PO

PO SM

PO PO PO PO PO

PLPP Scrum Team

PO

PO SM

PO PO PO PO PO

PLPF Scrum Team

PO

APO SM

LPO LPO LPO LPO LPO

Scrum Team Production

LPO

PO SMSM

SM

Rohbau Scrum Teams

Modulgruppen Development Teams

…

PO SMSM

SM

Rohbau Scrum Teams


…

PO SMSM

SM

Rohbau Scrum Teams


…

PO SMSM

SM

Rohbau Scrum Teams


…

PO SMSM

SM

Rohbau Scrum Teams


…

PO SM

APOAPO

APO APO APO APO APO APOAPO

APO

Scrum Team VehicleStakeholder

Line Organization

GPO SMSM

SM

Scrum Teams Structure

Development Teams

…

IPO SMSM

SM

Scrum TeamsIntegration

Development Teams

…

QPO SMSM

SM

Scrum TeamsCross-functional services

Development Teams

…

APO SM

GPO

GPOGPO

GPO GPO

Scrum Team Engineering

GPO IPOQPO

LPO

LPO

Neue innovative Projektfläche

Entscheider CTO+1

sind alle zwei Wochen auf der Projektfläche

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

5 Herausforderungen und Besonderheiten der agilen Entwicklung physischer Produkte


Potentially Shippable Product

Increments

Ergebnisse sind anfänglich nie funktionsfähige potenziell auslieferbaren Ergebnisse

Auch virtuelle Modelle, Simulationen oder Rapid Prototypes ermöglichen wertvolles Feedback und Richtungsentscheidungen

Matrixorganisation und Spezialisierung

Querschnittsbereiche sorgen für Standardisierung und Synergien. Experten können nicht zu 100% einzelnen Scrum Teams zugeordnet werden

Dann organisieren wir Querschnitts-bereiche mit Kanban und lassen sie produktorientierten Scrum Teams auch agil zuarbeiten

Interdisziplinarität Produktentwicklungsprojekte benötigen viel breiter Kompetenzen als Softwareentwicklungsprojekte

Wir integrieren auch Funktionen wie Einkauf, Fertigungsplanung, Kalkulation in die Scrum Teams

Große Projekte Komplexe physische Produkte können nicht von einem Scrum Team alleine entwickelt werden

Kein Problem! Dafür gibt es verschiedene Skalierungs-Frameworks wie SAFe, Scrum@Scale, LeSS oder Nexus

Product Backlog

Für den Produktionsstart eines physischen Produktes müssen mehr Ergebnisse vorliegen als nur ein funktionierendes Produkt

Der Product Backlog wird auch mit Ergebnisanforderungen aus dem Produktentstehungsprozess gefüllt

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Herausforderung 1: Interdisziplinarität - Development Teams mit breiter Kompetenz


Rollen

Product Owner

Scrum Master

Development Team

Entwicklung Einkauf

Fertigungsplanung Kalkulation

... Kundendienst

Kompetenzen

T-shaped People

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Herausforderung 2: Große Projekte - Einsatz von Skalierungs-Frameworks


Project Teams

Sprint 1 Sprint 2

Scrum Teams Backlog

Kanban Teams Backlog

Stakeholder Product Owner Development Team Scrum Master Systems Engineer

Chief Product Owner

Scrum Master

Systems Engineer

Team Level

Systems Level

Portfolio Level

Backlog

Sprin

t Rev

iew

R

evie

w

Rev

iew

Rev

iew

Sprin

t Pla

nnin

g P

lan

Pla

n P

lan

Sprin

t Pla

nnin

g P

lan

Pla

n P

lan

Sprin

t Rev

iew

R

evie

w

Rev

iew

Rev

iew

…

Sprin

t Ret

rosp

ectiv

e R

etro

R

etro

R

etro

Sprin

t Ret

rosp

ectiv

e R

etro

R

etro

R

etro

Sprin

t Pla

nnin

g P

lan

Pla

n P

lan

Getaktete Lieferung von Ergebnissen

Chief Chief Product Owner

Scrum Master

Systems Engineer Budget

Backlog

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Portfolio

Produkt …

Herausforderung 2: Große Projekte - Einsatz von Skalierungs-Frameworks


Product Owner Development Team Scrum Master System Engineering

Kom

mun

ikat

ion

und

Bes

eitig

ung

von

Hin

dern

isse

n

Verf

eine

rung

des

Pro

doct

Bac

klog

1. Skalierung der Rolle PO 2. Skalierung der Rolle SM 3. Einführen eines System Engineering

Interdisziplinär: Entwicklung, Fertigungsplanung, Einkauf, Kalkulation, …

Hauptbaugruppe …

Baugruppe

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Die Bandbreite agiler Skalierungs-Frameworks reicht von großen Projekten mit 70 Mitarbeitern (LeSS) bis zum Gesamtunternehmen mit allen Ebenen (SAFe oder Scrum@Scale)


Charakter des Frameworks präskriptiv deskriptiv

Gesamt- unternehmen

Projekt

Anwendungs-breite

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

SAFe ist das in der DACH-Region am meisten genutzte Skalierungs-Framework


50%

30%

20%

12% 8% 8%

0%

10%

20%

30%

40%

50%

60%

SAFe LeSS IndividuellesFramework

Sonstiges Scrum @ Scale Nexus

Welche Art von Scaling Frameworks sind in Ihrem Unternehmen im Einsatz?

Quelle: 3. Studie über Erfolg und Anwendungsformen von agilen Methoden , Hochschule Koblenz, Prof. Dr. Ayelt Komus, 131 Antworten http:/www.status-quo-agile.de

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Herausforderung 3: Product Backlog - Inputs aus zwei Quellen


Product Backlog

ProjektplanungKonzept

ProduktgestaltungSerieneinführung

Konzept-freigabe

Produkt-freigabeEntwicklungs-

freigabe

Projekt-genehmigungProjekt-

start

Projektmanagement

Design-to-Cost

Validierung

Anforderungsmanagement

Konstruktion

Musterbau

Qualitätsmanagement

Einkauf

Fertigungsplanung

Produktion

Serie

Lastenheft-freigabe

M2

Projekt-genehmigung

M3

Pflichtenheft-freigabe

M4

Konzept-freigabe

M5

Vorabserien-freigabe

M6

Pilotserien-freigabe

M8

Produkt-freigabe

M9

Projektab-schluss

M10

Entwicklung-freigabe

M7

Projekt-start

M1

Nicht-funktionale Ergebniserwartungen

Produktentstehungsprozess

Funktionale Ergebniserwartungen

Kunde / Stakeholder

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Produktteams / Baugruppenteams Business Owner

Herausforderung 4: Matrixorganisation und Spezialisierung Wir bilden eine agiles Matrix-Organisation


Fachbereich D

Fachbereich A

Fachbereich B

Fachbereich C

Fachbereich X

Kanban

…

Querschnittsabteilungen Expertenteams /

…

Scrum

Produkt 1

…

Produkt 2

…

Produkt 3

…

Produkt n

…

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Herausforderung 5: Potentially Shippable Increment liefern wir nicht zu jedem Sprint


Wir liefern etwas „Fertiges“ zu dem unsere Kunden und Stakeholder Feedback geben können.

Das dürfen auch virtuelle Modelle, Simulationen oder Rapid Prototypes sein.

Digital-Mock-up, virtuelle Entwicklungs-methoden, 3D-Druck und Augmented Reality helfen uns dabei, früher als bisher Produktinkremente demonstrieren zu können.

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Die agile Transformation muss von außen und von innen kommen und Strukturen und Regeln nachhaltig verändern

Agilität

Zeit

Pilotprojekt

Prozesse

Pra

ktik

en Fram

ework

Strukturen

Reg

eln

Metriken

Kultur Überzeugungen

Werte

Veränderung

In Anlehnung an Pete Behrens

Skalierung

Aufbau-organisation

HR-Management

Agiles Mindset

Agile Führung


Quelle: Pete Behrens, TrailRidge Consulting

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Ideal-Kriterien für die Auswahl eines SCRUM-Pilotprojektes


Freiwilligkeit des Teams

Mittlere bis hohe Projekt-komplexität

Frühe Projekt-phase

Hat einen entscheidungs-

befugten Product Owner

Team erzeugt das Ergebnis

alleine

Scrum-Team-Größe 5-11

Stabiles Projektteam

Vollzeitmitarbeit

Team arbeitet räumlich

zusammen

Starke Stakeholder-

Unterstützung

SCRUM Pilot

6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

9 Tipps für die agile Transformation

1. Führen Sie die agile Transformation auch agil durch.

2. Implementieren Sie ein cross-funktionales agiles Transformationsteam.

3. Agile Arbeitsweisen müssen erlebt werden, beginnen Sie mit einem Pilot-Bereich oder Pilot-Projekt und generieren Sie schnell sichtbare Erfolge.

4. Arbeiten Sie parallel zu der Implementierung des Frameworks von Anfang an auch an einer Veränderung des Mindset.

5. Beginnen Sie die Mindset-Veränderung top down.

6. Setzen Sie Scrum und Scaled Scrum nur für komplexe Geschäftsbereiche oder Projekte ein, verwenden Sie für einfachere Themen und in Querschnittsbereichen Kanban.

7. Starten Sie mit einer Implementierung der Frameworks „by the book“, adaptieren Sie mit den Retrospektiven.

8. Besetzen Sie neue Rollen nur nach Kompetenz, schaffen Sie alte Rollen konsequent ab.

9. Beginnen Sie mit physischen Scrum-Boards und stellen Sie erst später auf digitale Tools um.


6,6

7,0

9,0

12,8 8 13,3

-7,8

-0,8

12,8 13,3

6,2

Seite

-8,2

Ihr Ansprechpartner

22.10.2018 Unternehmenspräsentation 26

CO-Improve GmbH & Co. KG Düsseldorfer Straße 13 D-65760 Eschborn Fon: +49 (0) 6196 96754 – 0 Fax: +49 (0) 6196 96754 – 11 Mail: [email protected] Web: www.co-improve.com

Dirk Meißner, Geschäftsführender Gesellschafter

mailto:[email protected]



http://www.co-improve.com/



Documents

Agile Entwicklung physischer Produkte · Reduzierung von Risiken im Projekt Optimierung der Qualität ... Anwendung 22.10.2018 10 Agile Entwicklung physischer Produkte ... Rollen