Kontinuierliche Verbesserung und Wachstum

„KVP beruht auf der Annahme, das Wachstum der einzig relevante Faktor eines Unternehmens zur Steigerung seiner Wirtschaftlichkeit ist. KVP ist endlich und somit zum Scheitern verurteilt.“

Eine herrliche These, sofern man diese Behauptung als solche bezeichnen mag. Beruht KVP auf der Annahme, dass Wachstum der einzig relevante Faktor ist? Nein, definitiv nicht. Denn KVP macht sich um ziemlich viel Gedanken, aber nicht um Wachstum. Bei KVP geht es um Qualität von Dienstleistungen, Prozessen und Produkten. Aber wahrlich nicht um Wachstum.

Das wird als Seiteneffekt gerne in Kauf genommen, ist aber nicht das direkte Ziel von KVP.

Im Artikel wird Karl zitiert mit der Aussage, dass „unendliches Wachstum in einer endlichen Welt nicht funktionieren kann“. Das hört man sehr oft, ist aber, sofern es um Ökonomie geht, falsch. Natürlich ist es nicht möglich, das physikalische Entitäten in einer endlichen Welt unendlich wachsen. Ökonomie ist aber keine physikalische Entität, sondern ein virtuelles Modell. Das bedeutet, dass wir Ökonomie nur anhand ihrer Wirkung erleben und diese Wirkungen abstrakt beschreiben. Man kann davon ausgehen, dass eine Ökonomie, die auf dem Verbrauch von Ressourcen basiert, nur so lange funktioniert, wie diese Ressourcen zur Verfügung stehen. Im Falle eines kontinuierlichem Wachstums beschleunigt eine solche Ökonomie ihren Untergang, je näher sie ihm kommt.

Nun ist Ökonomie aber auch ein adaptives System, sie hat die Fähigkeit sich anzupassen. Man könnte sagen, der Ökonomie als solcher ist ein KVP innewohnend. Eine Ökonomie, die auf dem Verbrauch von Ressourcen begründet ist, hat die Möglichkeit, sich zu wandeln, nämlich zu einer Ökonomie, die auf der Transformation von Ressourcen beruht. Viele Ressourcen haben Eigenschaften, die eine beliebig häufige Wiederverwendung ermöglichen oder können durch Alternativen ersetzt werden. Damit ist die Existenz einer (ursprünglich Ressourcen verbrauchenden) Ökonomie in einer endlichen Welt auf unbestimmte Zeit möglich. Jetzt kommt die Frage nach dem Wachstum und hier sei – unter vielen anderen guten Büchern zu diesem Thema – Tomáš Sedláčeks „Die Ökonomie von Gut und Böse“ empfohlen.

Das ökonomische Wachstum das wir heute erleben ist zum Einen ein Wachstum der Dienstleistungen, für die ein Ende nicht bestimmbar ist, denn das würde bedeuten, dass wir alle denkbaren Dienstleistungen schon kennen. Dass das nicht der Fall ist, zeigt sich immer wieder auf’s Neue und kann gut durch die Five Orders of Ignorance erklärt werden. Zum Anderen beruht das Wachstum auf einer kontinuierlichen Entwertung des Geldes, das dem Prinzip unseres Schuldgeldsystems anzulasten ist. Das kann man gut oder schlecht finden, es funktioniert bisher ausreichend gut und sämtliche Adaptionen davon (Schwundgeld, Regionalgeld etc. ist nichts anderes als kontinuierlich entwertetes Geld) basieren auf dem gleichen Prinzip. Wer sich dafür interessiert, möge meine Thesis über den Gold Standard lesen, da habe ich das recht ausführlich erklärt.

Nun, zurück zur ursprünglichen Aussage. Diese ist meiner Meinung nach grundlegend falsch, weil sie von zwei falschen Prämisse ausgeht:

  1. KVP geht nicht von der erwähnten Annahme aus.
  2. KVP ist nicht endlich, weil selbst wenn KVP von dieser Annahme ausgehen würde, weder dem Wachstum noch den Verbesserungsmöglichkeiten Grenzen gesetzt sind.

Der hyperbolische Thread-Koeffizient – über Wirkungsgrad von Managern in agilen Organisationen

Ich kenne viele Manager, die KPIs lieben. Je mehr Faktoren auf eine Zahl reduziert werden, umso besser ist der KPI.

Nachdem ich mich in letzter Zeit häufiger im Umfeld der Organisationsentwicklung tummeln durfte, kam ich auf die Idee, doch einen KPI zu nutzen, um den Wirkungsgrad von Managern zu messen. Der Hintergrund meiner Überlegungen war, dass ich regelmäßig mit Managern sprechen muss, wenn eine Veränderung der Organisation notwendig ist. Manchmal muss ich dafür sehr lange auf einen Termin bei so einem Manager warten, was natürlich besonders in Organisationen, die gerne agil werden oder sein wollen, problematisch ist. Eventuell hat das Problem die Organisation schon überholt, wenn ich den Termin bekommen habe.

Hoher HTK
Ein hoher Hyperbolischer Thread-Koeffizient bedeutet eine geringe Wirksamkeit.
Nach einigem Nachdenken und der Lektüre von Gunter Duecks Meisterwerk Schwarmdumm bin ich dann zum Schluss gekommen, dass dieser Wirkungsgrad mit der Warteschlangentheorie zusammen hängt. Ein Manager, der eine kurze Queue und damit viel freie Zeit hat, ist wirksamer, als ein Manager, der eine lange Queue hat. Auf letzteren muss ich warten, wenn ich ein Anliegen habe, das reduziert seine Wirksamkeit. Der Wirkungsgrad von ersterem ist höher, weil er zeitnah reagieren kann.

Aber wie kann man das jetzt messen? Ich habe mich an meine eigene Zeit als Geschäftsführer erinnert und diese mit meinen Beobachtung vieler Manager verglichen. Dann kam mir die Idee: die ideale Quelle zur Berechnung der Wirksamkeit eines Managers ist sein Outlook-Kalender.

Ich habe mir dazu folgende Formel überlegt:
Die Wirksamkeit eines Managers verhält sich umgekehr proportional zu seinem Hyperbolischen Thread-Koeffizient [1]. Der HTK berechnet sich aus dem Median der Anzahl der Termine im Outlook pro Woche hoch dem Maximum der parallelen Termine innerhalb eines Kalenderjahres.

Die Wirksamkeit ist dann: \eta = \frac{1}{HTK} bzw. \eta = \frac{1}{MOT^{MPT}}

Wobei gilt:
MOT = med(Anzahl\ der\ Termine\ im\ Outlook\ pro\ Woche) und MPT = max(Gleichzeitig\ parallele\ Termine\ innerhalb\ eines\ Kalenderjahres)

Niedriger HTK
Ein niedriger Hyperbolischer Thread-Koeffizient bedeutet einen hohen Wirkungsgrad.
Damit hat jetzt jeder Manager einen persönlichen KPI zur Bewertung der eigenen Leistung! Und ich habe ihn erfunden.

[1] Der Begriff Hyperbolischer Thread-Koeffizient setzt sich aus mehreren wichtigen wissenschaftlichen Komponenten zusammen. Thread leitet sich aus der Tatsache ab, dass die Anzahl der parallelen Aktivitäten eine wichtige Rolle bei der Berechnung spielen. Hyperbolisch ist der Koeffizient, weil er zeigt, wie stark der oder die Betreffende es mit der eigenen Wirksamkeit übertreibt.

Planning Pattern II – Test Driven Sprint Planning

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks
Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen
Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

Planning Pattern I – Planen für den Flow

In dieser Artikelreihe möchte ich einige Pattern vorstellen, die agilen Teams helfen können, die Ergebnisse ihrer Sprint Plannings zu optimieren. Die meisten der Pattern sind bei der Arbeit mit Scrum Teams entstanden, sie lassen sich aber auch gut für Extreme Programming oder Kanban adaptieren.

20 Tasks am Board
20 Tasks am Board

Vor einigen Jahren kam ich als neuer Scrum Master zu einem Team, das schon eine geraume Weile zusammenarbeitete. Das Team arbeitete mit 2-Wochen-Sprints, hatte ein dreispaltiges Scrum Board, also auf den ersten Blick nichts außergewöhnliches. Allerdings hatte das Team in den letzten drei Sprints sein Commitment nicht geschafft. Was mich erstaunte, denn Aufgaben erschienen mir durchaus im Bereich des Machbaren und das Team war fit.

Als neuer Scrum Master halte ich mich immer erst mal mit Kommentaren zurück und beobachte viel. Beim Sprint Planning war ich dann erstaunt, dass das Team fast einen ganzen Tag dafür aufwendete und am Ende lediglich 20 Tasks am Scrum Board klebten. Ich fragte das Team also, ob sie sich sicher seien, dass das so ok war. Das Team meinte, ja, das wäre OK so. Es kam, wie es kommen musste – der Sprint lief schief, weil sich die Teammitglieder die ganze Zeit nur gegenseitig auf den Füßen standen und Tasks ewig „In Progress“ waren.

In einer Retrospektive konfrontierte ich das Team mit der Idee, dass ein Task nicht länger als einen Tag dauern sollte. Diese Idee kommt ja nicht von ungefähr, sie ist der Garant für einen guten Flow während des Sprints. Wir diskutierten eine ganze Weile darüber und schließlich kam eine recht interessante Betrachtung dabei heraus:

  • 1 Task <= 1 Tag
  • 1 Sprint = 10 Tage
  • 1 Team = 7 Personen
  • 1 Person benötigt >=10 Tasks (folgt aus (1) & (2))
  • 7 Personen benötigen >=70 Tasks (folgt aus (3) & (4))

Eines der Teammitglieder war Physiker und konnte das auf diese Weise kompakt zusammenfassen. Ein Team mit sieben Personen benötigt für einen 2-Wochen-Sprint mit 10 Arbeitstagen mindestens 70 Tasks am Scrum Board, um sicherzustellen, dass ein Task nicht mehr als einen Tag in Anspruch nimmt.

Diese Erkenntnis ist auch bereits das erste Planning Pattern:

Schneide die Tasks so, dass ihre Anzahl mindestens der Anzahl der Arbeitstage im Sprint multipliziert mit der Anzahl der Teammitglieder entspricht.

200 Tasks am Board
200 Tasks am Board

Das Team nahm die Herausforderung an und beim nächsten Planning befanden sich statt 20 plötzlich fast 200 Tasks auf dem Scrum Board. Nach einer Weile hat sich die Menge der Tasks auf 90 bis 120 Tasks pro Sprint eingependelt. Die kleinen Aufgaben führten zu einer sehr entspannten und kontinuierlichen Abarbeitung während des Sprints – das Team hatte seinen Flow gefunden. Ein angenehmer Nebeneffekt war, dass das Sprint Planning sich drastisch verkürzte.

Dieser Artikel erschien zuerst im adesso Blog.