Vortrag auf der Agile World 2013

Das Programm für die Agile World 2013 wurde gestern vorgestellt und mein Vortrag wurde angenommen.

Am 28.06.2013 spreche ich im Track Transformation – Erfahrungen und Konzepte über Agile Softwareentwicklung im Tien Shan.
Der Vortrag dreht sich um interkulturelle Einflüsse bei verteilter Softwareentwicklung und Möglichkeiten, räumliche Distanzen zu überwinden.
Natürlich erkläre ich die Konzepte basierend auf Scrum :-)

Ich freue mich schon sehr auf die Agile World und viele weitere spannende Vorträge.

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Wer immer wieder Projekte sieht, in denen das Chaos regiert, in denen die Projektleitung nur reagiert statt zu steuern, dem sei Mike Cohns Agile Estimating and Planning ans Herz gelegt.
Ein Buch, das dem Leser eine neue Perspektive darauf gibt, wie Projekte funktionieren können, wenn man nur endlich beginnt, Projekte und ihre Plannung besser zu verstehen.
Das Buch macht einem Lust darauf, Projekte nur noch agil zu planen. Zwar merkt man Cohns deutliche Vorliebe für User Stories und Scrum, aber die Ideen und Konzepte aus diesem Buch sind auch Problemlos mit anderen Methoden des Requirement Engineering oder agilen Vorgehensweisen kompatibel.
Zum Einstieg erfährt der Leser, warum Planung notwendig ist und warum sie so oft daneben liegt. Aus den Gründen für letzteres leitet Cohn ab, dass Planung eigentlich nur agil funktionieren kann – eine Erkenntnis der man unweigerlich zustimmen muss, wenn man neben der agilen auch die Welt des V-Modells kennt.
Im zweitel Teil des Buches nimmt Cohn dem Leser die Angst, zu schätzen. Es wird klar, dass Schätzen inhärenter Bestandteil von Planung ist und die einzige Möglichkeit, besser zu planen, darin besteht, besser zu schätzen. Dazu muss man mit dem Schätzen allerdings erst einmal beginnen. Mit echtem Schätzen, versteht sich. Cohn erklärt, wie man im Team schätzen kann, wann man neu schätzen muss und wann Story Points oder Ideal Days die bessere Grundlage sind.
Der dritte Teil des Buches geht auf die Fragen ein, anhand welcher Werte man priorisieren sollte. Steht das Budget im Vordergrund? Oder eher die Funktionalität? Man erfährt, wie man beides gewichten kann und den Kunden zufrieden stellt. Zum Abschluss des dritten Teils erfährt der Leser noch einiges wichtige über das Splitten von Stories, wie man anhand von Datenstrukturen, Geschäftsprozessen oder Cross-Cutting-Concerns splittet um ein Projekt beherrschbar – und damit planbar – zu machen.
Wie man einen agilen Plan mit einer Zeitplanung versieht, wird im vierten Teil des Buches erklärt. Ausgehend vom Release-Plan geht es zum Plan für Iterationen, entweder basierend auf der Velocity oder basierend auf Commitments. Auch die Unterschiede zwischen Release- und Iterationsplan werden erklärt. Interessant ist auch das Thema Schätzen der Verlocity und wie man in agilen Plänen mit Puffern umgeht. Ein kurzes Kapitel widment sich der Frage, wie man agile Pläne für Projekte mit mehr als einem Team aufstellen kann.
Da auch in agilen Projekten gefragt wird, wie weit das Projekt den voran gekommen ist, erklärt Cohn im fünften Teil des Buches, wie man Release- und Iterationsplänge beobachten kann und Maßnahmen ableitet. Es wird auch darauf eingegangen, wie man über und mit agilen Plänen kommuniziert.
Die beiden letzten Teile widmen sich zum einen der Frage, warum agile Planung funktioniert und einer Fallsstudie zum Thema agile Planung.
Fazit: Agile Estimating and Planning ist die konsequente Fortsetzung von User Stories Applied. Wer Projekte plant, egal ob agil oder klassisch, für den ist dieses Buch ein Muss.

Mike Cohn: User Stories Applied

Mike Cohn; User Stories Applied

Mike Cohn; User Stories Applied

User Stories Applied ist nach wie vor das Standard-Werk, wenn es um das Erstellen, Verwalten und Schätzen von User Stories geht. Mike Cohns Buch ist für Anfänger, die gerade beginnen, sich mit User Stories zu beschäftigen, ebenso gut geeignet wie als Inspriration für alte Hasen.

Im ersten, einführenden Teil erklärt der Cohn, was User Stories und Akzeptanztests eigentlich sind. Dabei erklärt er das Schreiben von Stories anhand des INVEST Paradigmas von Bill Wake. Wichtig fand ich das Kapitel 3 über die Benutzerrollen, denn das ist in meinen Augen der ideale Einstieg in einen Story-Workshop. Der Story-Workshop wird in Kapitel 4 als eine Möglichkeit vorgestellt, zu Ideen für User Stories zu kommen. Andere beschriebene Alternativen sind Fragebögen, Interviews und Beobachten von Benutzern.
In Kapitel 5 erklärt Cohn, welche Rollen als User Proxy zum Einsatz kommen können und welche Stärken und Schwächen diesen Rollen anhaften. Ein wichtiges Kapitel, denn leider gibt es zu häufig keinen Kontakt zwischen den Entwicklungsteams und den Nutzern.
Wie man Akzeptanztests für die User Stories erstellt, wie viele man benötigt und was sie beinhalten sollten wird im darauf folgenden Kapitel erklärt. Beendet wird der erste Teil des Buches einem Kapitel, das zusammenfasst, wie man gute User Stories schreibt. Man sollte mit klaren Zielen anfangen, große Stories aufteilen, das User Interface erst sehr spät beschreiben und noch einiges mehr.

Der zweite Teil des Buches beschäftigt sich mit Fragen rund um das Planen mit und das Schätzen von Stories.
Zunächst geht Mike Cohn auf die Idee der Story Points ein. Er erklärt, warum es wichtig ist, dass das Team die User Stories gemeinsam schätzt. In Kapitel 9 wird erklärt, wie man ein Release mit User Stories plant. Kapitel 10 macht deutlich, wie die Arbeit mit User Stories in Interationen erfolgen kann (z.B. Sprints in Scrum).
Zum Abschluß des zweiten Teils erklärt Cohn noch, wie die Velocity gemessen werden kann, wie sie bei der Planung hilft und wozu Burn Down Charts eingesetzt werden können.

Alle Themen, die nicht in die beiden ersten Teile passen, aber wichtig sind, werden im dritten Teil “Frequently Discusses Topics” besprochen. Das erste dieser Themen ist in Kapitel 12 die Frage, was User Stories nicht sind, gefolgt von einem Kapitel zur Frage, warum man User Stories benutzen sollte. Kapitel 14 stellt einige Story Smells vor, die leider immer wieder passieren und in Kapitel 15 geht Cohn kurz auf das “Dream-Team” User Stories mit Scrum ein. Abgeschlossen wird der dritte Teil mit verschiedenen Randthemen wie der Frage, nach den Zusammenhängen von Bugs und User Stories aus Anforderungs- und Planungssicht.

Das Buch wird durch einen vierten Teil abgerundet, in dem in mehreren Kapiteln ein Beispiel durchgesprochen wird. Dieser Teil ist im Wesentlichen für Einsteiger interessant, die Orientierung für das Handwerk benötigen.

Wie eigentlich alles, was Mike Cohn schreibt, kann ich auch dieses Buch wärmstens empfehlen.

Das I in INVEST – wie unabhängig können User Stories sein?

Heute hatte ich eine sehr spannende Diskussion. Es ging um das INVEST-Paradigma für User Stories, speziell um das I in INVEST. Das I steht für independent, also unabhängig.
Gute Stories sollen genau das sein: unabhängig.

Während der Diskussion ist mir bewusst geworden, dass das I in INVEST mindestens ebenso häufig falsch interpretiert wird, wie das zweite Wertepaar im Agilen Manifest.

Unabhängigkeit bei User Stories kann nämlich als die Möglichkeit einer beliebigen Reihenfolge verstanden werden. Wenn sich dieses Verständnis für Unabhängigkeit festgesetzt hat, führt das häufig zu künstlich unabhängigen oder zu großen User Stories und langwierigen Diskussionen über die Qualität der User Stories.
Künstliche Unabhängigkeit versucht um jeden Preis zu vermeiden, dass eine Story A implementiert sein muss, bevor eine Story B umgesetzt werden kann. Damit einher gehen häufig ziemlich schräge Akzeptanzkriterien oder es gibt eine Story-Explosion, weil versucht wird, so lange gemeinsame Teilaspekte aus den beiden Stories heraus zu splitten, bis die Abhängigkeit aufgelöst ist. Was aber nie passieren wird, Abhängigkeiten lassen sich manchmal vielleicht verstecken, aber nicht eliminieren.
Die zweite Variante, die ich beobachtet habe, führt dazu, dass Story B, die von Story A abhängt eben zu einer Story AB zusammengefasst werden. Die Story Points werden schnell addiert und man ist fein raus – glaubt man.
Meistens passt die Story dann nicht mehr in einen Sprint oder man erkennt erst, nach der Umsetzung von A und B, dass B überflüssig war. Bei zwei einzelnen Stories wäre diese Erkenntnis billiger zu haben gewesen.

Ich bin der Überzeugung, dass es völlig OK ist, wenn eine Story die Erledigung einer anderen Story voraussetzt. Insbesondere große und komplexe Systeme lassen sich gar nicht anders aufbauen. Die Unabhängigkeit von User Stories bedeutet eben gerade nicht, dass sie in beliebiger Reihenfolge realisiert werden können. Vielmehr bedeutet die Unabhängigkeit von User Stories, dass der Product Owner die Möglichkeit hat, im aktuellen Sprint das in Story A beschriebene Feature von einem Team realisieren zu lassen, ohne dass das von Story B beschriebene Feature auch realisiert werden muss. Story B kann zu einem beliebigen späteren Zeitpunkt von einem anderen Team realisiert werden. Genau das ist die Unabhängigkeit, die mit User Stories erreicht werden soll und die sowohl den Teams als auch dem Product Owner nützt.
Dazu ist es natürlich notwendig, dass die Story A in sich abgeschlossen ist. Hier spielen das T (Testable) und das V (Valuable) in INVEST mit der Unabhängigkeit zusammen. Insofern muss es in jedem größeren System Stories geben, die Vorbedingung für andere Stories sind.
Die Unabhängigkeit bezieht sich auf die Entscheidungsfreiheit des Product Owner, Features neu einzuplanen und neu zu priorisieren – nicht auf die notwendige technische Reihenfolge.

User Story Pattern: Teile und Herrsche

In meinem zweiten Artikel zum Thema Story Pattern möchte ich auf ein Problem eingehen, das mir vor kurzem bei einem Kunden begegnet ist.

Es gibt eine große Menge von auf den ersten Blick eher klein erscheinenden Änderungen an meinem Produkt, die bis zu einem bestimmten Zeitpunkt, z.B. einem Messeauftritt, fertig gestellt sein müssen. Die Liste der Änderungen kommt zu mir als Product Owner in Form einer Excel-Tabelle oder einer Powerpoint-Präsentation. Mit der Qualität der Beschreibungen können sowohl mein Team als auch ich gut leben. Wir wissen aber alle, dass die Menge der Änderungen zu groß ist, als dass sie bis zum gesetzten Termin umgesetzt werden können.
Weiterlesen

New, In Progress, Done – mehr nicht?

Ein Scrum Board kennt drei Zustände für Aufgaben, die im Sprint ausgeführt werden müssen. Nach dem Sprint Planning sind alle Aufgaben im Zustand „New“. Die so überschriebene Spalte des Scrum Boards repräsentiert das Sprint Backlog. Von links nach rechts sind die Aufgaben themenweise gruppiert und von oben nach unten sind die Themen priorisiert.
Sobald jemand eine Aufgabe beginnt, wandert diese Aufgabe in den Zustand „In Progress“. Ein guter Zeitpunkt um das zu machen ist das Daily Standup Meeting, aber natürlich kann man auch zu anderen Zeiten Aufgaben beginnen. Das Daily dient nur dazu, das Team zu informieren, was man an einem Tag alles tun möchte. „In Progress“ ist die Aufgabe erst, wenn man sie wirklich beginnt.
Den letzten Zustand „Done“ erreicht eine Aufgabe erst, wenn sie komplett abgeschlossen ist. Aufgaben von „In Progress“ nach „Done“ zu verschieben ist ebenfalls etwas, das im Daily Standup passieren sollte. Während es zumeist kein Problem ist, außerhalb des Daily Standup eine Aufgabe „In Progress“ zu nehmen, kann man mit dem Zustandswechsel auf „Done“ eigentlich problemlos bis zum nächsten Daily Standup warten.
Weiterlesen

User Story Pattern: Teilen nach Schnittstellen

Dass User Stories dem INVEST-Prinzip genügen sollen, ist keine Neuigkeit und leicht zu verstehen. Wie man es in der Praxis erreichen kann, dass Stories diesen Prinzipien entsprechen, ist schon schwieriger. Sucht man bei Google nach Pattern für Story Schnitt findet man eine ganze Reihe von Ideen und Empfehlungen.
Ich möchte in einigen kurzen Artikeln einige Pattern vorstellen, die mir in Projekten begegnet sind – oder die ich mir gewünscht hätte :-)

Beginnen möchte ich mit dem Pattern Teilen nach Schnittstellen (Split along interfaces).

Eine Änderung im System bedingt, dass eine Reihe von Schnittstellen, z.B. Web Services, angepasst werden müssen. Das kann z.B. bei Anpassungen am Datenmodell der Fall sein, wenn die gleichen Daten von verschiedenen Web Services für unterschiedliche Kontexte oder Anwendungsfälle benutzt werden.

Hier würde ich für jede Schnittstelle immer eine separate Story erstellen. Das wirkt vielleicht zunächst sehr aufwändig, weil vielleicht jede Story die gleiche Änderung beschreibt. Tatsächlich vereinfacht es aber meine Aufgaben als Product Owner.

Der Vorteil einer Story pro Schnittstelle liegt darin, dass ich als Product Owner die Möglichkeit habe, zu priorisieren. Habe ich nur ein Entwicklungsteam, kann ich entscheiden, welche Schnittstellen am wichtigsten sind und die Stories in eine entsprechende Reihenfolge zu bringen. Habe ich mehr als ein Team zur Verfügung kann ich bei getrennten Stories eine höhere Parallelisierung erreichen.

Ein gutes Schnittstellen-Design vorausgesetzt, sind sämtliche Stories isoliert voneinander testbar. Neben der Priorisierung schafft dieses Pattern auch Transparenz für mich als Product Owner. Ich kann jederzeit erkennen, wie weit mein Team mit den Änderungen fortgeschritten ist.

Schätzungen im Sprint-Planning

Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.

Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.
Weiterlesen

Burndown Charts im Sprint?

Diese Woche habe ich mich mit einem Kunden über den Nutzen von Burndown Charts zum Messen des Fortschritts eines Sprints unterhalten. Die Diskussion war sehr interessant, daher möchte ich die Essenz daraus in diesem Artikel teilen.

Ausgangspunkt war dass in einem Scrum-Projekt gemessen werden sollte, ob das Sprint-Ziel in Gefahr ist. Die altbekannte These “Was ich nicht messen kann, kann ich auch nicht managen” war dabei die Leitidee. Diese Leitidee teile ich im Prinzip. Einen Burndown Chart während eines Sprints halte ich aber nicht für hilfreich, insbesondere nicht, um eine Gefährdung des Sprint-Zieles abzulesen.

Warum nicht?

Messen kann man in Scrum, ob eine Story fertig ist. Fertig ist sie, wenn sie der Definition of Done genügt und der Product Owner sie sich in einem Review angeschaut und akzeptiert hat. Der Review durch den Product Owner erfolgt üblicherweise im Sprint Review am Ende eines Sprints. Natürlich könnte man das auch während des Sprints machen, aber im Sprint soll das Team möglichst ungestört arbeiten.
Das Sprint-Ziel ist erreicht, wenn alle Stories, auf die sich das Team committed hat, am Ende des Sprints der Definition of Done genügen und vom Product Owner akzeptiert sind.
Weiterlesen

Was zwischen Planning I und Planning II passiert

Die meisten Teams, denen ich bisher begegnet bin, teilen das Sprint Planning in einen ersten und einen zweiten Teil. Im ersten Teil stellt der Product Owner die Items aus dem Backlog vor, die im den nächsten Sprint entwickelt werden sollen. Das Team hat die Möglichkeit fachliche Fragen zu stellen und der Product Owner antwortet. Im Planning II zerlegt das Team die Stories in Tasks. So weit, so gut.

Die fachlichen Fragen des Teams hat der Product Owner im Planning I beantwortet. Aber was ist mit den technischen Fragen? Über diese stolpern die meisten Teams während des Planning II. Oft passiert es dann, dass sich einzelne Teammitglieder vor ihren Computer setzen und in den Tiefen des Quellcodes abtauchen – nur, um dann für den gesamten Rest des Plannings nicht mehr aufzutauchen. Das ist ärgerlich für den Rest des Teams.

Manche Teams lösen das über ein Pre-Planning der Stories im Sprint davor. Allerdings das Pre-Planning zu verschwendeter Zeit führen, nämlich dann, wenn Stories doch nicht in den nächsten Sprint kommen.

Um diese Situationen zu vermeiden, habe ich mit meinen Teams eine Phase zwischen Planning I und Planning II eingeführt.
Weiterlesen