Scrum oder die Kunst, mit Komplexität umzugehen

Ameisen und Software

Was haben Ameisenkolonien mit Scrum-Teams gemeinsam? Ameisenkolonien sind hochproduktiv, selbstorganisiert und cross-funktional: 50% beschaffen Nahrung, 25% bewachen die Kolonie, und 25% entfernen Dreck. Jede Ameise kann jede Aufgabe machen. Es gibt keine zentrale Vorgabe oder Planung, aus der die Ameisen ihre Aufgaben ablesen könnten. Sie erkennen anhand von chemischen Botenstoffen, was ihre Kollegen im unmittelbaren Umfeld machen - und passen sich entsprechend an. Gibt es schon genug Nahrungsbeschaffer, kann eine solche Ameise zum Wächter umsatteln.Es gibt noch mehr Parallelen: Ameisenkolonien sind komplexe Systeme, weil ihre Struktur nicht in Form von Ursache-Wirkung oder Vorgabe-Umsetzung verstanden werden kann. Sie entsteht vielmehr durch die Aggregation von vielen einzelnen, individuell getroffenen Entscheidungen (wer sich in die Ameisenwelt vertiefen will: hier eine sehr spannende Dokumentation).http://www.youtube.com/watch?v=z3qz84yqwds&feature=youtu.beSoftwareentwicklung ist ebenfalls komplex. Stellt ein Expertengremium zusammen, bestehend aus den besten Entwicklern, Testern und Fachleuten der Welt. Sperrt das Gremium drei Monate ein mit der Aufgabe, eine detaillierte Bauanleitung für ein mäßig anspruchsvolles Softwareprodukt zu entwerfen. Ich bin überzeugt: Die Experten würden grandios scheitern.Denn jede kleine Veränderung im technischen Entwicklungsprozess, jede minimale Abweichung von den fachlichen Anforderungen, jede noch so geringe Modifikation in den rechtlichen Rahmenbedingungen, kann eine Lawine an Veränderungen lostreten.Vor einem halben Jahr genau so erlebt: Das Entwicklungsteam versteht eine User Story ein wenig anders als vom Product Owner gewollt, setzt sie folglich mit Abweichungen um, stößt dabei auf einen bis dahin unbekannten Fehler in einer Kalenderfunktion, und entdeckt im Zuge des darauf folgenden Bugfixing eine neue Implementationsmöglichkeit für Timestamps, die auch fachlich höchst interessant ist, weil sie für den Kunden mehr Komfort bei der Bearbeitung von Personalfällen bietet. In der Folge wird das Product Backlog in wesentlichen Zügen umgeschrieben, um von dieser neu entdeckten Möglichkeit Gebrauch zu machen.Übrigens muss nicht alles, was schwierig zu verstehen ist, deshalb auch gleich komplex sein. Ein mechanisches Uhrwerk mit ewigem Kalender ist ein hochkompliziertes Gebilde - es braucht jede Menge Wissen, um seine Funktionsweise zu verstehen. Haben wir jedoch das Wissen, können wir das Verhalten des Uhrwerks und seiner Teile durch Beschreibung von Ursache-Wirkung sehr genau vorhersagen und eine taugliche, reproduzierbare Bauanleitung schreiben.

Planung ade?

Die Erkenntnis, dass es für Softwareprodukte keine solche Schritt-für-Schritt-Bauanleitung geben kann, wird bisweilen als Vorwand für eine "anything goes"-Philosophie verwendet. Dort heißt es dann, planmäßiges Arbeiten mache keinen Sinn, weil wir eben keinerlei Gewissheiten mehr haben. Das aber ist ein Trugschluss. Wenn ich keine sicheren Voraussagen machen kann, heißt das noch lange nicht, dass ich im Dunkeln tappe. Es bedeutet nur, dass meine Annahmen oder Hypothesen mit einer (nicht unbeträchtlichen) Wahrscheinlichkeit falsch sein können.Wie ist damit umzugehen? Indem Hypothesen so konstruiert werden, dass sie sich in möglichst kurzen Zeitintervallen durch die Praxis verifizieren und validieren lassen. Und indem wir dazu bereit sind, unsere Annahmen über Bord zu werfen, sobald sie sich als unhaltbar erweisen. In Scrum nennen wir solche Annahmen User Stories. Wir gehen davon aus, dass der Nutzer des Produktes eine Funktionalität haben will, weil er davon einen bestimmten Nutzen haben wird. Und fragen ihn regelmäßig, indem wir ihn die neue Funktionalität zum Ausprobieren geben, ob dieser Nutzen tatsächlich eintritt.Neulich herrschte bei einem unserer Projekte große Aufregung: Verbunden mit einem neuen Großkunden hatten sich die Anfragen auf eine Datenbank vervielfacht und zu erheblichen Performance-Problemen geführt, die der Kunde deutlich zu spüren bekommen hatte. Infolgedessen wurde das zuständige Scrum-Team zusammengetrommelt und gefragt, was es innerhalb des nächsten, zweiwöchigen Sprints an Lösungen bereitstellen könne. Manche Teammitglieder empfanden diesen Auftrag als Zumutung, denn es gab zu jenem Zeitpunkt keine produktionsnahe Testumgebung, auf der die Fehler auf der Datenbank zuverlässig hätten reproduziert werden können. "Wir können so nichts beweisen, sondern müssen wild vermuten, was die Performance-Probleme verursacht", lautete der Einwand.Aus den wilden Vermutungen entstand ein gemeinsames Brainstorming, und daraus wiederum ergaben sich Arbeitshypothesen in Form von kurzfristigen Lösungsansätzen. Das Team setzte sich für die Dauer eines zweiwöchigen Sprints zusammen, probierte seine Hypothese durch Umsetzung aus. Am Ende der zwei Wochen gab es eine Review: Was hatte funktioniert, was nicht, worauf sollte aufgebaut werden? Die akuten Probleme konnten in diesen zwei Wochen tatsächlich gelöst werden - der Kunde bekam von den Performance-Problemen nichts mehr zu spüren. Zugleich hatte die beinahe-Katastrophe das Bewusstsein für ein vorbeugendes Handeln geweckt. Am Ende dieses Reviews hingen über 100 weitere Lösungsansätze an der Wand. Auch hier galt es zu klären: Was davon wollen wir in den nächsten Wochen umsetzen und was lassen wir erstmal stehen?Softwareentwicklung ist in der Tat eine Zumutung. Es geht immer wieder um das Gleiche: Die Unwägbarkeiten des Alltags irgendwie in den Griff zu bekommen. Wer versucht, alles im Vorhinein zu klären, der investiert viel Zeit und Denken in etwas, das am Ende sowieso anders kommen wird. Wer im Gegenteil ganz auf das Planen verzichtet und unreflektiert loslegt, der wird am Ende überall ankommen - nur nicht dort, wo er sein möchte. Der gangbare Weg liegt dazwischen: Planen ja, aber in Form von klar formulierten, verifizierbaren Annahmen, die in kurzen Intervallen bestätigt oder eben enttäuscht werden. Das, zusammen mit der Bereitschaft zum ständigen Überdenken des eigenen Standpunktes, macht den Umgang mit Komplexität beherrschbar. Nicht nur für Ameisen.