239 - Clean Agile

Heute möchte ich mit euch über ein Buch sprechen, das mir wieder einmal bewusst gemacht hat, wie weit wir uns – trotz aller agilen Labels – oft von dem entfernt haben, was Agilität ursprünglich ausmacht: Clean Agile von Robert C. Martin, auch bekannt als „Uncle Bob“.

Er beginnt mit einem kraftvollen Bild, das viele aus dem Projektmanagement kennen: dem sogenannten Iron Cross – bestehend aus vier Dimensionen: gut, schnell, günstig und fertig. Die Faustregel lautet: Wähle drei, das vierte bekommst du nicht. Und genau hier setzt Agilität an: Sie gibt dem Management die Mittel, um pragmatisch zwischen diesen Dimensionen zu navigieren – und zwar datenbasiert. Agile Teams erzeugen Daten. Diese ermöglichen es, fundierte Entscheidungen zu treffen – statt auf Hoffnungen oder Bauchgefühl zu setzen.

Ein häufiger Reflex auf drohende Verzögerungen ist es, zusätzliche Leute ins Projekt zu holen. Aber hier greift Brook’s Law: Wer ein verspätetes Projekt durch zusätzliche Manpower beschleunigen will, macht es nur noch später fertig. Der Onboarding-Aufwand frisst jede potenzielle Produktivitätssteigerung auf. Es ist ein reines Glücksspiel – das meist verloren geht.

Ein anderer Reflex ist: Dann sparen wir halt bei der Qualität. Weniger Tests, mehr Output. Aber das ist ein Trugschluss. Uncle Bob bringt es auf den Punkt: „Es gibt kein Quick and Dirty. Es gibt nur Dirty – und das heißt: langsam.“ Schlechte Qualität verlangsamt Systeme, macht sie fehleranfällig – und zerstört jede Planbarkeit.

Gute Software zeichnet sich dadurch aus, dass sie sich leicht verändern lässt. Daher auch der Name: Software – „Ware“ für Produkte, aber „soft“ für flexibel anpassbar. Wenn neue Anforderungen deine Architektur brechen, dann – Zitat: „habe ich eine schlechte Nachricht für dich, Sunshine – deine Architektur ist schlecht.“ Ein guter Softwareentwickler sorgt dafür, dass ein System mit der Zeit stabiler und robuster wird – nicht brüchiger.

Dazu gehört auch ein ganz bestimmtes Teamverständnis. Uncle Bob formuliert es klar: Ich erwarte, dass Wissen geteilt wird. Zum Beispiel durch Pair Programming. Ich erwarte, dass Teammitglieder füreinander einspringen. Und ich erwarte, dass jeder sicherstellt, dass auch für ihn jemand einspringen kann. Ich erwarte, dass du „Nein“ sagst, wenn das Management auf einen Abgrund zusteuert. Und ich erwarte, dass du dein Wissen weitergibst – du bist Entwickler, aber auch Lehrer.

Und genauso wie Entwickler Rechte und Pflichten haben, haben auch Kunden Rechte – eine Art Bill of Rights. Das Ziel von Agile ist es nämlich, die Kluft zwischen Business und Entwicklung zu überbrücken. Kunden haben das Recht auf einen Gesamtplan: Was ist möglich? Wann? Und zu welchen Kosten? Dass Agilität keine Vorausplanung kennt, ist schlichtweg falsch. Natürlich braucht das Business Pläne – aber keine Illusionen. Die Pläne müssen die Unsicherheit abbilden – und zeigen, wie mit ihr umgegangen wird. Man kann nicht einen festen Funktionsumfang zu einem festen Termin garantieren. Entweder der Umfang oder das Datum muss „weich“ sein – und diese Weichheit muss sichtbar gemacht werden, etwa in Form einer Wahrscheinlichkeitsverteilung.

Das Ziel: maximaler Wert pro Iteration. Die Kund:innen priorisieren die Stories mit dem höchsten ROI. Der Fortschritt zeigt sich in einem laufenden, getesteten System – durch wiederholbare Tests, die vom Business spezifiziert wurden. Und: Kunden können ihre Meinung ändern – Prioritäten und Anforderungen – ohne dass sie gleich einen riesigen Preis dafür zahlen. Das ist der Sinn von Software – sie soll veränderbar bleiben.

Ein weiterer Punkt: Kunden haben kein Recht, auf einem Plan zu beharren, wenn sich dieser als unrealistisch herausstellt. Sie haben aber das Recht, informiert zu werden, sobald ein Termin gefährdet ist – damit sie den Umfang anpassen können. Und sie haben das Recht, jederzeit auszusteigen – und trotzdem ein funktionierendes System zu erhalten, das dem investierten Budget entspricht.

Auch Entwickler:innen haben ihre Rechte. Sie dürfen wissen, was gebraucht wird – mit klarer Priorität. Sie haben Anspruch auf hohe Qualität – jederzeit. Sie haben das Recht, Hilfe zu erbitten – und zu erhalten. Und sie sollen Arbeit annehmen, nicht zugewiesen bekommen. Schätzungen machen sie selbst – und passen sie bei Bedarf an.

Ein entscheidender Punkt, den viele Organisationen vergessen: Eine Software ist erst dann „released“, wenn sie technisch fertig für den Produktivbetrieb ist. Die Deployment-Entscheidung ist dann eine rein geschäftliche. Und auch Akzeptanztests sind ein zentrales Thema. Das Business – etwa Business Analyst:innen – formuliert die gewünschten Verhaltensweisen: „Given – When – Then.“ Die Entwickler:innen automatisieren diese. QA kümmert sich nicht nur um Tests am Ende, sondern von Anfang an. Business analysiert den Happy Path, QA den Sad Path – und QA sind dabei hochtechnische Menschen, die sowohl wissen, wie Entwickler denken als auch wie Nutzer Systeme zerstören können.

Was bei vielen sogenannten Agile Transformations leider fehlt: der Fokus auf technische Exzellenz. Prozesse allein genügen nicht. Niemand bringt den Entwickler:innen die entscheidenden Skills bei: Pairing, Git, Testing, CI/CD, Refactoring. Wer mehrmals täglich ausliefern will, braucht nicht nur neue Prozesse – sondern auch neue Fähigkeiten. Viele Coaches haben diese technischen Kompetenzen gar nicht – und werden deshalb eher als weitere Managementebene wahrgenommen.

Dabei ist Agilität nichts für Chaos oder Beliebigkeit. Im Gegenteil: Sie erfordert ein hohes Maß an Disziplin und strategischem Denken. Agile Coaches müssen genau das vermitteln – indem sie mitentwickeln, Designprinzipien diskutieren, Tests mitgestalten und gemeinsam mit dem Team an der Continuous Integration arbeiten.