Aufruf zu Eireichungen: OOPSLA 2009 Workshops

Veröffentlicht am von

Als Mitglied im Workshop Kommitee der diesjährigen OOPSLA bin ich moralisch schon fast verpflichtet, auch ein wenig die Werbetrommel zu rühren: Wer Interesse hat, für die OOPSLA vom 25. bis 29.10.09 in Orlando, Florida einen Workshop einzureichen, hat noch bis zum 19. März Zeit.

Die OOPSLA Workshops gehören zu den interessantesten Konferenzveranstaltungen, die ich kenne, da dort die Möglichkeit besteht, zu vielen Themen die weltweit führenden Köpfe in einen Raum zu holen und diskutieren zu lassen. In OOPSLA Workshops hat nicht nur die Patternbewegung ihren Ursprung, sondern auch große Teile der agilen Entwicklung.

Weitere Informationen findet man im offiziellen Call for Papers.

Crystal Methodenfamilie in einer Minute

Veröffentlicht am von

Ich wurde kürzlich von Peter Stevens auf der Deutschen Scrum Liste gefragt, wo man Crystal in zehn Minuten nachlesen könne. Ich denke, meine Antwort ist auch für Nicht-Scrummer interessant, deshalb hier noch mal in „voller Schönheit“ mit ein paar zusätzlichen Links.

Gibt es irgendwo ein „Crystal in 10 Minuten“? – Ein google dafür hat nichts nützliches produziert…

Starte vielleicht mal mit http://alistair.cockburn.us/Crystal+light+methods, das dürfte ca. 10 Minuten dauern.

> Oder was ist besonders an Crystal?

Der Kern in drei Sätzen:

  1. Arbeite in kurzen Iterationen
  2. Mache regelmäßig Retrospektiven
  3. Kommuniziere eng

Das ist sozusagen erstmal die Essenz agilen Arbeitens.

Basis sind Alistair Cockburns Überlegungen zur Software Entwicklung als kooperativem Spiel, sowie seine „Feldforschungen“ seit den frühen Neunziger Jahren.

Um das zu unterstützen bietet Crystal sehr viele Praktiken, die sich je nach Kontext einsetzen lassen. Allerdings nicht wie Scrum oder XP (1.0) mit dem Hinweis „So muss man es machen“, sondern mit einem „in dieser Situation haben Teams gute Erfahrung gemacht, jenes zu machen mit folgenden Konsequenzen“. Meines Wissens lassen sich sowohl alle Scrum Praktiken als auch alle XP Praktiken mit Crystal abdecken.

Crystal ist damit viel näher an einer Patternsammlung, als an einem Prozess. Deshalb redet Alistair auch von einer „Methodenfamilie“, bei denen die Methoden nach Kritikalität und Teamgröße zusammen gesetzt werden mit dem Ziel, die „Gerade noch ausreichende Methode“ zu finden. „Crystal Clear“ ist zum Beispiel für Teams bis zu 10 Personen in Projekten, bei denen es nicht um Menschenleben geht. Er deklariert Crystal auch ganz klar als Hilfe für Fortgeschrittene und nicht als Anfängermethode (siehe dazu auch http://alistair.cockburn.us/Shu+Ha+Ri). Sein Ziel ist also nicht unbedingt Minimalismus in der Beschreibung, wie es von Scrum und XP verfolgt wird, sondern Minimalismus im Einsatz.

Crystal bildet damit die Brücke zwischen den agilen „Meta-Methoden“ wie ASD (Jim Highsmith) und Lean Software Development (Mary und Tom Poppendieck) und den eher prozessartig gestalteten Verfahren wie XP und Scrum. Es ist ein Baukasten aus Praktiken mit Regeln, wie sie zusammen gesetzt werden.

Neben Alistair Cockburns Webseite gibt es zwei Bücher von ihm zu dem Thema:

Das Zertifizierungsverfahren ist noch lange nicht so ausgefeilt, wie bei Scrum, es gibt aber immerhin eine handvoll „Certified Crystal Practitioners“, die zu der Ehre gekommen sind, weil Alistair ihre Arbeit gesehen und für gut befunden hat.

Agil und V-Modell XT

Veröffentlicht am von

Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“

Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:

  • Der Auftraggeber ist gesetzlich und per Ausschreibungsrichtlinie gezwungen, das zu verlangen
  • Der Auftraggeber hat sich bewusst für ein hoch-zeremonielles Verfahren wie das V-Modell XT entschieden

In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.

Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.

Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.

Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.

Cutter IT Journal „Exploring the Agile Frontier“ derzeit kostenlos erhältlich

Veröffentlicht am von

Das von mir 2007 herausgegebene Heft des Cutter IT Journal mit dem Titel „Exploring the Agile Frontier“ ist derzeit im Zuge einer Marketinginitiative von Cutter kostenlos erhältlich, statt des üblichen Preises von ca. $40.00. Das Heft sammelt Analysen und Projektberichte aus Bereichen, die üblicherweise als „wenig geeignet“ für agile Verfahren gelten. Es enthält unter anderem:

  • Einen Projektbericht über agiles Arbeiten in weltweit verteilten Teams bei Schlumberger von Lise Hvatum
  • Einen Beitrag über agile Entwicklung bei großen und verteilten Teams von Jutta Eckstein
  • Einen Projektbericht über die agile Entwicklung von Beatmungsgeräten von Klaus Marquardt der nach meinen Informationen nirgendwo anders veröffentlicht ist
  • Einen Projektbericht über agiles Arbeiten bei einer „Wasserfall-Behörde“ von Matt Ganis und Tom Hawkins

Sie finden das Heft, auf der Cutter Homepage unter „Sample Our Research“ oder direkt hier.

Roman Pichler zu Produktvisionen

Veröffentlicht am von

Roman Pichler hat einen schönen Artikel zur Vision geschrieben, die jedem Produkt (und jedem Projekt) zugrunde liegen sollten („The Product Vision„). Für mich waren die fünf Elemente einer guten Vision am wertvollsten, auch wenn sie zum Standard einer guten Produktstrategie gehören:

1. Who is going to buy the product? Who is the target customer?
2. Which customer needs will the product address?
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product?
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
5. What is the target timeframe and budget to develop and launch the product?

Hinzufügen könnte man noch die beiden Fragen, wer das Produkt eigentlich will (und wer nicht!) und was geschehen würde, sollte das Produkt nicht (rechtzeitig) kommen.

Der Schlüssel einer guten Vision ist der richtige Kompromiss zwischen Verständnis und Kürze. Roman verlangt, dass man die Produktvision innerhalb einer Fahrstuhlfahrt erklären können muss — allerdings stammt der „Elevator Pitch“ aus den USA, wo Bürogebäude in der Regel deutlich höher sind, als bei uns… Wichtig ist auch das Verständnis, dass die Vision im Laufe des Projektes reift. Man sollte nicht am Anfang ein halbes Jahr investieren, um die Vision zu erstellen bevor man anfängt zu arbeiten und damit durch die Hintertür den Wasserfall wieder einführen. Kundenfeedback und eigene Erfahrung sind wichtige Bestandteile einer Produktvision und beides bekommt man erst, wenn man schon ein Stück unterwegs ist.

Ich persönlich versuche, die Vision am Anfang eines zwei- bis dreitägigen Kickoff-Workshops erstmals zu fixieren. Das ist zwar häufig nur der allererste Anfang, er stellt aber sicher, dass alle Teammitglieder an ihrer weiteren Ausarbeitung beteiligt sind. Zugegebenermaßen kann man auch deutlich mehr Zeit in eine Vision investieren, ohne gleich dem Wasserfall zu verfallen, doch habe ich die Erfahrung gemacht, dass der Diskussions- und Lernprozess im Team wichtiger ist, als das formale Ergebnis. Und es schadet durchaus nicht, wenn einige Fragen erst im Laufe der ersten Iterationen geklärt werden.

Agile Planung und Vorhersagen

Veröffentlicht am von

Nachdem ich mich in meinem Beitrag „Was ist anders bei agiler Planung“ mit den grundlegenden Mechanismen agiler Planung beschäftigt habe, stellte Maximilian Scherf die Frage, „Wie kann ich denn so beurteilen zu welchem Zeitpunkt ich was fertig haben werde?“ Die Frage ist sehr berechtigt, aber nicht so einfach zu beantworten, so dass ich hier in einem eigenen Eintrag darauf antworten möchte – zumindest grob.

Grundsätzlich muss man sich darüber im klaren sein, dass eine Terminaussage in einem Softwareprojekt die Vorhersage eines chaotischen Systems ist und damit der Wettervorhersage ähnelt (ich rede hier von chaotischen Systemen im Sinne der Theorie komplexer Systeme, nicht aus der Perspektive von Eltern, die in das Kinderzimmer schauen). Chaotische Systeme zeichnen sich dadurch aus, dass ihr Verhalten umso schwerer vorhersagbar ist, je weiter man in die Zukunft schaut: Die Wettervorhersage für die nächsten fünf Minuten bekommt auch der Laie üblicherweise korrekt hin, für den nächsten Tag müssen selbst Profis erheblichen Aufwand treiben und für mehr als eine Woche sind seriöse Vorhersagen derzeit nicht möglich.

Im Projektmanagement sind die planbaren Zeithorizonte zum Glück deutlich länger: Eine Woche ist meist kein Problem, einen Monat bekommt man auch noch ganz gut hin, ab einem Quartal wird es eng. Eine „genaue“ Vorhersage ist daher unmöglich, bei einer „verbindlichen“ Zusage muss man schon relativ vorsichtig sein, was man unter welchen Voraussetzungen verspricht. Erlaubt ein Planungsverfahren nur digitale Aussagen darüber, was „geschafft wird“, ist es also unrealistisch und nur wenig brauchbar. Statt dessen braucht man ein Verfahren, das einem zumindest ungefähre Aussagen zur Wahrscheinlichkeit ermöglicht: „So wie dieses Feature derzeit priorisiert ist, wird es mit 80% Wahrscheinlichkeit im nächsten Release enthalten sein“. Genügen einem diese 80% nicht, muss man es eben höher priorisieren – auf Kosten anderer Features, die dadurch weniger wahrscheinlich werden.

Wie kommt man auf Basis agiler Planung zu einer solchen Aussage? Die Basis sind die Schätzungen und die Erfahrungswerte aus den vorigen Iterationen. Die Grafik unten stammt von einem meiner Kunden, also aus einem real existierenden Projekt. In ihr sieht man die aus der Häufigkeitsverteilung abgeleitete Wahrscheinlichkeit, dass innerhalb einer Iteration mindestens n Aufwandspunkte abgeschlossen werden. Man kann aus dieser Kurve zum Beispiel ablesen, dass in mehr als 50% der Fälle mindestens 21 Punkte abgeschlossen wurden, in mehr als 80% der Fälle mindestens 13 Punkte und so weiter. Mit anderen Worten: Ist eine Aufgabe so hoch priorisiert, dass ihr eigener geschätzter Aufwand und der aller höher priorisierten Aufgaben in Summe weniger als 13 Punkte ausmacht, so wird sie in dieser Iteration mit mindestens 80% abgeschlossen werden. Oder noch anders formuliert: Ich kann Aufgaben für bis zu dreizehn Punkte Aufwand für diese Iteration zusagen, wenn mir 80% Erfüllungswahrscheinlichkeit ausreichen. Brauche ich 90%, sollte ich mich auf 10 Punkte beschränken, mit (fast) 100% erreiche ich 8 Punkte und reichen mir 50% so kann ich munter 21 Punkte „versprechen“. Unabhängig von dem, was man versprochen hat, zeigt diese Grafik aber auch, dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen, auch wenn man ziemlich sicher weiß, dass man das kaum erreichen wird (Die Grafik stammt übrigens aus meinem Vortrag für die OOP 2009).

Verteilung der Velocity

Kann ich für eine gegebene Aufgabe sagen, mit welcher Wahrscheinlichkeit sie innerhalb der nächsten Iteration fertig wird, so kann ich daraus auch längerfristige Vorhersagen ableiten, allerdings erstmal nur unter der — reichlich unrealistischen — Annahme, dass sich die Priorisierung in der Zwischenzeit nicht ändert. In der Regel ist das aber schon mehr als ausreichend, um zum Beispiel den Umfang des nächsten Releases kommunizieren zu können, ohne sich hinterher zu blamieren.

Für längerfristige Vorhersagen wird aber auch eine solche wahrscheinlichkeitsbasierte Technik zu unrealistisch. Hier kann man wieder Anleihen in der Meteorologie nehmen, diesmal in der Klimavorhersage. Dort wird nicht mit einem Modell gearbeitet, sondern es werden verschiedene Szenarien unter verschiedenen Annahmen berechnet, aus denen sich ein Korridor ergibt. Aber das würde jetzt den Umfang eines Blogeintrags endgültig sprengen.

Aufmerksame Leser werden jetzt anmerken, dass ich Maximilian Scherfs Frage eigentlich gar nicht beantwortet habe: Mit diesen Techniken kann man nämlich erstmal nur Vorhersagen darüber treffen, welche Features ich zu einem gegebenen Zeitpunkt wahrscheinlich fertig haben werde, nicht aber, wann ein gegebenes Feature fertig sein wird. Auch wenn der Unterschied subtil ist (und in den meisten Kontexten ohne Bedeutung), reflektiert das eine Grundidee iterativer Entwicklung: Die Termine stehen fest, gedreht wird am Umfang.

Das ist zwar unbequemer, als das übliche „Termine und Umfang stehen fest“, aber dafür erspart man sich das ebenfalls übliche Drehen an der Qualität, um die Zusage einzuhalten. Schlechte Qualität ist schließlich ein Selbst- und Fremdbetrug, der für alle Beteiligten sehr teuer ist. Zwar kann man auch bei agiler Planung darauf bestehen, dass bestimmte Features zu bestimmten Terminen fertig sind, aber eben nicht mehr, als erfahrungsgemäß realistisch sind. Also in unserem Beispiel für nicht mehr als 8 Punkte pro Iteration. Das ist zwar nicht immer bequem für die Verantwortlichen, aber realistisch. Und Management auf Basis unrealistischer Annahmen sollte angesichts der derzeit in der Weltwirtschaft zu besichtigenden Folgen nur noch von wenigen mit „durchsetzungstarkem Management“ verwechselt werden und damit verdienter Maßen und endgültig wieder aus der Mode kommen.

Was ist anders bei agiler Planung?

Veröffentlicht am von

Ein Thema, das meiner Meinung nach oft bei der Ausbildung von Coaches und Scrum Mastern und bei der Einführung von Agilität zu kurz kommt, ist agile Planung. Ich erlebe immer wieder Projektleiter und Scrum Master, die verzweifelt versuchen, ihre Teamplanung in MS Project zu gießen, „weil das hier so gefordert wird“. Das ist in etwa, als würden Sie Spikes unter Ihre Ski montieren, „weil das so gefordert wird“. Machbar, aber sicher keine gute Vorbereitung für außergewöhnlich gute Leistung. Was ist also anders bei agiler Planung?

Um den Eintrag in Grenzen zu halten, möchte ich mich auf die reine Planungstechnik beschränken, also Team- und Kooperationsaspekte außer Acht lassen. Schließlich kann ein Team auch kooperativ Gantt-Diagramme malen, nur es ist eben nicht sonderlich sinnvoll. Warum? Ein wesentlicher Unterschied zu traditioneller Projektplanung ist, dass bei der Agilität nicht die Auslastung der einzelnen „Ressourcen“ (dieser Ausdruck lässt so schön vergessen, dass wir über vernunftbegabte Menschen reden!) optimieren, sondern den Durchflussgeschwindigkeit und Durchsatz von neuen Fähigkeiten des Systems. Wir versuchen also, so viel zusätzliche Wertschöpfung fertig zu stellen, wie in guter Qualität möglich, nicht so viel zu arbeiten, wie möglich.

Schlüssel zu diesem Ziel ist die Erkenntnis, dass in der DV-Entwicklung ja keine Maschinen verplant werden, sondern in der Regel hoch qualifizierte Experten, die durchaus in der Lage sind, sich um ihre eigene Auslastung zu kümmern. Die Planung dient also der Koordination und Fokussierung, nicht der der Arbeitszuweisung. Etwas weniger abstrakt wird festgelegt, was zu tun ist, nicht wer etwas tun soll. Die nächste Person, die frei ist, bzw. das nächste freie Paar kümmert sich dann um die nächste Aufgabe, die ansteht. Das wird üblicherweise als „Pull-Prinzip“ bezeichnet, oft auch (nicht ganz korrekt) als Kanban.

Dieses System hat Vor- und Nachteile. Zum einen ist es wesentlich flexibler, als eine Zuteilungsplanung, die nur dann gut funktioniert, wenn die Bearbeitungsdauer pro „Ressource“ gut vorhergesagt werden kann, aber sehr empfindlich auf Schätzfehler reagiert. Das lässt sich mathematisch mit Hilfe der dabei konstruierten gekoppelten Warteschlangen begründen, die ein chaotisches System darstellen, aber das würde hier zu weit führen. Intuitiv kann das jeder Projektleiter bestätigen, der einmal versucht hat, sein Gantt-Diagramm durchzuhalten oder auch nur aktuell zu halten. Das Pull-Prinzip hingegen reagiert sehr gutmütig auf Schätzfehler und Veränderungen in den Vorgaben, was ebenfalls warteschlangentheoretische Gründe hat.

Der Nachteil ist, dass das Verfahren einen Generalistenansatz im Team benötigt. Teams, in denen jedes Mitglied genaustens seinen „Claim“ abgesteckt hat, in dem nur diese eine Person arbeiten darf („Code Ownership“) bauen trotz Pull-Prinzips genau das gleiche fragile Warteschlangensystem auf, das die Auslastungsplanung schon instabil macht. In der agilen Planung erkennt man diese Situation normalerweise daran, dass an niedrig priorisierten Aufgaben gearbeitet wird, obwohl noch höher priorisierte Aufgaben anstehen, weil „das nur die Eva machen kann“.

Dieser Nachteil ist aber verschmerzbar, weil er ohnehin keine erstrebenswerte Situation darstellt: Wird Eva krank, kann daran das ganze Projekt scheitern. Zudem sind in meiner Erfahrung Kopfmonopole eine der wichtigsten Ursachen für verpasste Termine. Sicherlich wird es immer Aufgaben geben, die Eva effizienter erledigen kann, als Adam. Aber das spielt erst dann eine Rolle, wenn beide auch gleichzeitig anfangen könnten. Bei der Optimierung des Durchsatzes spielt nämlich die Wartezeit auch eine Rolle, anders als bei der Optimierung der Auslastung. Oder, wie Alistair Cockburn formuliert, „Effizienz wird zur Dispositionsmasse abseits des kritischen Pfades“.

Darf man also noch Gantt-Diagramme malen? In seiner Freizeit natürlich. Für ein agiles Projekt spielen sie aber keine Rolle, es gibt keine Entscheidungen, die auf ihnen basieren und sie sind daher Zeitverschwendung. Fortschritt wird mit Hilfe von Burnup bzw. Burndowncharts gemessen und mit lauffähiger Software. Das ist aussagekräftiger, als ein Balken im Gantt-Diagramm, der zu 80% fertig ist, weil 80% der Zeit vergangen sind. Diese Instrumente sind einfacher, effektiver und effizienter, als die beeindruckende Kombinatorik von Ressourcen bei Werkzeugen zur auslastungsbasierten Planung, die von der Realität in der Regel schneller überholt werden, als man sie an der Wand aufhängen kann.