On Lean and Agility

Zu den wichtigsten Praktiken des Extreme Programming gehört der Einsatz von Metaphern, mit deren Hilfe man komplexe Sachverhalte einfach erklären kann. Zu den prominenteren Beispielen der letzten Zeit gehören dabei the Desert and the Forest von Kent Beck und Beth Andres-Beck. Der Wald (Forest) steht dabei für eine Umgebung, in der moderne Software-Entwicklungspraktiken möglich sind, während sie in der Wüste (Desert) nicht angewandt werden können. In diesem Konferenz-Vortrag erklären sie, was sich hinter diesen Metaphern verbirgt.

Erwähnenswert ist dabei ihre Einordnung ihres Konzepts in die Realitäten der Softwareentwicklung in vielen Firmen. Die Wüste gilt bei ihnen nicht als etwas per se Schlechtes, sondern als etwas was historisch gewachsen ist, durchaus Ergebnisse bringen kann (wenn auch relativ langsam) und durch die richtigen Entscheidungen nach und nach zu einem Wald werden kann.

Zu den (wenigen) Kritikpunkten an Extreme Programming (XP) gehört, dass es seit ca. dem Jahr 2000 nicht mehr weiterentwickelt wurde. Diese Einschätzung ist allerdings falsch - wie XP-Erfinder Kent Beck in diesem Interview erklärt, gibt es mittlerweile mindestens einen neuen Bestandteil: TCR (mit dieser Abkürzung wurde der etwas sperrige ursprüngliche Name test && commit || revert ersetzt). Verkürzt gesagt: neu geschriebener Code wird in kleinsten Mengen sofort nach dem Schreiben durch einen vordefinierten Test geprüft - und bei fehlgeschlagenem Test automatisch gelöscht, so dass man neu beginnen muss. Extreme Programming, aber noch ein bisschen extremer als bisher.

Das Interview umfasst ausserdem noch verschiedene weitere Themen. Wer ein bisschen Zeit hat und sich auch zu denen informieren will, kann das auf der Website zum Interview tun, wo es nicht nur das Transkript gibt, sondern in ihm eingebettet weitere Videos, die das jeweilige Thema vertiefen.

Bild: Wikimedia Commons / Rainer Flassig - CC BY-SA 2.0

Stellen wir uns folgende Situation vor: ein Product Owner (oder ein Mensch in vergleichbarer Rolle) kommt zu seinem Team. Er stellt ihm die neueste User Story vor, die auch von allen sofort verstanden wird. Als es dazu kommt eine Aufwandsschätzung abzugeben sind die Entwickler aber ratlos - die Umsetzung müsste in einer Technologie oder in einem System erfolgen mit denen sie noch nie gearbeitet haben. Ohne diese Erfahrungswerte können sie den Aufwand nur raten.

Im klassischen Projektmanagement würde man versuchen dieses Problem zu lösen inden man einem team-externen Experten die Aufwandsschätzung überlässt, z.B. einem Architekten, Lead Developer oder Business Analysten. In einem agilen Vorgehen wäre das aber keine gute Lösung, schliesslich soll die Aufwandsschätzung hier nach Möglichkeit von den Mitgliedern des umsetzenden Teams selbst kommen.¹ Wie versetzt man die also in die Lage das zu tun?

Eine Lösung dafür kommt aus dem Extreme Programming, dem Framework dem wir auch die User Story verdanken, und nennt sich Spike Solution (oft abgekürzt zu Spike). Sie besteht in Abgrenzung zur Perfect Solution oder Possible Solution, bei denen zumindest grundlegend klar ist wie gross der Aufwand ist und die direkt neue Funtionen erzeugen sollen.² Die Spike Solution soll das nicht, ihr Ziel ist es lediglich, die Entwickler mit der Technik vertraut zu machen.

But what if you haven't done anything like this story before? What if it's the beginning of the project and you haven't done anything at all? The answer is simple: do some experimenting. We call such an experiment a "Spike Solution" to remind us that the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out. You need to know how long it will take you to do something.

Ron Jeffries and Chet Hendrickson, Extreme Programming Installed, S.55

Was Ron Jeffries und Chet Hendrickson, zwei der drei Erfinder von Extreme Programming, hier sagen streicht die entscheidenden Punkte heraus: wenn die Erfahrungswerte für eine Aufwandsschätzung zu gering sind können diese dadurch hergestellt werden, dass so lange Experimente mit der Anwendung durchgeführt werden bis die Vertrautheit gross genug für eine Schätzung ist. Um möglichst schnell an diesen Punkt zu kommen sollten diese Experimente, bzw. Spikes, möglichst klein sein.

In dem Buch aus dem sein Zitat stammt nennen die beiden auch Beispiele dafür. Eines besteht darin einem System einfache Rechenoperationen hinzuzufügen, ein anderes in der Änderung der Formatierung einer Zahl. Derartige Experimente sind in wkurzer Zeit abschliessbar, geben dem der sie durchführt aber trotzdem ein Gefühl davon wie aufwändig die Arbeit in diesem System ist. Falls das noch nicht reicht kann ein zweites oder drittes folgen, bis ein Grundverständnis da ist.

Wichtig ist dabei, dass der im Rahmen der Spikes erzeugte Code im Anschluss nicht weiterverwendet wird und stattdessen gelöscht werden kann. Nur so kann sichergestellt werden, dass nicht versehentlich etwas beschädigt wird und dass das Experiment dort stattfinden kann wo die Unklarheit am grössten ist. Den bereits erzeugten Code irgendwie weiterverwenden zu wollen ist zwar ein verständlicher Reflex, allerdings ist davon aus den genannten Gründen abzuraten.

Soviel zu den Warum und Wie einer Spike Solution, es bleibt aber noch eine Frage - warum eigentlich der Name? Er leitet sich ab von einem einfachen Stech-Werkzeug mit dem Löcher gebohrt werden können. In Analogie dazu ist es durch den Spike möglich in die "Black Box" des unbekannten Systems Löcher zu bohren, wodurch Licht in das Innere fällt, das dadurch sichtbar und begreifbar wird.

Als Fan des Extreme Programming (XP) freut es mich jedesmal wieder wenn dieses Framework öffentlichkeitswirksam in den Mittelpunkt gerückt wird, gerade auch deshalb weil das mittlerweile nur noch relativ selten passiert. Den Vortrag "Putting the XP in Scrum" von Roy Osherove kann ich daher nur empfehlen.

Interessant ist bei seinen Ausführungen die Einordnung. Für ihn besteht agile Softwareentwicklung aus zwei Elementen: dem aus Scrum abgeleiteten iterativ-incrementellen Prozess und der aus DevOps übernommenen Nutzung automatisierter Build-Pipelines. Da Extreme Programming sowohl einen mit Scrum kompatiblen Prozess-Anteil als auch mit DevOps verwandte Entwicklungspraktiken hat ist es für Osherove der "missing Link", der die beiden anderen Ansätze miteinander verbindet.

Bild: Wikimedia Commons / Lisamarie Babik - CC BY 2.0

Bei der heutigen "Monokultur" von Scrum, Kanban und SAFe mag man es kaum noch glauben, aber gab eine Zeit, zu der keines dieser drei das dominierende agile Framework war. Um das Jahr 2000, also zu der Zeit als das agile Manifest geschrieben wurde, war ein anderes das bekannteste: Extreme Programming (XP). Damals noch so bekannt, dass es in den Dilbert-Comics veralbert wurde, sank es später zu einem nur noch schwach erinnerten Mythos herab. Höchste Zeit ihn hervorzuholen und zu entstauben.

Ein Sprung zurück in der Zeit: 1996 befindet sich beim amerikanischen Chrysler-Konzern ein IT-Projekt der Lohnbuchhaltung in der Krise, drei Jahre nach Beginn der Software-Entwicklung konnte noch kein einziges Gehalt mit dem neuen System ausgezahlt werden. Die Probleme sind dieselben die sich bis heute in IT-Grossprojekten finden - die Integration von Entwicklungs-Branches führt zu schwerwiegenden Merge-Konflikten, Tests, Bugfixes und Releases erzeugen massive Aufwände, die Kommunikation zwischen Fachabteilungen und Entwicklern ist voller Missverständnisse und Konflikte.

Neu zum Projekt gestossene Projektmanager und Entwickler untersuchen die Ursachen und finden ein Muster - da alle der gerade genannten Tätigkeiten für die Beteiligten anstrengend und unerfreulich sind, werden sie so lange wie möglich aufgeschoben. Bedingt dadurch wachsen sie zu riesigen Arbeitspaketen heran, die zum Zeitpunkt ihrer Umsetzung zum Teil bereits veraltet sind und durch ihre Grösse, Unübersichtlichkeit und Vernetztheit selbst zu ernsthaften Fehlerquellen werden.

Die gemeinsam erarbeitete Lösung für dieses Problem ist das Durchführen dieser Tätigkeiten in immer kürzeren Abständen und immer kleineren Umfängen. Die Idee dahinter: kleine Arbeitspakete sind übersichtlicher, weniger in sich vernetzt und werden bei Fehlern tendenziell kleinere Bugs erzeugen, kurze Abstände sorgen für häufige Wiederholung und damit auch für mehr Übung, für engere Zusammenarbeit, intensivere Kommunikation und als Folge dessen für weniger Missverständnisse.

Wichtig für das Verständnis dieser Entstehungsgeschichte ist, dass in all dem wenig Neues steckte. Code Reviews, Merges, Tests, Releases und Kommunikation mit Kunden und Auftraggebern gibt es, seitdem Software entwickelt wird. Das Ungewöhnliche war die aus damaliger Sicht unglaubliche Beschleunigung. Aus einmal pro Quartal oder pro Jahr wurde mehrmals pro Woche oder sogar pro Tag. Diese extreme Häufigkeit gab dem Ganzen ihren Namen: Extreme Programming.

Die einzelnen Praktiken von XP sind vor diesem Hintergrund zu verstehen: Pair Progamming ist die extrem intensive Zusammenarbeit von zwei Entwicklern, Unit Tests sind extrem kleine Validierungen von Funktionalität. Iterationen (ein- bis dreiwöchige Zeiträume) sind extrem kurze Lieferzyklen, Refactorings sind extrem häufige Überarbeitungen der Codebasis, etc. Dass sie für XP nötig sind, ist offensichtlich, und dass sie so zentral sind macht es zu einem der IT-spezifischsten unter den agilen Frameworks.

Vermutlich ist dieser sehr starke IT-Bezug auch einer der Gründe dafür, dass Extreme Programming der ganz grosse Durchbruch verwehrt geblieben ist. Bereits die "sichtbaren Praktiken" wie Pairing und Reviewing sind in Berater- und Management-Präsentationen nur schwer zu vermitteln, auf "unsichtbare Praktiken" wie Test First und Refactoring trifft das um so mehr zu. Und selbst wenn sie verstanden werden, ist ihre Einführung ungleich schwerer als die neuer Rollen und Meetings.

Aus diesen Umständen ergibt sich auch ein fast schon tragisches Phänomen: das was von XP in andere Frameworks übernommen wurde, ist in der Regel nicht der IT-spezifische Kernbereich, sondern es sind die im Vergleich weniger wichtigen Prozess-Elemente. Das heisst nicht, dass diese (v.a. User Stories, Story Points, Planning Poker und Onsite Customer) nicht gut und richtig wären, aber dass vor allen sie in Scrum und SAFe integriert wurden, vermittelt ein schiefes Gesamtbild ihres Ursprungs.

Noch einmal anders gesehen kann man aber auch Positives daran finden, dass Extreme Programming aus dem Scheinwerferlicht verschwunden ist. Da aus Softwareentwicklungssicht kaum ein anderes Framework so passend zur IT ist, kann man seinen Bekanntheitsgrad als Indikator dafür benutzen, ob und wie vertieft sich ein Entwicklungsteam mit dem Thema Agilität auseinandergesetzt hat. Wenn XP dort ein Begriff (oder sogar in Anwendung) ist, kann man als Agile Coach direkt zu den fortgeschrittenen Themen springen und kann auf Grundlagenarbeit verzichten.

Quelle: Twitter