In den letzten Jahren habe ich in verschiedenen Unternehmen gearbeitet, die unterschiedlich waren, aber ein gemeinsames Problem hatten: Sie hatten sich in Prozessen verloren. Agilität, Scrum, CI/CD — alles gute Ideen, die in der Praxis zu Selbstzwecken geworden waren. Das Produkt blieb auf der Strecke.
Das ist keine Kritik an agilen Methoden. Es ist eine Beobachtung darüber, was passiert, wenn Methoden von ihren Zielen entkoppelt werden.
Die Verheißung
Agilität verspricht schnelle Anpassung, kurze Feedback-Zyklen, bessere Zusammenarbeit. Scrum verspricht Transparenz, Fokus, kontinuierliche Verbesserung. CI/CD verspricht Qualitätssicherung, automatisierte Tests, zuverlässige Auslieferung. Alles sinnvoll. Alles wünschenswert.
Aber in der Praxis habe ich Folgendes beobachtet: Unternehmen, die von technischen Schulden geplagt waren, konzentrierten sich ausschließlich auf die Einhaltung agiler Prinzipien, anstatt die eigentlichen Probleme anzugehen. Statt die Architektur zu verbessern, Bugs zu fixen oder Features zu entwickeln, führten sie Tools ein und machten Schulungen. Das Team war beschäftigt — aber nicht produktiv.
Die Transformation zum Prozess-Unternehmen
Was passiert, wenn Agilität zum Selbstzweck wird? Ein typisches Szenario:
Die Rollenverschiebung. Plötzlich will niemand mehr Entwickler sein. Alle wollen Product Owner, Scrum Master oder Agilitätcoach sein. Die Titel sind attraktiver, die Meetings sind bequemer als Programmierung, und das Gehalt ist oft besser. Die Zahl der Menschen, die Tickets schieben, wächst. Die Zahl der Menschen, die Code schreiben, schrumpft.
Die Retrospektive als Therapiestunde. Statt über technische Probleme zu sprechen — Bugs, Architektur, Refactoring — wird über Gefühle gesprochen. Jeder muss offenbaren, wie er sich fühlt. Es gibt Spiele. Man muss sich gegenseitig loben. Das Produkt, das eigentlich im Zentrum stehen sollte, kommt nicht mehr vor.
Die Metriken-Dominanz. Velocity, Burndown-Charts, Sprint-Ziele — die Metriken werden zum Ziel. Statt den Kundenwert zu maximieren, wird die Story-Point-Zahl maximiert. Statt Qualität zu liefern, wird Durchsatz geliefert.
Die Abschaffung der Expertise. In einem agilen Team gibt es theoretisch keine Spezialisten. Jeder kann alles. In der Praxis bedeutet das: Niemand ist wirklich gut in etwas. Der Architekt, der die Codebase kennt, ist im Meeting. Der Entwickler, der das Feature bauen könnte, schreibt Tests für eine Software, die ohnehin ersetzt wird.
Das CI/CD-Dilemma
Ein konkretes Beispiel: Ich entwickelte ein Frontend, das zwei Kommandozeilenprozesse startete und überwachte. Eine einfache Software — schnell geschrieben, funktionsfähig, bereit für die Auslieferung. Etwa 4.000 Zeilen C++.
Nach der Fertigstellung hatte ich — wegen schlechtem Management — nichts mehr zu tun. Man schlug vor, dass ich mich mit Testing befassen sollte, da das Produkt in CI/CD integriert werden musste. Drei Aspekte:
- Unit- und Integrations-Tests mit Google Test
- Statische Codeanalyse mit SonarQube
- Automatische GUI-Tests
Ich habe mich über ein halbes Jahr ausschließlich mit Testing beschäftigt. Das Problem: Die Software war fertig. Sie sollte nicht weiterentwickelt werden. Sie war nicht fehleranfällig. Und sie sollte in naher Zukunft durch eine andere Software ersetzt werden.
Trotzdem: Das agile Testmanagement verlangte 70% Code Coverage. Für eine Software mit 4.000 Zeilen, von denen der Großteil GUI-bezogen war. SonarQube fand in den gesamten 4.000 Zeilen genau einen einzigen Bug — einen gelöschten Pointer, der in einem anderen Codesegment erneut aufgerufen wurde. Die restlichen Hinweise betrafen unbedeutende Aspekte wie die Anzahl der Member-Variablen.
Die automatischen GUI-Tests für zwei klickbare Buttons in einer wxWidgets-Anwendung ließen sich implementieren — mit erheblichem Aufwand. Das Ergebnis: Das GUI war vollautomatisch testbar. Die Software selbst war aber keinen Millimeter weitergekommen.
Das ist kein Einzelfall. In einem anderen Projekt wurden Tests für eine Software nachimplementiert, die drei Probleme hatte: mangelhafte Code-Qualität, komplexe Fachverfahren und die bevorstehende Ablösung durch eine komplette Neuimplementierung. Statt die Architektur zu verbessern oder die Ablösung vorzubereiten, wurden Tests geschrieben, die beim nächsten Release obsolet sein würden.
Wenn Testen zur ABM wird
Testing ist wichtig. Aber Testing ist nicht wichtiger als das Produkt. Wenn die Wahl zwischen einem funktionsfähigen Feature und 70% Code Coverage besteht, sollte das Feature gewinnen — besonders wenn die Software ohnehin ersetzt wird.
Das Problem ist nicht CI/CD. Das Problem ist, dass CI/CD zum Ziel wird statt zum Werkzeug. Die Pipeline ist nicht das Produkt. Die Testabdeckung ist nicht das Produkt. Das Produkt ist das Produkt.
In einem gesunden Entwicklungsprozess gibt es ein Gleichgewicht: Man entwickelt Features und sichert sie gleichzeitig durch angemessenes Testing ab. „Angemessen“ ist der Schlüsselbegriff. 70% Coverage für eine stabile, kleine Software, die ersetzt wird, ist nicht angemessen — es ist Verschwendung.
Was eigentlich wichtig ist
Die wichtigste Erkenntnis aus diesen Erfahrungen: Prozesse sind Mittel zum Zweck, nicht der Zweck selbst. Agilität ist ein Werkzeug, um schneller auf Veränderungen zu reagieren. Scrum ist ein Rahmenwerk, um komplexe Projekte zu managen. CI/CD ist eine Methode, um Qualität zu sichern.
Wenn diese Werkzeuge den eigentlichen Zweck verdrängen — die Lieferung eines guten Produkts —, dann haben sie ihre Funktion verfehlt.
Was wirklich zählt:
- Das Produkt. Es muss funktionieren. Es muss nützlich sein. Es muss gepflegt werden. Alles andere ist nachrangig.
- Die Architektur. Eine gute Architektur macht Entwicklung schneller, nicht langsamer. Technische Schulden abzubauen ist wichtiger als neue Tools einzuführen.
- Die Experten. Menschen, die den Code kennen, die Fachverfahren verstehen, die Architektur-Entscheidungen treffen können — sie sind wertvoller als noch so viele Prozess-Beauftragte.
- Angemessenes Testing. So viel wie nötig, so wenig wie möglich. Tests sollten das Produkt voranbringen, nicht die Pipeline füllen.
Der Ausweg
Der Ausweg aus der Agilitätsfalle ist einfach, aber nicht leicht: Rückbesinnung auf das Wesentliche.
Hinterfragen. Jeder Prozess, jedes Meeting, jede Metrik sollte die Frage beantworten: Hilft das dem Produkt? Wenn nicht: Weg damit.
Mut zur Einfachheit. Nicht jedes Team braucht Scrum. Nicht jedes Projekt braucht CI/CD. Nicht jede Software braucht 70% Code Coverage. Die Methodik muss zum Projekt passen, nicht umgekehrt.
Technische Exzellenz priorisieren. Bevor man agil wird, sollte man kompetent sein. Eine gute Codebase, eine klare Architektur, eine verständliche Dokumentation — das sind die Grundlagen, auf denen agile Methoden funktionieren können.
Entwickler entwickeln lassen. Die Rolle des Entwicklers ist nicht, Tickets abzuarbeiten. Sie ist, Lösungen zu bauen. Wenn Entwickler die meiste Zeit in Meetings verbringen statt zu programmieren, ist etwas falsch.
Agilität ist eine gute Idee, die schlecht umgesetzt werden kann. Der Test ist einfach: Zählt das, was das Team gerade tut, für den Kunden? Wenn ja — weiter so. Wenn nein —_STOP und nachdenken.
Das ist nicht radikal. Das ist gesunder Menschenverstand. Und der ist in vielen Unternehmen dringender nötig als noch eine Retrospektive.