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.

Mehr Kohäsion als alternativlos erachtet

Kohäsiv ist, was zusammenhält. In der Softwareentwicklung ist es eine Tugend, das Kohäsive zu identifizieren und ihm durch ein Modul auf angemessenem Level eine Form zu geben. Module sind Container für das, was zusammengehört. Zum Zwecke der Wandelbarkeit.

Was in einem Modul zusammengefasst ist, kann sich weniger gestört durch die Umwelt weiterentwickeln. Das Modul zieht eine Grenze, einen Schutzwall.

Umgekehrt schützt das Modul die Umwelt vor den Entwicklungen in ihm. Jedenfalls wenn die Modulgrenze angemessen ausgelegt ist.

Hohe Kohäsion, lose Kopplung: das ist einer der zentralen Sätze für zukunftsfähige Softwarearchitektur.

Aber was ist kohäsiv? Und ist das, was heute zusammenhängt, morgen auch noch zusammenhängend? In „Sweet Aspects“ habe ich versucht, die Relativität und Volatilität von Kohäsion anschaulich darzustellen.

Es ist also nicht die Frage, ob es in einer Menge von Elementen Kohäsion gibt, sondern welche. Wird erkannt, was kohäsiv ist? Und wird dem Rechnung getragen.

So ist das bei Software. Aber so ist das auch bei Menschen. Menschen gehören zueinander. Anders als bei Softwareartefakten, wählen wir selbst jedoch die, die uns nahestehen. Wir modularisieren uns sozusagen autonom. Familie, Sportmannschaft, Verein, Unternehmen, Glaubensgemeinschaft, Nation... Das sind unsere ideellen Container. Die grenzen wir von anderen ab. Dafür suchen wir uns sogar physische Entsprechungen, vom Gebäude bis zum Territorium.

Und umgekehrt: Was „auf einem Haufen“ versammelt ist, hat besser hohe Kohäsion. Sonst kommt es zu Unverständnis und Spannungen. Sonst entsteht keine Gemeinschaft. Kräfte werden dann unproduktiv in Konflikten verschwendet, statt sie auf die Erreichung gemeinschaftlicher Ziele anzuwenden. Und am Ende zerfällt der nicht kohäsive Haufen in kleinere mit höherer Kohäsion.

Das ist nur natürlich. Manchmal funktioniert es besser, manchmal nicht so gut. So ist das menschliche Gemeinschaftsgefüge auch immer in Bewegung. Derzeit wieder ganz gehörig.

Die Zusammensetzung der Mitglieder in unserem hübschen Staatscontainer „Deutschland“ ändert sich gerade gewaltig. Wir haben mal geglaubt, die Zuwanderung von Gastarbeitern sei ein Problem, das zu Überfremdung führt. Doch das ist schon länger kein Thema mehr. Gastarbeiter sind keine Gastarbeiter mehr, sondern Dauerarbeiter geworden. Sie gehören zu Deutschland wie der deutsche Wald. Knapp 20% der Bevölkerung Deutschlands haben erwähnenswerten Migrationshintergrund. 10% sind sogar immer noch Ausländer. Das ist normal. Das ist gut so.

Die, die zunächst keine hohe Kohäsion hatten – Deutsche und Spanier, Griechen, Italiener, Türken, Chinesen und wer noch alles zugezogen sein mag –, haben sich zusammengerauft. Das nennt man erfolgreiche Integration. Wir haben uns auf einander zu bewegt.

Dass nicht alles eitel Sonnenschein ist, ist klar. Das war es im „ursprünglichen Deutschland“ aber auch nicht. Vor historisch gesehen kurzer Zeit haben allein wir Deutschen uns selbst und der Welt ja noch so einige Probleme bereitet.

Integration hat funktioniert. Über 20, 30, 40, 50 Jahre sind Millionen von Ausländern zu Inländern geworden. Eine großartige Leistung!

Vor allem aber auch eine nötige Leistung, denn sonst wäre der deutsche Staatscontainer auseinandergebrochen. Er hätte sich quasi selbst refaktorisiert. Extract nation hätte die Operation wohl geheißen. So wie 1990 die Operation Inline nation ausgeführt wurde: Die DDR ist der BRD beigetreten.

Exportweltmeister sind wir ja schon. Vielleicht sollten wir uns also auch Integrationsweltmeister nennen? 20 Millionen Ausländer, 20 Millionen DDR-Bürger: alles integriert – und immer noch ein Land, in dem wohl die meisten gerne leben. Ist das nicht eine großartige Leistung?

Andere finden das Ergebnis jedenfalls sehr attraktiv. So attraktiv, dass sie ebenfalls nach Deutschland kommen wollen. Sei es aus wirtschaftlichen Gründen oder weil sie schlicht Schutz für Leib und Leben suchen. Ihr Bild von Deutschland: hier gibt es Geld und/oder Sicherheit.

Können wir nicht stolz darauf sein, so ein Bild zu vermitteln? Trotz oder vielleicht sogar wegen all der Integrationsleistung, die in Deutschland vollbracht wurde, sind wir so etwas wie das gelobte Land geworden.

Dieses Bild ist sicher eine Überhöhung. Wir können ihm nicht einfach so gerecht werden. Milch und Honig fließen hier nicht. Doch woanders fließen mehr Tränen und vor allem Blut. Selbst wenn wir nur Milchpulver und Zuckerrübensirup zu bieten hätten, wäre das für viele eine deutliche Verbesserung.

Aber wollen wir das? Über diese Frage lässt sich lange diskutieren. Letztlich ist sie jedoch müßig. Die kanzlerische Alternativlosigkeit findet hier nämlich eine berechtigte Anwendung. Wir können nicht anders, als Menschen, viele Menschen an- und aufnehmen zu müssen. Sie sind schlichtweg da. Nicht nur vor der Tür, sondern schon im Flur oder gar im Wohnzimmer. Wer fragt „Wolle ma se reinlasse?“ kann das nur rhetorisch meinen.

Zwar hatten wir schon länger keine explizite Einladung mehr ausgesprochen – Deutschland ist kein Einwanderungsland, das aktiv um Zugüge im Ausland wirbt –, d.h. die, die nun schon da sind, sind keine geladenen Gäste. Deshalb ist die Frage selbstverständlich erlaubt, wen wir diesseits der Haustür wirklich bewirten wollen. Und die Antwort wird nicht für alle, die schon drin sind, positiv ausfallen.

Doch egal, wie das Gastkriterium auch formuliert ist oder werden mag, es werden viele bleiben. Und wohl vor allem schneller mehr, als in bisherigen Jahrzehnten. Das ist so. Das ist auf die eine oder andere Weise eine schlicht historische Konsequenz. Ich möchte hier sogar von Karma sprechen.

Deutschland und vor allem Europa erleben eine Bewegung, die vor Jahrzehnten oder gar Jahrhunderten angestoßen wurde. Von wem? Irgendwie wäre das schon wichtig zu eruieren, wenn man versuchen möchte, näher an der Wurzel etwas zu verändern. Andererseits führt diese Frage auch schnell in ein unendliches Fingerzeigen, das bei Obama/Bush beginnen mag und selbst bei Papst Urban II nicht enden würde.

Im Menschlichen herrscht, wie in der Physik, das Prinzip Actio und Reactio. Wer Gewalt benutzt, wird Gegengewalt erzeugen. Früher oder später. Der Abgrund ruft den Abgrund.

Aber einerlei. Es ist wie es ist. Die Tür ist auf, viele, viele Gäste strömen herein. Quasi Facebook-Party auf nationalem Niveau.

Die Frage der Stunde lautet: Was tun? Und die allererste, alternativlose Antwort ist: Integration. Jetzt! Sofort! So schnell wie möglich.

Zwei Phasen müssen wie bei jede Katastrophe schnellstmöglich durchlaufen werden:

1.     Triage

2.     Hilfe

Ursachenanalyse usw. muss auch geschehen. Parallel. Vor Ort kann es jedoch keine zwei Meinungen geben. Da sind die Ressourcen knapp und sollen bestmöglich eingesetzt werden.

Wenn es so sein kann, dass nicht alle die, die Deutschland so attraktiv finden, auch willkommen sind, dann muss das Kriterium dafür schnellstmöglich angewandt werden. Jeder Tag, den seine Anwendung später erfolgt, kostet Ressourcen, die der echten Hilfe nicht zur Verfügung stehen. Das ist Verschwendung pur. Jeder Tag Verzögerung lässt auch den Widerstand in der Bevölkerung wachsen, weil Unentschiedenheit als Führungslosigkeit gedeutet wird und Unsicherheit schürt.

Triage ist eine harte Sache. Immer. Sie wiederspricht dem Reflex des Altruismus. Aber es hilft im wahrsten Sinne des Wortes nichts: Wo Ressourcen knapp sind, müssen sie hier zugewiesen und woanders entzogen werden.

Über die Kriterien kann man ja, nein, muss man diskutieren. Aber nicht darüber, ob es Kriterien geben sollte. Und wenn man sich festgelegt hat, dann muss man sie anwenden. Zügig. Und dann muss man beobachten, ob man mit dem Ergebnis zufrieden ist. Und man muss akzeptieren, dass es zu Fehlern kommt. Es wird zu false positive und zu false negative Bewertungen kommen.

Je größer der Ansturm der Gastkandidaten, desto eher brauchen wir quasi Judge Dredd vor Ort für eine Triage. Das ist bei jeder Katastrophe so. Und die liegt vor.

Nach der Triage schnellstmögliche Hilfe. Das bedeutet in diesem Fall: Integration der Gäste. Rigoros. Alternativlos.

Denn wie lange die Gäste bleiben, ist ja unbekannt. Und angesichts des Weltenlaufs in den letzten Jahrzehnten sollten wir uns wohl eher auf länger denn kürzer einstellen. Aber selbst wenn sie nach 2-3 Jahren wieder heimreisen sollten, würden sie und wir von einer schnellen Integration profitieren. Sie nähmen in ihre Heimat nämlich ein bestätigtes gutes Bild von Deutschland mit. Deutschland wäre das Land, in dem sie so willkommen geheißen wurden, dass man sie sogar integriert hat.

Integration bedeutet natürlich vor allem Angleichung der Gäste an den Gastgeber Deutschland. Das ist für Deutsche selbstverständlich; Gäste mögen da eher zögerlich bis unwillig sein. Sie wollten doch „nur“ Geld und/oder Schutz. Aber es hilft nichts. „Nur“ gibt es nicht in dieser Größenordnung. Geschenke kann es geben im Leben – doch wie spätestens die vielen Gratisangebote im Internet auch dem letzten klar gemacht haben sollten: am Ende ist doch nichts umsonst. Und der Preis für den Empfang der Segnungen Deutschlands ist... Integrationswille. Jeder Gast ist aufgefordert, nach Kräften mitzumachen.

Doch die Integration ist keine Einbahnstraße. Es ist nicht zu vermeiden, dass auch die deutsche Gesellschaft sich den „Neuzugängen“ annähert. Es ist immer eine Co-Evolution. Anderes anzunehmen wäre naiv. Wir sehen es ja jeden Tag auf der Straße.

Wenn man das zulässt, dann ist das auch angenehm. Wer möchte auf die kulturelle Vielfalt in Deutschland denn wirklich verzichten? Nicht nur will ich in Hamburg einen Schwarzwälder Schinken genießen, ich möchte auch zum türkischen Friseur oder libanesischen Restaurant oder einem Diskussionskreis in der Moschee gehen können.

Also Integration. Aber wie?

Beim Couchsurfing im fernen Land sich nur mit Händen und Füßen verständigen, mag für ein paar Tage witzig sein. Da lernt man etwas fürs Leben.

Wenn Flüchtlinge und andere „Deutschlandfans“ jedoch nach der Triage hier bleiben dürfen, dann ist es nicht witzig, wenn sie uns und wir sie nicht verstehen. Das behindert vielmehr die so wichtige Integration. Kein gesellschaftlicher Anschluss, keine Job ohne gute Sprachkenntnisse.

Wir brauchen Kohäsion und die beginnt bei der Sprache. Sie ist die Bedingung für die Möglichkeit jedes anderen Kontaktes und damit weiterer Annäherung.

Ohne gemeinsame Sprache ist der Grundstein gelegt für den Verbleib im physischen und geistigen Ghetto. Ohne unsere Sprache können Gäste sich nicht zurechtfinden und auch nicht wirklich die Segnungen unserer Gesellschaft schätzen lernen. Vieles muss ihnen kryptisch erscheinen und bleiben. Und umgekehrt: Uns muss vieles als fremd und damit potenziell bedrohlich erscheinen.

Aber sofortige Sprachvermittlung von spätestens Tag 1 nach der Triage an ist nur der Anfang. Wie gesagt: die Bedingung für alle anderen Möglichkeiten.

Der nächste Schritt der Integration muss Bildung sein, die dazu führt, dass Gäste zu unserer Gastgebergesellschaft beitragen können.

Sicherlich gilt das in gleichem, nein, eigentlich sogar größerem Maß zunächst für schon deutsche Bürger. Da mangelt es im Grunde auch an Integration in diesem Sinn. Aber das ist ein anderes Thema. Mir geht es hier um das akute Problem der vielen Einströmenden.

Ja, ich denke, Bildung sofort tut Not. Bildung in Bezug auf unsere Kultur und gesellschaftliche Organisation. Aber auch Bildung im Hinblick auf einen möglichen Beitrag zu dem, was unsere Attraktivität ausmacht und überhaupt ermöglicht, dass wir fähig sind, Gäste aufzunehmen.

Wer kurz zu Besuch kommt, wird bedient. Das ist Ehrensache. Wer aber kommt, um unabsehbar zu bleiben... der wird vom ersten Tag an in unseren Alltag eingebunden. Das weiß jeder, der schonmal in einer WG gewohnt hat.

Aufgabe der Integration ist mithin, die Beitragsfähigkeit alle anerkannten Gäste herzustellen. In maximaler Geschwindigkeit. Jeder Tag Verzug sorgt für Verschwendung und Unsicherheit.

Wenn dann einer schneller wieder geht als gedacht, ohne einen Beitrag geleistet zu haben, dann ist die Investition in ihn auch kein Verlust. Er wird gut davon daheim berichten. Und angesichts der hohen Chance, dass er bleibt, haben wir das Richtige getan: Wir haben Aufbauarbeit geleistet für einen baldigen Beitrag. Wir haben Kohäsion hergestellt. Jeden Tag ein wenig mehr.

Denn ohne Kohäsion keine Einheit. Und wenn die Kohäsion einer Einheit sinkt durch Einflüsse von außen, dann müssen Anstrengung zu ihrer Aufrechterhaltung und Auffrischung unternommen werden. Das ist die oberste strategische Notwendigkeit. Alles andere ist ein Gefahr für die Einheit. Es ist wahrhaft Lebensgefährlich, nicht sofort in Integration zu investieren.

Softwareartefakte werden fremdorganisiert. Wir als Menschen müssen uns selbst organisieren. Die Gesetzmäßigkeiten sind jedoch dieselben: Erfolg setzt Kohäsion voraus. Ohne Kohäsion keine Kohärenz, keine Kraft zur Erreichung von Zielen.

Sinkt die Kohäsion durch Einmischung neuer Menschen, dann muss dem gegengesteuert werden. Grenzziehung hilft da nur bedingt. Vor allem muss integriert werden. Nur dann sind wir auf Dauer fähig, uns weiter mit der Welt zu wandeln – zumindest wenn wir das Modul „Deutschland“ für erhaltenswert befinden.

Geschätztes Desaster

Glauben Sie noch, dass sich Aufwände in der Softwareentwicklung abschätzen lassen? Ja, wirklich? Dann beruht Ihr Glaube zumindest zum Teil auf der Vorstellungen, dass sich Schätzfehler ausgleichen. Mal schätzen Sie etwas zu wenig Aufwand, ein andermal aber schätzen Sie etwas zu viel Aufwand. Oder?

Ja, das hört sich plausibel an. Manche Aufgaben stellen sich als schwieriger heraus, als gedacht, andere als leichter. In Summe heben sich also die Schätzfehler auf. Deshalb funktioniert das Schätzen unterm Strich, auch wenn es nicht fehlerfrei ist.

Ok, dann hier ein Gedankenexperiment:

Das Spiel

Sie haben eine Münze, mit der Sie Kopf oder Zahl mit einer Wahrscheinlichkeit von jeweils 0,5 werfen können.

Nun bekommen Sie das Angebot, mit dem Münzwurf Geld zu verdienen - oder zu verlieren. Wenn Sie Kopf werfen, bekommen Sie 1€, wenn Sie Zahl werfen, dann müssen Sie 1€ abgeben. Es geht also um +1€ und –1€ mit einer 50%igen Wahrscheinlichkeit.

Wenn Sie mit 0€ auf Ihrem Spielkonto beginnen würden, wie viel Geld wäre ungefähr nach 50 Würfen darauf?

a) ca. 0€ b) ein deutlich von 0€ abweichender Betrag

Überlegen Sie ruhig einen Moment…

Ich habe diese Frage einigen mathematisch normal gebildeten Menschen gestellt. Deren überwiegende Antwort war a). Sie glauben, dass sie mit so einem Spiel über 50 Würfe weder Geld verdienen noch verlieren würden.

Die Begründung: Gewinn und Verlust gleichen sich ja wegen der Wahrscheinlichkeit von 50% für beide Ergebnisse aus.

Die Statistik

Die Antwort aus dem Bauch heraus ist verständlich. Sie ist auch korrekt für eine genügend große Zahl von Spielen. Über ganz viele Spiele hinweg sollte der Kontostand bei 0€ sein. So wie der Mittelwert über viele Münzwürfe (Kontobewegungen) auch 0€ ist.

Die Frage war ja aber nicht, wie der Kontostand im Mittel am Ende von vielen Spielen wohl wäre, sondern am Ende eines Spieles. Und da liegt die Antwort aus dem Bauch heraus weit neben der Realität.

Am Ende eines Spieles ist der Kontostand sehr wahrscheinlich deutlich von 0€ abweichend. Hier als Beispiel ein Simulationsergebnis:

Sie sehen, am Ende des Spiels hätten Sie 10€ verloren!

Oder hier ein Verlust von 4€:

Oder hier ein Verlust von 16€:

Oder hier, oh, ein Gewinn von 4€:

Usw. usf.

Die Kontobewegungen (blaue Linie) in den Simulationen bewegen sich hübsch pendelnd um die Nulllinie. Pro Spiel ist die Zahl der Würfe groß. Der Mittelwert der Kontobewegungen ist nahe 0€.

Doch die Kontostände… die bewegen sich deutlich unterhalb oder oberhalb der Nulllinie.

Noch ein Beispiel gefällig? Hier ein Gewinn von 5€ - allerdings nur bis knapp nach der Spielmitte. Danach stürzt das Konto ab auf –6€.

Sie sehen, auch das Spiel mit einer Wahrscheinlichkeit von 50% für Gewinn und Verlust ist ein Spiel, bei dem Sie deutlich verlieren (oder gewinnen) können.

Auf der schiefen Bahn

So weit das faire Spiel. Beide Münzseiten werden mit derselben Wahrscheinlichkeit geworfen. Was aber, wenn die Münze unregelmäßig ist? Was, wenn Sie mit etwas größerer Wahrscheinlichkeit verlieren? Statt 50% Gewinnchance haben Sie vielleicht nur 45%. Dann kann Ihnen das passieren:

Klar, das Ergebnis muss nicht immer unter 0€ liegen - aber selbst im Mittel über viele Spiele hinweg, werden Sie die 0€ nicht mehr erreichen, sondern Verlust machen. Und das wird immer schlimmer, je weiter sich die Wahrscheinlichkeit für Zahl zu Ihren Ungunsten verschiebt.

Mit einer größeren Wahrscheinlichkeit für Verlust als für Gewinn kommen Sie auf eine schiefe Bahn. Sie rutschen in die Spielschulden. Garantiert über mehrere Spiele hinweg. Aber auch steiler innerhalb nur eines Spieles.

Geschätzte Annahmen

Nun zurück zur Softwareentwicklung. Ich denke, Sie verstehen, worauf ich mit diesem Gedankenexperiment hinaus will:

Selbst wenn sich Ihre Schätzfehler aufheben, laufen Sie Gefahr, Ihr Projekt ins Desaster zu fahren.

Ihr Projekt ist wie ein Spiel. In dem schätzen Sie 50 Aufwände oder 100 oder 500… Das bedeutet aber nicht, dass Sie bei sich aufhebenden Schätzfehlern am Ende on time, on budget herauskommen. Wie die Simulationen zeigen, können Sie sich weit, weit in die Miesen gefahren haben. Und das, obwohl die Wahrscheinlichkeit für positives und negatives Verschätzen gleich sind.

Sie könnten auch gewinnen. Das stimmt. Aber wollen Sie bei einem Projekt wirklich spielen? Ist es das, was Sie für Ihren Kunden sein wollen: ein Spieler, der auf sein Glück hofft?

Wie die Grafiken zeigen, kann Sie das Glück ganz schön pro Spiel, ich meine, pro Projekt im Stich lassen. Und das, obwohl hier sehr günstige Annahmen zugrunde liegen.

Annahme 1: Positives und negatives Verschätzen gleichen sich aus. Ist das aber in der Realität wirklich, wirklich anzunehmen? Das glaube ich nicht. Diese Abschätzung, die Sie da machen, dass das Verschätzen eine Wahrscheinlichkeit von 50:50 hat, hat einen Fehler. So wie ich die Entwicklungsrealität kennengelernt habe, verschätzen Sie sich mit viel größerer Wahrscheinlichkeit zu Ihren Ungunsten. Wir müssten also nicht mit 50:50 simulieren, sondern eher mit 20:80: nur mit einer Wahrscheinlichkeit von 0,2 schätzen Sie zu große Aufwände; in 80% der Fälle schätzen Sie jedoch zu kleine Aufwände. Damit fährt das “Projektkonto” direkt in die Miesen. Probieren Sie es selbst aus in einer kleinen Excel-Simulation.

Annahme 2: Wenn Sie glauben, dass Sie sich in etwas so oft zu Ihren Gunsten wie zu Ihren Ungunsten verschätzen, dann beziehen Sie das wahrscheinlich auf die Anzahl Ihrer Schätzungen: bei 50 Schätzungen schätzen Sie 25 Mal zu wenig und 25 Mal zu viel.

Aber was ist eigentlich mit der Größe des geschätzten Aufwandes? Der hängt von der Größe der Aufgabe ab. Diese Größe variiert jedoch wahrscheinlich beträchtlich. Mal sind die Aufgaben klein, mal sind sie größer, dann sogar groß. Wie ist diese Größenverteilung? Und verschätzen Sie sich bei jeder Größe in gleicher Weise?

Glauben Sie wirklich, dass Sie auch das realistisch einschätzen? Ich erlaube mir, das zu bezweifeln.

Wenn nun aber die Größen der Aufgaben unterschiedlich sind und Ihr Schätzfehler ebenfalls unterschiedlich ist… dann wird damit die Unvorhersehbarkeit des “Projektspiels” angeheizt.

TL;DR

Wenn Sie glauben, Aufwandsschätzungen in der Softwareentwicklung könnten funktionieren, weil sich positive und negative Schätzfehler doch aufheben würden… dann machen Sie die Softwareentwicklung zu einem Glücksspiel. Denn auch bei 50:50 Chancen für Gewinn und Verlust, kann Sie ein einziges Spiel mit mehreren “Würfen” weit in die Miesen führen.

Dafür, dass das Gesetz der großen Zahl Ihnen ein ausgeglichenes Konto beschert, führen Sie einfach zu wenige Projekte durch.

Widerstehen Sie also der Spielsucht. Glauben Sie nicht länger, am Ende doch noch abzuräumen und alle Schulden zurückzuzahlen.

Rezension: Macht, was ihr liebt!

Schon wieder ist es passiert: Ich habe ein Buch des Autorenduos Förster & Kreuz gelesen. Beim letzten Mal ist es “Nur Tote bleiben liegen” gewesen. Das hatte ich dann zufällig und positiv in einem Blogartikel erwähnt - und schon wurde ich nun angesprochen, ob ich nicht auch das neueste Buch rezensieren möchte.

Da der Verlag - diesmal nicht Campus, sondern Pantheon - mir sogar eine eBook-Version zur Verfügung stellte, habe ich gern einmal reingeschaut und schreibe als Gegenleistung darüber. Aber keine Sorge, ich fühle mich nicht gekauft. Weitere Zuwendungen gab es nicht. Und da es mir an Lesestoff nicht mangelt, habe ich auch das Gratisbuch nicht als Lohn empfunden.
Also, dieses Mal nun “Macht, was ihr liebt!”.

Lohnt es sich, das Buch zu lesen?

Ich sage es mal so: Wenn man von den Autoren noch nichts gelesen hat und/oder Ermunterung für einen Aufbruch in Lebens- bzw. Arbeitsveränderungen sucht, dann sind die 9,99€ für die eBook-Ausgabe gut angelegt.

Dafür bekommen Sie 66 1/2 sehr überschaubare “Muntermachgeschichten” für Zwischendurch geliefert. Die lassen sich beim Pendeln mit Bus und Bahn locker zwischendurch lesen. Oder morgens als “Energizer” für den Tag. Lassen Sie das Radio aus, vermeiden Sie den Blick in die Tageszeitung. Was Sie dort hören oder lesen ist frustrierend; ein guter Start in den Tag sieht anders aus.

Motivierend ist hingegen, was Förster & Kreuz in Kurzform über Menschen zusammengetragen haben, die “einfach” tun, was sie lieben.
Das ist nicht tiefschürfend, aber vielfach einfach wahr. Ich jedenfalls konnte nicht anders als immer wieder innerlich zu nicken. Meine eBook-Seiten sahen deshalb alsbald so aus:

Kaum eine Seite vergeht ohne einen Satz, der der Hervorhebung lohnt.
Es ist also nicht falsch, wenn ich sage, das Buch hat mir gefallen. Ich kann es empfehlen.
Einerseits.

Denn andererseits… Es ist doch auf die Dauer etwas seicht, finde ich. So viel gute Laune, so viele kleine Motivationshappen… und sonst eben recht wenig. Es berichten zwei Paradiesvögel vor allem über andere Paradiesvögel. Da bleibt mir das Praktische, das Umsetzbare ab und an auf der Strecke.

Iris Apfel und Alexandre Farto sind zweifellos beeindruckende und inspirierende Persönlichkeiten. Nur hebt die Häufung solcher Persönlichkeiten zwischen zwei Buchdeckeln irgendwann ab. Da wären mir doch ein paar mehr Geschichten von Menschen wie du und ich noch lieber. Wo ist Ines Bäuerlein (38), Zahnarzthelferin in Unna, die glücklich ist, weil sie macht, was sie liebt? Wo ist Gunnar Schenk (52), Steuerberater in Radebeul, der glücklich ist, weil er macht, was er liebt?

Es ist nicht zu verkennen: Zwei Menschen mit Haus in Frankreich, die sich auch einen Business Class Flug nach Tokio leisten können, schreiben, weil sie das lieben. In jeder Geschichte, die eigene Anekdoten enthält, wird deutlich: Hier sind zwei authentisch. Das ist wunderbar. Weniger wäre für das Thema auch schlecht.

Leider macht es diese Authentizität ca. 97% der Bevölkerung nicht leichter, der Aufforderung zu folgen. Denn angesichts der Einkommensverteilung in Deutschland sind es wohl 97%, die nicht über diese Mittel verfügen. Wer arbeitslos oder alleinerziehend mit zwei Kindern ist, wer als Paketzustellerin oder Verkäufer bei H&M arbeitet, dessen Mittel sind so viel begrenzter.
Etwas mehr Handreichung oder “Volksnähe” würden das Buch meiner Meinung nach also noch besser machen.

So viel zu andererseits.

Meine bottom line: Es war nett zu lesen. Aber es ist wohl mein letztes Förster & Kreuz Buch gewesen. Stil und Botschaft wiederholen sich. Das eine oder andere Buch der beiden Autoren lohnt der ermunternden und horizonterweiternden Lektüre. Quasi als Gegengift zum sonstigen Miesepeterjournalismus. Sie zeigen “Es geht auch anders!” Das ist gut.

Nur wenn ich dann bereit bin, es auch anders zu versuchen… dann braucht es wohl andere Lehrer und Lektüre.

Konsequente Verlässlichkeit - Promise Like a Pro

Die grundlegenden Kompetenzen, die jeder Softwareentwickler haben sollte sind nach Joel Spolsky:

1. Smart, and
2. Get things done.

Dem kann ich nur zustimmen. Und nicht nur für Softwareentwickler gilt dies, würde ich sagen. Es sind die Voraussetzungen für jeden “Wissensarbeiter”, egal ob Programmierer, Tester, Product Owner, Softwarearchitekt, Entwicklungsleiter usw.

Wie es mit der Smartness in der Branche steht, will ich hier nicht diskutieren. Das ist ein schwieriges Feld. Auch wenn ich ein Gefühl dafür habe, was “Smart” bedeutet… eine klare Definition fällt mir noch nicht ein. Da geht es um Auffassungsgabe, Denkvermögen, Abstraktionsvermögen, Konzentrationfähigkeit, Lernfähigkeit und -willigkeit. Weniger allerdings um schon vorhandenes Wissen. Nur soviel ist klar: Smartness ist sehr unterschiedlich verteilt.

Wie es allerdings mit “Get things done” steht, das soll hier mein Thema sein. Denn da ist das Bild grimm.

“Get things done” setze ich gleich mit “zuverlässig sein”. Jemand liefert Zugesagtes wie vereinbart. Ganz einfach. Ohne, dass man ihn andauernd anstoßen muss.

Solche Zuverlässigkeit sehe ich in unserer Branche am Boden. Genauso wie bei der “Büroarbeit” im Allgemeinen. In Ersteres habe ich selbst Einblick, über Letzteres erfahre ich immer wieder von meiner Freundin, die Professional Organizer und Efficiency Trainer ist.

Was wird denn zuverlässig erledigt? Im Kleinen wir im Großen grassiert die Unzuverlässigkeit. Man kommt zu spät zum Meeting, man ruft nicht wie versprochen zurück, Emails werden nicht (in angemessener Zeit) beantwortet, Abschätzungen werden nicht eingehalten, Zulieferungen werden nicht in vereinbarter Qualität gemacht, man vergisst Unterlagen usw. usf. ad nauseam.

Natürlich sind die Entschuldigungen vielfältig. Meist sind “die Umstände” schuld, dass man unzuverlässig ist. Ist das nicht verständlich?

Und da jeder unzuverlässig ist, entschuldigt man sich auch gegenseitig immer wieder. Man nimmt es hin. Man sagt gar “Ach, ist doch nicht so schlimm.” - weil man es ohnehin schon geahnt hatte, dass es nicht so kommen würde, wie es vereinbart war.

Ja, so ist das. Das beobachte ich überall. Und es kotzt mich an. Was ist denn das für eine Art des Umgangs miteinander?

Unabhängig von der Respektlosigkeit die in dieser epidemischen Unzuverlässigkeit steckt, ist sie auch noch kontraproduktiv. Sie trägt dazu bei, dass die Arbeit länger dauert, als sie müsste. Sie trägt dazu bei, dass die Arbeit teurer wird, als sie müsste. Unzuverlässigkeit erzeugt Verschwendung.

Leider ist der Preis, den jeder Einzelne wie auch Unternehmen dafür zahlen, oft kaum messbar. Nachbesserungen und Wartezeiten und zusätzliche Transaktionskosten aller Art sind meist unterhalb des Radars des Controlling. Das sieht dann nur ungünstige makroskopische Effekte und versucht - kaum verwunderlich - mit wenig tauglichen Maßnahmen gegenzusteuern. Eher verschlimmern solche Maßnahmen sogar die Unzuverlässigkeit. Eine negative Spirale beginnt sich zu drehen…

Die Klagen sind laut über die Unzuverlässigkeit. Warum, zum Teufel, können denn Zusagen nicht eingehalten werden? Warum wird zu spät geliefert? Warum ist das alles teurer als geplant? Warum sind die Leute, die zugesagt wurden, nicht da?

Und keiner sieht, dass die Ursache dafür nicht woanders liegt, sondern in jedem selbst.

Wir alle sind für die großen Unzuverlässigkeitsprobleme mit verantwortlich, wenn wir uns schon im Kleinen gleichgültig verhalten, was unsere persönliche Zuverlässigkeit angeht.

Wir haben verlernt, Zuverlässigkeit als Wert anzusehen. Pünktlichkeit war einmal ein Charaktermerkmal, an dem man gemessen wurde. Das ist wie andere auch in Ungnade gefallen. Pünktlichkeit ist heute keine Selbstverständlichkeit mehr. Und andere Zuverlässigkeit auch nicht. WTF!

Wenn wir wollen, dass Kunden mehr Vertrauen in unserer Tätigkeit haben, dann müssen wir etwas dafür tun. Wir müssen die Zuverlässigkeit wieder kultivieren. Wir müssen anstreben, 100% zuverlässig zu sein. Ja, genau: 100% sind das Ziel. Nicht weniger.

Wir müssen jedes, aber auch jedes Versprechen einhalten. Immer. Denn um nichts weniger geht es bei Zuverlässigkeit: Zuverlässig ist, wer Versprechen stets einhält.

Wer unzuverlässig ist, bricht ein Versprechen - und irgendwo stirbt ein kleines Kätzchen einen grausamen Tod.

Jedes gebrochene Versprechen hinterlässt einen Knacks bei dem, dem wir versprochen haben. Es mögen manchmal und zuerst nur Haarrisse sein. Doch je öfter wir nicht halten, was wir versprechen, desto weiter wird das Geflecht dieser Risse. Dann entstehen brüchige Stellen im Vertrauen. Und am Ende… da zerbricht es womöglich daran.

Das ist ein schlimmer Effekt. Denn Vertrauen ist ein wesentliches Mittel zur Reduktion von Komplexität. Fehlt das Vertrauen, zieht explizite Kontrolle ein. (Micro-)Management ist die Folge. Oder Rechtsanwälte übernehmen.

Nach 100% Zuverlässigkeit zu streben, hat also nur positive Effekte. Warum tun wir es dann nicht?

Weil unser Verständnis von Versprechen undifferenziert ist. Im Grunde ist uns meist nicht bewusst, was wir da eigentlich tun, wenn wir etwas versprechen. Oder wir ahnen nicht einmal, dass wir überhaupt etwas versprochen haben.

Aber das lässt sich ändern. Hier einige Denkanstöße für Sie. Das Ziel 100% Verlässlichkeit ist erreichbar.

Verantwortung übernehmen

Zunächst einmal sollte jedem, der etwas verspricht bewusst sein, dass man nur für sich selbst etwas versprechen kann. Denn ein Versprechen abgeben, bedeutet, Verantwortung zu übernehmen. Wichtig ist dabei das Übernehmen. Verantwortung kann - entgegen dem Sprachgebrauch - nicht übertragen werden. Sie kann nur im vollen Besitz aller geistiger Kräfte übernommen werden.

“Ich verspreche, dass ich Auftrag A wie gewünscht ausführe!”: Das ist ein gültiges Versprechen. Damit kann ein Auftraggeber etwas anfangen. Der Auftragnehmer wird damit verantwortlich; das Ergebnis wird zurechnungsfähig.

“Ich verspreche, dass Mitarbeiter M den Auftrag A wie gewünscht ausführen wird!”: Das ist ein ungültiges Versprechen - zumindest solange die dritte Partei, der eigentliche Auftragnehmer, nicht selbst schon die Verantwortung übernommen hat. Wer diese Verantwortungsübernahme lediglich vermittelt, übernimmt sie dann nicht selbst.

Leider grassiert die Unart, dass Versprechen im Namen Dritter ohne vorherige Rücksprache und Übernahme abgegeben werden. Da verspricht der Vertrieb, dass ein Feature bis zum Termin T eingebaut sein wird - ohne die Entwicklung vorher zu fragen. Der Support verspricht, dass ein Bug sofort gefixt wird - ohne den Product Owner zu konsultieren. Der Manager verspricht, dass das Release noch diese Woche live geht - ohne das mit der IT-Abteilung abgesprochen zu haben.

All dieses und viele andere Versprechen mehr sind jedoch ungültig. Man kann ihnen nicht vertrauen. Ihr Bruch ist vorprogrammiert. Oder zumindest ist Stress vorprogrammiert. Die Gründe liegen auf der Hand:

• Wer im Namen Dritter verspricht (und nicht nur vermittelt) übernimmt selbst Verantwortung. Wenn er dann aber nicht an der Ausführung beteiligt ist, wird er dazu tendieren, Druck auf die Ausführung auszuüben, damit er sein ungültigerweise abgegebenes Versprechen auch hält. Das macht selten für die Ausführung etwas besser.
• Wer im Namen Dritter ohne deren ausdrückliche Verantwortungsübername verspricht, also über deren Zeit und Arbeitsinhalte bestimmt, beschädigt die Motivation. Wer will schon keine Wahl haben bei der Verantwortnungsübernahme?
• Ohne echte Verantwortungsübernahme sind die Bedingungen für die ausführenden Dritten selten so, wie sie sein müssten. Auch ohne Micro-Management entsteht dadurch sehr wahrscheinlich Stress, weil es an Budgets und/oder Ressourcen mangelt.

Merke: Versprechen kann nur, wer selbst ausführt.

Und was kann einer versprechen, der etwas ausführt?

Ergebnisse versprechen

Üblicherweise werden Ergebnisse versprochen. Das wird auch erwartet.

“Die Kosten der Wagenreparatur werden 1000€ sein. Sie können ihn übermorgen abholen.”, “Das Essen wird in einer halben Stunde auf dem Tisch stehen.”, “Das Release geht morgen früh raus.”, “Ich rufe dich um 9h an.”, “Meine Email-Adresse ist …” - so lauten größere und kleinere, bewusstere und unbewusstere Ergebnisversprechen, die wir jeden Tag abgeben.

Das Dumme dabei: Ergebnisse zu versprechen, ist sehr risikoreich. Man muss die Ausführungsumstände schon sehr unter Kontrolle haben, um ein Ergebnis verlässlich zu erzielen. Für die Zubereitung des Mittagessens mag das noch der Fall sein. Wahrscheinlich auch bei der Wagenreparatur - immerhin hat der KFZ-Mechaniker sich für den Kostenvoranschlag Zeit genommen zu einer Begutachtung des Autos. Aber ob das Release wirklich morgen früh rausgeht?

Selbst so simple Versprechen wie der Anruf am Morgen oder auf Emails in angemessener Zeitspanne zu antworten, sind risikoreich, wie es scheint. Denn wie oft werden sie gebrochen…[1]

Ein Ergebnis kann nur versprochen werden, wenn seine Herstellung eine “handwerkliche Tätigkeit” ist (vgl. “Unschätzbare Arbeitsweisen”). Handwerker sind die, die Ergebnisse verlässlich reproduzieren. Dafür bauen sie über Jahre Erfahrung auf. Diese Erwartung haben wir an sie - zurecht.

Ein Mittagessen zuzubereiten sollte eine handwerkliche Tätigkeit sein. Auch den Anruf für den nächsten Tag sollte auf dem Niveau sein. Ebenso, sich zu einem Treffen einzustellen. Und nach Erforschung des Zustands eines Wagens erwarten wir auch, dass der KFZ-Mechaniker sich in einer Handwerkerzone befindet.

Aber ist das Fixing eines Bugs handwerklich? Kaum. Dazu gehört eine unbestimmte Menge Forschung. Dito die Umsetzung eines neuen Features oder auch nur die Analyse von Anforderungen. Gerade in der Softwareentwicklung sind wir immer wieder erwartbar (oder auch überraschend) als Forscher und Ingenieure gefragt. Dann tun wir gut daran, keine Ergebnisse zu versprechen. Denn nichts anderes wollen Kunde und Management, wenn sie um eine Aufwandsschätzung bitten. Schlimmer noch, wenn z.B. das Marketing ungültig verspricht, “Das Feature haben wir bis zur Messe drin!”

Widerstehen Sie in diesen Fällen! Lassen Sie sich auf kein Ergebnisversprechen ein - solange für Sie als Ausführender nicht sonnenklar ist, dass die Ausführung zu 80+% rein handwerkliche Tätigkeit ist.

Und wie erkennen Sie ein Ergebnisversprechen? Ergebnisse sind Zielzustände, deren Erreichung an ein Budget geknüpft ist.

Budgets können finanziell sein, aber vor allem zeitlich. “Das Essen ist um 12h auf dem Tisch!” Wer dieses Ergebnis um 11h verspricht, hat ein Zeitbudget von 60 Minuten, um den Zustand “Essen auf dem Tisch” herzustellen.

Wie gesagt: Es ist nicht unmöglich, Ergebnisse zu versprechen. Aber vermeiden Sie es oder seien Sie sich zumindest dessen sehr, sehr bewusst. Tun Sie es nur, wenn die Herstellung des Zielzustands quasi eine Reproduktion ist, wenn sie das schon oft unter gleichen Umständen getan haben.

Merke: Ergebnisversprechen sind riskant!

Eine Sonderform von Ergebnisversprechen sind die, bei denen die Budgetgröße nicht im Vordergrund steht, sondern der “Liefertermin” für den Zustand. Das ist der Fall, wenn das Ergebnis mit einem (unplanbaren?) Ereignis verknüpft wird. Beispiele: “Ich verspreche, dass ich bei jedem Anruf Name und Anliegen und Uhrzeit notiere.”, “Ich verspreche, dass ich keine Aufträge mehr annehme, die nicht schriftlich vorliegen.”

Das Risiko besteht hier weniger in der Herstellbarkeit des Zielzustands, als vielmehr darin, ihn auch tatsächlich zu produzieren. Handwerkskunst ist in Bezug auf das Erinnerungsvermögen und den Willen gefragt. Erinnere ich mich im rechten Moment daran, was ich versprochen habe? Habe ich die Disziplin, das Versprochene zu tun? Der zu erreichende Zustand ist also vor allem “Bewusstsein und Energie”.

Verhalten versprechen

Sie werden nun wahrscheinlich denken: “Aber wenn ich keine Ergebnisse mehr versprechen darf… Was soll ich denn dann versprechen? Man verlangt von mir doch ein Commitment.”

Sie haben Recht. Wir brauchen Commitments in der Zusammenarbeit, im Zusammenleben. Ohne Verlässlichkeit wird alles zäh, stressig, ärgerlich.

Aber Sie können ja nicht nur riskante Ergebnisse versprechen, sondern auch Verhalten. Das ist viel weniger riskant.

Ein plakativer Vergleich: Wenn Sie das Ergebnis “2020 habe ich den Welthunger besiegt!” versprechen, ist der Misserfolg vorprogrammiert. Versprechen Sie hingegen “Ab heute werde ich jeden Tag bis 2020 2 Stunden dem Sieg über den Welthunger widmen!”, dann ist ein Erfolg in Ihrer Reichweite.

Ein Verhaltensversprechen verlangt Ihnen keine handwerkliche Erfahrung in Bezug auf den Tätigkeitsgegenstand ab. Sie müssen kein Budget für die Ergebniserreichung angeben. Verhaltensversprechen können Sie also auch immer dann guten Gewissens eingehen, wenn Sie noch forschen und planen müssen. Und das ist - zumindest in der Softwareentwicklung - meistens der Fall.

Und wie erkennen Sie ein Verhaltensversprechen? Verhalten ist eine Tätigkeit unter festgelegtem Ressourceneinsatz.

Verhaltensversprechen versprechen also keinen Zustand (“Bug gefixt”, “Essen gekocht”), sondern eine Aktivität (“Bug fixing”, “Essen kochen”). Statt Futur II (“Ich werde geschafft haben.”) benutzen Sie Futur I (“Ich werde tun.”).

Verhaltensversprechen haben allerdings nichts mit Versuchen zu tun, ein Ergebnis herzustellen. Sagen Sie also nicht “Ich werde versuchen, Zustand Z bis zum Termin T herzustellen.” Damit verleiten Sie den Auftraggeber, ein Ergebnisversprechen herauszuhören. Wenn Sie kein Ergebnis versprechen können oder wollen, dann tun Sie das auch nicht. Seien Sie mutig und klar in Ihrer Aussage.

Ebenso wenig haben Verhaltensversprechen mit Mühe zu tun. Sagen Sie also auch nicht “Ich werde mich bemühen, Aktivität A zu tun.” Was Sie da nämlich versprechen, ist nicht die Aktivität A, sondern sich zu bemühen. Das will ein Auftraggeber jedoch nicht. Der möchte A und sonst nichts. Sagen Sie ihm also klar, ob ud wie Sie A leisten können.

Warum hört man aber so oft, dass jemand nur Mühe verspricht? Weil es an handwerklichem Können fehlt. Denn auch für Verhaltensversprechen ist Handwerk grundlegend. Wir müssen nämlich in Bezug auf unsere Zeit Handwerker sein. Wir müssen unser Zeitmanagement im Griff haben. Der Umgang mit Kalender und Aufgabenliste ist zentral für jede Verlässlichkeit.

Bei Ergebnisversprechen ist das selbstverständlich und offensichtlich. Da steht der Zustandslieferungstermin im Vordergrund.

Verhaltensversprechen haben zwar keinen solchen Termin, dennoch braucht das Verhalten einen präzisen zeitlichen Rahmen.

Das war mir lange nicht klar. So sinnig ich die Unterscheidung zwischen Ergebnis- und Verhaltensversprechen fand, war mir doch manchmal beim Versuch, ein Verhalten zu versprechen, nicht ganz wohl. Oder es kam mir bei vermeintlichen Verhaltensversprechen anderer irgendetwas noch nicht stimmig vor. Der Grund dafür, wie ich nun herausgefunden habe, war ein Mangel an zeitlicher Präzision. Da war zwar eine Tätigkeit statt eines Ergebnisses im Gespräch, nur war die unverbindlich. Es fehlte das Commitment.

Beim Ergebnisversprechen besteht das Commitment in der Verknüpfung von Zustand mit Budget. Ich formalisiere das mal als Tupel: (Zustand, Budget), z.B. (Repariertes Auto, 2 Stunden Aufwand).

Das Commitment des Versprechens muss die Tätigkeit auch mit etwas verbinden. Es gibt zwar kein fixes Budget, aber eine Ressource muss eingesetzt werden. Da Ressourcen jedoch kaum vollständig zur Verfügung stehen, geht es allgemeiner um einen Ressourcenanteil, z.B. (Bug fixen, 10% meiner Arbeitszeit).

So sieht das minimale Verhaltensversprechen aus: Sie versprechen, einen gewissen Prozentsatz Ihrer Zeit auf eine Aktivität zu konzentrieren. Das tun Sie so lange, bis das gewünschte Ergebnis erreicht ist - oder ein anderer Zustand, der eine Meldung und ggf. eine Neuorientierung erfordert.

Wenn Sie dem Auftraggeber schon nicht sagen können, dass Sie das gewünschte Ergebnis mit einem Budget verlässlich herstellen können, dann sichern Sie zumindest zu, sich mit einer gewissen Kraft darum zu kümmern. Wie viel Kraft das ist, muss verhandelt werden.

Sie haben natürlich mehr auf dem Zettel als einen Auftrag. Deshalb müssen Sie den Ressourceneinsatz genau formulieren. Wenn es um Zeit geht, sind drei Angaben nötig:

1. Wann beginnen Sie mit der Tätigkeit?
2. Wie viel Prozent Ihrer Zeit widmen Sie der Tätigkeit?
3. Wie dicht ist Ihr Einsatz gepackt?

Auftraggeber wünschen sich natürlich, dass Sie sofort mit einer Tätigkeit beginnen. Sie wollen das Ergebnis schnellstmöglich. Kommt jedoch ein zweiter Auftrag herein, während der erste noch nicht abgeschlossen ist, führt dessen sofortiger Beginn zu einer Unterbrechung des ersten. Schädliches Multitasking nimmt seinen Lauf. Alles dauert länger, Ergebnisse werden später geliefert. Vermeiden Sie das! Staffeln Sie Aufträge, beginnen Sie sie nacheinander.

Auftraggeber wünschen sich natürlich ebenfalls, dass Sie 100% Ihrer Zeit der gewünschten Tätigkeit widmen. Sie wollen das Ergebnis schnellstmöglich. Das ist nur möglich, wenn Sie immer nur einen Auftrag bearbeiten, bis das Ergebnis erzielt ist. Eine solche Staffelung ist jedoch nicht immer möglich und gelegentlich sogar unökonomisch. Immer wieder gibt es durch Abhängigkeiten Wartezeiten während der Bearbeitung eines Auftrags. Warum die nicht mit anderen Aufträgen füllen? Bis zu einem gewissen Grad ist solches Multitasking bekömmlich. Sie können Ihre Zeit also auch in Teilen versprechen. Aber Achtung: Zu klein sollten diese Teile nicht werden. Ich würde sagen, kürzer als 45–60 Minuten sollten Bearbeitungseinheiten nicht sein. Versprechen Sie also nicht weniger als 10% Ihrer Zeit.

Weder bei 100%iger Auslastung mit einem Auftrag noch bei weniger können Sie sagen, wie lange es dauern wird, bis das gewünschte Ergebnis hergestellt ist. Deshalb geben Sie ja ein Verhaltensversprechen. Es kann daher sein, dass Sie nicht mit einem Zeitblock an einem Tag auskommen. Aber wann widmen Sie sich dann wieder dieser Tätigkeit? Das könnte morgen sein oder erst übermorgen oder nächste Woche. Das sollten Sie ebenfalls dem Auftraggeber kommunizieren.

Beispiel 1, “Ich werde mich ab heute jeden Tag 2 Stunden mit dem Thema beschäftigen.”: Hier versprechen Sie 25% Ihrer Zeit einzusetzen. Die Dichte ist 100%, da das jeden Tag geschieht.

Beispiel 2, “Ich werde jede Woche 4 Stunden X tun.”: Hier versprechen Sie 10% Ihrer Zeit für X aufzuwenden - allerdings nicht jeden Tag, sonder vielleicht einmal die Woche en bloc. Deshalb ist die Dichte in Bezug auf Tage nur 20%.

Formal ist ein Verhaltensversprechen also ein 4-Tupel der Form (Tätigkeit, Startzeitpunkt, Zeitanteil, Dichte), z.B. (Anforderungen analysieren, morgen 13:00h, 4 Stunden (50%), täglich (100%)).[2]

Für ein Versprechen auf dem Gang zwischen Tür und Angel ist das natürlich ein bisschen zu detailliert. Aber wenn Sie etwas mehr Zeit haben oder für die Reflexion ist solche Differenziertheit nützlich, finde ich.

Wenn Ihnen jetzt etwas mulmig wird, kann ich das verstehen. Wie sollen Sie denn eine bestimmte Intensität der Beschäftigung mit einem Auftrag versprechen können. Was wissen Sie über Ihren Kalender morgen oder nächste Woche? Aber genau das ist die Handwerkskunst, die mindestens nötig ist, wenn wir vertrauensvoll und verlässlich zusammenarbeiten wollen. Als Wissensarbeiter müssen Sie Meister des Zeitmanagements sein. Nicht weniger. So sieht die Grundkompetenz für die Zusammenarbeit jenseits handwerklicher Arbeiten aus. Das kann ich nicht schonend formulieren. Wer seine Zeit, seinen Kalender nicht im Griff hat, hat schon verloren. Der ist verdammt zu nicht endendem Stress.

Merke: Verhaltensversprechen sind jederzeit möglich!

Handfeste Prioritäten

Ständig konkurrieren mehrere Aufträge um eine Verarbeitungsressource. Das kann eine Person, ein Team, ein Unternehmen, eine Maschine sein. Es stellt sich daher die Frage, wie sich die Ressource diesen Aufträgen widmen sollte.

Mit der differenzierten Sicht auf Verhaltensversprechen ist es möglich, darüber handfest mit den Auftraggebern zu sprechen. Die können sich nun entscheiden, in welchen Aspekt sie investieren wollen, um die Abarbeitung eines Auftrags zu beschleunigen, d.h. höher zu priorisieren:

1. Der Auftraggeber kann Argumente liefern, warum ein Auftrag möglichst bald begonnen werden soll. Je früher, desto höher die Priorität. Insbesondere, wenn dadurch andere Aufträge unterbrochen werden müssten, sind gute Argumente nötig.
2. Der Auftraggeber kann Argumente liefern, warum für die Abarbeitung eines Auftrags ein möglichst großer Prozentsatz der Ressourcenzeit pro Zeiteinheit alloziert werden sollte. Mehr Anteil, desto höher die Priorität. Insbesondere, wenn dadurch der Anteil für andere schon begonnene Aufträge verringert werden soll, sind gute Argumente nötig.
3. Der Auftraggeber kann Argumente liefern, warum die Anteilsdichte möglichst hoch sein sollte. Je höher die Dichte, desto höher die Priorität. Insbesondere, wenn dadurch die Dichte für die Abarbeitung anderer Aufträge sinken würde, sind gute Argumente nötig.

Höchste Priorität hat, was sofort mit 100% der Zeit und 100% Dichte begonnen wird. Da gibt es kein Vertun. Das ist wünschenswert, um schnellstmögliche Ergebniserzielung zu erreichen. Das ist Work-in-Progress (WIP) = 1. Das ist erstrebenswert, weil nur so die Verschwendung minimal ist. Feedback wird maximal schnell generiert.

Aus verschiedenen Gründen mag es aber doch sinnvoll sein, mehrere Aufträge quasi gleichzeitig zu bearbeiten, also Multitasking zuzulassen.

Deshalb werden Sie Aufträgen eher selten 100% Anteil gewähren. Seien Sie jedoch vorsichtig! Erstens sollten Sie ohnehin nie 100% Ihrer Zeit verplanen; lassen Sie eher 30–40% Luft als Puffer für Unvorhergesehenes. Zweitens sollten Sie die Anteile nicht zu klein schneiden; unter 1 Stunde lohnen sich viele Tätigkeiten nicht. Sie brauchen zu lange, um (wieder) reinzukommen. Es ergibt sich, dass Sie pro Tag maximal 3–4 verschiedene Aufträge sinnvoll bearbeiten können.[3]

Dasselbe gilt für die Dichte. Eine zu geringe Dichte ist dem Fortkommen eines Auftrags und der Bearbeitungsqualität abträglich. Streben Sie eine Dichte von 100% an. Bringen Sie Aufträge jeden Tag bis zum Abschluss voran, wenn schon nicht mit 100% Anteil. Wenn die Dichte darunter sinkt, dann nur weil externe Abhängigkeiten das erfordern. Wenn Sie auf Zuarbeiten warten müssen, hilft es nichts, dass Sie schon morgen weitermachen wollen. Dann sichern Sie nur eine geringere Dichte zu. Aber vermeiden Sie, bei Eintreffen von Ergebnissen sofort zur unterbrochenen Aufgabe zurückzukehren. Tun Sie das erst, wenn sie laut Anteil und Dichte wieder in Ihrem Plan dran ist.

Teileweise arbeiten

Versprechen zu halten ist schon schwer genug, auch Verhaltensversprechen. Versprechen über lange, gar unbestimmt lange Zeit zu halten, ist aber noch schwerer. Versuchen Sie daher, Aufträge, deren Budget sie nicht kennen, aber deren Größenordnung Ihnen ungefähr klar ist und jenseits von 7–10 Tagen liegt, in kleinere Teilaufträge von max. einer Woche zu zerlegen.

Große Aufträge liegen schwer in Ihrem Kalender. Sie wirken immobilisierend. Sie verlieren mit ihnen die Fähigkeit, auf Änderungen zu reagieren.

Suchen Sie in großen Aufträgen daher “Sollbruchstellen”, die für den Auftraggeber Sinneinheiten darstellen. Statt einer langen Verhaltensstrecke mit Blick auf das ultimative Ergebnis stecken Sie lieber Teilstrecken für Teilverhalten mit Teilergebnissen ab.

Das gibt nicht nur Ihnen Flexibilität und erhöht Ihre Verlässlichkeit. Auch Auftraggeber bekommen die Möglichkeit, sich nach der Erarbeitung von Teilergebnissen wieder neu zu entscheiden.

Pacta sunt servanda

“Versprochen ist versprochen!” Wenn Sie Ergebnisse oder Verhalten versprechen, dann müssen Sie wie versprochen leisten. Schon die Römer wussten, dass das ein Grundpfeiler für Zivilisation ist und sagten “pacta sund servanda”, Verträge müssen eingehalten werden.

Solange Sie jedoch im Dialog mit dem Auftraggeber stehen, können Sie bei Bedarf nachverhandeln. Versprechen können verändert werden, wenn alle beteiligten Parteien dem zustimmen.

So eine Nachverhandlung erhält die Verlässlichkeit allerdings nur, wenn Sie ein Nein akzeptieren können. Veränderungswünsche sind Bitten, die abgelehnt werden können.

Beispiel: “Ich weiß, ich habe Ihnen den Bericht für 13:00h zugesagt - aber nun würde ich gern dem Kollegen bei einem dringenden Auftrag helfen. Dadurch würde sich die Berichtsabgabe bis 15:00h verzögern. Ist das ok?” Die Frage zu stellen, ist völlig legitim. Dadurch brechen Sie kein Versprechen. Doch wenn der Auftraggeber Nein sagt und sie nach 13:00h liefern, sind Sie unzuverlässig.

Merke: Ergebnisversprechen führen häufig zu Nachverhandlungen. Versprechen Sie daher lieber ein Verhalten.

Merke: Alle Versprechen können im gegenseitigen Einvernehmen modifiziert werden.

Aber Vorsicht: Auch wenn Versprechen grundsätzlich nachverhandelt werden können, sollte das die Ausnahme sein. Wenn Sie ein Versprechen abgeben, versprechen Sie nämlich auf zwei Ebenen. Ebene 1 ist die offensichtliche; Sie versprechen z.B. etwas zu tun. Ebene 2 liegt unausgesprochen darunter. Auf der Versprechen Sie, das Versprechen genau so einzuhalten, also eben nicht ständig nachzuverhandeln. Denn ein Versprechen soll ja Ruhe in die Zusammenarbeit bringen. Es soll damit eine Sache vorläufig abgeschlossen werden. Mentale Ressourcen sollen frei werden. Dieser Zweck würde durch ständige Nachbesserungen torpediert.

Promise Like a Pro

Versprechen scheinen so einfach. Wir versprechen ja schon als Kinder. Formal sind sie auch einfach. Sogar so einfach, dass wir sie oft unbewusst und leichtfertig abgeben. Wir sind uns über die Tragweite nicht im Klaren. Und wir haben nicht gelernt, mit diesem wichtigen Werkzeug der Zusammenarbeit systematisch umzugehen. So interpretiere ich jedenfalls das, was ich in Unternehmen sehe: die Unzuverlässigkeit grassiert im Kleinen wie im Großen. Die Effekte: Stress, Demotivation, hohe Kosten.

Wenn wir diese Effekte nicht wollen, dann müssen wir Zuverlässiger werden. 100% aller Versprechen müssen eingehalten werden. Ja, das ist möglich, wenn Sie bewusst und vorsichtig und manchmal mutig sind. Schauen Sie genau hin, ob Sie all die Ergebnisse wirklich versprechen wollen und können und müssen, zu denen Sie sich jeden Tag committen. Wählen Sie bewusst immer öfter Verhaltensversprechen. Und bekommen Sie Ihre Zeit in den Griff! Wenn Sie keine Hoheit über diese ultimativ knappe Ressource Ihres Lebens haben… dann sollten Sie das als erstes ändern.

Für mehr Vertrauen, für mehr Zuverlässigkeit müssen wir Profis des Versprechens werden. Der Slogan für mich ist: Promise Like a Pro. Das ist die Voraussetzung für “Gets things done”.

---

1. Das ist natürlich eine Unart und darf nicht sein. So simple Dinge müssen wir 100% unter unserer Kontrolle haben. Wer einen Anruf verspricht, muss anrufen. Wer eine Email-Adresse herausgibt, muss antworten. ↩

2. Um genau zu sein, gehört zu einem Ergebnisversprechen auch ein Startzeitpunkt: (Zustand, Startzeitpunkt, Budget), z.B. “Ich werde für das Bug fixing 4 Stunden brauchen - und morgen um 8:00h damit beginnen.” Doch insbesondere bei ad hoc Versprechen ist der Startzeitpunk uninteressant. Dann geht es nur um den Liefertermin. Das Budget ist also der Zeitraum ab Versprechensabgabe bis dahin. Deshalb habe ich den Startzeitpunkt oben nicht aufgeführt. Für Verhaltensversprechen ist er wichtiger, da sie keinen Liefertermin haben. ↩

3. Ich spreche hier nicht über ein Call Center mit Anrufdauern von 3 Minuten. Das wäre auch handwerkliche Arbeit. Es geht um Wissensarbeit, zu deren Erledigung in den meisten Fällen mehrere Stunden, Tage, gar Wochen nötig sind. Dass Sie darüber hinaus noch eine Menge “Kleinscheiß” zu tun haben, ist klar. Damit müssen Sie gesondert umgehen. Die Tagesplanung ist aber nicht Thema dieses Artikels. ↩