en
de

Technische Schulden: Ein Killer für Agile Transition

10 März 2014
| |
Lesezeit: 3 Minutes

Von Zeit zu Zeit lohnt sich es, mal wieder ein klassisches Buch aufzuschlagen und sich von neuem inspirieren zu lassen. So ist es mir vor kurzer Zeit ergangen, als mir mein fast 10 Jahre altes Buch „Lean Software Development – An Agile Toolkit “ von Tom & Mary Poppendieck in die Hände gefallen ist.

Auf ihrer letzten Seite vor der Bibliographie geben sie ihre Garantie-Erklärung („Warranty“) für ihr Toolkit an. Mir ist dabei insbesondere der letzte Satz im Gedächtnis geblieben:

„This warranty is invalid if practices are transferred directly from other disciplines or domains without thinking, or if the principles of empower the team and build integrity in are ignored.”

Die Ignoranz des Prinzips “build integrity in” ist in diesem Fall der springende Punkt.

Agile Transition

In einem unserer Mandate haben wir die Transition einer Entwicklungsorganisation begleitet, die komplexe langlebige Produkte entwickelt: Es geht um die Kombination von PC-Software, Embedded-Software, Elektronik und Mechanik. Grund der Anfrage war die Feststellung, dass die Entwicklungszyklen viel zu lange dauern, so dass kaum noch neue Produkte den Weg aus der Entwicklung gefunden haben.

Unser Ansatz war die Einführung von agilen Entwicklungsprozessen, um den langsamen und schwerfälligen wasserfallartigen Prozess abzulösen. Ein ganz wesentliches Problem der Organisation war die schiere Zahl gleichzeitig laufender Entwicklungsprojekte: Mehr Projekte als Entwickler! In den ersten Schritten ging es daher darum, die Projektpipeline massiv zu verschlanken, um sich auf das Wesentliche zu konzentrieren. Parallel dazu wurden zwei Pilotteams aufgesetzt, die als cross-funktionale Teams agile Methoden ausprobieren.

Grundlegende Änderungen in der Organisation führen immer zu Widerständen und zu Problemen, die es im Change-Prozess zu managen gilt. Das war auch bei uns nicht anders. Wir hatten guten Support aus dem Top-Management und konnten daher die Klippen umschiffen. Nach 3 Monaten haben wir weitere Entwicklungsteams gestartet, und haben angefangen, die angrenzenden Abteilungen der Entwicklung mit Methoden aus Scrum, Kanban und Elementen aus dem SAFe zu versorgen. Das Prinzip „empower the team“ hatten wir damit umgesetzt und es hat funktioniert, so wie erwartet.

Pilotteams arbeiten auf Neuland

Typischerweise sind kulturelle Probleme und weiche Faktoren das Schwierige bei der Einführung agiler Prozesse. Dann hat sich bei uns aber doch eine ganz andere Baustelle aufgetan.

Die beiden Pilotteams haben im Wesentlichen isoliert von den restlichen Entwicklern gearbeitet, um die neue Arbeitsweise auszuprobieren. Die Vorhaben waren daher von Neuentwicklung geprägt, agile Praktiken einzuführen war einfach: Unit Tests, komplette Durchstiche durch die Architektur, schnelle Ergebnisse. Alles hat gut funktioniert, die Geschwindigkeit der beiden Teams war spürbar höher als bei vorherigen Arbeitsweise.

Technische Schulden müssen bezahlt werden

Ernüchterung trat dann auf, als die übrigen Teams ihre Arbeitsweise auf die agilen Prozesse umgestellt haben und damit auch die Pilotteams ihre Ergebnisse wiederum in die Gesamtentwicklung integrieren mussten. Jetzt zeigte sich, dass das Gesamtsystem nicht nur sehr komplex ist, sondern im Laufe der letzten 20 Jahre auch eine Menge an technischen Schulden angesammelt hatte. Neben einer schleichenden Erosion der Architektur, die das System anfällig gegenüber Änderungen macht, war eine fehlende Testautomatisierung  ein großes Manko.

Ohne Testautomatisierung bricht aber das technische Rückgrat der agilen Arbeitsweise: Kurze Iterationen, die nachweislich qualitativ hochwertige Änderungen im System bewirken, werden wirkungslos, wenn der Nachweis dazu sehr aufwändig wird: Wir hatten Zeiten, in der der Systemtest des Ergebnisses eines Entwicklungssprint weitere drei Sprints benötigte. Auf diese Weise ist keine Verkürzung der Cycle-Time zu erwarten, egal wie agil man die Features implementiert.

In dieser Situation hilft es nur, wenn man beherzt in Testautomatisierung investiert. Dies beginnt auf der Gesamtsystemebene, wo das vollständige System als Black-Box betrachtet wird. Ist auf dieser Ebene eine kontinuierliche Qualitätsüberwachung etabliert, kann man anfangen, auch auf tieferen Ebenen zu testen. Dafür muss aber das System angepasst werden:

  • um Teilsysteme abzukoppeln,
  • um Mocks aufzubauen,
  • um Messpunkte zu realisieren und
  • um eine übergeordnete Testarchitektur zu entwickeln.

Was man alles im Detail bedenken muss, haben Daniel Mölle und Matthias Kraatz in ihren beiden Blog-Artikeln zu Unit-Testing und zu automatisierten Systemtests beschrieben.

Derartige Änderungen an den Systemstrukturen vorzunehmen, ohne vorher bereits eine zumindest rudimentäre Testautomatisierung zu haben, ist wie eine Operation am offenen Herzen ohne sterile Umgebung: Maximal gefährlich.

Ohne gravierendes Investment in das „Axt schärfen“ wird die Agile Transition also nicht erfolgreich sein: technische Schulden müssen irgendwann zurückgezahlt werden. Zum Glück ist diese Einsicht auch bei den Verantwortlichen angekommen. Der Aufbau der Testautomatisierung ist unterwegs, es besteht Hoffnung.

Die Garantie-Erklärung

Schaut man sich also die Garantie-Erklärung der Poppendiecks an, so muss man feststellen, dass sie recht haben: Es reicht nicht aus, nur die kulturelle Sicht im Auge zu haben. Man kann auch fundamental scheitern, wenn die technische Basis nicht die notwendige Qualität (oder Integrität um im Wording der Poppendiecks zu bleiben) aufweist.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »