Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn
•
2 gefällt mir•465 views
Vortrag auf dem 7. Wiener PM Symposium (bfi Wien)
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn
Ähnlich wie Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn (20)
Mehr von Christoph Schmiedinger
Mehr von Christoph Schmiedinger (20)
Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn
- 1. Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn Christoph Schmiedinger boris gloger Consulting Wien, 08.06.2016
- 2. Christoph Schmiedinger Agile Consultant Product Owner Projektmanagement Agile Transitionen Sicherheitskritische Entwicklung
- 3. Agile = Anarchie ? Problematik: Schlechte Implementierungen
- 6. Scope Time Budget Scope TimeBudget Fixiert Variabel Quality Quality Das „Projektmanagement“-Dreieck
- 7. Agieren Sie als Venture Capitalist! Ideen- bewertung Phase 0 Phase 1 Budget- Freigabe Budget- Freigabe
- 8. Das „Richtige“ messen! 100% der angeforderten Features in < 100% der Kosten/Zeit geliefert = erfolgreiches Projekt ? The Standish Group: “We have seen many projectsthat meetthe tripleconstraints of OnTime, OnBudget, and OnTarget, but the customer was not satisfied with the outcome.” Quelle: CHAOS Report 2015, The Standish Group
- 9. Messen Sie den Business Value oder Kundennutzen! Quelle: Agile Product Ownership in a Nutshell, HendrikKniberg
- 10. Agile Releaseplanung 1.0 Planung: 200 Story Points Best Case: 8 Sprints Worst Case: 14 Sprints Max. Budget: 14 Sprint x Kosten/Sprint Product Backlog Σ 200 Story Points 200 SP
- 11. Agile Releaseplanung 3.0 Ideen Product Backlog Max. 50 Items Delivery Entry Date DeliveryDate Planung: Ø Lead Time/Item Kosten: Kosten/Woche Ø Items/Woche Nein!
- 12. Risk-Management
- 13. Inhärente Verankerung Delivery alle 1-2 Wochen De facto Ausschluss eines katastrophalen Fehlschlags Starke Verminderung des Risikos der Nichterreichung des Kundenzufriedenheit
- 14. Reduzierung technisches Risiko Kurze Timebox Quellen: scanrail,carmenmsaa / 123RF LizenzfreieBilder Prototyping Proof of Concepts
- 15. Transparentes Risikomanagement Impediment Backlog Priorität Öffentlich! Hindernisse des Scrum Teams
- 16. Eine Metrik für Fortschrittskontrolle Traditionell Agile Sicherstellung durch Definition of Done (DoD)
- 17. Claim-Management
- 18. Agile Manifesto Individuals and interactionsover processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over followinga plan
- 19. Notwendige „Claims“ Kunde muss sich aktiv im Prozess einbringen! Feedback, Priorisierung Kunde muss Verantwortung übernehmen! Priorisierung, getroffene Entscheidungen
- 20. Neue Dimension der Zusammenarbeit Paradigmenwechsel Kunden zentralerBestandteil des Entwicklungsprozesses Entwicklung direkt “am Endanwender“ Kein Bedarf mehr an Anforderungslisten
- 22. Anarchie Kontroll- wahn Agile Agile jenseits von Anarchie und Kontrollwahn
- 23. Selbst sicher zum Erfolg.
Hinweis der Redaktion
- Herzlich willkommen zu meinem Vortrag, den ich sehr gerne an das Thema des diesjährigen Symposiums anlehnen möchte. Ich möchte heute über erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn sprechen, das heißt, Ihnen heute mit ein paar Inputs zeigen, warum ich denke, dass agile Methoden, wenn sie richtig angewandt werden, ein gutes Mittelmaß zwischen Anarchie und Kontrollwahn abgeben.
- Mein Name ist Christoph Schmiedinger und vielleicht ein paar einleitende Worte zu mir. Ich bin als agiler Coach und Berater in der DACH-Region unterwegs und bin bereits vor meiner Beratungstätigkeit bei der Frequentis hier in Wien mit agilen Methoden in Berührung gekommen. Wir sind damals vom klassischen Projektmanagement umgestiegen und haben im Selbstversuch agile Methoden eingeführt. Das hat soweit auch so gut funktioniert, dass auch heute noch diese Teams damit arbeiten. Meine Rollen waren damals im klassischen der Entwicklungsprojektleiter und später dann der Product Owner. In meiner aktuellen Beratungstätigkeit. Arbeit ich viel in agilen Transitionen, also Veränderungsprozessen, in denen komplette Organisationen agiler werden wollen. Aus meiner Frequentis-Zeit habe ich auch heute noch ein Herz für sicherheitskritische und safety-relevante Entwicklungen.
- Zu Beginn möchte ich folgendes Statement beleuchten! Warum wird Agilität so oft mit Anarchie oder Chaos verbunden? Ich denke, dass es in erster Linie an schlechten Implementierungen in Organisationen liegt. In meiner Beratungstätigkeit habe ich eine Vielzahl von agilen Teams begleiten dürfen und gerade in den Erstkontakten wird mir immer wieder vor Augen geführt, wie viele der Prinzipien und Regeln in diesen Teams gar nicht betrachtet werden. Man gibt sich schnell mit Kompromissen zufrieden und hat einfach nicht die Disziplin, die es braucht, wirklich Agilität zu leben.
- Doch was bedeutet das jetzt für agile Methoden und agile Teams, wenn wir wieder an das Thema des Symposiums denken. Gibt es so etwas wie Projektcontrolling, Risikomanagement und Claimmanagement in agilen Projekten oder gibt es hier tatsächlich nur Fragezeichen? Das möchte ich heute in meinem Vortrag gerne auflösen, indem ich ein Thema nach dem anderen in den nächsten 20-25 Minuten beleuchten möchte.
- Starten wir mit dem Projektcontrolling...
- Jeder von uns kennt das “klassische“ Projektmanagement-Dreieck bestehend aus Scope, Time und Budget. Zusätzlich wird Qualität gerne in die Mitte des Dreiecks gestellt, um zu verdeutlichen, dass die Qualität des Projekts die Summe der Balance der drei Ecken darstellt. Wie auch immer, die Definitionen sind hier nicht alle gleich. Was ich Ihnen zeigen möchte ist, dass dieses Dreieck im agilen Kontext quasi auf den Kopf gestellt wird. Statt wie im klassischen Projektmanagement am Anfang des Projektes alle Ecke zu definieren und dann im Zuge des Verlaufs so zu steuern, dass dies auch in etwa erreicht wird, wird im agilen Kontext das Budget und die Time fixiert. Basierend auf diesen fixen Constraints wird das gesamte Projekt nur über den variablen Scope gesteuert. Innerhalb des Rahmens von Budget und Zeit soll so das bestmögliche Ergebnis gemeinsam mit dem Kunden und Endanwendern erarbeitet werden. Das geschieht durch die kurzen Iterationen, in denen das Ergebnis alle 1-2 Wochen betrachtet werden kann und durch Feedback (Scope) gesteuert wird. Wenn der Budget- und Zeitrahmen einigermaßen realistisch geschätzt wurde, wird so das beste erzielbare Ergebnis entwickelt werden. Beispiel: Messen Roll-out System.
- Jetzt werden Sie mich sicher fragen: Ist das nicht total risikobehaftet, einfach am Anfang eines Projektes eine Summe X freizugeben, ohne genau zu wissen, wo wir hinwollen? Ich gebe Ihnen Recht, daher gebe ich Ihnen den Tipp, als Management oder Product Owner wie ein Venture Capitalist zu agieren. Lassen Sie Ihre Mitarbeiter um Ideen pitchen und finanzieren Sie diese in einer ersten Runde. Das Team rund um die Idee kann so innerhalb weniger Iterationen ein erstes Produkt bauen, welches dann Feedback erhält und wir uns die Frage stellen können, ob ein weiteres Investment in dieses Projekt Sinn machen. Das Ganze funktioniert ähnlich einem Stage-Gate-Prozess, indem schrittweise mehr Kapital freigegeben wird oder das Vorhaben auch durchaus „gekillt“ werden kann -> nach dem Motto: “Fail fast“. In der freien Marktwirtschaft funktioniert das Funding von Innovationen und anderen risikobehafteten Vorhaben genauso! Wenige Idee werden es bis auf den Markt schaffen, aber diese werden derart großartig sein, dass sie die vielen Lernerfahrungen und somit auch Fehlschläge locker refinanzieren können. Ganz nebenbei erhöht sich auch noch der Buy-In Ihrer Mitarbeiter, wenn Sie an Ihren eigenen Ideen mit voller Leidenschaft arbeiten können.
- Wichtig ist auch, das Richtig zu messen! Kommen wir zurück auf das Dreieck. Die Qualität im Inneren des Dreiecks wird in manchen Quellen auch als Kundenzufriedenheit oder als Erfolg ersetzt. Die Standish Group, welche jährlich den CHAOS Report erstellt, und durch diese Recherchen bereits zigtausende Projekte über die letzten Jahrzehnte analysiert haben, das sehr viele Projekte trotz Einhaltung aller Ecken des Dreiecks den Kunden nicht zufrieden machen. Daher wird in agilen Projekten über den Scope gesteuert, um das wahre Ziel, einen zufriedenen Kunden oder einen Kunden, der möglichst viel bezahlt, zu erreichen.
- Die Idee ist, die agilen Features so zu priorisieren, dass die, die den höchsten Nutzen erzielen, als erstes implementiert werden. Wenn Sie sich die Grafik ansehen, in der der aggregierte Kundennutzen der Zeit eines Projektes gegenüber gestellt wird, ist in der ersten Phase ein „Anlaufen“ des Projektes zu sehen. Das Team spielt sich erst ein, technische Grundfundamente werden etabliert und Basisfunktionalität wird eingebaut. In der zweiten Phase werden dann die “wichtigen“ Features aus Kundensicht implementiert, sodass der Nutzen möglichst schnell ansteigt. Irgendwann muss man sich die Frage stellen, ob die nächste 2-3 Features, die ich in der nächsten Iteration schaffe würde, auch tatsächlich das Geld wert sind, was mein Team kostet. Nüchtern festgestellt kommt man an den Punkt, wo es sich nicht mehr lohnt, zusätzliche Add-ons einzubauen und man das Projekt beenden sollte, um sich dem nächst wichtigeren zu widmen.
- Der klassische Ansatz der agilen Releaseplanung arbeitet mit dem Verhältnis der Product Backlog Größe, also der Summe aller zu implementierenden User Stories oder Story Points, zur Geschwindigkeit des Entwicklungsteams. Diese Geschwindigkeit kann in einem solchen Diagramm auch noch mit einem Worst- und Best-Case Szenario ergänzt werden. Wird dann die Product Backlog Größe per Gerade in das Diagramm übertragen, erhält man eine Schätzung, in welchem Sprint die Lieferung in etwa zu erwarten sei. Durch das ungefähre Wissen der Kosten eines Sprints (ein Team sollte ja möglichst konstant bleiben) kann das max. Budget ebenfalls abgeschätzt werden. All diese Informationen helfen dem Product Owner eine rechtzeitige Einschätzung über die Zielerreichung zu treffen.
- Eine “neuere“ Variante der agilen Releaseplanung ist die Besinnung auf die Lead Time eines einzelnen Features, also wie lange ein Feature von der Nennung durch den Stakeholder oder Ideengeber bis zur tatsächlichen Lieferung am operativen Set-up benötigt. Diese Fokussierung kommt stark aus dem Lean Management, in dem der Fokus ein möglichst hoher Durchsatz bei geringstmöglicher Lead Time ist. Diese Lead-Time lässt sich auch sehr gut in der Kommunikation mit dem Kunden nutzen, da dieser so eine Vorstellung bekommt, wann er ungefähr mit dem Feature rechnen kann. Aber der Reihe nach. Für die Funktionalität eines solches Modells dürfen nur bestimmte Idee in das Produkt Backlog aufgenommen werden. Hier empfiehlt sich ein möglichst kleines Backlog, da größere Backlogs eine größere Streuung der Lead Time mit sich ziehen, welche nicht gewünscht wird. Wir empfehlen hier max. 50 Items, idealerweise sogar um die 30 Items oder weniger. Sobald eine Anforderung durch den Product Owner gegenüber dem Kunden versprochen wird, landet sie in diesem committed Backlog und wird mit einem Entry Date versehen. Anschließend wird die Anforderung früher oder später durch das Team bearbeitet und schlussendlich auch geliefert und mit einem Delivery Date versehen. Durch diese zwei Daten haben wir nun die Lead Time, die wir für jede Anforderung messen können. Dem Kunden kann anschließend dann die durchschnittliche Lead Time inkl. der damit verbundenen Varianz kommuniziert werden. Die Kosten pro User Story werden weiterhin aus dem Verhältnis der Geschwindigkeit des Teams zu den eingesetzten Kosten berechnet. Eine Schätzung von Anforderungen und Planung sind in so einem Modell, welches sich vor allem für die kontinuierliche Produktweiterentwicklung eignet, gar nicht mehr notwendig. Alles basiert auf einem Ansatz der Produktion, indem der Durchsatz für das System möglichst optimiert und erhöht wird.
- Das Risikomanagement...
- Meines Erachtens haben wir in agilen Methoden bereits eine erste built-in-Maßnahme für das Risikomanagement. Durch die regelmäßigen Lieferungen alle 1-2 Wochen ist es de facto unmöglich, einen absolut katastrophalen Fehlschlag zu erzielen. Durch das kontinuierliche Feedback wird sich die Lösung in eine Richtung bewegen, die annähernd dem entspricht, was der Kunde für akzeptabel hält. Das bedeutet, dass agile Methoden das Risiko der Nichterreichung der Kundenzufriedenheit sehr stark verringert.
- Zusätzlich schafft es die kurze Timebox so Druck auf die Teams auszuüben, in der Erstellung ihrer Teillieferungen kreativer zu werden. Anstatt große Konzepte über Monate zu entwickeln, benötigt es ein Ergebnis innerhalb von 1-2 Wochen. So wird auf bewährte Prototyping oder Proof of Concept Verfahren zurückgegriffen. Nur so kann bewiesen werden, dass das Versprochene tatsächlich möglich ist und damit das Risiko reduziert wird.
- Und zu guter Letzt gibt es zumindest in Scrum die Rolle des ScrumMasters, der mit Hilfe des Impediments Backlogs ebenfalls aktiv Risiken managed. Impediments sind in agilen Methoden jene Hindernisse, die das Team derzeit hat, und es daran hindert, noch produktiver zu sein. Diese werden in einem Backlog ebenfalls nach der Reihe deren Priorität gepflegt. Des Weiteren ist diese Liste immer öffentlich, sodass jedem Projektbeteiligten und Stakeholder klar ist, warum das Team derzeit mit eben dieser Geschwindigkeit und nicht noch schneller liefert. Da eine der Hauptaufgaben des ScrumMasters die Verantwortung der Lösung dieser Hindernisse ist, werden diese kontinuierlich bearbeitet und gelöst.
- Als Abschluss für den Risikomanagement-Part will ich Ihnen einen Vergleich zeigen, der ebenso gut auch in den Projektcontrollings-Part passen würde. Während in traditionellen Methoden oft jedes Ergebnisdokument einzeln getracked wird, gibt es in agilen Methoden nur die Metrik der Funktionalitäten bzw. User Stories. Alle anderen Arbeitsdokumente, ganz gleich ob Bedienungsanleitungen oder auch risikorelevante Aspekte wie Safety- und FMEA-Analysen bei sicherheitskritischen Produkte werden im Zuge der User Story mitgezogen und iterativ erweitert. Das bedeutet, das zu jedem Zeitpunkt das Produkt inkl. Aller zugehörigen Deliveries auf Stand ist. Sichergestellt wird dies durch die Definition of Done (DoD), eine Checkliste, die pro User Story sicherstellt, dass alle notwendigen Arbeiten mit erledigt werden.
- ... Und zu guter Letzt das Claimmanagement ...
- Ein Blick auf das agile Manifesto verrät, dass die Zusammenarbeit mit dem Kunden über Vertragsverhandlungen gestellt wird. Das heißt, dass es um eine intensive und vertrauensvolle Zusammenarbeit und weniger um das „Pochen“ auf Verträge geht. Im Claimmanagement wird häufig davon gesprochen, vereinbarte Bereitstellungen des Kunden einzufordern.
- Zu Beginn gleich die wesentlichsten „Claims“ an den Kunden, um überhaupt zu einer Zusammenarbeit im agilen Sinn zu kommen. Ich denke, dass ist deswegen ein wichtiger Punkt, weil ich immer wieder höre, dass unsere Beratungskunden gerne agil arbeiten würden, aber ihr eigener Kunde das wiederrum nicht zulässt. In agilen Methoden ist es einfach schlicht und weg notwendig, dass sich der Kunde aktiv in den Prozess einbringt und Verantwortung übernimmt – und das ist leider oft nicht gewünscht. Einbringen im Sinne von kontinuierlichem Feedback, zumindest nach jeder fertigen Iteration. Kontinuierliches Feedback zur Priorisierung des Backlogs, um dem Product Owner nicht die gesamte Arbeit alleine machen zu lassen. Dieses „Einbringen“ fordert jedoch auch Verantwortungsübernahme. Wo früher ein Kunde nach x Monaten sagen konnte, dass wollte ich so nicht, so kann er das heute nicht mehr, wenn er alle 1-2 Wochen die Gelegenheit dazu hatte, Einfluss zu nehmen. Das ist nicht immer leicht, erfordert sogar gewisse Eingeständnisse. Wenn man diesen Stand der Zusammenarbeit erreicht hat, sind die eigentlichen Fragen des Claimmanagements meines Erachtens gar nicht mehr so wichtig.
- Schauen wir auf Unternehmen, die agile Methoden in Ihrer Zusammenarbeit mit dem Kunden leben, so erkennen wir tatsächlich einen Paradigmenwechsel. Der Kunde ist nicht nur in den Prozess am Rande involviert, sondern er ist ein zentraler Bestandteil. Die potentiellen Endanwender sind sogar so tief in den Prozess eingebunden, dass die Entwicklung direkt auf diesen Anwendern stattfindet und somit jede neue Idee einfach am lebenden Objekt verifiziert wird. Die Conclusio daraus ist, dass es irgendwann keinen Bedarf mehr an Anforderungslisten gibt. Die Endanwender sind Teil des Entwicklungsteams und können so gemeinsam mit dem Team jenes Produkt bauen, welches sie am besten in ihrer täglichen Arbeit oder bei ihren Bedürfnissen unterstützt.
- Ich hoffe, ich konnte Ihnen heute einen kleinen Überblick über ein paar agile Stilmittel geben, die mich dazu bewogen haben, Agile zwischen Anarchie und Kontrollwahn zu verorten – mit der Einschränkung, dass dieses agile Arbeiten auch tatsächlich mit einer gewissen Disziplin durchgeführt wird!