Die agilen Prinzipien machen für mich nur Sinn, wenn sie nicht im Widerspruch zur Theory of Constraints (TOC) stehen. Noch besser: Der Geist der TOC sollte sie sogar durchwehen. Ist das aber der Fall?
Als ich neulich eine hübsche Übersicht über die agilen Prinzipien bei Knowledge Train gesehen hatte, habe ich mir vorgenommen, diesbezüglich nochmal genauer hinzuschauen.
Untermalt von den Visualisierungen von Knowledge Train schaue ich mir deshalb jedes Prinzip daraufhin an, was es mit Durchsatz, Engpass und den fünf Fokussierungsschritten der TOC zu tun hat.
1. Satisfy the Customer
Einen Engpass gibt es nur im Hinblick auf ein Ziel. Ohne das Ziel zu kennen, kann kein “Fortschrittsprozess” definiert werden, der darauf zu läuft. Und ohne eine Idee vom Prozess zu haben, kann eine Produktion bzw. eine Zielannäherung nicht systematisch beurteilt und optimiert werden.
Das erste agile Prinzip legt aus Sicht deshalb die Grundlage für eine Anwendung der TOC. Es macht das Ziel agiler Softwareentwicklung klar: es geht um wertvolle Software.
Was wertvoll ist, wird dahingestellt. Wert entsteht im Auge des Betrachters. Doch egal was als wertvoll angesehen wird, es soll stetig geliefert werden. Es gibt in der agilen Softwareentwicklung also einen Strom von Lieferungen (Inkrementen). Es kann ein Durchsatz beobachtet werden, der nicht nur aus einem finalen Big Bang besteht.
Sollte die Entwicklung des Wert-Durchsatzes sich unvorteilhaft entwickeln, kann die TOC angewendet werden, um den Prozess dahinter zu verbessern.
2. Welcome Change
Über die konkrete Struktur des Prozesses schweigen die agilen Prinzipien sich aus. Allerdings machen sie klar, dass die Reaktion auf Änderungen ein wichtiger Bestandteil ist. Ihnen sollte kein Widerstand entgegengesetzt werden. Ein Engpass an dieser Stelle soll von vornherein vermieden werden.
Warum betonen die agilen Prinzipien die Änderungswilligkeit? Weil die in vor-agilen Zeiten weniger vorhanden war. Änderungswünsche mussten sich durch ein Entscheidungsnadelöhr zwängen, was einer kontinuierlichen Wertentwicklung entgegenstand.
3. Deliver Frequently
Das dritte Prinzip schließt an das erste an: Es betont eine häufigere Lieferung. (Teil)Produkte sollen in einem stetigen Fluss von der Softwareproduktion “ausgestoßen” werden. Die Agilität wirbt für einen hochfrequenteren Durchsatz.
Auch das ist eine Reaktion auf vorherige Praktik, die darauf konzentriert war, “das perfekte Gesamtprodukt” erst am Ende zu liefern — um regelmäßig zu scheitern.
4. Work Together
Das vierte Prinzip spielt auf einen im vor-agilen Produktionsprozess identifizierten Engpass an: die Kommunikation zwischen Entwicklung und Kunde. Wenn die im Prozess explizit und sequenziell ist, wird der Kunde schnell zum Engpass. Für die Beschäftigung mit dem Softwareprojekt darf bei ihm keine spezielle Planung nötig sein; vielmehr soll er permanent involviert werden. Dann steht er als Ressource (quasi) ständig zur Verfügung.
In der Praxis haben sich daraus Projektteams ergeben, in die der Kunde (bzw. ein Stellvertreter mit Entscheidungskompetenz) eingebettet ist: die cross-functional teams. Damit verschwindet die Abstimmung mit ihm in gewisser Weise aus dem Entwicklungsprozess; sie kann kein Engpass mehr sein.
Mit diesem Prinzip wird die Entwicklung im Grunde aufgestockt. Das entspricht dem vierte Fokus-Schritt: elevate constraint.
5. Trust and Support Motivation
Hier wird ein weiterer Engpass angesprochen: das Management. Wenn die Kundenkommunikation nicht der begrenzende Faktor war, dann management attention, d.h. das wiederholte Einholen von Entscheidungen und Feedback.
Die agilen Prinzipien werben dafür, das Management so weit wie möglich aus der Produktion herauszuhalten. Es sollen keine “Schleifen übers Management” nötig sein, um voranzuschreiten. Geschwindigkeit durch Vertrauen ist das Motto.
Außerdem soll das Entwicklungsteam, das von außen gesehen die einzige Ressource ist, die den Wert-Durchsatz produziert, möglichst viel Kapazität auf diese Aufgabe verwenden können. Alles Tätigkeiten, die davon ablenken, sind zu vermeiden. Das bedeutet, administrative Aufgaben, die nicht dem Wert dienen, sind zu minimieren. Hohe Autonomie dem Entwicklungsteam, dann wird es sich selbst optimieren auf das Ziel hin.
Hohe Motivation der Beteiligten wirkt dabei als Schmiermittel. Sie gilt es zu hegen und zu pflegen.
Insgesamt sehe ich in diesem Prinzip einen Verweis auf den dritten Fokus-Schritt der TOC: subordinate everything to the constraint.
6. Face-to-Face Conversation
Klärende Kommunikation, die viele Schleifen durchläuft, wird mit Wartezeit aufgebläht, wenn sie nicht mündlich stattfindet. Das führt zu Multi-Tasking. Das führt zu weiterer Zeitverschwendung durch Umschaltzeiten. Insgesamt werden die Lieferzeiten länger.
Das sechste Prinzip zielt also ebenfalls darauf ab, Kapazität der Entwicklungsressource frei zu machen für das Wesentliche. Mündliche Kommunikation soll helfen, den Durchsatz zu erhöhen. Ein Anschluss an das vierte Prinzip und eine Referenz auf den zweiten Fokus-Schritt: exploit constraint.
7. Working Software
Was stellt Wert da? Software, die tut, was sie soll, die also funktioniert. Das klingt selbstverständlich, ist es aber nicht. Die Softwareentwicklung steht im Ruf, Bananen zu liefern, die erst beim Kunden reifen: Software wurde (und wird) zu oft zum Einsatz gebracht, obwohl ihr noch geforderte Eigenschaften fehlen oder gelieferte fehlerbehaftet sind.
Das ist nicht nur für den Kunden unmittelbar unbefriedigend. Das ist auch für die Produktion von hohem Wert-Durchsatz negativ. Denn jeder Fehler, der beim Kunden auftritt, führt zu einem Rücklauf, der nachbearbeitet werden muss. Das reduziert die Kapazität der Entwicklung für weiteren Wert und erzeugt womöglich sogar Multi-Tasking mit einer weiteren Verringerung des Durchsatzes.
Das siebte Prinzip betont also nicht nur, was als Lieferung gilt, sondern mahnt an, durch von vornherein saubere Arbeit dem zweiten Fokus-Schritt der TOC - exploit the constraint - zu folgen.
8. Sustainable Development
Die Lieferung von Wert soll keine Eintagsfliege sein. Agile Softwareentwicklung soll darauf achten, keine Ressource zu verschleißen. Produktion heute darf Produktion morgen nicht schwieriger machen. Der Durchsatz an Wert soll hoch sein und auch bleiben.
Was sind die Ressourcen, die pfleglich zu behandeln sind? Das sind natürlich die Menschen und ihre Beziehungen, das ist aber auch der Code. Aus diesem Prinzip leitet sich eigentlich Clean Code Development ab.
Einen speziellen Bezug zur TOC erkenne ich hier insofern als dass ganz allgemein darauf zu achten ist, die Kapazität keiner Ressource durch Nutzung schrumpfen sollte — Bezug auf zweiten Fokus-Schritt: exploit constraint —, und dass alle aufgefordert sind, darauf stets zu achten — Bezug auf dritten Fokus-Schritt: subordination.
9. Continuous Attention
Mit diesem Prinzip wird die Wichtigkeit der Ressource Code betont. Sie soll von vornherein hohe Qualität in allen Dimensionen haben, um zügig Wert heute und in Zukunft zu liefern. Sie soll aber auch nicht in eine Regression fallen, wenn Neues hinzugefügt wird. Ein Bezug auf zum zweiten Fokus-Schritt: exploitation. Vorhandene Kapazität soll erhalten bleiben.
10. Maintain Simplicity
Ebenfalls ein Verweis auf den zweiten Fokus-Schritt: exploit the constraint. Dessen Kapazität ist heilig. Sie darf nicht mit “Müll” belastet werden, dazu gehört unnötige Komplexität.
Was ist der Engpass? Von außen betrachtet das ganze Entwicklungsteam. Es ist die Durchsatz produzierende Ressource.
Und im Entwicklungsteam, im Entwicklungsprozess? Darüber schweigen sich die agilen Prinzipien aus. Aber einige Prinzipien geben Hinweise, wo man meint, dass Engpässe üblicherweise existieren oder leicht entstehen können:
Prinzip 4: der Kunde
Prinzip 5: das Management
Prinzip 9: der Code
11. Self-Organizing Teams
Hier im Grunde eine Wiederholung von Prinzip 5 mit Konkretisierung: Der Durchsatz wird optimiert, wenn die Kapazität des Teams nicht durch Interventionen von außen reduziert wird (Fokus-Schritte 2 und 3: exploitation und subordination). Autonom funktionieren cross-funktionale Teams (Prinzip 4) am besten.
12. Reflect and Adjust
Und schließlich Fokus-Schritt 5: prevent inertia, nicht träge werden, sondern ständig hinschauen, wo sich der Engpass befindet, um dort zu optimieren. Der Engpass kann überall lauern: im Prozess der Codeproduktion, in der Reaktionsfähigkeit auf Veränderung, in der Anpassungsfähigkeit des Prozesses und “noch höher”. Veränderungsprozesse sind auch nur Prozesse, die wiederum Engpässe haben können. Das letzte Prinzip gesteht das ein und versucht in ein Gegengewicht zu installieren.
Zusammenschau
Haben die agilen Prinzipien mit der TOC etwas zu tun? Ja, ich denke, das liegt auf der Hand. Wer die TOC-Brille aufsetzt, wird Unterstützung bei den agilen Prinzipien finden. Die einen sind dabei klarer, die anderen weniger.
Und für mich ganz natürlich beziehen sich die meisten auf den zweiten Fokus-Schritt: exploit the constraint. Das ist der schlicht einfachste und kostengünstigste Ansatz.
Was ist der Engpass? Da eine genauere Prozessbeschreibung fehlt, kann nur das Entwicklungsteam als Ganzes angenommen werden. Management wird abgekoppelt (Prinzip 5) und Kunde wird eingebettet (Prinzip 4). Damit bleibt das Entwicklungsteam übrig — weitere Optimierung ist darin vorzunehmen. Dafür soll es Autonomie besitzen.
Auf der Flughöhe des agilen Manifests ist das genug. Ich freue mich über das Ergebnis. Für die Praxis fehlt aber natürlich einiges. Eine genauere Vorstellung vom Entwicklungsprozess ist wichtig für weitere Optimierung. Eine Forderung von Nachhaltigkeit, Reflexion, Qualitätsfokus und persönlicher Kommunikation ist kein Ersatz dafür. Solange die Entwicklung eine Black Box bleibt, droht der Durchsatz trotz aller agiler Prinzipien suboptimal zu bleiben.
PS: Mein Mapping von Prinzipien auf TOC ist wahrscheinlich nur ein mögliches von vielen. Weitere Bezüge zu sehen oder Bezüge etwas zu verschieben, fände ich völlig normal. Dass aber überhaupt ein signifikanter Bezug vorhanden ist, scheint mir auf der Hand zu liegen.