Microsoft tech ed 2010 in Berlin - Tag 2 (Scrum/Agile)
-
Microsoft tech ed 2010 in Berlin
Tag 2 – Donnerstag, 11.11.2010 – die Themen zu Scrum/Agile
Zusammenfassung
Da die Zusammenfassung des 2. Tags zu lang geworden wäre, habe ich die C++-Themen und die Themen rund um Agile/Scrum in zwei verschiedene Artikel getrennt.
ARC207 - When Working Software is Not Enough: Death of an Agile Project
Agile ist erfolgreich? Nicht zwangsläufig. Auch solche Projekte können scheitern – lernen Sie aus den Fehlern anderer.
ARC206 – Scrum for Managers
Was muß aus Sicht eines Projektverantwortlichen bei Scrum bedacht werden? Welche organisatorischen Rahmenbedingungen sind dafür notwendig?
DPR201 – Agile Estimation
Bei Projekten mit einer agilen Abwicklungsmethode ist die Frage nach dem „wann sind wir fertig?“ nicht immer leicht zu beantworten. Mit welchen Methoden gelangt man zu funktionierenden Abschätzungen?
Einleitung
Nicht näher zugeordnete Fotos zu der Veranstaltung findet Ihr unter http://www.c-plusplus.net/misc/teched2010 .
Der Bericht zu Tag 1
Der Bericht zu Tag 2 (C++)ARC207 - When Working Software is Not Enough: Death of an Agile Project
Mitch Lacey, Mitch Lacey & Associates, Inc.
Mitch – PMP und Certified Scrum Master – berichtet von einem Fallbeispiel, bei dem in der Automobilindustrie ein Order-Tracking-System eingeführt werden sollte. Mitch strukturierte die Phasen des Projekts wie die Phasen einer Beziehung – erst kommt das Kennenlernen, die Heirat, die Flitterwochen, bis am Ende Anwalt und Scheidung stehen.
Das Projekt
Die Projektlaufzeit betrug 1 Jahr, und das benötigte Budget mit 1 Million $ war nur zur Hälfte vorhanden. Um das Budget zu schonen, sollten die Testaufwände vom Kunden in Eigenleistung getragen werden. Ebenso die Integrationsarbeiten am System. Die Transformation der Daten wurde laut Plan ebenfalls vom Kunden übernommen.
Als Basis dienten die vorhandenen Use Cases. Die Mitarbeit des Kunden im Team sollte sicherstellen, daß es nicht zur Situation „you did what I said but you didn’t do what I meant“ kommen könnte. Die Einschätzung des Projekts war „machbar“, allerdings waren nicht alle Anforderungen klar, daher sollte als Vorgehensweise eine Abwicklung nach Scrum erfolgen. Das Projekt wurde in zweiwöchige Sprints eingeteilt.
Es gelang rasch die ersten Versionen auszuliefern, mit positivem Feedback. Aber dann begannen die Kosten pro Story-Point zu wachsen. Ein Problem war, daß das Produkt-Backlog nicht stabil wurde. Alle Storys hatten die gleiche Priorität und änderten sich fortlaufend. Der Kunde begann zu merken, daß er tatsächlich nicht mehr alle Storys geliefert bekommen würde. Der Kunde verlangte vom Projektteam, daß dieses die Storys zu priorisieren hätte – er selbst war nicht bereit dazu.
Die Funktionalabteilungen des Kunden waren für Freigaben wie Datenmodell zuständig, aber die Verantwortung für diese Entscheidungen sollte beim Projektteam liegen. Dazu wurden die Firmenstandards für die Implementierungen ständig geändert, waren aber nie dokumentiert.
Das organisatorische Umfeld verursacht „Taxes“ (wirklich wörtlich als „Steuern“ zu verstehen) beim Projekt – unter „Tax“ versteht Mitch die Overhead-Kosten für Meetings, Abstimmungen mit dem Kunden, Sicherheits- und Freigabechecks. Im Verlauf des Projekts nahmen diese Kosten ständig zu, wodurch die Möglichkeit fertige Storys zu liefern ständig abnahm.
Das Projektteam wurde zunehmend weniger produktiv und undisziplinierter, wodurch die bearbeiteten technischen Aufgaben weiter abnahmen.
Der Kunde verweigerte die Mitarbeit an den Tests, weil seiner Meinung nach das Produkt noch nicht fertig war. Dies wiederum lag an ständigen Änderungen der Forderungen. Der Kunde hatte nie verstanden, daß das Backlog Stabilität benötigt, und gleichzeitig auch nie alle Punkte geliefert würden. Weiterhin war dem Kunden nicht klar, daß er bei einer Projektabwicklung nach Scrum permanent testen müsste, und nicht nur am „Projektende“.
Da bereits Anwälte involviert waren, arbeitete das Projektteam nur noch zum Selbstschutz, was laut Vertrag unbedingt zu liefern sei.
Was lief schief?
In der nachträglichen Betrachtung gab es folgende Fehler in den frühen Projektphasen:
Zu Beginn wurde zu viel Zeit für die Erstellung der Spezifikationen aufgewendet. Beide Seiten waren bereits frustriert, und wollten unbedingt starten um endlich anzufangen.
Durch den Zeitverlust nahm aber der Zeitdruck zu, da nur noch ein bestimmter Zeitraum zur Verfügung stand.
Der Kunde war sich nicht wirklich sicher was er bekommen würde, und begann „zu glauben“ was er bekommen würde. Diese Divergenz zwischen Erwartungshaltung und tatsächlicher Lieferung sorgte dann im weiteren Verlauf für immer größeren Ärger und Enttäuschung beim Kunden.
Die Personen der IT-Abteilung waren ausgeschlossen vom Prozess und unterstützten den Prozess folglich auch nicht. Gleichzeitig konnte diese Abteilung aber Anforderungen vorgeben und Abnahmen verweigern.
Die Dokumentation der Abläufe war nach Meinung des Kunden ausreichend als Spezifikation. Dabei war diese gleichzeitig zu umfangreich um sie noch zu bearbeiten, aber in den Details trotzdem unzureichend.
Die Komplexität der Kundenorganisation, deren Kultur, war vom Projektteam nicht ausreichend verstanden und wurde daher unterschätzt.
Letztlich hatte der Kunde hatte das Prinzip von Scrum nicht verstanden. Der Kunde hatte seine Rolle und den Einfluß seiner Entscheidungen auf das Backlog nicht verstanden. Dazu kam, daß ständige Änderungen das Backlog beeinflussten, der Kunde dafür aber keine Verantwortung übernahm.
Da der Kunde glaubte er bekäme alles was im Backlog steht, war er vom Produkt nicht mehr überzeugt als er hörte, daß er nicht alles bekommen könne.
Der Beginn von Tests und Nutzen wurden vom Kunden verweigert, weil er der Meinung war das Produkt wäre nicht fertig. Im Scrum-Umfeld gibt es diesen Endzeitpunkt aber nicht.
Lessons Learned:
Es muß auf das Projektabwicklungssystem eine übereinstimmende geben. Auf der Kundenseite muß jemand die Grundsätze und Prinzipen von Scrum verstehen und die Abläufe entsprechend kommunizieren.
Seitens des Kunden wurden durch eine Person Anforderungen an das Projekt übergeben, aber erst im Verlauf des Projekts bemerkte man, daß die Endnutzer die Funktionalität bemängelten – sie waren mit der Übermittlung ihrer Wünsche unzufrieden. Trotzdem wurde diese Schuld dem Projektteam zugeschrieben, frei nach „der Kunde hat immer Recht“.
Der Projektleiter des Kunden war auf Zeit und Kosten fixiert, die Nutzer beim Kunden dagegen auf die Eigenschaften des Produkts, eine unglückliche Kombination. Daher übernahm der Kundenprojektleiter nicht die Rolle des Product Owners, diese in Scrum-Projekten wichtige Rolle war daher nie wirklich besetzt.
Es wurde versäumt dem Kunden mitzuteilen, wie es sich mit dem Abarbeitungsgrad des Product Backlogs verhalten würde, und auch daß sich die Taxes noch weiter negativ auf den Abarbeitungsgrad der Storys auswirken würden.
Es gelang nicht dem Kunden die Verantwortung für seine eigenen Entscheidungen zu übertragen. Zwar waren diese alle relativ gut dokumentiert, trotzdem spielte das am Ende für die Schuldfrage gar keine Rolle – Schuld war das Projektteam.
Was war eigentlich mit den Kosteneinsparungen?
Zu Beginn des Projekts sollten doch massive Einsparungen realisiert werden, indem Teile der Arbeit vom Kunden zu erbringen seien. Was wurde am Ende daraus?
Das Testen wurde vom Projektteam durchgeführt – die Systemintegration wurde teilweise vom Projekt durchgeführt – die Datenmigration wurde vom Projektteam durchgeführt
Am Ende hat das Projekt 1 Million $ gekostet – wie ursprünglich geplant. Bezahlt wurde aber trotzdem nur die Hälfte.
ARC206 – Scrum for Managers
Mitch Lacey, Mitch Lacey & Associates, Inc.
Die Rolle des Managers im Scrum-Team ist die Beseitigung von Hindernissen.
Agile ist in erster Linie eine Einstellungssache, um Ziele anders und schneller zu erreichen.Die Scrum-Prinzipien
Mut zur Überbringung von schlechten Nachrichten und der Wahrheit.
Offenheit gegenüber Feedback und Ideen.
Respekt im Team und nach Außen, um auch die Wahrheit zu sagen.
Fokus, denn das Team muß sich auf die Ziele der Sprints konzentrieren und darf nur an diesen arbeiten.Das ideale Feld für Scrum
Das Projekt kann in Bezug auf Technik und Anforderungen eingeschätzt und in der folgenden Grafik markiert werden.
Liegt das Projekt im weißen Bereich, ist dies eine ideale Anwendung für Scrum. Die Einschätzung des Kunden ist oft rechts unten, die des Team oft links oben.
Ein schönes englisches Wortspiel an dieser Stelle: „assume“ heißt „make an ass of you (u) and me“.
Der Wasserfall – das klassische Modell
Wenn man die gleichen Sachen immer und immer wieder wiederholt, wie kann man unterschiedliche Ergebnisse erwarten?
Im Wasserfall-Modell hat man im Projektverlauf wesentlich länger das beruhigende Gefühl, daß einen die Veränderungen der Außenwelt nicht beträfen. Denn man hat eine verabschiedete Spezifikation, die zu bearbeiten ist. Nur - dies entspricht nicht der Wahrheit. Die Außenwelt ändert sich fortlaufend und alle Änderungen stauen sich bis zum Ende des Projekts auf.
Bei einem adaptiven Ansatz zur Vorgehensweise im Projekt kann man während des Ablaufs auf sich verändernde Anforderungen und Ziele reagieren.
Das bekannte Teufelsdreieck aus Zeit, Kosten und Qualität sagt, daß üblicherweise zwei Parameter fix sind und der dritte wählbar wird. Bei Agile ist die Idee, die Kosten und Zeiten festzuschreiben, und daraus die möglichen Features abzuleiten.
Scrum – das Zusammenspiel der Abläufe.
In dem Product-Backlog werden die User Storys gesammelt und vom Aufwand her in Story-Points gemessen – dies ist besser als Tage oder sogar Stunden, da diese auf die reale Arbeitsgeschwindigkeit des Teams skalierbar sind.
Das folgende wunderbare Bild zeigt genau, wie sich das Endprodukt aus den sukzessiven Arbeitsteilen zusammensetzen wird.
Die Rollen bei Scrum
Der Scrum-Master ist dafür zuständig, daß die Dinge laufen, daß Störungen beseitigt werden und das Team arbeiten kann.
Der Product-Owner ist dafür verantwortlich, daß die Anforderungen des Kunden in das Produkt kommen. Er gibt die Richtung vor und kontrolliert die Abweichung. Er sorgt dafür, daß so viele Eigenschaften vom Team geliefert werden wie möglich.
Das ist auch der Grund, warum diese Rollen auf 2 Personen aufgeteilt sein sollten.
Das Team – erledigt die Arbeit. Software, Testing, Dokumentation, Meetings.
Und was ist mit dem Projektmanager? Sollte dieser ein Scrum-Master sein? Hat man einen Projektmanager, so vermischt sich seine Rolle mit dem Scrum-Master, Product-Owner und dem Team. Der PM ist von allem etwas. Die Verantwortlichkeit ist nicht mehr klar. Er arbeitet sinnvollerweise nicht innerhalb des Scrum-Verbundes, oder man verzichtet auf ihn.
Multitasking is slowing you down
Im Auditorium lässt Mitch ein schnelles Spiel durchführen – er teilt die Zuhörer in zwei Gruppen. Alle sollen drei Spalten schreiben – in der linken Spalte die Zahlen von 1 bis 26, in der mittleren Reihenfolge die Buchstaben A bis Z, und in der rechte Spalte die römischen Zahlen von I bis XXVI. Die eine Gruppe schreibt spaltenweise (immer erst eine Spalte nach der anderen), die andere zeilenweise. Nicht überraschend, daß die Gruppe „Spaltenweise“ deutlich gegen die Gruppe „Zeilenweise“ gewann – noch dazu fühlte man sich in der Gruppe „Zeilenweise“ regelrecht angestrengt.
Der ständige Kontextwechsel verursacht den Zeitverlust – dies gilt auch im größeren Maßstab und erhöht die Frustration im Team.
Ein weiterer Grund, warum die Story Points überschaubar und in einem Sprint bearbeitbar sein sollten. Denn wenn noch Storys „offen“ sind, werden die Entwickler gezwungen zwischen verschiedenen Themen zu wechseln.
Wenn schon scheitern, dann früh
In Firmenorganisationen werden Personen belohnt, die Risiken eingehen und erfolgreich sind. Wer aber nur wenig tut (also in der „comfort zone“ verbleibt) wird ebenfalls belohnt – geringer, aber immerhin. Und wer scheitert, erfährt oftmals sogar eine „negative“ Belohnung.
Um einen Paradigmenwechsel wie die Einführung von Scrum zu bewältigen, ist ein anderes Anreizmodell sinnvoll – wer in der “comfort zone” bleibt sollte dafür nicht belohnt werden. Wer Risiken eingeht und scheitert, wird dafür immer noch zu einem Teil belohnt.
Als Manager sollte der Bruch mit Gewohnheiten gefördert werden, der Manager schützt das Team diesbezüglich. Fehler müssen erlaubt und in gewisser Weise sogar gefördert werden.
Um mit Scrum zu beginnen, muß in der Firma jemand aus dem Top-Management die Vorgehensweise unterstützen und aktiv vermarkten.
Wodurch scheitert man bei der Einführung von Scrum?
- Wenn man denkt „das geht bei uns nicht“
- Durch den Rückfall in alte Gewohnheiten
- Wenn man bei Betrachtungen von alten Projekten unehrlich ist
- Indem man „einfach mal anfängt“, ohne Vorbereitung
- Durch fehlende Autorität
- Wenn die Unternehmenskultur die agilen Werte nicht unterstützt oder diese nicht integrierbar sind
Weiterführende Links:
http://jeffsutherland.com/ScrumPapers.pdf
DPR201 – Agile Estimation
Stephen Forte, Chief Strategy Officer, Telerik
Heißt Agile, daß man nicht mehr planen muß? Dieser Vortrag berichtet davon, wie man bei Anwendung agiler Methoden zu korrekten Abschätzungen und Planungsergebnissen kommt.
Das Problem der Einschätzung
Eine Einschätzung ist die Berechnung einer Näherung an ein Ergebnis. Einschätzungen werden oft als unwiderruflicher Zeitplan betrachtet, wo jede Abweichung als schlecht betrachtet wird. Dabei sind Einschätzungen eine Näherung, nicht mehr.
Man nehme als Beispiel eine grobe Projektskizze, bestehend aus 1 Monat Design und Architektur, 4 Monaten Entwicklung und 1 Monat für Tests. Die erste Schätzung für Design und Architektur ist falsch, es dauert eine Woche länger. Die Versuchung ist groß, den Zeitplan um eine Woche zu verlängern. Aber das ist falsch, denn hier wurde die Zeit bereits um +25% überschritten – sinnvoll wäre es den Zeitplan um 1,5 Monate zu verlängern! Aber dies ist im Regelfall nicht realisierbar.
Statistische Auswertungen zeigen, daß die erste Einschätzung um einen Faktor 4 falsch ist – im Mittel. Und zwar nach oben oder nach unten. Auch wird zu viel Zeit für die Spezifikation aufgewandt, die trotzdem nicht vollständig ist – nicht genug Details stehen fest. Mit dem Lauf der Zeit tauchen mehr und mehr Details auf.
Vom Mythos des Mann-Monats | ISBN: 9783826613555Diese Tatsache ist nicht wirklich neu und wurde in dem IT-Literatur -Klassiker „The Mystical Man Month“ („Vom Mythos des Mann-Monats“, Fredrick Brooks) vor fast 40 Jahren bereits erstmalig als „Cone of Uncertainty“ („Unsicherheitsschlauch“) beschrieben.
Mit zunehmender Laufzeit des Projekts wird die Abschätzung immer genauer.
Agile Estimation
Bei Agile Estimation wird das Konzept umgeworfen, es gibt keine große Abschätzung zu Beginn des Projekts, sondern eine fortlaufende Abschätzung nach jeder Iteration. Der psychologische Vorteil: eine Abweichung ist keine Abweichung, sondern eine genauere Abschätzung. Der Abweichungsschlauch wird damit zum Vorteil bei der Abschätzung, da er mit dem Zeitfortschritt genauere Ergebnisse ermöglicht.
Neu eingeschätzt werden in jeder Iteration zum einen neue Punkte im Product-Backlog und Dinge, zu denen neue Erkenntnisse auftauchten. Es wird nicht jede Story komplett neu eingeschätzt.
In der Diskussion mit dem Publikum wurde die Frage gestellt, wie diese Vorgehensweise zu festen Endterminen passt. Wenn der Endtermin feststeht, bewegen sich die Features. Wenn die Features feststehen, bewegt sich der Endtermin. Was angemessen ist, hängt vom Projekt ab. Müssen zu einem bestimmten Endtermin bestimmte Features festliegen und dies ist nicht erreichbar – dann hat man einen Konflikt und muß über eine Form der Änderung nachdenken: mehr Ressourcen, weniger Features, oder mehr Zeit.
Einen solchen Zeitpunkt möglichst früh zu erkennen ist eine Aufgabe der Schätzung.
Wie schätzt man?
Basis sind die User Storys – die Funktionalität wird in kleine User Storys runtergebrochen. Jede Story enthält eine oder mehrere Abnahmebedingungen. Diese sollten übersichtlich und nicht zu groß sein. Sogenannte „Epic User Storys“ – zu große Storys – eignen sich nicht mehr zur Einschätzung, sie müssen runtergebrochen und in kleinere Storys aufgebrochen werden.
Im Planning Poker werden die Storys nach Schwierigkeit eingeschätzt, von einfach bis extrem schwierig. Die Pokerkarten enthalten eine Bewertung, wieviel schwieriger die Aufgabe wird als der Standard. Man wählt einen Bezug, den das Team zum Beispiel in einem halben oder ganzen Tag durchführt. Die Abstimmung erfolgt gemeinsam, bis eine gemeinsame Bewertung feststeht. Weicht die Einschätzung stark ab, so ist dies in einer Diskussion zu klären und erneut abstimmen.
Unter http://www.planningpoker.com gibt es ein kostenloses Online-Tool für Durchführung des Planning Poker.
Das Ergebnis sind die Story Points – eine relative Bezugsgröße nicht zur Messung von Zeit, zur Messung von Größe und Komplexität. Stephen bevorzugt eine echte relative Bezugsgröße, um die Werte zu vergleichen – und kein abstrakte Skala. Mit anderen Worten: es sollte wirklich ein festgelegtes Basisproblem geben, bei dem man sich über die Erledigung sicher ist und dieses als Bezugsmaß dienen.
Das Product Backlog besteht aus den User Storys mit einer Einschätzung der Story Points. Diese Punkte sind zu bearbeiten, um das Projekt zu beenden. Im Backlog kann auch die Priorisierung stehen.
Die Geschwindigkeit, wie viele Story Points pro Sprint bearbeitet werden können, nennt sich Velocity. Diese ergibt sich am Ende eines Sprints aus der Menge der bearbeiteten Story Points und der Dauer des Sprints. Naja, eine Geschwindigkeit eben.
Die erste Einschätzung der Projektdauer besteht aus der Summe der Story Points bezogen auf die Bezugsgröße, aber unter Berücksichtigung des Cone of Uncertainty.
Der erste Sprint
Die Entwickler übernehmen die Erledigung von bestimmten Story Points. Normalerweise ist das am Anfang eine völlige Fehleinschätzung, wie viel das Team im ersten Sprint tatsächlich schafft (außer das Team hat schon in vorigen Projekten zusammengearbeitet).
Die Team Geschwindigkeit ist die Anzahl der Story Points, die pro Sprint erledigt werden. Dies funktioniert, wenn die Einschätzung der Story Points konsistent ist. Je besser die Geschwindigkeit eingeschätzt ist, desto genauer wird die Abschätzung des Projektzeitplans. Nach 3 bis 6 Iterationen sollte die Geschwindigkeit einigermaßen stabil sein.
Die erneute Einschätzung: Re-Estimation
Die Geschwindigkeit ändert sich im Laufe des Projekts. Eine erneute Einschätzung erfolgt nach jedem Sprint, mit Berücksichtigung der aktuellen Team-Geschwindigkeit, den neuen Punkten im Product Backlog und eventuell inzwischen im Backlog vorhandenen Bugfixes – diese werden als neue Aufgaben ebenfalls im Backlog abgelegt.
Auch Urlaub von Teammitgliedern kann als Story Point vorgesehen werden, dies hat den Vorteil, daß die Zeitmessung konstant ist. Andernfalls müßte man bei einem Urlaub berücksichtigen, daß sich die Teamkapazität – also das was bearbeitet werden kann – während dieses Zeitraums ändert.
Die ermittelte Team-Geschwindigkeit kann bei künftigen Projekten als erste Schätzung verwendet werden – falls sich das Team nicht ändert.
Steht der Endtermin unwiderruflich fest, kann aus der Teamgeschwindigkeit und den vorhandenen User Storys im Backlog ermittelt werden, welche User Storys zu streichen sind, um das Zeitziel zu treffen.
Literaturhinweise:
User Stories Applied | ISBN: 9780321205681User Stories Applied, Mike Cohn
Agile Estimating and Planning | ISBN: 9780131479418Agile Estimation and Planning, Mike Cohn
Agile Retrospectives | ISBN: 9780977616640Agile Retrospectives, Esther Derby und Diana Larsen