Was Kanban-Teams unter „dringend“ verstehen

Wer laut schreit, der kriegt

Matthias Bohlen
wer-schreit-der-kriegt

© Shutterstock / Ollyy

Nicht alle Arbeit ist gleich dringend. Dem lautesten Kunden Vorrang zu geben, kann richtig oder falsch sein. „Der Product Owner wird’s schon richtig priorisieren“, sagen manche Teams im Zweifelsfall – und machen es sich damit zu leicht. Kanban-Teams nutzen stattdessen für das Work Scheduling ein besonderes Denkmodell: Serviceklassen (Classes of Service), basierend auf Verzögerungskosten.

Die Firma Siemens hätte der Deutschen Bahn in 2011 sechzehn neue ICE-Züge liefern sollen. Im Februar 2013 waren sie immer noch nicht geliefert. Der Grund: Die ICEs fielen durch den Bremstest, weil es zu lange dauerte, von dem Moment, in dem der Fahrer auf den Knopf drückt bis die Bremse wirklich zog. Siemens musste die Deutsche Bahn damit trösten, dass sie einen weiteren ICE gratis liefern. Ein ganzer ICE gratis – können Sie sich vorstellen, was das kostet? Und damit nicht genug: Siemens machte im folgenden Quartal eine Rückstellung von rund 116 Millionen Euro, um für weitere solche Verzögerungen gerüstet zu sein [1].

Der Zug kam nicht

Verzögerungen können also ausgesprochen unangenehm werden. Deshalb ist es sehr wichtig, dass Produktmanager (oder Product Owner) und Teams Features so einplanen, dass Verzögerungen minimiert oder zumindest deren Auswirkungen begrenzt werden. In einfachen Projekten kein Problem, doch was macht ein Team, das für mehrere Kunden auf einmal arbeitet? Jeder Kunde beurteilt Dringlichkeit in der Regel nur nach seinen eigenen Maßstäben –die anderen Kunden sind ihm dabei egal. Ein Dienstleister muss aber, um finanziell erfolgreich zu sein, selbst eine klare Vorstellung haben bzw. sich einen Begriff davon machen, was Dringlichkeit für mehrere Kunden gleichzeitig bedeutet.

Verzögerungskosten

Nehmen wir noch einmal das Siemens-Beispiel: In 2011 sollte geliefert werden. Anfang 2013 hatten sie noch nicht geliefert. Sie mussten dafür einen ganzen ICE kostenlos geben, also hat jede Verzögerungswoche quasi 1,5 Mio. Euro gekostet. Solche Verzögerungskosten sind meist Opportunitätskosten, manchmal aber auch reale Kosten:

  • Betrachten Sie z. B. den Umsatzausfall pro Tag, wenn Sie einen Onlineshop haben, Ihr Kreditkartenprovider das API ändert und Ihre IT es nicht schafft, die Änderung in Ihren Systemen rechtzeitig zu implementieren.
  • Oder was ist, wenn eine neue Playstation-Version nicht rechtzeitig vor Weihnachten in die Geschäfte kommt?
  • Was, wenn man fünf Jahre lang nicht auf eine neue Datenbanksoftware umgestellt hat, obwohl der Support des Herstellers dafür ausläuft, und wenn dadurch die Kosten einer Fehlersuche und -beseitigung auf der alten Datenbanksoftware entsprechend hoch sind?

Diese Fälle sind sehr unterschiedlich. Für den Dienstleister, der die Software für solche Fälle realisiert, ist es wichtig, daraus einen Begriff von Dringlichkeit abzuleiten und Features unterschiedlich einzuplanen, je nachdem wie viel Verzögerungskosten sie auslösen.

Wie funktioniert das mit der Einplanung der Tickets aber nun im Alltag? Gibt es dafür ein einfaches Verfahren, das die Teams nicht von der Arbeit ablenkt und die richtigen Features wählen lässt?

Datum und Dringlichkeit

In Scrum gibt es die Rolle des Product Owners, kurz auch PO genannt. Er ist für das Produkt und seine Features verantwortlich, inklusive der finanziellen Aspekte. Der PO muss den Ertrag seines Produkts maximieren und die notwendigen Investitionen minimieren.

Eine unangenehme Hauptaufgabe ist dabei die Priorisierung der Features, sodass der Ertrag voraussichtlich maximal werden wird. Das Team hält sich dabei vornehm zurück, denn „wir sind ja reine Techniker – lass das mal den PO machen.“ Oft ist der PO dann überfordert, denn er kann das für einen Kunden noch sicherstellen, doch bei einer Vielzahl von Features, die für unterschiedliche Kunden auch unterschiedlich dringend sind – was macht er dann? Wie kann er das ausbalancieren?

Viele Manager trennen nicht zwischen datumsgetriebener und dringlichkeitsgetriebener Arbeit. Das hat böse Folgen. Sie ordnen dringenden Features einfach ein geplantes Datum zu und managen sie wie datumsgetriebene Arbeit. Dadurch setzt man die Features mit echten Terminen einem Risiko aus.

Umgekehrt: Managt man alles als dringlichkeitsgetrieben, ohne Termine, so wird man dem Terminrisiko nicht gerecht. Keine der beiden (einseitigen) Ansätze führt zu guten Entscheidungen. Alles wird deutlich besser, wenn wir getrennte Aspekte auch getrennt managen.

Serviceklassen

Teams, die zusätzlich zu ihrem Prozessframework noch die Kanban-Methode anwenden, wissen, was sie tun müssen, um ihrem PO zu helfen. Kanban-Teams werden das zeitliche Risiko nämlich so interpretieren:

„Wir müssen unsere Arbeit so steuern, dass bei Verzögerungen die Summe der Auswirkungen für die Firma minimiert wird.“

Kanban-Teams teilen Features in mehrere so genannte Serviceklassen ein. Der Begriff Serviceklasse ist dabei genau definiert:

Eine Serviceklasse ist eine Menge von Prozessrichtlinien, die beschreiben, wie ein Arbeitspaket behandelt werden sollte, basierend auf dem Risiko, das in dem Paket steckt. Meistens ist mit Risiko das zeitliche Risiko gemeint, Serviceklassen sind jedoch auch für andere Risiken anwendbar (z. B. Änderungswahrscheinlichkeit).

Konzentrieren wir uns hier auf den zeitlichen Aspekt: „Wir möchten realistische Termine versprechen und so viele versprochene Termine wie möglich einhalten. Darin steckt das Risiko der Verzögerungskosten, die eintreten, wenn wir Termine nicht schaffen.“ Das Risiko für jede Serviceklasse betrachten wir hier anhand je eines Beispiels:

Express: Bei einem Kunden steht die Produktion. Die Uhr tickt; es entstehen für den Kunden hohe Kosten pro Stunde Systemstillstand.

Fester Termin: Der Kreditkartenprovider des Onlineshops wird ab dem 1. April sein API ändern. Also muss ab 1. April das neue API unterstützt werden, sonst wird der Onlineshop kein Geschäft mehr machen. Das neue API vorher zu unterstützen, bringt keinen Vorteil.

Standard: Es gibt eine Menge Features, die alle gleich wichtig sind. Je früher die Firma sie liefert, umso glücklicher ist zwar der Kunde, doch es gibt keinen finanziellen Vorteil, wenn man einen bestimmten Termin einhält.

Schlupf: Der Datenbankhersteller sagt, er wird die aktuelle Version der Datenbank nur noch bis 2018 unterstützen. Also muss man bis dahin umgestellt haben. Doch es bringt keinen Vorteil, wenn man es vorher tut. Andere Schlupf-Beispiele: Verbesserungen der Fähigkeit, Experimente mit neuen Tools, Investitionen in Menschen usw.

Der PO hilft dabei, die Features in diese Klassen einzusortieren.

Kostenverlauf

Das Sortieren der Features erfolgt nach dem Verlauf der Verzögerungskostenkurve. Je früher sie beginnt und je steiler sie verläuft, desto höher müssen Features dieser Klasse beim Pull der Tickets priorisiert werden.

Die X-Achse der folgenden Diagramme ist die Zeit. Der Nullpunkt liegt bei heute. Die Y-Achse sind die Verzögerungskosten. Der Nullpunkt liegt bei 0 Euro.

Abbildung 1 zeigt die Verzögerungskosten für die Serviceklasse Standard. Sie sehen, die Kosten nehmen linear zu, je später ein Feature geliefert wird. Die Kurve beginnt heute und beim Wert Null.

Anders sieht es bei der Klasse Express aus: Beim Kunden steht die Produktion, er kann nicht weiterarbeiten, die Kosten sind bereits ab jetzt sehr hoch (Abb. 2).

Ähnlich ist es bei der Klasse Festes Datum. Der Unterschied zu Express ist: Die Kosten sind nicht ganz so hoch und entstehen nicht heute, sondern erst nach einem bestimmten Termin (Abb. 3).

Bei der Klasse Schlupf gibt es lange Zeit überhaupt keine Verzögerungskosten, doch eines Tages steigen sie drastisch (Abb. 4). Der Unterschied zur Klasse Festes Datum ist, dass der Zeitpunkt des Anstiegs zwar nach einem bestimmten Datum liegt, doch dieses Datum zuvor einfach nicht bekannt ist. Denken Sie z. B. an zurückgestellte Refactorings: Wenn Sie jetzt nicht handeln, passiert nichts. Wenn Sie in drei Jahren nicht gehandelt haben, fängt quasi eine Zeitbombe an zu ticken. Danach können weitere Änderungen am System plötzlich erstaunlich teuer werden, und die Verzögerungskosten kommen voll zum Tragen.

Abb. 1: Verzögerungskostenkurve der Klasse „Standard“

Abb. 1: Verzögerungskostenkurve der Klasse „Standard“

Abb. 2: Verzögerungskostenkurve der Klasse „Express“

Abb. 2: Verzögerungskostenkurve der Klasse „Express“

Abb. 3: Verzögerungskostenkurve der Klasse „Festes Datum“

Abb. 3: Verzögerungskostenkurve der Klasse „Festes Datum“

Abb. 4: Verzögerungskostenkurve der Klasse „Schlupf“

Abb. 4: Verzögerungskostenkurve der Klasse „Schlupf“

Prozessrichtlinien

Die Teams geben sich selbst Prozessrichtlinien. Diese beschreiben ein Teamverhalten, das notwendig ist, um dem Kunden eine bestimmte Servicequalität zu bieten. Das notwendige Teamverhalten wird für jede Serviceklasse anders aussehen. Beispiele:

  • Express: Alle Griffel fallen lassen, die Arbeit unterbrechen und sich zuerst um das Expressticket kümmern, das eben hereingekommen ist.
  • Fester Termin: Einen Termin errechnen, zu dem spätestens mit der Arbeit begonnen werden muss. Zum Beispiel: Den Zieltermin 1. April nehmen, die durchschnittliche Realisierungszeit (Time in Process) für Tickets dieses Typs „dreißig Tage“ abziehen, dann kurz vor diesem errechneten Starttermin 1. März beginnen, zum Beispiel am 20. Februar.
  • Standard: Tickets dieser Klasse einfach in der Reihenfolge ihres Eingangs oder in der Reihenfolge bearbeiten, die mit dem Kunden abgesprochen wurde.
  • Schlupf: Immer wieder Tickets dieser Klasse in den Ticketmix des Teams aufnehmen. Das Team arbeitet kontinuierlich auch an diesen Tickets – sie dürfen nicht vernachlässigt werden, nur weil kein konkreter Termin ansteht oder er noch weit entfernt ist. Teammitglieder werden jedoch bei Pull-Entscheidungen (wenn nötig) andere Tickets den Schlupf-Tickets vorziehen. Schlupf-Tickets sind auch „Kanonenfutter“, also Puffer für dringendere Dinge.

Farbige Zettel an der Wand

Kanban-Teams arbeiten mit Zetteln an der Wand oder mit Tickets in einem Ticketsystem, oder beides. Sie färben die Tickets entsprechend ein, z. B. weiß für Express, pink für fester Termin, gelb für Standard und grün für Schlupf. Danach teilen die Teams ihre Kapazität auf die Serviceklassen auf und legen in Absprache mit dem PO fest:

  • Damit wir gut organisiert bleiben und nicht verrückt werden, arbeiten wir nur an max. 20 Tickets gleichzeitig. Davon akzeptieren wir nur ein Expressticket, also 5 Prozent. Wenn ein weißes Ticket kommt, lassen wir alles liegen und erledigen dies zuerst.
  • Lieferungen mit festem Termin bedeuten ebenfalls ein Risiko, deshalb vereinbaren wir, dass nur 20 Prozent aller Zettel, die gerade in Arbeit sind, pink sein dürfen. Pinkfarbene Tickets werden wir in den Prozess ziehen, sobald der Endtermin so nahe rückt, dass die durchschnittliche Realisierungszeit (Time in Process) gerade noch gut ausreichen wird.
  • Für die Tickets der Klasse Standard spendieren wir 50 Prozent unserer Kapazität, also darf die Hälfte aller Tickets gelb sein. Die gelben Tickets ziehen wir einfach eins nach dem anderen.
  • Schlupf muss auch immer mal erledigt werden, sonst wird er plötzlich so dringend, dass er stört. Also achten wir darauf, dass 30 Prozent aller Tickets, die in Arbeit sind, grün sind. Wenn es eng wird, werden wir jedoch die grünen als Erstes liegen lassen, nicht die gelben.

Abbildung 5 zeigt eine Kanban-Tafel mit entsprechend eingefärbten Tickets. Solch ein Mix von Tickets ist wie ein Portfolio mit gut ausbalanciertem Risiko. Immer, wenn es Probleme gibt, weiß das Team dadurch von allein, wie es reagieren muss, auch wenn der PO gerade einmal nicht in der Nähe sein sollte (was ja in manchen Organisationen angeblich vorkommen soll). Die vereinbarten Prozessrichtlinien wirken als Entscheidungsfilter und ermöglichen dem Team zu handeln.

Abb. 5: Kanban-Tafel mit farbigen Tickets der vier Serviceklassen

Abb. 5: Kanban-Tafel mit farbigen Tickets der vier Serviceklassen

Stellen Sie sich nun ein Daily-Stand-Up-Meeting in diesem Team vor. Die Leute werden zwei Fragen beantworten wollen:

  • Was können wir fertigmachen oder wenigstens voranbringen?
  • Was können wir an neuen Tickets ziehen, weil wir Kapazität frei haben?

Die Mitglieder werden zuerst nach weißen Tickets Ausschau halten und diese auf der Überholspur fertigmachen. Auch das Management, also PO und Co., verfolgen die weißen Tickets aktiv.

Danach kommt die Farbe Pink in den Blick. Das Team wird aus der Position eines pinkfarbenen Tickets auf der Tafel entnehmen, wie lange es wohl noch dauern wird, bis dieses in der Spalte Fertig landen wird. Die Teammitglieder vergleichen dann mit dem Datum, das auf dem pinken Ticket steht, und beurteilen, ob die Zeit ausreichend ist. Wenn nicht, werden sie ab jetzt reagieren wie bei einem weißen (Express) Ticket.

Die gelben Tickets (Standard) kommen als Nächstes dran, danach die grünen (Schlupf). Das Team wird bei allen Tickets darauf achten, dass der Anteil einer Farbe mit dem vereinbarten Anteil übereinstimmt, dass also z. B. 50 Prozent Standard und 30 Prozent Schlupf jederzeit an der Wand zu sehen sind. Beim Nachziehen neuer Tickets aus der linken Spalte der Tafel werden die Leute im Team sich fragen:

  • Ist ein weißes Ticket aufgetaucht? Dann sofort ran, es sei denn, ein anderes weißes ist noch unterwegs. Dann machen wir zuerst das, damit es „rausgeht“.
  • Ist ein pinkfarbenes Ticket da, das aufgrund seines Datums nach einem Pull „ruft“? Dann ziehen wir das jetzt.
  • Haben wir Leute frei, sodass wir jetzt noch gelbe und grüne Tickets hereinziehen können, entsprechend der vereinbarten Prozentverteilung?

Für Fortgeschrittene

Sie haben gesehen, dass das Vorgehen mit expliziten Prozessrichtlinien für Serviceklassen einen echten Vorteil hat: Das Team kann entschlossen handeln und trotzdem cool dabei bleiben. Es nimmt Aufregung und Spannung heraus, unter der viele Teams heute immer noch arbeiten. Wir müssen uns nicht verrückt machen, denn wir haben ein Verfahren, das die Kosten für die Firma und die Folgen für den Kunden minimiert. Wildes Hin- und Herspringen hat noch nie geholfen, doch jetzt wissen wir sogar, ob und wann wir springen müssen. Kanban gibt uns die Signale so rechtzeitig, dass es kein Problem ist, zu entscheiden und zu handeln.

Teams, die damit Erfahrung haben, können jetzt noch Faktoren einbauen, die die Kundenzufriedenheit steigern. Nehmen Sie an, Sie haben drei Kunden für dieses Team. Kunde A zahlt 50 Prozent des Budgets, Kunde B zahlt 30 Prozent, Kunde C nur 20 Prozent.

Bei den Pull-Entscheidungen vor der Tafel könnte das Team die gelben Tickets nach der Menge ziehen: 50 Prozent der gelben Tickets auf der Tafel stammen immer von Kunde A, 30 Prozent von B, 20 Prozent von C. So bekommen die Kunden den Anteil an der Teamkapazität, der ihnen zusteht. Beim Pull werden die Leute sich kurz fragen, ob Gerechtigkeit herrscht und das nächste Ticket desjenigen Kunden ziehen, dessen Anteil gelber Tickets zu klein zu werden droht. Auch diese Vorgehensweise entzieht dem Ganzen weitere Dramatik.

Fazit: Dringlichkeit ist relativ

Wenn Sie in Ihrer Organisation mit Arbeit unterschiedlicher Dringlichkeit zu tun haben, hier noch einmal die Schritte, die Ihnen helfen werden:

  1. Legen Sie generell fest, was Verzögerung für Ihren Kontext bedeutet, nicht im Einzelfall, sondern überhaupt.
  2. Unterscheiden Sie ein echtes Zieldatum (an dem etwas passiert) von einem beliebig gesetzten Datum (an dem nichts passiert).
  3. Vergessen Sie beliebig gesetzte Daten und ersetzen Sie sie durch Risikobetrachtung mit Serviceklassen.
  4. Legen Sie pro Serviceklasse fest, woran Sie sie erkennen und welches Verhalten Sie von Ihrem Team dafür erwarten.
  5. Weisen Sie jeder Serviceklasse einen Anteil an der Kapazität Ihres Teams zu. Helfen Sie dem Team, diesen Anteil einzuhalten.
  6. Betrachten Sie es als Alarmzeichen, wenn vor lauter Express- und datumsgetriebener Arbeit keine Kapazität mehr für dringlichkeitsgetriebene Standardarbeit oder für langfristige Verbesserungen bleibt. Diskutieren Sie das mit dem Team und schaffen Sie Abhilfe.

Vertrauen Sie diesem sorgfältig ausbalancierten System, nicht der Energie einzelner Helden im Team, die „es immer wieder rausreißen“. Das wird Ihnen ermöglichen, kontinuierlich und zuverlässig zu liefern. Ihre Kunden werden das zu schätzen wissen.

Matthias Bohlen hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://mbohlen.de/bt0215/ und http://treffpunkt.mbohlen.de finden.

Aufmacherbild: Little girl screaming via Shutterstock / Urheberrecht: Ollyy

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
  1. Was Kanban-Teams unter Dringlichkeit verstehen (Artikel in Business Technology Magazin) - Matthias Bohlen2015-10-25 22:17:34

    […] Freude beim Lesen (hier klicken)! Und danach: Hier erfahren Sie, wie Sie das für Ihre Firma und Ihre Kunden ebenfalls umsetzen […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.