Story Points entsprechen Zeit (und passen trotzdem auf keinen Zeitstrahl)

Bild: Pixabay / Geralt - CC0 1.0

Zu den am häufigsten missverstandenen Elementen agiler Arbeitsweisen gehören Story Points. Von klassischen Projektmanagern werden sie häufig in Zeiteinheiten umgerechnet, was bei den meisten agil arbeitenden Team zu heftigen Abstossungsreaktionen führt. Auf die Frage was diese Punkte denn dann sein sollen wenn nicht Zeit wird häufig erklärt, dass sie die Komplexität der geschätzten Arbeit anzeigen, was nicht in Stunden oder Tage umrechenbar wäre. Für alle die dieser Meinung sind dürfte die letzte Woche ein unangenehmes Erwachen gewesen sein.

OK, experts who think story points aren't about cost, and that cost isn't essentially time, educate me. What are they, what are they good for, why do we estimate them?

In answering, show no concern for the likelihood that I invented them.

If I did, I'm sorry now.

— Ron Jeffries (@RonJeffries) 14. Mai 2019

Der Herr der diese (rhetorische) Frage stellt ist Ron Jeffries, und was er andeutet stimmt - er gehörte in den 90ern zu den Erfindern der Story Points. Er weiss also tatsächlich wie sie gemeint sind und was sie bedeuten sollen. Auch zum Thema Komplexität hat er eine Meinung - und es ist keine gute.

I really don't understand what "complexity" means or how one uses it. If it doesn't come down to time to build, what is it good for?

— Ron Jeffries (@RonJeffries) 15. Mai 2019

Für ihn ist also klar, dass Story Points Zeit bedeuten und nicht Komplexität. Und wie gesagt, er ist der (Mit)Erfinder. Haben die oben genannten Projektmanager demnach recht wenn sie einen Punkt mit einer Stunde gleichsetzen? Nun - nein. Auch nicht. Es ist (Ironie der Geschichte) komplexer als das.

Zunächst ist ein Story Point eine neutrale Schätzgrösse. Die ist nötig, da unterschiedliche Menschen für die selbe Aufgabe unterschiedlich viel Zeit brauchen. Je nachdem wer an ihr arbeitet dauert es also mehr oder weniger lang (siehe hier). Zur Ermittlung der Umsetzungsdauer einzelner Aufgaben sind Story Points demnach unbrauchbar. Genau diese Einzelfallschätzung ist es aber, die häufig verlangt wird - und dass das nicht funktionieren kann ist dann Ursache der oben genannten Abstossungsreaktionen.

Was aber machbar ist, ist die Verwendung von Story Points für die Planung grosser Mengen von User Stories. Bei 50, 100 oder mehr User Stories mitteln sich die verschiedenen Abweichungen, so dass die so genannte Velocity entsteht: der durchschnittliche Durchsatz von Story Points pro Sprint. Basierend darauf kann man Prognosen über die zukünftige Arbeitsgeschwindigkeit eines Teams machen (wichtig an dieser Stelle: grosse Mengen von User Stories sind nicht das Selbe wie einzelne grosse Arbeitspakete).

Aber ist denn damit zumindest langfristig eine Planungssicherheit möglich? Nun - immer noch nicht. Die Durchschnittsleistung eines Teams wird mit grosser Wahrscheinlichkeit sinken wenn einzelne Mitglieder ausgetauscht werden, wenn neue Technologien eingesetzt werden, wenn neue fachliche Herausforderungen anstehen oder wenn mit neuen Schnittstellen oder Kunden umgegangen werden muss. Umgekehrt kann Stabilität in Teamzusammenstellung, Technologie, Aufgabenstellung oder Umgebung auch die Velocity stabilisieren oder sogar steigern.

Hier könnte man letztendlich den Silberstreifen am Horizont vermuten. Es ist also nur nötig Teamzusammenstellung, Technologie, Aufgabenstellung und Umgebung stabil zu halten und schon kann verlässlich und sicher prognostiziert geplant werden? Ja, tatsächlich, das wäre theoretisch möglich. In der Realität dürften derartige Rahmenbedingungen aber selten bis nie auftreten. Und damit kommen wir zum vielleicht grössten der Missverständnisse rund um Story Points.

Story Points haben gar nicht den Zweck berechenbare Arbeit zu planen. Sie sollen helfen Annahmen zur Umsetzungsdauer unberechenbarer (und damit unplanbarer) Arbeit zu machen (mehr dazu hier). Das findet zwar in Zeiteinheiten statt (mit den oben genannten Einschränkungen), da einige der Annahmen sich aber als falsch herausstellen werden wird das Gesamtergebnis immer anders sein als die initiale Annahme. Das Fazit kann daher nur lauten: Story Points entsprechen zwar Zeit - passen aber trotzdem auf keinen Zeitstrahl.

Modularisierung

Manchmal sind die Unterschiede zwischen Software und Hardware kleiner als man denken sollte. Bestimmte Situationen können in beiden Fällen so ähnlich sein, dass sie ähnliche Herausforderungen und ähnliche Lösungsansätze mit sich bringen. Ein Glücksfall für alle die diese erklären müssen, schliesslich bieten sich dadurch verständliche Analogien mit denen man arbeiten kann.

Ein derartig eingängiges Fallbeispiel befindet sich zur Zeit zwischen Köln und Bonn, in einem Ort mit dem schönen Namen Wahn. In Wahn befindet sich eine Brücke über die die Autobahn 59 geführt wird, und da diese Autobahn um eine weitere Spur ausgebaut werden soll wird als erster Schritt diese Brücke erneuert. So weit, so banal. Und doch ist dieser Brückenneubau etwas Besonderes.

Wie man den Internetseiten des Landesbetriebs Strassenbau entnehmen kann wurde die Wahner Brücke anders gebaut als üblich. Während es sich bei den meisten Autobahnbrücken um zwei parallele Teilbauwerke handelt (eine pro Richtung) besteht diese hier aus einem einzigen Stück. Um jetzt jeweils die eine Hälfte erneuern zu können während der Verkehr über die andere geführt wird muss die Brücke vorher in zwei Teile zersägt werden.

Natürlich ist das kein einfaches Unterfangen. Die Geräte benötigen Platz, die Statik und Stabilität des Gesamtbauwerks muss gesichert werden, die Arbeit muss von Spezialisten durchgeführt werden die nicht sofort zur Verfügung stehen, sowohl die benötigte Zeit als auch die zu zahlenden Kosten sind höher als sie es bei einer der üblichen zweigeteilten Brücken sein würden. Man kann sich vorstellen was alles dahintersteckt.

Zur Analogie: auch in der Softwareentwicklung können derartige Situationen auftreten. Es sind hier zwar keine Fahrspuren die parallel laufen, es können aber Transportwege für Daten sein, beispielsweise einer für Stammdaten und einer für Metadaten. Und auch hier ist es so, dass ein festes Verbinden dieser Wege zu Problemen führt - soll einer von ihnen erneuert werden muss man entweder beide umbauen (und ggf. sperren) oder sie vorher aufwändig in separate Module zerschneiden.

Sogar die Ursachenforchung dürfte zu ähnlichen Ergebnissen führen. Ob es Zeitnot war, zu wenig Budget, fehlende Erwägungen zukünftig nötiger Arbeiten oder schlicht Gedankenlosigkeit, all das kann sowohl im Fall von Software als auch im Fall von Hardware der Grund für die fehlende Modularisierung sein, in Wahn genau wie in der IT.

Zuletzt bietet der Brückenbau zu Wahn noch ein weiteres "Geschenk" für alle die ihn zu Vergleichszwecken nutzen wollen: neben dem Anlass und der Analogie bietet er auch die Zeit für eine Erklärung. Er sorgt nämlich ein Jahr lang jeden Tag für Stau.

Scrum in der Schule

Manchmal muss man in die Ferne blicken um das Naheliegende zu entdecken. Auf der re:publica 2019 wurde eine Schule aus Bonn vorgestellt die Scrum im Unterricht einsetzt. Und ohne es zu wissen bin ich erst vor wenigen Tagen an ihr vorbeigelaufen. Eine kleine Welt.

Retrospektiven-Ergebnisse

Bild: Pexels / Elevate Digital - CC0 1.0

Egal ob man sie Retrospektiven nennt oder Lessons Learned-Meetings, Kaizen-Events, Schulterblick oder KVP-Sitzung, es sind derartige Veranstaltungen die den Kern aller ständigen Verbesserungsprozesse bilden und damit auch den Kern der Agilität. In ihnen können Beschlüsse und Massnahmen erarbeitet werden durch die der Inspect & Adapt-Prozess mit Leben gefüllt wird. Um in diesem Zusammenhang zielgerichtet vorgehen zu können empfiehlt sich ein näherer Blick: welche Arten von Ergebnistypen können hier entstehen?

1. Action Items

Der Retrospektiven-Klassiker. Was auch immer vom Team selber erledigt werden kann lässt sich als Massnahme beschliessen und mitnehmen. Wie das im Einzelfall aussieht kann sich von Fall zu Fall unterscheiden, es gibt aber good Practices: die Massnahmen sollten bis zur nächsten Retrospektive abschliessbar sein, es sollte eine Person für die Umsetzung (bzw. deren Koordination) verantwortlich sein und der damit verbundene Aufwand sollte in die Kapazitätsplanung einfliessen. Besonders das letzte klingt zwar selbstverständlich, wird aber häufig vergessen.

2. Anforderungen

Für die einen naheliegend, für die anderen nicht. Gehören Anforderungen nicht eher zur Planung als zum Lessons Learned? Im Prinzip ja, allerdings fallen sie auch im Planning oder Replenishment nicht vom Himmel. Irgendwo befindet sich ein vorgelagerter Schritt in dem sie initial erdacht werden, und der kann auch eine Retrospektive sein. Wenn hier z.B. beschlossen wird, dass ein Refactoring oder Monitoring Sinn macht, kann das in den Planungs- und Priorisierungsprozess einfliessen und auf diese Weise in die Umsetzung gegeben werden.

3. Apelle

Ein eher unschöner Ergebnistyp. Wenn sich ein Missstand ausserhalb der Einflusssphäre eines Teams befindet bleibt manchmal keine andere Möglichkeit übrig als einen Apell an denjenigen zu richten der zur Behebung in der Lage ist. An dieser Stelle liesse sich zwar kontrovers diskutieren ob ein Team das nicht alle Probleme selbst beheben kann an seiner Crossfunktionalität arbeiten müsste, im Moment des unmittelbaren betroffen Seins sind diese Überlegungen aber nicht hilfreich. Ein parallel zum Apell verfasstes Action Item zum Skillaufbau ist dagegen eine gute Idee.

4. Buffer / Slacktime

Frei nach Max Weber: auch das Unterlassen von etwas ist eine Massnahme. Dementsprechend kann es eine gute Idee sein einen Teil der eigenen Zeit bewusst nicht zu verplanen. Ob dieser dann als Reserve für ungeplante Arbeiten verwendet wird, für Überstundenabbau oder für Weiterbildung kann kurzfristig entschieden werden. Vor allem in hoch volatilen Umfeldern kann es sehr sinnvoll sein so vorzugehen, da es das Risiko versehentlicher Überplanung verringert und das Reaktionsvermögen erhöht.

Sicherlich existieren neben diesen vier noch weitere Retrospektiven-Ergebnistypen, die überwiegende Mehrzahl dürfte aber einem von ihnen zuzuordnen sein. Alleine sich über sie bewusst zu werden kann helfen. Sollte sich z.B. herausstellen, dass aus Retrospektiven fast ausschliesslich Apelle entstehen ist das in fast allen Fällen ein Indikator dafür, dass hier ein Problem existiert das angegangen werden sollte.

Code Ownership (IV)

Bild: FFCU / Markus Spiske - CC0 1.0

Wie viele andere Begriffe hat auch der der Code Ownership verschiedene Bedeutungsaspekte, je nachdem aus welchem Blickwinkel man ihn betrachtet. Auf der anderen Seite verbirgt sich dahinter eine Art von Besitzanspruch im Sinne von "dieser Code gehört mir" (warum das ein Problem ist kann man hier, hier und hier nachlesen). Es lässt sich aber auch eine zweite Deutung formulieren: sich den Code zu eigen machen. Auch die ist von grosser Wichtigkeit.

Unter dem "sich zu eigen machen" können sich wiederum verschiedene Bedeutungen verbergen, die aber alle einen verwandten Inhalt haben - es geht darum das Objekt (in diesem Fall den Code) zu studieren, zu verstehen, zu erlernen oder zu verinnerlichen, bis zu dem Punkt an dem bei neuen Problemen und Herausforderungen sofort eine Idee entsteht wo und wie diese zu lösen sein könnten. Sie muss noch nicht perfekt sein, aber einen ersten Anhaltspunkt bieten.

Der Nutzen eines solchen Wissens ist offensichtlich: wann immer die genannten Problemen und Herausforderungen auftreten ist es nicht nötig sich zuerst in die Dokumentation einzulesen, Code Reviews zu machen oder Reverse Engineering zu betreiben, stattdessen kann schneller mit der eigentlichen Arbeit begonnen werden. Und bedingt durch die gegebene Vertrautheit dürfte auch deren Ergebnis besser sein.

Um ein Code Ownership in diesem Sinn zu erreichen ist es nicht ausreichend ihn geschrieben oder einmalig verstanden zu haben, schon gar nicht wenn das nur durch eine Person geschieht. Idealerweise ist es eine ganze Gruppe die sich regelmässig mit ihm beschäftigt, um so das Wissen nicht nur zu verteilen sondern durch ständige Kommunikation am Leben zu halten. Am Ende sollte dabei ein kollektives Gedächtnis des gemeinsam verinnerlichten Codes stehen.

An dieser Stelle beginnen in vielen Organisationen die Herausforderungen. Nicht etwa in erster Linie wegen der Herstellung von Collective Code Ownership (obwohl auch das schon ein Problem sein kann) sondern vielmehr weil eine regelmässige Beschäftigung eines Teams mit einem bestimmten Anwendungsteil oft nicht vorgesehen ist. Modifizierungen finden vor allem im Rahmen von Projekten statt zwischen denen Monate oder sogar Jahre liegen können.

Von diesem Muster wegzukommen und sich in Richtung einer "Continuous Code Ownership" zu bewegen kann grössere und aufwändige Umstellungen erfordern, es ist aber eine der Voraussetzungen um im Zweifel schnell lieferfähig zu sein.

Ein Bild sagt mehr als 1000 Worte (XXIV)

AFTER - #SAFe Program Board after @ScaledAgile PI Planning w/ a couple of #dependencies #transparency #collaboration pic.twitter.com/dCJ3m0Xfvk

— Michael Stump (@michael_p_stump) April 15, 2016

Kommentierte Links (XXXXVIII)

• Christiaan Verwijs: Here’s what's wrong with maturity models

Die Frage ist erstmal naheliegend: Wie gut bin ich eigentlich in dem was ich mache? Auf diesen Kontext hier übertragen: Wie gut beherrsche ich Agile, Scrum, Lean, Kanban, etc.? Die scheinbar naheliegendste Lösung der Überprüfung und Auszeichnung durch Zertifizierungen läuft sich gerade tot, so dass eine andere gesucht wird. Maturity Modelle scheinen auf den ersten Blick eine naheliegende Alternative, allerdings eine die mit Vorsicht zu betrachten ist. Christiaan Verwijs zeigt die grundlegenden Probleme dieses Konzepts auf - zu generalistisch, zu wenig auf den jeweiligen Fall eingehend, zu linear. Mit anderen Worten: nicht agil.

• Joshua Kerievsky: Preconditions for Agility

  Mit der Bewegung von agilen Vorgehensweisen in Richtung Mainstream erhöht sich nicht nur die Zahl der Erfolgsgeschichten sondern auch die der Fehlschläge. Ein häufiger Grund dafür ist der Versuch "agile" Vorhaben in einem Kontext durchzuführen in dem sie nur eingeschränkt oder gar nicht funktionieren können. Joshua Kerievsky führt einige Vorbedingungen auf die gegeben sein müssen damit das Ganze Erfolgsaussichten hat: Crossfunktionalität, gemeinsames Verständnis der Ziele, Teamwork, Bereitschaft zu Work in Progress-Limits und Kenntnis der üblichen Praktiken bei allen Beteiligten. Dass das für Agilität elementar ist dürfte offensichtlich sein, umgekehrt stellt sich aber die Frage wie ohne zumindest einige dieser Vorbedingungen überhaupt produktiv gearbeitet werden kann.
  

• Jeff Sutherland: Why Less Communication is Better!

  Ein weiterer Beitrag zu den Ursprüngen von Scrum und Agilität im Militär. Nach den römischen, mongolischen und preussischen Armeen diesesmal mit einem Verweis auf die modernen amerikanischen und vor allem deutschen Streitkräfte. Vom Deutschland des 21. Jahrhunderts aus betrachtet nicht ganz unproblematisch. Einen der beiden Scrum-Gründer von Wehrmachts-Begriffen wie "Auftragstaktik" und "Führen mit Auftrag" schwärmen zu sehen ist (gelinde gesagt) befremdlich und führt spätestens dann zu Unwohlsein wenn der Frankreich-Feldzug von 1940 als positives Beispiel herangezogen wird. Selbst wenn man versuchen könnte das militärische Vorgehen von der dahinterliegenden Ideologie zu trennen ist es unwahrscheinlich, dass dieses Thema hier populär wird.

• Roman Pichler: 10 Scaling Tips for Product People

  Im Grunde auch benutzbar für jede andere Form von Skalierung im agilen Umfeld (und darüber hinaus). Pichlers 10 Skalierungstips sind:
  
  1. Beziehe die richtigen Leute ein
  2. Skaliere nicht zu früh
  3. Starte mit einem MVP (um noch nicht skalieren zu müssen)
  4. Mache die Entwicklungsteams verantwortlich und selbstständig
  5. Teile Teams und fülle sie auf um zu wachsen
  6. Mache Teams produktorientiert statt komponentenorientiert
  7. Starte mit allen Beteiligten an einem Ort und expandiere schrittweise (und nur wenn nötig)
  8. Erwäge die Abspaltung neuer Teilprodukte oder Varianten
  9. Nutze die Vorteile gemeinsamer Plattformen (z.B. von Frontend-Komponenten oder Security)
  10. Skaliere nie zu einem späten Zeitpunkt
  Interessant an dieser Liste: während das meiste die vorbehaltlose Zustimmung der meisten agilen Practitioner finden dürfte sind mit den Tips 5 und 9 zwei durchaus kontrovers zu betrachtende dabei. Nicht dass sie nicht funktionieren könnten, sie bergen aber Risiken in sich derer man sich bewusst sein sollte.

• Shaaron A. Alvares: Tuckman Was Wrong! Doc Norton on Reteaming Models

  Zum Abschluss noch ein Link der zusammen mit dem ersten eine thematische Klammer bildet. Auch das legendäre Tuckman-Modell der Teambildungsphasen (Forming, Storming, Norming, Performing, Adjourning) krankt daran, dass es zu generalistisch, zu wenig auf den jeweiligen Fall eingehend und zu linear ist. Interessant ist insbesondere der Link zu einer Studie mit über 300 Teams, derzufolge nur zwei Prozent von ihnen (!) sequentiell durch die fünf Phasen gingen. Ob die beschriebenen Alternativen der "fluiden Teams" oder des "dynamic Reteamings" besser sind könnte man aber auch diskutieren. Wie so oft: es kommt darauf an.

The New Managerial Contract

Nach diesem Video ist man glatt versucht sich bei Hamza Khan um einen Job zu bewerben, so überzeugend ist er in seinem Vortrag. Dazu die Acherbahnfahrt durch die Management-Geschichte, von der Industrialisierung über Peter Drucker bis Jay-Z und einige minimalistische Slides mit prägnanten Aussagen. So sollten Talks sein.