Vorschläge zur Messung von Agilität

Wann ist ein Team, eine Organisation agil? Gibt es mehr oder weniger Agilität? Das sind Fragen, die eigentlich jeden umtreiben müssten, der sich mit dem Thema Agilität beschäftigt, egal ob Enthusiast oder Skeptiker.

Was für mich den Kern von Agilität ausmacht, habe ich an anderer Stelle mal beschrieben. Darauf hat nun Volker Meurer mit einem interessanten Beitrag reagiert.

Volkers Idee, Agilität als einen Raum zu betrachten, der durch mehrere Dimensionen aufgespannt wird, finde ich anschaulich und hilfreich. Damit kommt Agilität aus der pseudowissenschaftlichen Ecke heraus, sie wird quantifizierbar(er).

Mit solchen Dimensionen würde Agilität besser greifbar. Es gäbe etwas zu messen – und das ist für jeden der bewusst seine Fähigkeiten verbessern will, immer eine gute Sache. Messungen geben Feedback über Fort- bzw. Rückschritt. Außerdem kann man sich damit Ziele setzen.

Agilität aus dem Manifest destilliert

Das Agile Manifest ist in seiner Beschreibung von Agilität schwammig; wann man agil ist, kann man nicht so genau wissen. “Individuals and interactions over processes and tools” usw.: das klingt gut, da ist eine Menge dran – aber hat man es denn schon realisiert? Ja, genau, real-isiert. Ist es schon real? Wie stellt man das für eine Organisation fest? Wie misst man das? Und ist es wichtig dafür, dass morgens alle im täglichen Standup-Chor singen? Muss man dafür Story Points schätzen?

Alles, was Scrum und XP – die beiden ursprünglichen agilen Vorgehensmodelle - vorschlagen sind nur, lediglich und nicht mehr als Mittel. Ebenso “customer collaboration” oder “individuals and interactions”. Alles nur Mittel. Aber zu welchem Zweck? Was soll durch mehr “individuals” denn “tools” erreicht werden?

Auch in meiner Beschreibung eines Kerns von Agilität habe ich vor allem Mittel genannt. Als Destillat stellten sie für mich Muster in Softwareproduktionen dar, die mir typisch für ein bestimmtes positives Gesamtverhalten, ein gutes Ergebnis schienen. Das kann man dann “agile Softwareproduktion” nennen; mir persönlich schmeckt “flüssige Softwareproduktion” allerdings besser. Doch beides sind wieder nur verkürzende Etiketten. Die Frage bleibt: Ja, was ist denn das, wofür Inkremente oder daily stand-ups oder Reflexion oder co-located teams usw. Mittel sind, es herzustellen?

Aus diesem kreiselnden Denken, aus der Gefahr des Cargo-Kults müssen wir endlich aussteigen. Wir müssen irgendeine Softwareproduktion herstellen, die was taugt. Wie die heißt, das ist egal. Also, worum gehts?

Worum geht es?

Unter einem Berg an gut gemeinten Mitteln finden sich im Agilen Manifest Hinweise. Hier die richtungsweisenden Begriffe in Reihenfolge der Fundstellen bei den Werten und den Prinzipien:

• “Working software”
• “responding to change”
• “satisfy customer”
• “welcome changing requirements”
• “harness change for the customer’s competitive advantage”
• “Deliver working software”
• “Working software is the primary measure of progress”
• “sustainable development”

Aus dieser Liste lässt sich herauslesen, wie damals die Welt der dysfunktionalen Softwareproduktion gesehen wurde. Und eben, was man daraus für Schlüsse für eine bessere Softwareproduktion gezogen hat:

• Die Softwareentwicklung hat sich mehr um sich selbst als um den Kunden gedreht. Man war verstrickt in technische Belange. Materialien und Werkzeuge haben viel Energie absorbiert. Ob die Gründe dafür tatsächlich in einem Mangel an genügend leistungsfähiger Technologie lag oder eher in der Psyche der damaligen Softwareentwickler, sei dahingestellt. Jedenfalls rief das Manifest zu einem Umdenken auf. “Working software” (3 Nennungen) und Wert für den Kunden (“satisfy customer”, “customer’s competitive advantage”) sollten der Leitstern sein. Agil ist also, was qualitätsorientiert ist. Denn Qualität ist, wofür irgendwer bereit ist, Geld auszugeben.
• Außerdem erschien die Softwareentwicklung damals als schwerfällig und starr. Die Erkenntnis war, dass sich Kundenwünsche schneller ändern als man darauf reagieren kann. Vielleicht, weil der Kunde tatsächlich neuen/anderen Bedarf hat; vielleicht, weil der Kunde zu Beginn der Entwicklung nicht genau wusste, was er wollte; vielleicht, weil er es wusste, aber nicht gut ausdrücken konnte; vielleicht, weil das Verständnis der Entwickler mangelhaft war oder das Ergebnis fehlerhaft. Einerlei. Jedenfalls war die Beweglichkeit der Softwareproduktion nicht groß genug. Deshalb fordert das Agile Manifest “responding to change” und “welcome changing requirements” und “harness change”. Agil ist also, wo die Softwareentwicklung schmerzfrei den Kurs ändern kann, wenn Kundenwünsche sich ändern.
• Und schließlich hielt man die Softwareproduktion für zu sehr auf den Moment konzentriert. Weil man starr war und technikfokussiert, hinkte man der Qualität immer hinterher. Qualität herzustellen war damit quasi eine Form von kurzfristiger Reparatur. Das Ergebnis: Todesmarschprojekte und rasant wachsender Legacy Code. Dem sollte die allerdings nur einmalige Nennung von “sustainable development” entgegenwirken. Agil ist also Softwareproduktion, die nicht nur an heute denkt, sondern nachhaltig arbeitet in allen Aspekten.

In einem Satz:

Agile Softwareentwicklung ist nachhaltig reaktionsfreudig qualitätsorientiert.

Das ist doch knackig, oder? Das lässt sich twittern ;-)

Ich habe es auch bewusst ohne Kommata geschrieben, um den Zusammenhalt der Adjektive zu stärken. Agilität bedeutet eben nicht nur qualitätsorientiert zu sein, sondern das in reaktionsfreudiger Weise: reaktionsfreudige Qualitätsorientierung. Und eben nicht nur das, sondern auch auch soll diese reaktionsfreudige Qualitätsorientierung nachhaltig sein: nachhaltige reaktionsfreudige Qualitätsorientierung. Agilität gibts nur als Paket. Sie ist eben mehr als eine Aufzählung von Attributen; sie ist ein Ganzes, quasi nachhaltigreaktionsfreudigqualitätsorientiert.

Warum Agilität?

Klar, man kann noch fragen, warum sollte Softwareentwicklung agil sein. Aber darauf ist die Antwort ja einfach: agil scheint wirtschaftlicher als nicht agil. Agilität erhöht die Wahrscheinlichkeit für das Überleben eines Unternehmens - und zwar das des Kunden wie das des Softwareproduzenten. Alles andere wäre ja uninteressant.

Wie erreicht man Agilität?

Und nun, da klarer ist, was bessere Softwareproduktion als früher ist, wie erreicht man diese Art Softwareproduktion?

Das ist im Grunde völlig egal. Agilität, die sich auf bestimmte Mittel versteift, ist fehlgeleitet.

Das Agile Manifest gibt zwar Hinweise für Hilfsmittel und Verhaltensweisen. Weitere sind zusammengefasst in den agilen Vorgehensmodellen Scrum und XP. Aber letztlich können das nicht mehr als Empfehlungen sein. Es haben sich halt Muster herausgeschält, die kausal verantwortlich scheinen für Verhältnisse, auf die die obige Definition von Agilität passt. Nicht weniger, aber auch nicht mehr.

Agilität messbar machen

Viel wichtiger als die Frage nach dem Wie ist die nach dem Ob. Ob man nämlich schon die agile Vision realisiert hat? Wie ist man auf dem Weg zu Agilität vorangekommen? Wenn der Einsatz von Mitteln kein Maßstab sein darf - da wäre nur Cargo-Kult -, dann muss eine andere Messlatte her. Ohne Messlatte kein Feedback zum Fortschritt auf einem Weg.

Auftritt Volker Meurer. Genau solch eine Messlatte schlägt er vor. Ob und wie agil eine Softwareproduktion ist, soll bestimmt werden durch Messungen in drei Dimensionen:

• Reaktionszeit
• Aufwand
• Wert

Diese Grundidee gefällt mir sehr gut. Und doch passt da für mich etwas noch nicht ganz. Ich glaube, das liegt daran, dass Volker von einer weniger differenzierten Definition ausgegangen ist.

Ich meine, wenn schon messen, dann das, wofür Agilität steht. Dazu müssen die Grade bestimmt werden, zu denen Qualitätsorientierung, Reaktionsfreudigkeit und Nachhaltigkeit erreicht sind.

Reaktionsfreudigkeit

Reaktionsfreudigkeit scheint der am einfachsten zu messen Aspekt von Agilität zu sein. Volkers Reaktionszeit-Dimension bezieht sich offensichtlich ebenfalls darauf.

Reaktionsfreudig/-fähig ist, wer auf eine neue Anforderung, eine Überraschung, eine unerwartete Kursänderung schnell reagiert. Das kann nötig sein, weil ein vom Support gemeldeter Bug dringend gefixt werden muss. Oder es stellt sich bei der Abnahme einer gelieferten Qualität heraus, dass die nun doch nicht auf einem zufrieden stellenden Niveau für den Kunden ist und deshalb eine baldige, wenn schon nicht unmittelbare Nachbesserung erforderlich wird.

Jeder einzelne Entwickler mag total reaktionsfreudig sein und alles stehen und liegen lassen, wenn der Kunde einen neuen Wunsch äußert. Diese Reaktionsfreude ist sogar durchaus weit verbreitet - stellt aber ein Anti-Pattern dar.

Es geht vielmehr um Reaktionsfreudigkeit des gesamten Produktionsprozesses. Und das auch noch unter einer Bedingung: Es darf dabei keine Verschwendung entstehen. Darauf bezieht sich Volkers Wert-Dimension.

In welcher Ferne liegt im Gesamtprozess der nächste Punkt zur Kursänderung, ohne bisherige Qualität zu vernichten (Regression) oder in Arbeit befindliche Qualität nicht fertig zu stellen?

Kann in 4 Stunden oder in 5 Tagen oder in 4 Wochen eine neue, dem Kunden wichtige Änderung begonnen werden? Natürlich unter Berücksichtigung begrenzter Kapazität; andere Qualitäten, deren Realisierung gestern noch als nächstes anstanden, müssen u.U. zurückstecken.

In keinem Fall jedoch wird der grundsätzliche Produktionsfluss dadurch aus der Bahn geworfen.

Reaktionsfreudigkeit ist mithin mehr als Reaktionszeit. Zu der Frage “Wie lange, bis zum nächsten ‘Unterbrechungspunkt’, damit nichts Angefangenes auf Halde gelegt werden muss?” muss die Frage treten “Wie viel existierende Qualität wird vernichtet durch diese unerwartete Kursänderung?”

Die erste Frage lässt sich mit Blick auf die Uhr bzw. auf den Produktionsplan gem. de facto Produktionsprozess beantworten.

Die zweite Frage jedoch brauch ein anderes Messinstrument. Existierende Qualität kann nur durch Tests gemessen werden. Agilitätsbestimmung setzt mithin automatisierte Tests mit angemessener Abdeckung voraus, weil sonst nicht zu jedem Zeitpunkt der aktuelle Qualitätsstand leicht gemessen werden kann.

Automatisierte Tests dienen also nicht nur als Sicherheitsnetz, sondern als Messinstrument. Ohne angemessene Testabdeckung fehlt ein Messinstrument. Und damit - so würde ich sagen - fehlt per se Agilität.

Es gibt keine Agilität ohne automatisierte Tests. Da kann man sich in Iterationen drehen, wie man will. Ohne automatisierte Tests kann man sich schlicht alles in die Tasche lügen. Verschwendung durch Qualitätsvernichtung ist dann nicht auf dem Radar.

Und noch eine weitere Frage stellt sich im Rahmen der Reaktionsfreudigkeit. Selbst wenn der nächste Unterbrechungspunkt nahe ist, selbst wenn existierende Qualität durch die Kursänderung nicht vernichtet würde, so kann die Reaktionsfreudigkeit doch suboptimal sein.

Denn der nächste Zeitpunkt zum Beginn der Arbeit an einer Anforderung ist nur oberflächlich interessant. Viel wichtiger ist, wann kann mit der produktiven Arbeit an den für die neue Anforderung relevanten Aspekten begonnen werden? Das meint Volker mit seiner Aufwand-Dimension, glaube ich.

Wenn schon in 4 Stunden die neue Anforderungen in Angriff genommen werden könnte, ohne dass Verschwendung entstünde, dann wäre das super. Weniger super wäre jedoch, wenn dann erstmal 3 Tage lang refaktorisiert werden müsste, um produktiv zu werden.

Refaktorisierung würde ich nicht als Verschwendung bezeichnen. Aber die dafür aufgewandte Zeit ist unproduktiv. Weniger davon ist besser. In Analogie zur materiellen Produktion würde ich sie als Rüstzeit bezeichnen. Sie muss sich sogar nicht nur auf das Material (Code) beziehen, sondern umfasst auch die Bereitstellung von Maschinen (Tools, Infrastruktur) und Menschen. Alles, was verändert werden muss, um die eigentlich vom Kunden gewünschte Qualität herzustellen, ist hier einzurechnen.

Wie kann man solche Rüstzeit messen? Natürlich mit der Uhr. Wenn man weiß, dass es sie gibt, dann muss man schauen, wo man Anzeichen dafür sieht, dass die Produktion sich gerade in Rüstzeit befindet. Ein Blick ins Repository kann Hinweise liefern. Refaktorisierungen sollten dort als solche gekennzeichnet sein. Aber auch eine Befragung der Entwickler hilft. Hier könnte ein daily stand-up meeting als Messinstrument dienen. “Wie viel Zeit hast du gestern mit Refaktorisierung zur Vorbereitung einer Aufgabe verbracht?” oder “Wie viel Zeit hast du gestern in das Aufsetzen von Infrastruktur zur Vorbereitung gesteckt?” oder “Wie lange haben wir gestern auf Beiträge von Dritten gewartet, um mit der neuen Aufgabe zu beginnen?” sind Fragen nach Rüstzeit.

Ein daily stand-up meeting begründet mit “individuals and interactions” ist schwach. Und die Frage “Was hast du gestern gemacht?” in einem co-located Team ist langweilig. So degenerieren stand-ups schnell zu Pflichtveranstaltungen, zu Cargo-Kult. Sich allgemein kollaborativ austauschen kann man auf andere Weise besser. Aber mit der konkreten Aufgabe “Rüstzeit messen” ist die Kraft hinter einem stand-up ganz anders. Spüren Sie das? Da weiß jeder ganz genau, worum es geht und worauf man am Tag achten muss. (Ob ein daily stand-up das beste Messinstrument ist, sei aber weiter dahingestellt. In jedem Fall ist es eines, mit dem Sie leicht beginnen können.)

Reaktionsfreudiger ist also, wer mit kürzerer Reaktionszeit und mit weniger Verschwendung und weniger Rüstzeit auf neue Anforderungen reagieren kann als andere oder vormalig er selbst.

Qualitätsorientierung

Volkers Dimensionen dienen der Bestimmung des Agilitätsgrades einer Organisation. Aber sie beziehen sich aus meiner Sicht nur auf den Aspekt der Reaktionsfreudigkeit. Der ist wichtig, aber nicht eben nicht der einzige.

Wer Agilität implementieren will, der muss mehr sein, als reaktionsfreudig. Der muss Qualitätsorientierung zeigen. Nur wie drückt die sich aus? Wie kann man die messen?

Qualität ist etwas von Wert. Dafür ist der Kunde bereit, zu zahlen. Die erste Frage muss daher lauten: Wird der Fortschritt der Produktion an werthaltigen Aufgaben gemessen?

Es gibt immer wieder Projekte, in denen Meilensteine lauten, “Kommunikationsframework eingebaut” oder “ORM entwickelt”. Natürlich zielen solche Aufgaben auf die Herstellung irgendeiner Qualität ab. Doch die Qualität selbst ist eben nicht Aufgabe. Technologien, Infrastruktur, Tools sind lediglich Mittel, um Qualitäten herzustellen.

Für den Kunden ist mit spürbarem Wert also nichts geschafft, wenn ein Kommunikationsframework eingebaut oder ein ORM entwickelt wurde. Das ist kein messbarer Fortschritt. Ob das gut getan ist, kann er nicht sagen.

Qualitätsorientierten Fortschritt gibt es nur, wenn Aufgaben Feedbackfähiges betreffen. Use Cases oder User Stories sind anerkannter Ausdruck dafür; ich würde aber lieber etwas neutraler von Inkrementen sprechen. Je mehr Inkremente den Ausgangspunkt der Produktionsplanung darstellen, desto agiler die Softwareentwicklung.

Aber dabei sollte die Messung nicht stehenbleiben. Denn wir hoch ist der Wert jeder dieser hübsch formulierten Aufgaben? Ihre Formulierung zeigt, dass sie irgendeinen Wert haben, aber nicht welchen. Weder absolut noch im Vergleich. Ohne eine Wertzuordnung ist aber nicht einschätzbar, ob die Produktion gerade viel Wert oder wenig herstellt.

Ein zweiter Maßstab für Agilität ist daher, in welchem Ausmaß Inkremente mit einem Wert versehen sind. Sehr große Aufgaben haben gewöhnlich einen vom Management oder Kunden bezifferte Wert. Aber wie steht es mit kleineren und kleinsten Aufgaben?

Wert muss dabei nicht direkt etwas mit Geld zu tun haben. Es geht nicht darum zwanghaft einen vermuteten Umsatz an eine Aufgabe zu hängen oder cost of delay zu berechnen. Auch die Zahl der Anwender, die von der Umsetzung einer Aufgabe profitieren, stellt einen Wert dar. Oder die erwartete Nutzungshäufigkeit einer Qualität. Oder ein Erkenntnisgewinn über Kundenverhalten oder Technologiefunktionalität. Der Wert an Information ist nicht zu unterschätzen. Das schließt die Ausräumung von Unsicherheiten ein.

Damit aber nicht genug. Wert allein macht auch nicht glücklich, kann man sagen. Viele kleine Verbesserungen schnell ausgeliefert können mehr bewirken als die mega Verbesserung in ferner Zukunft.

Qualitätsorientierung muss dem Wert einer Aufgabe daher einen Aufwand gegenüberstellen. Es muss also ebenfalls gemessen werden, wie weit Aufgaben mit geschätzten Aufwänden versehen sind. Die Maßeinheit ist dabei egal (Fibonacci-Zahlen oder T-Shirt-Größen). Es geht auch nicht um Vorhersagen, wie lange die Realisierung einer Qualität zeitlich dauern wird.

Lediglich eine vergleichende Schätzung von Aufgaben, die derzeit auf dem Tisch sind, ist nötig. Wichtig ist einzig der Faktor, in dem sie sich unterscheiden. Beispiel: Aufgabe A ist die kleinste, ihr Faktor ist 1. Aufgabe B braucht geschätzt doppelt so viel Aufwand, ihr Faktor ist 2. Aufgabe C braucht ca. 50% mehr Aufwand als B, ihr Faktor ist also 3.

Ob in diesem Beispiel am Ende A in 2 Tagen und B daher in 4 Tagen realisiert würde oder wurde, ist uninteressant. Die Messung im Nachhinein ist zwar möglich - aber sollte nicht zur Kalibrierung von Faktoren führen. “Aha, der Faktor 2 bedeutet 4 Tage! Beim nächsten Mal werden wir das bei der Planung berücksichtigen.” Solche Gedanken sind irrig. Sie führen konsequent in Konflikte aufgrund von falschen Voraussagen. Sie erzeugen Unzuverlässigkeit.

Außerdem sind solche Voraussagen für eine Qualitätsorientierung völlig überflüssig. Durch (nicht einhaltbare) Versprechen von einer bestimmten Qualität zu einem bestimmten Zeitpunkt wird keine Qualität hergestellt. Qualität wird ausschließlich dadurch hergestellt, dass man programmiert. Schnellstmöglich geschieht das, wenn die Reihenfolge der Aufgabenabarbeitung wertmaximierend ist.

Es ist also viertens zu messen, in welchem Umfang die feedbackfähigen Aufgaben gemäß Wert und Aufwand priorisiert abgearbeitet werden. Dazu wird der Wert durch den Aufwand geteilt. Das Verfahren heißt Weighted Shortest Job First (WSJF) und berechnet für jede Aufgabe ein Gewicht, das umgekehrt proportional zur Priorität einer Aufgabe ist: je kleiner das Gewicht, desto höher die Priorität.

Dass irgendwann irgendwer beurteilt, ob eine Aufgabe mit der erwarteten oder dann benötigten Qualität umgesetzt wurde, muss nicht diskutiert werden. Das ist auch in voragilen Zeiten so gewesen.

Echte Qualitätsorientierung braucht jedoch mehr. Sie will möglichst schnell wissen, ob sie erfolgreich ist. Es kommt also nicht nur auf die Reaktionszeit für die Aufnahme der Arbeit an einer neuen Anforderung an, sondern auch auf die Reaktionszeit des Abnehmers.

Bei der Reaktionsfreudigkeit kann es zu Verschwendung kommen. Bei der Qualitätsbeurteilung auch. Sie setzt ein, sobald die Abnahme einer fertiggestellten Qualität sich verzögert. Dann liegt Wert auf Halde. Was erarbeitet wurde, kann seinen Wert - falls es den hat - noch nicht entfalten. Es wurde ja noch nicht beurteilt.

Zu messen ist also die Zeit zwischen Fertigstellung und Abnahme. Wie lange dauert es, von dem Moment, da die Programmierung sagt “Fertig! Aufgabe umgesetzt.”, bis zu dem Moment, da der Abnehmer sich das anschaut?

Dass der Verzug möglichst klein sei, ist aber nicht nur für den Kunden von Interesse, damit er schnell Wert in die Hand bekommt. Denn nicht immer ist die gewünschte Qualität ja auch durch die Softwareproduktion erreicht. Das Vorgestellte kann einen Fehler enthalten, missverstanden sein oder aus anderen Gründen nicht recht passen. Dann muss nachgebessert werden.

Nachbesserungen reduzieren die Kapazität der Softwareproduktion für Neues. Nachbesserungen stellen Wert verspätet her. Das kann nicht im Sinne von Agilität und Flüssigkeit sein. Daraus ergibt sich eine weitere Messlatte: Wie oft kommt es zu Nachbesserungen?

Nachbesserungen können bei der Abnahme gefordert werden; es handelt sich um Bugs oder Korrekturen von Missverständnissen bzw. Unvollständigkeiten. Oder sie kommen quer herein vom Support. Je mehr es gibt, desto schlechter ist es um die Qualitätsorientierung bestellt.

Bitte bemerken Sie: Ich fordere hier keine Unit Tests oder eine QA. Auch keine Rolle für die Anforderungsanalyse. Das sind alles nur mögliche Mittel, um die eine oder andere Metrik zu verbessern. Genau das ist ja aber hier nicht der Punkt. Es geht nicht um Maßnahmen, sondern erstmal nur den Vorschlag einer Sammlung von Messlatten für die Agilität.

Eine Rolle für die Abnahme ist jedoch zwingend. Sonst kann das, worum es der Agilität geht, nicht beurteilt werden.

Qualitätsorientierter ist also, wer inkrementeller in gewichteter Weise voranschreitet und schnelleres Feedback mit weniger Nachbesserungswünschen erhält als andere oder vormalig er selbst.

Nachhaltigkeit

Zu guter Letzt die Nachhaltigkeit. Wie könnten wir die messen?

Nachhaltig handeln bedeutet, jetzt etwas tun, das unsere Optionen in der Zukunft nicht verringert, sondern bestenfalls sogar erhöht. Ressourcen, die heute zur Verfügung stehen, dürfen ihre Kapazität nicht verlieren; sie sollten sie sogar tendenziell steigern.

Nachhaltigkeit erfordert also die Beobachtung der Entwicklung von Ressourcen.

Die für die Softwareentwicklung relevanten Ressourcen sind: die Menschen, der Produktionsprozess und die implementierte Lösung, d.h. Code und nötige Infrastruktur.

Zu messen ist zunächst, ob die Beobachtung dieser Ressourcen überhaupt stattfindet.

Nach allgemeinem Sprachgebrauch würde ich sagen, dass Reviews die implementierte Lösung beobachten und Retrospektiven Menschen und Prozess.

Wie die Beobachtung in Reviews und Retrospektiven erfolgt, ist eine zweite Sache. Aber die Diskussion darüber ist nicht Teil dieser Betrachtung.

Beobachten ist gut, nur was passiert dann mit den Erkenntnissen? Sicherlich werden in Reviews und Retros Entscheidungen für Veränderungen getroffen, die umgesetzt werden müssen. Das mag für einige “einfach so” im Tagesgeschäft gehen. Um das verlässlich hinzubekommen, muss die Organisation ein Bewusstsein für und den Willen zu Verlässlichkeit haben. Hat sie das aber wirklich? Das sollte gemessen werden. Welche Versprechen werden gegeben, wie viele davon werden eingehalten, wie viele gebrochen, wie viele neu verhandelt, bevor man sie erfüllt?

Nicht alle beschlossenen Veränderungsmaßnahme lassen sich jedoch sofort umsetzen. Angesichts der Entwicklungsgeschwindigkeit unserer Branche ist zu erwarten, dass immer etwas so neu und umfangreich ist, dass die Organisationsmitglieder es sich erst außerhalb der normalen Produktion erarbeiten müssen. Dafür muss Raum zum Lernen bereitstehen - und zwar nicht nur gelegentlich, ad hoc, sondern kontinuierlich. Nur so erhält sich jeder Einzelne und die Organisation als Ganzes Zukunftsfähigkeit. Zu messen ist also mindestens der Anteil der Lernzeit an der Arbeitszeit. Besser jedoch sollte auch noch gemessen werden, wie hoch die Lernfrequenz ist.

Beobachten und Lernen ist gut, aber kann auch zu spät kommen oder nicht die gewünschte Wirkung entfalten. Zur Nachhaltigkeit gehören deshalb Puffer, um Minderleistungen bzw. Unerwartetes jeder Art abzufedern. Die Organisation darf gar nicht erst in eine Situation kommen, die ihre Existenz bedroht.

Welche Puffer es geben kann/gibt, hängt von den im Einsatz befindlichen Ressourcen ab. Naheliegend ist da der Gedanke ans liebe Geld. Oder der an Maschinen. Aber auch Mitarbeiter, deren Zeit, deren Motivation, deren Kenntnisse, deren Kreativität sind Ressourcen. Oder Kunden. Oder Zulieferer.

All das und mehr hat jeweils eine Menge, Leistungskraft, Kapazität, die für die aktuelle Produktion gerade reicht - oder eben größer sein sein. Was ist, wenn unerwartete Veränderungen in der Umwelt oder in der Organisation fordern, dass eine Ressource sich mehr als bisher einbringt? Ein Mitarbeiter will in die Elternzeit gehen, ein Mitarbeiter kündigt, ein Zulieferer fällt aus, ein Kunde springt ab, eine neue Technologie soll zukünftig verwendet werden, eine neue Anforderung erweist sich als deutlich schwieriger als angenommen in der Umsetzung… Das sind Belastungen jenseits des Normalen, für deren Bewältigung Reservekapazität, d.h. Puffer vorhanden sein müssen.

Gibt es dafür Puffer? Das sollte gemessen werden. Zugegeben, das mag nicht leicht fallen. Aber das Mindeste ist, sich überhaupt der Wichtigkeit von Puffern bewusst zu sein. Existiert also zumindest dieses Bewusstsein? Gibt es einen Willen zum Aufbau und Vorhalten von Puffern? Ich denke, das lässt sich schon in Gesprächen mit Organisationsmitgliedern herausfinden.

Nachhaltiger ist also, wer reflektierter und zuverlässiger bewusst lernend und gepuffert produziert als andere oder vormalig er selbst.

Zusammenfassung

Puh… da ist einiges zusammengekommen. Das hätte ich am Anfang nicht gedacht, als ich begann, diesen Artikel zu schreiben. Vorher wusste ich das nicht so genau, weil Schreiben für mich immer auch Nachdenken ist. Während des Schreibens entwickelt sich oft erst, was ich eigentlich denke.

Hier die Messinstrumente nochmal in der Übersicht:

• Reaktionsfreudigkeit

• Reaktionszeit bis zur Aufnahme der Arbeit an einer neuen Anforderung

• Umfang der durch eine Änderung entstehenden Regression

• Rüstzeit bis zum Beginn produktiver Arbeit an einer neuen Anforderung

• Qualitätsorientierung

• Prozentsatz der Aufgaben, die Inkremente darstellen

• Prozentsatz der Inkremente, die mit einem Wert versehen sind

• Prozentsatz der Inkremente, die mit einem Aufwand versehen sind

• Prozentsatz der Inkremente, die nach Gewicht (Wert/Aufwand) priorisiert abgearbeitet werden

• Wartezeit von Fertigstellung einer Aufgabe bis zur Abnahme

• Menge der Nachbesserungen bei Abnahme und vom Support

• Nachhaltigkeit

• Frequenz von Reviews

• Frequenz von Retrospektiven

• Zahl der erfüllten, gebrochenen, nachverhandelten Versprechen

• Prozentsatz der Lernzeit an der Arbeitszeit

• Frequenz der Lernzeiteinheiten

• Anzahl und Größe von Puffern

Ist das nicht ein bisschen viel? Volkers drei Dimensionen waren so schön übersichtlich.

Keine Ahnung, ob das am Ende zu viele Messinstrumente sind. Im Augenblick wüsste ich aber nicht, welches davon unnötig wäre. Sie scheinen zwar unterschiedlich wichtig zu sein, man muss wohl nicht sofort alle in Anschlag bringen. Andererseits ist ja auch nicht alles schwierig zu messen.

Wie es um Reviews steht oder ob in Inkrementen vorangeschritten wird, ist doch leicht zu messen. Rüstzeiten oder der Umgang mit Versprechen hingegen, mögen schwieriger zu beurteilen sein.

Würde es nicht reichen, einfach nur auf Scrum oder Kanban zu setzen? Scrum führt doch z.B. Retros und Inkremente ein und zwingt zu Versprechen. Damit wird doch das Richtige getan. Ja, einerseits. Dagegen ist nichts zu sagen - solange man versteht, warum (!) Scrum das macht. Solange man versteht, dass das nicht alles ist. Eine Diskussion über Kriterien und Metriken für Agilität ist eine andere als eine über Maßnahmen.

Wenn einige der Metriken hier schon wie klare Empfehlungen zu Maßnahmen aussehen, dann ist das ja nicht schlecht. Bei anderen Metriken habe ich mich aber bewusst zurückgehalten. So dachte ich z.B., dass auch gemessen werden könnte, ob/wie Zeitmanagement gelebt wird. Aber das wäre zu viel Vorgabe. Solange Zuverlässigkeit vorhanden ist, ist es egal, wie sie entsteht. Dito muss nicht gemessen werden, ob ein ProductOwner vorhanden ist, der Inkremente formuliert. Woher die kommen, wer die Werte und Aufwände bestimmt… keine Ahnung. Solange es geschieht, ist das doch egal.

Maßnahmen, wie Messwerte über die Zeit verbessert werden können, können sich Organisationen selbst überlegen oder von anderen abschauen und ausprobieren. Dafür ist die Reflexion da. Dass die da ist, muss dann jedoch gemessen werden.

Und warum reicht Kanban nicht einfach? Für meinen Geschmack stellt sich Kanban in mancher Hinsicht zu dumm. Transparenz + WIP Limit: mehr braucht es am Ende nicht. Das mag ultimativ korrekt sein - nur dauert es dann womöglich länger als nötig, um die richtigen Maßnahmen zu finden.

Bei systemischen Ansätzen soll der Klient ja die Lösung immer in sich finden. Schöner Gedanke. Natürlich muss die Lösung auch zum Klienten passen. Die Frage ist nur, wie kommt der Patient zu dieser Lösung? Ich glaube, dafür darf der Klient erstens Input von außen erhalten; ein Coach darf Vorschläge unterbreiten und Sichtweisen äußern. Und zweitens gehört dazu eben eine sehr feine Wahrnehmung. Um beurteilen zu können, was ihm taugt, muss der Klient die Effekte, die eine Idee oder probeweise Veränderung hervorruft, sehen, hören, schmecken, tasten, spüren, fühlen. Es braucht schlicht Messungen entlang vieler Dimensionen.

Ein WIP-Limit und der aus seinem Erreichen resultierende Schmerz sind mir da zu wenig und kommen womöglich zu spät. Wenn ich von einer Sache keine Ahnung habe, dann fange ich vielleicht mit diesem Minimum an. Aber von Softwareentwicklung sollten wir Ahnung haben und deshalb schon wissen, wo es haken kann. Da sollten wir dann Messpunkte einrichten. Dafür habe ich hier mal ein paar Vorschläge gemacht.

Ausgehend von einer Definition dessen, was überhaupt erreicht werden soll - reaktionsfähige nachhaltige qualitätsorientierte Softwareproduktion - sollten wir zunächst darüber sprechen, wie sich deren Güte ausdrücken könnte. Welche Attribute hat sie? Wenn wir sofort zu Maßnahmen springen, dann ist das gut gemeint, führt aber eben schnell zu Ritualen ohne Verbesserung der Attributwerte. Der Effekt ist das, was wir seit Jahren bei der Agilität sehen: Es wird Orthodoxie und Häresie gesprochen. Die Maßnahmen werden zum Problem. Das eigentliche Problem tritt in den Hintergrund.

Wenn wir uns jedoch zunächst über geeignete Messpunkte unterhalten, dann sind wir viel offener, was die Maßnahmen angeht. Vielleicht behalten manche Maßnahmen ihren Wert. Vielleicht finden sich aber auch ganz andere Maßnahmen, ohne dass man sich dafür entschuldigen müsste. Denn es zählen die Ergebnisse: bessere Messwerte. Morgens zusammen stehen oder co-location oder story point Schätzungen… Ist doch egal, solange etwas besser wird.

Die Verlagerung des Fokus auf Attribute und Messinstrumente lässt auch Raum für unterschiedliche Level an Agilität. Muss denn jeder maximal agil sein? Oder reicht es, angemessen agil zu werden für einen gewissen Kontext? Oder gibt es eben ganz unterschiedliche Maßnahmenausprägungen für Agilität je nach Kontext?

Messungen statt Maßnahmen an den Anfang zu setzen, scheint mir überfällig und zeitgemäß. Damit wird der Individualität von Organisationen mehr Rechnung getragen. Damit erhalten Organisation mehr Autonomie, den ihnen gemäßen Weg zur Agilität zu finden.

Agilität ist kein Absolutum. Sie ist ein Mittel, das dosiert einzusetzen ist, um mit Unsicherheit, mit Komplexität umzugehen. Wenn die aber unterschiedlich ist für verschiedene Organisationen, dann sollte die Agilität das widerspiegeln.

Das bedeutet: Am Anfang jeder Agilität steht die Entscheidung für eine Definition und der Wille zur Messung relevanter Attribute mit kontinuierlicher Reflexion über die Beobachtungen und Ableitung geeigneter Maßnahmen, um die Werte mehr in Einklang zu bringen mit den Notwendigkeiten, die sich aus Veränderungen im Außen und Innen ergeben.