Agilität im starren Umfeld

2.928 Aufrufe

Veröffentlicht am

Kürzere Entwicklungszeiten, höhere Kundenzufriedenheit, mehr Transparenz sind nur einige Ziele, die agile Entwicklungsmethoden versprechen. Scrum, Kanban, XP & Co. werden erfolgreich verbreitet eingesetzt. Aber starre Rahmenbedingungen wie sie häufig im Embedded-Umfeld auftreten, wie z.B. Hardware-Entwicklung mit langen Entwicklungszeiten, Auflagen von Regulierungsbehörden wie der FDA in der Medizintechnik oder hoher Dokumentationszwang sind schnell K.o.-Argumente gegen die Einführung agiler Methoden. Scheinbar sind sie nur für gewöhnliche Softwareprojekte geeignet. Ich zeige Ihnen, dass Agilität und starre Rahmenbedingungen kein Widerspruch sind und kläre Missverständnisse auf.

Biographie Tim Weilkiens
Als Geschäftsführer der oose Innovative Informatik GmbH schaffe ich unseren Mitarbeitern Raum, Ihre innovativen Ideen umzusetzen. Ich entleere meinen Kopf, indem ich mein Wissen in Büchern, Artikeln und Vorträgen festhalte. Das schafft mir Freiraum, mich mit neuen Ideen und Konzepten auseinanderzusetzen. Best Practices manifestiere ich in Standards bei der OMG, wo ich aktiv z.B. die SysML, die UML oder die Zertifizierungsprogramme OCEB und OCSMP mitgestalte. Privat motivieren mich 42,195 km, Ziele zu erreichen.

Veröffentlicht in: Business, Technologie
  • Als Erste(r) kommentieren

Agilität im starren Umfeld

  1. 1. © by oose GmbH Agilität im starren Umfeld „ Hart, aber agil“ Open Change, Stuttgart 13. Juli 2011 Tim Weilkiens Geschäftsführer [email_address]
  2. 2. oose Innovative Informatik GmbH – Erfahrung nutzen. Ziele erreichen. Gründung: 1998 durch Bernd Oestereich 35 Mitarbeiter International anerkannte Experten und Buchautoren kundenspezifisch Firmensitz: Hamburg Beratung, Coaching, Workshops, Training Maßgeblich an der Entwicklung führender Standards beteiligt Erfahrung nutzen. Ziele erreichen.
  3. 3. „ Hart und starr“ © by oose GmbH „ Hart“ = Nicht nur Software „ Starr“ = Viele Regulatorien
  4. 4. Hart und starr... <ul><li>...und agil? </li></ul>© by oose GmbH
  5. 5. © by oose GmbH
  6. 6. © by oose GmbH
  7. 7. © by oose GmbH
  8. 8. Widerspruch? Engel? Teufel? © by oose GmbH
  9. 9. Entwicklungstechniken müssen der Komplexitätssteigerung folgen © by oose GmbH Zeit Komplexität, Time-to-Market, Qualität, Kostenreduktion Systeme Markt Agilität Modellierung Hebel: Innovation der Entwicklungstechniken Entwicklungstechniken
  10. 10. © by oose GmbH Quelle: agilemanifesto.org !
  11. 11. Scrum – ein agiles Vorgehen im Überblick © by oose GmbH Sprint (timeboxed) Daily-Scrum Review Retrospektive Sprint-Planung
  12. 12. Agile Techniken im 4-Schichtenmodell © by oose GmbH
  13. 13. Antipattern: 4-Iterationen-Modell © by oose GmbH Analyse Design Implementierung Test
  14. 14. Phasen iterativer Entwicklung © by oose GmbH Architektur Durchstich Architektur-rahmen Teamausbau, Realisierungs-rahmen klar Realisierung Maximaler Nutzen hergestellt Nutzen-bewertung Iterative Realisierung von Features Realisierungs-optionen erarbeiten Bewältigung von Risiken Teststrategie Vorbereitung Entwicklung Produktvision / Big Picture Stakeholder Risiken Makro-schätzung / Wirtschaft-lichkeit Release-planung Entscheidung über Projekt-durchführung Abschluss Lernende Organisation Formaler Abschluß Schlußpunkt im Teamprozess Projekt abgeschlossen
  15. 15. Iterative Systementwicklung – Beispiel Zeitstrahl © by oose GmbH Die Iterationen müssen nicht gleich lang sein und können auch innerhalt einer Disziplin zeitlich variieren.
  16. 16. Problem: Das Iterationsergebnis <ul><li>Am Ende eines Sprints steht immer eine lauffähige, getestete, inkrementell verbesserte Software (Quelle: Wikipedia). </li></ul>© by oose GmbH Am Ende eines Sprints steht immer ein lauffähiges, getestetes, inkrementell verbessertes System. ? Zweck: Feedbackfähigkeit (nicht Lauffähigkeit) Am Ende einer Iteration steht immer ein getestetes, inkrementell verbessertes System, das dem Kunden ermöglicht, Feedback zu geben.
  17. 17. Urspr ünge von Scrum und Kanban liegen außerhalb der Softwaredisziplin <ul><li>Scrum (1986): Methode zur Produkt-Entwicklung </li></ul><ul><li>Kanban (1947): Methode zur Produktionsablaufsteuerung (Serienproduktion) </li></ul><ul><li>Scrum in der IT: </li></ul><ul><ul><li>Peter DeGrace, Leslie Hulet Stahl (1990) </li></ul></ul><ul><ul><li>Ken Schwaber, Mike Beedle, Jeff Sutherland </li></ul></ul><ul><li>Kanban in der IT: David Anderson 2007 </li></ul>© by oose GmbH Rückweg der agilen Vorgehen in die Systementwicklung ist schwierig.
  18. 18. „ Agile Projekte dokumentieren nicht“ © by oose GmbH Dokumentation in agilen Projekten ist kein Widerspruch!
  19. 19. Das Produkt © by oose GmbH Die Dokumentation ist Teil des Produkts und wird ebenso entwickelt wie die Software und Hardware. Produkt
  20. 20. Agilität und Projekterfolg hängen stark zusammen! © by oose GmbH Agile Projekte Klassische Projekte Erfolgreich Nicht erfolgreich Erfolgreich Nicht erfolgreich Quelle: oose-Projektmanagementstudie, http://www.oose.de/pm-studie, 2009
  21. 21. Stärkster Einfluss auf Projekterfolg: Direkter Kundenkontakt © by oose GmbH mehrmals wöchentlich oder kontinuierlich wöchentlich monatlich bei Lieferungen/Planungsaktualisierungen bei Lieferungen zu Projektbeginn/-ende oder seltener
  22. 22. Woher kommt der Widerstand? © by oose GmbH Skeptiker (ca. 40%) Gegner (ca. 15%) Bremser (ca. 40%) Befürworter (ca. 5%) <ul><li>Befürworter ins Boot holen </li></ul><ul><li>Skeptiker/Bremser überzeugen </li></ul><ul><li>Gegner ignorieren </li></ul>Akzeptanzmatrix (nach Mohr, Woehe, Diebold, 1998) Einschätzung persönlicher Risiken hoch niedrig Einschätzung sachlicher Risiken niedrig
  23. 23. Veränderung bewegt © by oose GmbH Schock Eigene Erwartungen scheinen nicht erfüllbar Verneinung Selbstschutz durch Verleugnung und/oder Selbstüberschätzung Einsicht Veränderung betrifft mich, Unsicherheit Akzeptanz Veränderung ist da, alte Muster aufgeben „ Tal der Tränen“ Ausprobieren Neue Muster bringen Erfolg und Misserfolg Bewusstsein Ursache-Wirkung von Mustern und Erfolgen Integration Erfolgsmuster werden unbewusst ausgeführt Wahrgenommene Kompetenz Zeit
  24. 24. Agiles Projektmanagement für Systeme im reguliertem Umfeld (APS) <ul><li>Ziel der Arbeitsgruppe APS ist es sich über Erfahrungen aus der Praxis zum agilen Projektmanagement für Systeme im regulierten Umfeld auszutauschen. </li></ul><ul><li>Geplante Ergebnisse sind Best-Practices , um Hindernisse zu beseitigen und agile Techniken erfolgreich im reguliertem Systementwicklungsumfeld einzusetzen. </li></ul>© by oose GmbH Webseite: http://www.gfse.de | Arbeitsgruppen | APS
  25. 25. (Be-)Merkenswertes <ul><li>Gängige agile Vorgehen haben ihren Ursprung außerhalb der Software-Welt. </li></ul><ul><li>Agilität und „harte und starre Projekte“ sind kein Widerspruch. </li></ul><ul><li>Einzelne agile Techniken machen Projekte erfolgreicher. </li></ul><ul><li>Agilität erfüllt keinen Selbstzweck. </li></ul><ul><li>Agilität wird die Projektmanagementlandschaft nachhaltig verändern. </li></ul><ul><li>Widerstände verstehen und aushalten (Veränderungskurve, Akzeptanzmatrix) </li></ul>© by oose GmbH
  26. 26. © by oose GmbH www.oose.de – Vom Wissen zum Können Beratung und Training Kontakt: Tim.Weilkiens@oose.de

×