Agile Entwicklung physischer Produkte

Transkript

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

2 Agile Konzepte entstanden in den 80er Jahren in physischen Produktentwicklungsprojekten 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 Seite 2 Agile Entwicklung physischer Produkte

3 Die Erfolgsfaktoren der untersuchten Entwicklungsprojekte physischer Produkte wurden als der Rugby Approach oder Moving the SCRUM Downfield bekannt Flexible Anforderungen Organisationales Lernen Vertrauen und Fehlerkultur Erfolgsfaktoren Im Prozess und voneinander lernen Selbst- Organisierende interdisziplinäre Teams Überlappung von Phasen Quelle: The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, Januar-Februar Seite 3 Agile Entwicklung physischer Produkte

4 Anfang der 2000er Jahre wurden diese agilen Konzepte zum Scrum Guide weiterentwickelt 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 Seite 4 Dirk Meißner Konferenz Agile@Hardware Frankfurt Klassikstadt

5 Scrum ist heute die bedeutendste agile Methode auch im non-it Bereich Welche Bedeutung haben die jeweiligen Methoden für Ihren Bereich? Scrum Kanban Lean Design Thinking Lean Startup 0% 20% 40% 60% 80% 100% zentrale Bedeutung für meinen Tätigkeitsbereich wird für meinen Tätigkeitsbereich neben anderen Methoden genutzt geringe Beduetung in meinem Tätigkeitsbereich keine Bedeutung in meinem Tä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 Seite 5 Agile Produktentwicklung

6 Geänderte Rahmenbedingungen erfordern neue Führungsstile und Arbeitsmethoden Stable Das Umfeld verändert sich nur langsam Volatile Die Veränderungsgeschwindigkeit nimmt kontinuierlich zu Secure Die Vorhersehbarkeit ist gegeben Uncertain Die Vorhersehbarkeit nimmt ab Easy Probleme sind relativ einfach und Lösungen bekannt Complex Probleme sind nicht mehr linear bei mehrfach verbundenen Variablen Explicit Die Realität ist eindeutig Ambiguous Die Realität ist unscharf Seite 6 Agile Entwicklung physischer Produkte

7 Beweggründe für die Nutzung agiler Methoden Warum hat sich Ihr Unternehmen dazu entschlossen mit agilen Methoden zu arbeiten? Optimierung der Produkteinführungszeit 61% Optimierung der Qualität 47% Reduzierung von Risiken im Projekt 42% Optimierung des Produktwertes 35% Optimierung der Planbarkeit 31% 0% 10% 20% 30% 40% 50% 60% 70% Quelle: 3. Studie über Erfolg und Anwendungsformen von agilen Methoden, Hochschule Koblenz, Prof. Dr. Ayelt Komus, 784 Antworten Seite 7 Agile Entwicklung physischer Produkte

8 klar bekannt Was? (Anforderungen) unklar unbekannt Agile Methoden reagieren auf die gestiegene Veränderungsgeschwindigkeit und Unsicherheit in komplexen Bereichen mit adaptiver Planung und empirischer Prozesskontrolle Stacey-Matrix Empirische Prozesskontrolle chaotisch komplex Transparenz kompliziert Agiles Projekt Reduktion von Unsicherheit durch empirische Prozesskontrolle Anpassung Überprüfung einfach etabliert Wie? (Technologie) neu Original: Strategic management and organisational dynamics, the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002Ralph D. Stacey, Adaptiert: Dirk Meißner Seite 8 Agile Entwicklung physischer Produkte

9 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 Hohe Effektivität und Wertsteigerung durch konsequente Priorisierung Kürzere Time-to-Market und Terminverlässlichkeit durch fokussiertes Arbeiten, Team-Commitment und schnelle Entscheidungen Hohe Transparenz durch festgelegte Ereignisse und offene Informationen Gesteigerte Effizienz durch das Entfernen von Hindernissen und kontinuierliche Verbesserung Seite 9 Agile Entwicklung physischer Produkte

10 Das Scrum-Framework kommt bei der Entwicklung physischer Produkte ohne Anpassungen zur Anwendung Product Increment Sprint Review 15 min Daily Scrum Sprint Retrospective Sprint 1-4 weeks Product Backlog Refinement Product Vision Product Backlog Product Sprint Backlog Sprint Planning 1 Sprint Planning 2 Stakeholder Product Owner Development Team Scrum Master Event Artefact Seite 10 Agile Entwicklung physischer Produkte

11 Projektmanagement Anforderungsmanagement Konstruktion Musterbau Validierung Design-to-Cost Einkauf Qualitätsmanagement Fertigungsplanung Produktion M1 Entwicklungfreigabe Projektstart M2 M3 M4 M5 M6 M7 Projektabschluss M8 M9 M10 Konzeptfreigabe Produktfreigabe Entwicklungsfreigabe Projektgenehmigung Projektstart Lastenheftfreigabe Projektgenehmigung Pflichtenheftfreigabe Konzeptfreigabe Vorabserienfreigabe Pilotserienfreigabe Produktfreigabe Case Study 1: Gesamtfahrzeugentwicklung e-lkw Unmöglicher Vorstandsauftrag Falls wir es schaffen, dann nur als Scrum Pilot 1 PO, 1 SM 10 Entwickler aus unterschiedlichen Hierachieebenen Sprint-Länge 4 Wochen Agile Zusammenarbeit mit Entwicklungsdienstleister Produktgestaltung Konzept Projektplanung Serie Serieneinführung Erlaubnis zur Verschlankung des PEP Entscheider sind wöchentlich auf der Projektfläche Minimal Reportingeffort Realisierung in 24 statt 60 Monaten Seite 11 Webinar - Agile Development of Physical Products

12 Case Study 2: Agile Transformation der gesamten Entwicklung Agile Awareness im Vorstand Januar 2016 Schritt 1 Produktfamilie als Scrum Pilot April PO, 1 SM Hydraulik, Mechanik, Firmware, Elektronik Sprint-Länge 4 Wochen Begleitendes Team- und Einzelcoaching Schritt 2 Umstellung des gesamten Bereichs Pumpensysteme und Antriebe bis September Scrum Teams, 3 Kanban Teams an einem Standort Agile Coach Scrum Master Master Sync Team Kanban Team Plattform und Technologie Kanban Team Hardware Scrum Team Kompaktpumpen Scrum Team Antriebe Scrum Team Systeme Kanban Team Prüffeld Schritt 3 Rollout auf alle Standorte bis März 2018 Advantages Kürzere Entwicklungszeiten Besseres Erfüllen marktseitiger Anforderungen durch Hohe Transparenz Offener Umgang mit Problemen Verringerung der technischen Schuld Schritt 4 Rollout außerhalb der Entwicklung ab Juli Seite 12 Webinar - Agile Development of Physical Products

13 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 Ein cross-funktionale Team entwickelte einen zielführenden skalierten Ansatz Nov 16 Jan 17 Scrum Team Vehicle Stakeholder PO SM APO APO APO APO APO APO APO APO APO APO Scrum Team Engineering Scrum PLPF Team PLPP PLM Scrum PLC Production PLD Scrum PLED Team Scrum PLQ Team PLAS Scrum Team Team Scrum Team Team APO SM APOPOPOPOPOPOPOPOPO SM SM SM SM SM SM SM SM SM Neue innovative Projektfläche Sprint-Länge 2 Wochen GPO LPO GPO GPO GPO GPO GPO IPO QPO LPO LPOPOPOPOPOPOPOPOPO LPOPOPOPOPOPOPOPOPO LPOPOPO LPO PO PO PO LPO PO PO PO PO LPO PO PO PO PO PO PO PO PO PO PO PO PO PO PO Scrum Teams Rohbau Structure Scrum Rohbau Teams Scrum Rohbau Teams Scrum Rohbau Teams Scrum Rohbau Teams Scrum Teams Scrum Teams Integration Scrum Teams Cross-functional services Line Organization GPO PO PO PO SM PO SM PO SM SM SM SM SM SM SM SM SM SM IPO SM SM QPO SM SM SM SM SM SM SM SM SM SM Development Modulgruppen Modulgruppen Teams Development Modulgruppen Development Modulgruppen Teams Development Modulgruppen Teams Development Teams Development Teams Teams Development Teams Development Teams Scrum Teams wurden in Wellen implementiert 4 50 seit Jan 17 Entscheider CTO+1 sind alle zwei Wochen auf der Projektfläche Vorteile Kürzere Reaktionszeiten Bessere Erfüllung der Kundenanforderungen by Hohe Transparenz Interdisziplinäre Zusammenarbeit Schneller Entwcheidungen Seite 13 Webinar - Agile Development of Physical Products

14 5 Herausforderungen und Besonderheiten der agilen Entwicklung physischer Produkte 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, LeSS oder Nexus Product Backlog Matrixorganisation und Spezialisierung Potentially Shippable Product Increments Für den Produktionsstart eines physischen Produktes müssen mehr Ergebnisse vorliegen als nur ein funktionierendes Produkt Querschnittsbereiche sorgen für Standardisierung und Synergien. Experten können nicht zu 100% einzelnen Scrum Teams zugeordnet werden Ergebnisse sind anfänglich nie funktionsfähige potenziell auslieferbaren Ergebnisse Der Product Backlog wird auch mit Ergebnisanforderungen aus dem Produktentstehungsprozess gefüllt Dann organisieren wir Querschnittsbereiche mit Kanban und lassen sie produktorientierten Scrum Teams auch agil zuarbeiten Auch virtuelle Modelle, Simulationen oder Rapid Prototypes ermöglichen wertvolles Feedback und Richtungsentscheidungen Seite 14 Agile Produktentwicklung

15 Herausforderung 1: Interdisziplinarität - Development Teams mit breiter Kompetenz Rollen Product Owner Development Team Scrum Master Kompetenzen Entwicklung Einkauf Fertigungsplanung Kalkulation... Kundendienst T-shaped People Seite 15 Agile Produktentwicklung

16 Plan Plan Sprint Planning Plan Sprint Review Review Review Review Retro Retro Retro Sprint Retrospective Plan Plan Sprint Planning Plan Sprint Review Review Review Review Retro Retro Retro Sprint Retrospective Sprint Planning Plan Plan Plan Herausforderung 2: Große Projekte - Einsatz von Skalierungs-Frameworks Portfolio Level Chief Chief Product Owner Scrum Master Systems Level Systems Engineer Budget Backlog Sprint 1 Sprint 2 Chief Product Owner Scrum Master Getaktete Lieferung von Ergebnissen Backlog Team Level Scrum Teams Backlog Systems Engineer Kanban Teams Backlog Project Teams Stakeholder Product Owner Development Team Scrum Master Systems Engineer Seite 16 Agile Produktentwicklung

17 Verfeinerung des Prodoct Backlog Kommunikation und Beseitigung von Hindernissen Herausforderung 2: Große Projekte - Einsatz von Skalierungs-Frameworks Portfolio 1. Skalierung der Rolle PO 2. Skalierung der Rolle SM 3. Einführen eines System Engineering Produkt Hauptbaugruppe Baugruppe Interdisziplinär: Entwicklung, Fertigungsplanung, Einkauf, Kalkulation, Product Owner Development Team Scrum Master System Engineering Seite 17 Agile Produktentwicklung

18 Die Bandbreite agiler Skalierungs-Frameworks reicht von großen Projekten mit 70 Mitarbeitern (LeSS) bis zum Gesamtunternehmen mit allen Ebenen (SAFe oder Gesamtunternehmen Anwendungsbreite Projekt präskriptiv Charakter des Frameworks deskriptiv Seite 18 Agile Produktentwicklung

19 SAFe ist das in der DACH-Region am meisten genutzte Skalierungs-Framework 60% 50% Welche Art von Scaling Frameworks sind in Ihrem Unternehmen im Einsatz? 50% 40% 30% 30% 20% 10% 20% 12% 8% 8% 0% SAFe LeSS Individuelles Framework Sonstiges Scale Nexus Quelle: 3. Studie über Erfolg und Anwendungsformen von agilen Methoden, Hochschule Koblenz, Prof. Dr. Ayelt Komus, 131 Antworten Seite 19 Agile Produktentwicklung

20 Herausforderung 3: Product Backlog - Inputs aus zwei Quellen Kunde / Stakeholder Product Backlog Produktentstehungsprozess Produktfreigabe Entwicklungsfreigabe Konzeptfreigabe Projektgenehmigung Serieneinführung Projektstart Serie Produktgestaltung Konzept Projektplanung M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 Entwicklungfreigabe Projektstart Projektabschluss Lastenheftfreigabe Projektgenehmigung Pflichtenheftfreigabe Konzeptfreigabe Vorabserienfreigabe Pilotserienfreigabe Produktfreigabe Projektmanagement Anforderungsmanagement Konstruktion Musterbau Validierung Design-to-Cost Einkauf Qualitätsmanagement Fertigungsplanung Produktion Funktionale Ergebniserwartungen Nicht-funktionale Ergebniserwartungen Seite 20 Agile Produktentwicklung

21 Herausforderung 4: Matrixorganisation und Spezialisierung Wir bilden eine agiles Matrix-Organisation Business Owner Produktteams / Baugruppenteams Produkt 1 Produkt 2 Produkt 3 Produkt n Querschnittsabteilungen Expertenteams / Fachbereich A Fachbereich B Fachbereich C Fachbereich D Fachbereich X Kanban Scrum Seite 21 Agile Produktentwicklung

22 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 Seite 22 Agile Produktentwicklung

23 Praktiken Regeln Die agile Transformation muss von außen und von innen kommen und Strukturen und Regeln nachhaltig verändern Agilität Aufbauorganisation Veränderung Prozesse Strukturen HR- Management Agile Führung Kultur Überzeugungen Werte Metriken Framework Agiles Mindset Skalierung Pilotprojekt Quelle: Pete Behrens, TrailRidge Consulting Zeit In Anlehnung an Seite Pete Behrens 23 Agile Entwicklung physischer Produkte

24 Ideal-Kriterien für die Auswahl eines SCRUM-Pilotprojektes Freiwilligkeit des Teams Starke Stakeholder- Unterstützung Mittlere bis hohe Projektkomplexität Team arbeitet räumlich zusammen Vollzeitmitarbeit Stabiles Projektteam SCRUM Pilot Scrum-Team- Größe 5-11 Team erzeugt das Ergebnis alleine Frühe Projektphase Hat einen entscheidungsbefugten Product Owner Seite 24 Agile Entwicklung physischer Produkte

25 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 Seite 25 Agile Entwicklung physischer Produkte

26 Ihr Ansprechpartner Dirk Meißner, Geschäftsführender Gesellschafter CO-Improve GmbH & Co. KG Düsseldorfer Straße 13 D Eschborn Fon: +49 (0) Fax: +49 (0) Mail: office@co-improve.com Web: Seite 26 Unternehmenspräsentation