Suche
Wie Kanban-Teams ihre Messgrößen nutzen

Kanban: Pünktlich und zuverlässig liefern

Matthias Bohlen

© istock/nullplus

Der Kunde möchte schon zu Beginn einer Entwicklung wissen, wann er das Ergebnis bekommen wird: lauffähige Software, die passende Doku, entsprechende Schulungen etc. Setzen die beteiligten Teams die Kanban-Methode ein, verfügen sie bereits über eine aktuelle Basis von Messdaten bezüglich ihrer eigenen Leistungsfähigkeit. Zu den meistbenutzen Messgrößen im Kanban-Umfeld zählen Time in Process, Work in Progress, Throughput sowie Queue Sizes.

In diesem Artikel soll aufgezeigt werden, wie man eben diese Messgrößen nutzt, um zu sinnvollen Terminaussagen zu kommen. Dabei wendet der Autor moderne Verfahren der probabilistischen Prozesssteuerung an. Zufälle und Rauschen werden dabei absichtlich mit einbezogen, anstatt diese durch hektische Eingriffe in den Prozess beherrschen oder gar ausschließen zu wollen. Kanban [1] gibt den Teams Wetterbericht und Steuerknüppel in die Hand, um das Vorhaben gemeinsam mit dem Kunden pünktlich landen zu können.

Pünktlich liefern

Was ist in der Softwareentwicklung eine pünktliche Lieferung und warum ist es eigentlich so schwer, pünktlich zu liefern? Bei der ersten Frage handelt es sich auf den ersten Blick um reine Definitionssache: „Eine Lieferung ist pünktlich, wenn sie vor oder an dem Datum eintrifft, zu dem sie dem Kunden versprochen wurde.“ Wenn es doch nur so einfach wäre. Denn es gibt ja unterschiedliche Arten von Lieferungen:

  • Kunden, die ein großes Softwarerelease erwarten, das aus vielen zu entwickelnden Features besteht, erwarten vom Team eine so hohe Schlagzahl, dass bis zum versprochenen Termin möglichst alle geplanten Features fertig werden.
  • Kunden, die auf eine Fehlerbehebung warten, sind an einer möglichst kurzen Bearbeitungszeit für diesen einzelnen Fehler interessiert. Welche Releases das Team darüber hinaus plant und wie die Auswirkungen der Fehlerbehebungen auf den Zeitplan dieser Releases sind, ist für diesen Kunden nicht von Belang. Sie wollen einfach, dass der Fehler in einer verabredeten Zeit behoben wird.

Die obige Definition trifft in beiden Fällen zu, bedeutet aber jeweils etwas völlig Unterschiedliches. Hinzu kommt, dass ein Team in der Produktentwicklung meist für mehrere Kunden auf einmal arbeitet. Wenn für einen Kunden etwas Dringendes erledigt werden muss, hat das Auswirkungen auf die Lieferzeiten für die anderen Kunden. Einen einzelnen Kunden pünktlich zu bedienen, ist daher einfacher, als eine große Menge von Kunden.

Und was heißt hier eigentlich „dringend“? Würde man denjenigen Kunden sofort beliefern, der am lautesten schreit, dann wäre plötzlich alles dringend und damit alles gleich wichtig. Der Begriff „dringend“ würde einfach seine Bedeutung verlieren.

Der letzte Faktor, den ich hier betrachten möchte, macht das Bild nochmals komplizierter: Die Variabilität, das „Rauschen“ in der Arbeit selbst. Vermeintlich ein und dieselbe Entwicklungsarbeit kann unterschiedlich lange dauern. „Bau doch mal eben noch ein Feld ein und zeige es in der Maske für die Kundendaten an“. An guten Tagen ist das Feld bis zum Abend eingebaut. An schlechten Tagen laufen die Entwickler auf größeren Refactoring-Bedarf, der sie ohne Weiteres bis zu zwei Tagen beschäftigen kann, und können erst anschließend das Feld einbauen. Das sichtbare Resultat für den Kunden ist dasselbe: ein Feld mehr. Der Kunde fragt sich also, wie dieser Unterschied zustande kommt.

Damit haben wir die folgenden Faktoren ermittelt, die pünktliches Liefern zum Problem werden lassen:

  • Verschiedene Typen von Arbeit, z. B. Featurestapel versus Einzelfehler
  • Arbeit für mehrere Kunden auf einmal
  • Variabilität (Rauschen) in den Tätigkeiten
  • Unterschiedliche Dringlichkeit von Arbeit

Warum Aktivitätsplanung meist nicht funktioniert

Früher versuchte man, durch Aktivitätenlisten Termine zu planen und einzuhalten:

  1. Man machte eine Liste aller nötigen Aktivitäten.
  2. Man schätzte, wie lange jede Aktivität dauert.
  3. Man legte die Aktivitäten entsprechend ihrer Dauer nacheinander oder parallel auf einen Zeitstrahl.
  4. Man schaute, welcher Endtermin sich ergab, rechnete noch einen Sicherheitspuffer drauf und versprach das Endergebnis dem Kunden.
  5. Man versuchte, den Verlauf der Aktivitäten so zu steuern, dass der Endtermin erreicht wurde.

Diese Art der Planung und Steuerung funktionierte nie wirklich gut. Projekte, die so geplant und verfolgt wurden, waren zeitlich meist zu spät dran. Außerdem brauchte es einen großen Aufwand, den Plan nachzupflegen und aktuell zu halten.

Woran liegt es, dass wir mit diesem Vorgehen meist zu spät kamen? Ein Grund ist das nicht berücksichtigte Rauschen.

Was Rauschen ist

Eine einfache Tätigkeit dauert manchmal drei Tage, manchmal dauert dieselbe Tätigkeit aber auch einen bis fünf Tage. Das liegt daran, dass in der Softwareentwicklung jede Änderung an einer Stelle des Systems Nebenwirkungen auf andere Komponenten des Systems hat. Dies verändert die Dauer der nachfolgenden Änderungen, weil das darunterliegende System nicht mehr dasselbe ist.

Stellen Sie sich also darauf ein, dass Dinge manchmal weniger lange und oft länger dauern, als „dasselbe“ Ding vorher gedauert hat. Diesen Effekt nennt man Variabilität oder einfach „Rauschen“.

Es gibt viele Ursachen, die dazu führen, dass dieselbe Arbeit unterschiedlich lange dauert und Ihnen die Planung verhagelt:

  • Es entstehen Folgefehler beim Einbau neuer Funktionalität.
  • Ein Fachexperte des Kunden steht für eine Rückfrage gerade nicht zur Verfügung.
  • Die Testmaschine fällt aus.
  • Es stehen zu wenig produktionsnahe Testplattformen zur Verfügung.
  • Das Deployment kurz vor der Auslieferung klappt gerade nicht.
  • Ein Teammitglied wird krank.
  • Ein wichtiger Spezialist (z. B. Architekt oder Datenbänker) steht im Moment nicht zur Verfügung.

Diese Arten von Rauschen sollten Sie wo immer möglich eliminieren. Dazu später mehr. Hier nur so viel: Je weniger Rauschen im Prozess, desto besser werden Sie Ihre Termine halten können.

Welchen Einfluss Fehlversuche haben

Fragen Sie einen Entwickler „wie lange dauert Feature X“, das er als Nächstes entwickeln soll. Er wird vielleicht sagen „zwei Tage“. Dann fängt er an zu arbeiten, und nach drei Tagen hat er etwas, das nicht funktioniert, wie erwartet. Dann versucht er einen anderen Ansatz, und siehe da: Nach insgesamt fünf Tagen funktioniert alles perfekt. Der zweite Ansatz, den er probierte, dauerte exakt zwei Tage. Die drei ersten Tage waren zum Lernen absolut notwendig, jedoch äußerlich betrachtet ein „Fehlversuch“.

Fragen Sie Ihn später noch einmal „wie lange dauert Y“ (wobei Y ziemlich ähnlich zu X ist), so wird der Entwickler wieder antworten „zwei Tage“, weil er seinen Fehlversuch beim ersten Mal inzwischen verdrängt hat. Und es wird wahrscheinlich wieder fünf Tage dauern.

 

Warum Schätzen nicht so gut ist

Wir Menschen sind einfach nicht gut darin, die Zukunft vorherzusagen. Wenn wir schätzen, versuchen wir jedoch genau das. Wir berechnen aber Rauschen und Fehlversuche nicht mit ein und die Zeit für die vielen Taskwechsel am Tag auch nicht. Qualitätsprobleme im System, die ein Team verlangsamen, werden nicht mitgerechnet, und Abstimmungsaufwand, Fehlerbeseitigung, Inbetriebnahme und Dokumentation geraten beim Schätzen auch leicht in Vergessenheit.

Wir Menschen haben nicht genug Aufmerksamkeit, um das alles beim Schätzen mit zu berücksichtigen. Da beißt die Maus keinen Faden ab. Alle Teams, die ich jemals habe schätzen sehen, lagen im Nachhinein betrachtet daneben.

Also: die Kombination aus einfacher Aktivitätsplanung plus Schätzen ist out, das ist klar. Sie berücksichtigt weder Rauschen noch Multi-Kunden-Umgebung noch Arbeitspakettypen noch Dringlichkeiten in adäquater Weise.

Was tun Sie stattdessen am besten? Lassen Sie die Teams messen, was sie wirklich schaffen und dann Versprechungen machen, die auf Fakten basieren, nicht auf Schätzungen [2].

Versprechungen auf Faktenbasis

Es muss zunächst ein System her, bevor wir anfangen können, dem Kunden realistische Termine zu versprechen. Zunächst einmal müssen wir anerkennen, dass es vier Einflussfaktoren gibt, die uns das Leben schwer machen und diese konsequent berücksichtigen. Fangen wir also mit dem ersten Faktor an: Verschiedene Typen von Arbeitspaketen (z. B. Stapelarbeit wie bei Projekten und Einzelarbeit wie bei der Fehlerbehebung) und die unterschiedlichen Kundenerwartungen an diese.

Stapelarbeit

Bei Stapelarbeit (z. B. in einem Projekt mit einem Releasetermin) geht es dem Kunden um eine hohe und gleichmäßige Schlagzahl der Teams, damit der versprochene Releasetermin für die große Featuremenge auch tatsächlich erreicht werden kann. Das ist ein Durchsatzproblem. Durchsatz (auch Produktionsrate oder Fertigstellungsrate genannt) ist eine Messgröße für die Teamkapazität, gemessen in fertigen Features, Stories oder Arbeitspaketen pro Woche oder Monat (wie auch immer Sie die Währung nennen, in der Sie den Wert messen, der für den Kunden geschaffen wird).

Naive, durchsatzfokussierte Leute sagen einfach: Der Kunde will 400 Stories, das Team schafft 40 pro Monat, also dauert das Projekt zehn Monate. Das ist das Prinzip. Doch so einfach ist es nicht.

Multikundenumgebung

Hier kommen nämlich Multikundenumgebung und Rauschen als weitere Einflussfaktoren hinzu. In einer Multikundenumgebung müssen Sie entscheiden, welchem Kunden Sie welchen Anteil am durchschnittlichen Durchsatz Ihrer Teams geben. Zum Beispiel bekommt Kunde A 50 Prozent, weil er das größte Budget hat. Die Kunden B und C teilen sich vielleicht den Rest des Durchsatzes dieses Teams. Die Kunden D und E werden von einem anderen Team bedient.

Teams, die mit Kanban als Methodik arbeiten, kennen ihren eigenen Durchsatz, weil sie ihn messen. Wenn das Team nun Kunde C einen Termin versprechen will und Kunde C einen Stapel von 20 Stories erledigt haben möchte, dann ist der Ansatz so: Das Team schafft 40 Stories im Monat. Kunde C bekommt 25 Prozent des Durchsatzes, also zehn pro Monat. Wenn er 20 Stories lauffähig haben möchte, muss er also zwei Monate auf die letzte Story warten. Kunde A hätte bei 50 Prozent Anteil am Durchsatz nur einen Monat warten müssen.

Wichtig ist, dem Kunden von Anfang an klar zu sagen, dass das Durchschnittswerte sind und der tatsächliche Wert einer Schwankung unterliegt. Kanban-Teams messen auch diese Schwankung, um die Erwartungen zu managen.

Variabilität und Rauschen

Jetzt werden Sie sagen: Augenblick mal, es dauern doch nicht alle Stories gleich lange. Also kann doch der Durchsatz nicht gleichmäßig sein, oder? Natürlich, so ist es auch. Das Rauschen wächst mit der Größe der einzelnen Anforderungen, z. B. der User Stories. Es gibt bei User Stories aus meiner Sicht genau zwei Größen: im Team beherrschbare und zu große.

Gehen Sie mit den Stories zu Ihren Teamkollegen und fragen sie: „Was haltet ihr von dieser Story? Ist sie klein genug, damit ihr sie einwandfrei verstehen, zügig entwickeln und leicht testen könnt?“ (Zügig bedeutet meist: in einer Woche oder weniger. Das Team selbst sollte entscheiden, was „zügig“ heißt). Wenn die Antwort „ja“ lautet, lassen Sie die Story durch, in den Entwicklungsprozess hinein. Bei einem „nein“ splitten Sie die Story gemeinsam mit dem Team in zwei oder mehrere kleine, zu denen das Team schließlich „ja“ sagt.

Damit haben Sie eine gemeinsame Obergrenze für die Durchschnittsgröße von Stories. Der Durchsatz kann dann nicht mehr so stark schwanken wie zuvor.

Machen Sie die Durchsatzmessung bereits auf Basis der kleinen Stories. Zählen Sie auch, wie viele kleine Stories im Schnitt aus einer rohen, großen Story entstanden sind und halten Sie das ebenfalls als Messwert fest. Wenn derselbe Kunde Sie das nächste Mal fragt, wie lange ein paar „rohe“ Stories dauern würden, wissen Sie durch diesen Multiplikator, was das im Durchschnitt als Menge von kleinen Stories ergeben wird und können damit rechnen.

Einzelarbeit

Wenn Ihre Arbeit eher Servicecharakter (also eine kurze Bearbeitungsdauer für jeden einzelnen Fehler oder Change) als Projektcharakter hat (also viele Dinge bis zum Termin fertig haben), dann tritt aus Kundensicht der Durchsatz in den Hintergrund. Die Bearbeitungsdauer ist ihm wichtiger.

Aus Kundensicht geht die Bearbeitungsdauer von der Beauftragung bis zur Lieferung. Wir sprechen in der Sprache der Lean-Methoden auch von Lead-Time. Aus Teamsicht besteht diese aus drei Komponenten:

  • Queue-Time in der Eingangswarteschlange, bis der Fehler überhaupt das Team erreicht.
  • Time in Process, also die Zeit, die der Fehler in Diagnose und Fixing verbringt.
  • Queue-Time in der Ausgangswarteschlange für diesen Kunden, bis der Fix tatsächlich beim Kunden eintrifft und dort in Betrieb genommen ist.

Nehmen wir an, das Team hat schon dreißig Fehler in seiner Eingangswarteschlange und einen Fixing-Durchsatz von zehn pro Woche, so dauert es allein drei Wochen, bis der Fehler überhaupt zum Fixen ins Team gelangt. Danach braucht das Team vielleicht 0,5 Wochen zum Fixen, und der Fix gelangt in die Warteschlange zur Auslieferung an den Kunden. Der möchte die Fixes vielleicht nur alle vier Wochen installieren, also sind wir nun bei einer Lead-Time von 3,5 bis 7,5 Wochen, je nachdem, ob der Fix genau auf ein Installationsfenster beim Kunden trifft oder nicht.

Wenn Sie diesem Kunden eine Bearbeitungsdauer für Fehler versprechen wollen, sagen Sie ihm also „im Durchschnitt 5,5 Wochen“.

Das war nur ein Beispiel. Bei anderen Kunden oder bei gehosteten Livewebsites kann diese Bilanz völlig anders aussehen, weil es vielleicht gar keine so langen Warteschlangen und keine Installationsfenster gibt. Wenn Sie die Messgrößen jedoch richtig erheben und auswerten, wird jedoch auch in diesen Umgebungen das Richtige herauskommen.

Multitasking

Jetzt ist alles gut, oder? Für das Versprechen von Projektterminen brauchen wir den Durchsatz mit Mittelwert und Schwankungsbreite. Für das Versprechen von Serviceterminen brauchen wir die Bearbeitungszeit und deren Schwankungsbreite. Dann haben wir doch alles, was der Kunde braucht, oder? Nein, noch nicht. Es fehlt noch eine große Rauschquelle, die uns alle Messwerte verhageln kann, und die heißt Multitasking.

Menschen können nicht wirklich an mehreren Aufgaben gleichzeitig arbeiten. Unser Gehirn bearbeitet immer nur eine Aufgabe gleichzeitig und schaltet dann zwischen mehreren hin und her. Das kostet Energie, und wir machen Fehler dabei.

Das bedeutet: Wenn in einer Multikundenumgebung ein Kunde etwas ganz Dringendes verlangt und wir nehmen es einfach ins Team herein, dann erzeugen wir Multitasking. Dies setzt Bearbeitungszeiten herauf und den Durchsatz herab. Und zwar in doppelter Hinsicht.

John D. C. Little hat das schon 1961 erforscht [3]. Er wurde von Supermarktbesitzern gefragt: Wie viel Platz muss ich im Supermarkt für wartende Kunden bereitstellen? Auf diesen Platz kann ich keine Ware stellen, also kostet er mich bares Geld. Professor Little fand das heraus, was man später auch als Little’s Law bezeichnen würde: Anzahl Kunden gleichzeitig im Laden = Ankunftsrate * Bedienzeit.

Wenn also im Schnitt 100 Kunden pro Stunde eintreffen und jeder im Schnitt eine halbe Stunde im Laden verbringt, so muss der Supermarkt durchschnittlich 100 * 0,5 = 50 wartende Kunden gleichzeitig aufnehmen können.

Bei uns in der Softwareentwicklung handelt es sich nicht um Kunden im Supermarkt, sondern um Arbeitspakete im Team, doch das Gesetz ist dasselbe. Wenn 100 Stories pro Monat eintreffen und jede einen halben Monat braucht, dann muss das Team an 50 Stories gleichzeitig arbeiten können, um Schritt zu halten. Stellt sich nun die Frage, wie wir das im Team am besten machen. Nehmen wir zehn Leute und lassen sie fünffach multitasken? Das wird nichts. Wir brauchen da schon 50 Leute, damit jeder nur an einer Story gleichzeitig zu arbeiten braucht und zwei im Monat erledigen kann.

Man kann Little’s Law auch umstellen und sagen: Bearbeitungszeit = gleichzeitige Arbeit / Durchsatz.

Das bedeutet: Wenn wir bei gegebenem Durchsatz mehr gleichzeitige Arbeit (Work in Progress) ins Team lassen, steigt die Bearbeitungszeit. Der Durchsatz wird durch die Schlagzahl des Teams bestimmt und lässt sich ohne Überstunden oder Neueinstellungen nicht sofort verändern. Doch Work in Progress kostet lediglich eine Teamentscheidung: Wie viel Arbeit wollen wir (uns) gleichzeitig (an-)tun?

Was in Little’s Law noch nicht enthalten ist: je mehr Multitasking, umso mehr Fehler macht der Mensch und muss noch einmal nacharbeiten. Das vergrößert die Bearbeitungszeit noch einmal. Also wird ein Team mit steigendem Work in Progress nicht linear langsamer, sondern weit mehr als linear.

Was wird also ein Kanban-Team tun, wenn es realistische Termine versprechen können will? Die Leute werden Work in Progress streng limitieren, sodass Durchsatz und Bearbeitungszeit nicht so stark schwanken. Das ist analog zu einem Fluss, der in einem engen Bett schnell und gleichmäßig fließt.

Fazit: Ihr Messgrößencocktail

Bisher habe ich vier Faktoren gezeigt, die Softwareteams das Leben schwer machen. Drei davon haben wir jetzt im Griff: Verschiedene Typen von Arbeit, Arbeit für mehrere Kunden auf einmal und Variabilität (Rauschen) in den Tätigkeiten. Das Thema Dringlichkeit ist einen separaten Artikel wert. Die typischen Messgrößen von Kanban-Teams kennen Sie nun.

Kanban-Teams wissen, dass das Rauschen mit steigender Arbeitspaketgröße und mit Work in Progress wächst. Beides werden Kanban-Teams deshalb möglichst klein halten, um zuverlässige Voraussagen treffen zu können. Die Bearbeitungszeit und der Durchsatz schwanken dann nicht mehr so stark wie vorher. Entsprechend nimmt die Zahl der Fehler ab und das Verhalten wird ruhiger, angenehmer und zuverlässiger.

Kanban-Teams halten Warteschlangen so kurz wie irgend möglich. Das ermöglicht Businessagilität, d. h. schnelles Eingehen auf das, was die Kunden jetzt brauchen, nicht das, was sie am Anfang glaubten, zu brauchen.

Kunden schätzen dieses souveräne und gleichzeitig flinke Verhalten, und die Teams fühlen sich wohler dabei.

Matthias Bohlen hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://mbohlen.de/bt0115/ und http://treffpunkt.mbohlen.de finden.
Geschrieben von
Matthias Bohlen
Matthias Bohlen
Matthias Bohlen arbeitet als Experte für effektive Produktentwicklung. Teams engagieren ihn als Coach in vielen Projekten, um Prozesse, Architektur und Organisation für sich selbst zu finden und aufzustellen. Matthias Bohlen hilft aktuell auch Teams, die gerade die Startup-Phase verlassen und zu einer erfolgreichen Company skalieren. Er hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://scaletonextlevel.com finden können.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Kanban: Pünktlich und zuverlässig liefern"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Matthias Bohlen
Gast

Hallo vom Autor,

ich habe noch zusätzliche Infos zu diesem Artikel auf meiner Website veröffentlicht: http://mbohlen.de/bt0115je/

Viel Freude beim Lesen!
Matthias Bohlen