Es dauerte nicht lange, bis auch darüber diskutiert wurde, ob Dinge, die keine User Stories sind, in ein Product Backlog gehören. Dies ist nicht ungewöhnlich – an der Frage, ob es technische Stories in einem Scrum Product Backlog geben darf scheiden sich bekanntlich die Geister.

Ich schaue mir das Hin- und Her jetzt mehr als 6 Jahre an und ehrlich gesagt – mich langweilt es. Die einen verkaufen den Ansatz “nur Kundenanforderungen im Backlog”, die anderen beharren darauf, dass auch technische Themen explizit im Backlog zu platzieren sind.

Die einen sagen “technische Themen müssen autmatisch miterledigt werden”, die anderen weisen darauf hin, dass dies bei vielen Themen nicht möglich ist.

Die einen leben in einer Welt, in der (fast) alles neu ist, das Team organisatorisch gut aufgestellt und technisch überdurchschnittlich gut ist, die anderen stecken im Sumpf der Mittelmäßigkeit und wissen, dass sie froh darum sein müssen, zumindest durchschnittliche Entwickler zu haben, die an einem durchschnittlich gutem Bestandprodukt arbeiten.

Sind wir einmal ehrlich: Wir alle wissen, dass gewisse technische Themen nicht einfach “mit gemacht” werden können, da dies einen mehr als spürbaren Impact auf die Lieferleistung von Kundenanforderungen hat. Und wer hat ein Interesse an der Lieferleistung? Der Product Owner und die ganzen Stakeholder. Diese müssen wissen was passiert, schon alleine, da wir sonst nicht offen kommunizieren würden, was wir gerade tun (Verstoß gegen den Wert “Offenheit”).

Refactoring vs Redesign

Ich rede jetzt nicht vom einfachen Refactoring, welches im Rahmen einer Story durchgeführt werden kann, sondern von einem Redesign, welches auf Grund der Entscheidungen einer mehrjährigen Produktentwicklung mit einem durchschnittlichen Team irgendwann nötig wird. Interessant hierbei ist auch die Definition von Refactoring und Redesign: Ich verstehe unter Refactoring Arbeit zur Verbesserung der Softwarestruktur, die nicht mehr als 1-2 Tage maximal benötigt. Bei mehr Aufwand ist es kein Refactoring mehr sondern ein Redesign.

Qualität gesetzt?

Da können jetzt alle schreien: “Hey! Nicht sauber gearbeitet! Nicht aufgepasst!”. Aber wisst ihr was? Selbst ein Kernkraftwerk fliegt in die Luft weil es nicht perfekt ist und es zu Fehlern im Detail kommt. Wie soll es da um eine 08/15 Softwarelösung stehen, die unter Kostendruck mehrere Jahre lang entwickelt wurde? Bei der fast keiner der ursprünglichen Entwickler mehr da ist?

Kunde ist nicht der einzige Stakeholder

Für mich bedeutet dies, daß man sich der Realität stellen muss. Nicht nur Kunden haben ein Interesse an den durch das Team erstellen Artefakten. Nein, es sind ganze Heerscharen an Stakeholder. Was hilft es mir beispielsweise, wenn ich Mehrwert für Kunden schaffe, aber interne Reportingvorgaben nicht erfüllen kann?

Budget gestrichen, Produkt tot, alle arbeitslos. Kunden glücklich?

Das Problem mit der USER Story

Die Frage ist natürlich, ob dies eine USER Story ist oder eine andere Art von Backlog Item. Mittlerweile bin ich immer skeptischer, was USER Stories angeht. Folgt man der grundlegenden Idee von User Stories, dann wird man in komplexen Umgebungen Probleme bekommen. Warum? Werfen wir doch einen Blick in das Buch von Frank Wirdemann: “Scrum mit User Stories”. Erst kürzlich erneut versucht zu lesen, es aber nach kurzer Zeit wegen akutem Bluthochdruck wieder zur Seite gelegt. Das Buch ist “old school”, so wie ich Scrum vor 7 Jahren verstanden haben:

• Eine User Story beschreibt keine Details sondern nur den Benutzeraspekt. Details sind böse, böse, böse!
• Spezifikation erfolgt mündlich. Schriftliche Dokumentation ist böse, böse, böse!
• Geschätzt wird in Story Points, die Dauer ist zu vernachlässigen (nicht relevant)
• Man arbeitet mit einer gemittelten Velocity, Schwankungen in der Kapazität (Urlaub etc) werden nicht berücksichtigt (übers Jahr gesehen sind wir ja beim Mittel)

Ja, ich möchte in einem Umfeld arbeiten, in dem diese Ansätze ausreichen, um erfolgreich zu sein. Ich kann jedoch nur jeden warnen, in einem komplexeren Umfeld mit mehreren Stakeholdern, externen Terminen, Budgetplanungen etc. sich komplett auf diese vereinfachte Sichtweise zu verlassen

Ich habe mehr als ein Team gesehen, das “so” in das Verderben geführt wurde. Als Product Owner bin ich dann auch meist gezwungen, harte Kämpfe durchzustehen, um eine Planbarkeit zu bekommen. Die brauche ich, um ausserhalb des Scrum Teams argumentieren zu können. Kann ich dies nicht, dann stehe ich blank da.

Ja, das ist ein Impediment. Ja, daran muss gearbeitet werden. Aber hey, es ist zu just diesem Zeitpunkt eben Realität. Und jetzt einmal unter uns: Das Ignorieren der Realität hilft nur in Ausnahmefällen.

Vorgehensweise

Hierbei hilft es eine Kernaussage (User Story) ganz bewusst in der Nähe des Implementierungshorizontes mit Details zu annotieren. Oft ist es jedoch nicht leicht, herauszufinden, wann welche Details hinzugefügt werden müssen.

Damit wird wir schnell bei einem zentralen Thema in agilen Prozessen: Wie formulieren ich Anforderungen?

Dieses Thema werde ich in einem anderen Artikel – “Lebenszyklus eines Backlog Items” (ich vermeide hier “User Story”) diskutieren.

Ach – wer sich für ein umfassendes Modell von agilen Anforderungen interessiert, dem sei ein Artikel von Dean Leffingwell empfohlen: Updated Agile Requirements Metamodel (Enterprise Backlog Model)

Anmelden via EVENT in XING.

Beginn: 05.10.2011, 20:00
Ort: Restaurant Großer Kurfürst, Sophienstrasse 80, 76135 Karlsruhe

Thema dieses Mal: WorldCafé zum Thema “Unser Product Backlog”.
“Wir erleben täglich Fragen nach Backlogtools, Granularität, Ausrichtung auf PO oder eher auf Teambedürfnisse,… ”

Wichtig: Wer etwas essen möchte, sollte spätestens 19:30 Uhr im Restaurant sein, da für das WorldCafe die Tische gebraucht werden.

Nun, dies ist nicht ganz richtig.

2003 – ERSTE SIG IN KARLSRUHE ZUM THEMA “AGILE”

Bereits ab 2002 waren Themen rund um Agilität (und hier besonders XP) etwas, was meine Interesse wecken konnte. Mitte 2003 habe ich schließlich mit ein paar weiteren “Early Adopters” (u.a. Ilja Preuss, Malte Finsterwalder, Johanness Link, …) eine Special Interest Group in Karlsruhe gegründet: “Methoden der agilen Softwareentwicklung” (KAgile).

Diese Karlsruher Gruppe war eine Zeit lang recht aktiv, es gab einige sehr interessante Treffen zu den unterschiedlichsten Themen rund um “Agile”. Ende 2005 ging aus verschiedenen Gründen die Aktivität zurück und mittlerweile wurde die Gruppe de facto durch die viel später gegründete “SCRUM User Group Karlsruhe” abgelöst.

Als “KAgile” gegründet wurde, war ich noch als Entwickler in einem Portalprojekt (Java Enterprise, Spring, Lucene – ja das konnte ich mal richtig gut) tätig, in dem wir auf eigene Faust (Bottom Up) im Laufe der Jahre 2003 und 2004 zunehmend agile Organisationsmethoden eingesetzt und somit mehr oder weniger das operative IT Projektmanagement übernommen haben. Leider ist es uns nicht gelungen auch die agile Entwicklungsmethoden so konsequent umzusetzen, wie wir uns das vorgenommen hatten. Im Nachhinein etwas, was ich sehr bedaure, da ich später nie mehr so intensiv Software entwickeln konnte wie bis 2005.

AGILISIERUNG

Anfangs 2004 hatte ich den sehr zielführenden Einfall meinen Abteilungsleiter zu überzeugen, dass wir an einer Einführungsveranstaltung zu SCRUM teilnehmen sollten, die zu dieser Zeit durch die Andrena Objects in Zusammenarbeit mit Joseph Pelrine angeboten wurde. Die entscheidenden Kriterien damals waren: GÜNSTIG! KURZ!. Damit war es viel einfacher, “das Management” von dieser Investition zu überzeugen als bei einem Zertifizierungskurs. Die Strategie ging auf – nach dem Seminar wurden unsere Ideen endlich ernst genommen und wir konnten sie zunehmend konsequent in unserem Projekt einsetzen.

Im Nachhinein wurde dieses Projekt von meinem damaligen Abteilungsleiter als eines der bestgeführten Projekte seiner Laufbahn bezeichnet. Transparentes, inkrementelles, iteratives Vorgehen sowie die grundlegenden Werte der agilen Philosophie. Ein schönes und positives Feedback!

Auch meine weiteren beruflichen Stationen waren geprägt von “Agile” und im Speziellen von “SCRUM”. Ich konnte dabei mitwirken agile Methoden einzuführen, sehen wie erste Erfolge gefeiert wurden und wie immer mehr Kollegen die Vorteile eines agilen Vorgehen erkannten. Ich habe aber auch immer wieder erlebt, wie Wunschdenken (auch und gerade bei den neu agilisierten Kollegen/Vorgesetzten) positive Ansätze verwässert und ad absurdum geführt haben. Seit jener Zeit reagiere ich recht empfindlich auf Wunschdenken / “Wishful Thinking”. Der Weg zur Hölle ist gepflastert mit guten Vorsätzen. Ja, das ist wohl wahr.

Auch ist es interessant zu sehen, wie die gleichen Fehler immer wieder gemacht werden. Egal, ob in “Wasserfall” oder in “Agile” verpackt. Jeder neu zertifizierte SCRUM Master (oder neu zertifizierte Projektleiter) erfindet vieles neu, ignoriert gerne den Status Quo und überschätzt im Allgemeinen seinen Einfluss. Schön, wenn ein etwas erfahrener Kollege diesen Willen zur Veränderung auf Themen lenken kann, die konkret angegangen werden können. Strategie der kleinen Schritte – und zusammen mit wirklich erfahrenen Experten dann der große Sprung! Aber man kann das natürlich auch ignorieren und das eigene Team/Projekt schön an die Wand fahren lassen. Für was sind Wände denn sonst da?

Seit 2010 bzw. 2011 (Vollzeit) bin ich als Berater für agile Organisationsformen tätig. Hierbei helfe ich gerne als Sparringspartner das ALTE aber auch das NEUE in Frage zu stellen, um dann gemeinsam gute Lösungswege zu erarbeiten. Eine Aufgabe, die mir viel Spaß macht, da ich meine langjährige Erfahrung einbringen kann, wovon wiederum meine Kunden profitieren.

STATE OF AGILE

Mittlerweile sind agile Methoden weit verbreitet und de facto Standard in der Softwareentwicklung. Allerdings gibt es auch häufiger warnende Stimmen vor einer Verwässerung bzw. vor dem “2. Graben” zwischen Early und Late Majority.

ES GIBT ETWAS ZU FEIERN …

Nun, ich werde 2012 wohl mein persönliches Jubiläum “Zehn Jahre Agile” feiern. Um herauszufinden, wann genau, muss ich wohl noch etwas E-Mail-Archäologie betreiben.

… UND IHR?

Wisst ihr noch, wann ihr AGILISIERT wurdet? Welche Erfahrungen habt ihr auch eurem Weg der “Agilisierung” gemacht? Welche Erfolge und Rückschläge erlebt?

Über ein paar Kommentare würde ich mich freuen!

On Saturday I gave a short lightening talk about “Definition of READY”. I didn’t like my performance on the stage but I got some positive feedback from Oleksiy Rezchykov in his blog post where he recommends my lightening  talk.

Another article with positive feedback for my Lightening Talk can be found at ConfRadar:

Felix Russel did a good job reminding about the “definition of ready” and the time each product owner should spend on preparing stories before the team can actually swarm around them. It was one of the lighting talks during the second day, that I attended.

The slides are available via Slideshare:

I will give a short version of my presentation about "Definition of READY". For more information see the list of lightening talks.

See you in Kiev @ Agile Easter Europe 2011!

Die PDF-Version kann hier herunter geladen werden:

Viel Spaß beim lesen. Über Feedback freue ich mich natürlich!

Meinen nächsten Vortrag mit dem Titel "Traditionelles Projektmanagement und Scrum – Wie Feuer und Wasser?" halte ich auf dem diesjährigen Scrum Day.

Verbreitung der Definition of Ready

Viele Scrum Team kennen die “Definition of Done”, in der definiert wird, in welchem Zustand ein Inkrement den Sprint verlässt. Laut Jeff Sutherland wenden diese jedoch nur ca. 50% aller Teams konsequent an. Die” Definition of Ready” (Definition, in welchem Zustand eine Story den Sprint betritt) ist jedoch deutlich weniger Team bekannt. Nur ca. 1% aller Scrum Teams weltweit wenden eine Defnition von “Fertig für den Sprint” konsequent an.

Die inkonsequente Anwendung ist erstaunlich, da die Definition of Done als auch die Definition of Ready das Potential haben die Produktivität von Teams zu verdoppelt. Jeff Sutherland fasst dies unter dem Begriff “Hyperproductive Scrum Teams” zusammen. Zusammen mit einer echten Selbstorganisation, bietet die konsequente Anwendung von DONE und READY das Potential die Produktivität um den Faktor 4-8 zu erhöhen!

Stichprobe: Definition of Ready in der Community

Eine Stichprobe in der größten Scrum Mailingliste “scrumdevelopment” (Yahoo Group) bestätigt jedoch, dass gerade die Definition of Ready bei weitem nicht so bekannt ist, wie ihre Effekte nahelegen würden:

• „definition of done“: 1001
• „definition of ready“: 6
• „ready state“: 14

Was versteht man unter “READY”?

Vereinfacht ist eine Story bereit für die Implementierung, wenn die Anforderung verständlich beschrieben wurde und folgende Fragen beantwortet werden können:

Warum?

• Zielsetzung / Problemstellung klar,
• Geschäftswert verstanden

Was?

• Gewünschtes Ergebnis verstanden, Akzeptanzkriterien formuliert

Wie?

• Implementierungsstrategie/-konzept bekannt
• Kosten / Größe bekannt

Wichtig: Zuerst WARUM, dann WAS, dann WIE!

Alternative Erklärung

Roman Pichler, hat sich diesem Thema ebenfalls schon in einem Blog-Artikel zugewandt. Aus seiner Sicht muss eine Story folgende Kriterien erfüllen, um “READY” zu sein:

Klar

• Gemeinsames Verständnis was genau gemeint ist

Testbar

• Es gibt klare Entscheidungskriterien, ob etwas erfolgreich umgesetzt ist oder nicht.

Handhabbar

• Größe muss stimmen (nicht zu groß/klein)
• Komplexität muss handhabbar sein
• Unsicherheit, Abhängigkeiten

Eine teamspezifische Definition of READY listet meist detailliertere kontextbezogene Kriterien auf und dient als Quality Gate, um sicherzustellen, dass nur Stories in den Sprint übernommen werden, die wirklich bereit für die Implementierung sind.

Der Weg zu “READY”

Es ist die Aufgabe des Product Owners sicherzustellen, dass Stories bereit für die Implementierung sind, wenn er sie in einem Sprint umgesetzt bekommen soll. Hierzu arbeitet er mit allen Beteiligten eng zusammen, um von groben Ideen zu klaren – “bereiten” – Stories zu kommen. Gerade bei der technischen Analyse ist auch das Team gefragt, frühzeitig Informationen und Feedback zu liefern.

Ein Blick in das Backlog zeigt dann in etwa folgendes Bild:

Etwas genauer betrachtet, erkennt man, wie im Lebenszyklus von Anforderungen immer mehr Details hinzugefügt werden. Die Details sind meist das Ergebnis von Diskussionen und sollten – je nach Kontext – auch schriftlich festgehalten werden. Hierbei kann eine Vorlage oder eine Checkliste sehr hilfreich sein.

Eine solche Checkliste oder ein Template kann jedoch auch gefährlich sein. Wenn zu viel Augenmerk auf das Dokument und zu wenig auf die Diskussion gelegt wird, nähert man sich schnell dem alten Requirement Engineering an und verliert an Agilität.

Die Präsentation zu diesem Thema werde ich in absehbarer Zeit noch veröffentlichen.

„Geschichten vom Scrum“ (Holger Koschek)

Wer Scrum noch nicht kennt und Märchen liebt, dem kann man die „Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten“  von Holger Koschek ans Herz legen.

Im Wieimmerland werden das Großväterchen, Aschenputtel, Hexe, Geist und Ritter Magnolius vom König beauftragt, die „beste und flexibelste Drachenfalle aller Zeiten“ zu bauen. Unterstützt werden Sie dabei vom Prinz (als Scrum Master). Auch wenn es sich um ein altes Königreich handelt, so sind die genutzten Methoden fortschrittlich, weil agil.

Mittels dem Einhorn Bumaraia (Scrum Coach) lernt das Team die wichtigsten Scrum-Artefakte kennen (einen festen Zeitrahmen, gemeinsame Scrum-Meetings und Selbstorganisation). Über den Zeitraum von 7 Sprints (1 Sprint entspricht einem Monat) soll laut König die gewünschte Drachenfalle gebaut werden.

Da es sich um ein praktisches Beispiel handelt, werden die entwickelten Inkremente am Ende des Sprints sogar am lebenden Drachen getestet und die Ergebnisse fließen entsprechend wiederum in die nachfolgenden Backlog Items ein. Das Team arbeitet in einem eingespielten Rhythmus. Um es mit den Worten des Einhorns auszudrücken:

„Eines der Grundprinzipien von Scrum ist die Etablierung eines Taktes, nach dem das Projekt seine Sprints plant und durchführt. Wie in der Musik bildet der Takt die Grundstruktur, auf dem der Rhythmus und die Harmonie aufbauen. […] Einem Orchester fehlte in einer Taktlosen Welt die Grundlage für das gemeinsame Spiel.“

Selbst im Märchen klappt nicht alles reibungslos, so dass neben zwischenmenschlichen Problemen vor allem auf die Schwierigkeiten eingegangen wird, die bei der Einführung von Scrum auftreten können. Als Scrum Master ist unser Prinz hier stark gefordert (z.B. bei der Einhaltung der Zeiten fürs Daily Scrum, bei der Planung der Backlog Items für kommende Sprints).

Das Einhorn Bumaraia gibt weiterführende Informationen zum Thema Scrum (was hat es mit der Definition von „fertig“ auf sich; warum es wichtig ist den Kunden frühzeitig einzubeziehen; wie geht man mit Fehlern um? etc.) und eignet sich damit als Einsteiger-Buch für alle Scrum-Neulinge und alle, die Ihr Wissen über Scrum auffrischen wollen.

Die knapp 230 Seiten „Geschichten vom Scrum“ lesen sich wie im Flug und bleiben aufgrund der Anschaulichkeit der Erzählung länger im Gedächtnis als ein Scrum-Lehrwerk.