NBA78: Kanban Serviceklassen (Classes of Service)

Effiziente Priorisierung in Kanban

In dieser Episode erkläre ich, wie du unterschiedliche Prioritäten in Kanban durch die Einführung von Serviceklassen effektiv abbilden kannst. Oft haben wir es mit unterschiedlich wichtigen Aufgaben zu tun, sei es aufgrund von Kundenvereinbarungen oder internen Anforderungen. Ich teile praktische Tipps zu Service-Limits, SLA-Vereinbarungen und dem Umgang mit Prioritäten, die dir helfen werden, deinen Kanban-Prozess zu optimieren.

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile oder ihr hinterlasst mir eine Sprachnachricht: +4950329677123

—

No Bullshit Kanban Starter Guide

• Artikel mit Infografik und PDF zum Download: https://no-bullshit-agile.de/no-bullshit-kanban-guide.html
• Folge zum Anhören: https://no-bullshit-agile.de/nba77-no-bullshit-kanban-starter-guide.html

NBA55 – Walking the Board

• https://no-bullshit-agile.de/nba55-walking-the-board-agile-methode.html

NBA66 – Flow-Messung in agilen Teams – was bringt’s, was ist Bullshit?

• https://no-bullshit-agile.de/nba66-flow-messung-in-agilen-teams.html

Zusammenfassung

In dieser Episode von "No Bullshit Agile" tauche ich in das Konzept der Serviceklassen im Kanban-Framework ein und erläutere, wie du damit unterschiedliche Prioritäten innerhalb deiner Arbeitsaufgaben managen kannst. Oftmals müssen wir in der agilen Praxis verschiedene Kundenanforderungen und interne Deadlines berücksichtigen, die eine klare Priorisierung erfordern. Durch die Einführung von Serviceklassen kannst du nicht nur deine Arbeit optimal kategorisieren, sondern auch den Flow deiner Aufgaben effektiver gestalten.

Außerdem bespreche ich häufige Fallstricke bei der Implementierung von Serviceklassen und gebe dir wertvolle Tipps, welche Kriterien du zur Festlegung deiner Klassen nutzen solltest. Ich empfehle, mit wenigen klar definierten Serviceklassen zu beginnen, um Überforderung zu vermeiden. Diese Episode richtet sich an alle, die ihre Kanban-Methodik vertiefen und anpassen möchten, um so einen reibungsloseren Workflow zu erreichen.

Transkript

Hallo und herzlich willkommen bei No-Bullshit-Agile. Mein Name ist Thomas. Jede Woche spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe ich euch den No-Bullshit-Kanban Starter Guide vorgestellt. Wenn du darüber nachdenkst, ob Kanban was für dich ist, dann höre gerne in die Folge. Schau dir gerne den Artikel dazu an und auch die Infografik. Alle Links dazu und alle weiteren Links, die ich erwähne, findest du in den Shownotes.

Heute in Folge 78 will ich einen Randaspekt von Kanban aufgreifen. Nämlich was machst du in Kanban, wenn du unterschiedlich wichtige Arbeit hast.

Ein einführendes Beispiel

Um einzuführen ein kleines Beispiel. Du arbeitest für verschiedene Kunden, intern oder extern und du hast Vereinbarungen mit den Kunden, wann du etwas lieferst oder in welcher Geschwindigkeit du etwas lieferst. Und das ist zwischen diesen Kunden unterschiedlich.

Jetzt ist es in Kanban so, dass wir grundsätzlich ja nur, in Anführungszeichen, den Flow managen. Und eigentlich bedeutet das, das nächste Element, was oben ist, wird gepullt, wenn denn die Kapazität im Team dafür vorhanden ist. Und wie dieser ganze Flow funktioniert, wie gesagt, dafür gibt es diesen Kanbans Starter Guide. Schau da gerne rein.

Das Problem: Unterschiedliche Prioritäten

Was machen wir jetzt? Klingt ja theoretisch sehr gut. Wir nehmen einfach das nächste Element. Wenn wir festlegen müssen, wenn dieser Fall eintritt, also wir machen etwas für diesen Kunden oder auch noch ein kleiner Ausblick, wenn denn ein Produktionsproblem auftritt, dann ist es wichtiger oder anders zu behandeln, als in anderen Situationen. Wie wollen wir das im Flow repräsentieren?

Natürlich ist es so, wir sortieren ja das Backlog. Wir sortieren auch das Up Next. Auch da wieder der Verweis auf das Board, was ich als Beispiel, als Vorschlag im Kanbans Starter Guide habe. Schon nach Priorität, sprich eigentlich müsste das Team die nächste wichtigste Story von oben pullen und es tut das Team auch. Doch was passiert, während wir das auf dem Board reflektieren?

Die Lösung: Service-Klassen

Und um das zu steuern, gibt es die sogenannten Service Klassen, Classes of Services. Ich kann definieren, dass eine bestimmte Art von Arbeit wichtiger ist als eine andere.

Und damit kann ich unter anderem Folgendes tun. Gerade wenn man mit Kunden arbeitet, ist es so, dass man mit den Kunden unterschiedliche Service Level Agreement Vereinbarungen hat, sprich in bestimmten Situationen definiert ist, was für erste Reaktionszeiten zum Beispiel da sind. Und das ist eine Art der Kategorisierung und auch eine Art von Service Klasse, die ich benutzen kann.

Im echten Leben ist es ebenso, wenn etwas in eine bestimmte Klasse fällt, ich also eine bestimmte Geschwindigkeit brauche, um ein Problem zu lösen oder eine erste Reaktion zu haben, dann ist das aufgrund einer vertraglichen Vereinbarung und das ist auch alles ganz normal. Und die Frage ist jetzt, wie bilde ich das in Kanban ab? Und die Antwort darauf ist eben Service Klasse.

Eine zweite Art kann sein, ich brauche die Möglichkeit, dass bestimmte Elemente andere überholen können. Also vielleicht ist es so, dass ich sage, alles was zu diesem Projekt gehört, ist wichtiger als bei einem anderen Projekt. Oder ich sage, alles was von diesem Kunden kommt, ist wichtiger als ein anderes. Oder ich sage, alles was ein Produktionsproblem ist, ist wichtiger als etwas anderes.

Eine Analogie kann sein, stellt euch vor, ein Kunde kann einen Express-Versand buchen oder einen Standard-Versand und das muss ich jetzt auf meinem Board abbilden. Das Fundament ist also grundsätzlich mal, nicht alle Arbeit, die wir haben, ist gleich. Sie ist nicht gleich wichtig und nicht gleich dringend. Heißt also, das sehr vereinfachte Pull-Prinzip funktioniert in Kanban sehr gut, manchmal vermisst man aber eben eine weitere Strukturierung.

Typische Service-Klassen

Jetzt hatte ich schon ein paar Beispiele genannt, trotzdem vielleicht noch mal durchgehen, was können typische Service-Klassen sein, damit du weißt, passt das für mich, kann ich davon was gebrauchen, macht das für mich Sinn.

Die erste Klasse ist halt wirklich, es gibt irgendeinen Notfall, also ein Produktionsausfall, eine Sicherheitslücke, vielleicht hat sich irgendwas in einem rechtlichen Kontext verändert und deswegen ist es auf einmal ganz wichtig. Vielleicht ist es auch so, dass jetzt ein Wettbewerber im Markt auf einmal etwas implementiert hat und für den Kunden es super wichtig ist, jetzt schnell zu sein. Also nenne ich jetzt erst mal Notfall, manchmal hört man das Wort Expedite.

Das zweite ist, es gibt vielleicht bestimmte Dinge, die haben ein fixes Datum. Es gibt eine Marketing-Kampagne für ein Jubiläum beim Kunden oder gesetzliche Anforderungen, die sich zu einem bestimmten Stichpunkt ändern. Auch das könnte eine Art von Service-Klasse sein.

Eine ganz andere Kategorie von Service-Klasse kann sein, welche Services habt ihr denn? Also vielleicht gibt es einen Service-Backend und einen Service-Frontend oder einen Service-Datenbank oder einen Service-Firewall oder was auch immer ihr tut und diese Services haben unterschiedliche Kapazitäten und eventuell sogar unterschiedliche Prioritäten. Dann könnte man auch auf dieser fachlichen Ebene Service-Klassen einführen.

Implementierung von Service-Klassen

Gut, wir sind also an einem Punkt, wir haben ein schönes Kann-Mann-System, unsere Arbeit fließt und wir stellen jetzt fest, nicht jede Arbeit ist gleich aus den diversesten Gründen, die ich gerade genannt habe. Und die Lösung innerhalb von Kann-Mann ist dann halt in dem Moment zu sagen, okay, dann gucken wir uns unsere Services an und wir führen diese Service-Klassen ein und wir definieren in den Service-Klassen jetzt alle Parameter, die wir kennen.

Also vor allen Dingen den Parameter Web-Limit. Unterschiedliche Service-Klassen können jetzt unterschiedliche Work-in-Progress-Limits haben. Das zweite ist, man kann diese Service-Klassen in den meisten Tools, also zum Beispiel Jira, so einstellen, dass sie optisch anders dargestellt werden.

Nehmen wir ruhig diese Service-Klasse Expedite, also Produktionsausfall oder etwas in dieser Art, dann würde ich den natürlich über alle anderen Service-Klassen setzen. Und das würde bedeuten, oder das ist dann so, dass auf dem Board alle Elemente, die zu dieser Klasse gehören, auch auf dem Board ganz oben stehen. Das heißt, dem Team ist halt sofort auch klar, okay, das ist dann augenscheinlich unsere höchste Priorität und das macht inhaltlich natürlich dann auch entsprechend Sinn.

Speaking of Board-Darstellung, das hilft euch natürlich auch beim Daily und auch hier nochmal der klare Hinweis darauf, nutzt dieses Format Walk the Board fürs Daily, denn auch genau da hilft euch jetzt wieder dieses von oben nach unten und vor allen Dingen von rechts nach links arbeiten. Ihr seht aufgrund der Service-Klasse und aufgrund der optischen Darstellung, zum Beispiel in Jira, dass ihr etwas ganz Wichtiges oben habt.

Erweiterte Regeln und Metriken

Mit diesen Service-Klassen kann man jetzt noch deutlich mehr machen. Ihr könntet überlegen, ob ihr bestimmte dedizierte Regeln für diese Service-Klassen einführt und sagt, wenn etwas in der Service-Klasse 1 zugeordnet ist, dann müssen wir dem Kunden innerhalb von vier Stunden eine Antwort schicken. Reaktionszeit im Bereich SLA.

Könntet auch überlegen, wenn etwas in der Service-Klasse B ist, bedeutet das für uns, wir müssen eine ausführlichere technische Dokumentation dazu schreiben. Sprich, die Service-Klassen erweitern jetzt das Standard Kann-Mann-Modell um eine Organisation, eine weitere Unterteilung und damit Organisation eurer Arbeit.

Ihr könnt euch übrigens überlegen und das sollte man auch tun, ob ihr Metriken, wenn ihr sie denn erfasst, also zum Beispiel eine Cycle-Time, dann an Service-Klassen festmacht. Die Cycle-Time in der Service-Klasse 1 ist anders als die Cycle-Time in der Service-Klasse 2 und das gilt nicht nur für Cycle-Time, das kann auch für andere Metriken, die ihr benutzt, relevant sein.

Pitfalls und Fallen

Was euch wahrscheinlich klar ist, ich will aber trotzdem darauf eingehen, es gibt so ein paar Pitfalls mit Service-Klassen. Also, wenn ihr zu viele Service-Klassen auf einmal habt, dann ist das schlecht, weil ihr immer wieder überlegen müsst, ist das jetzt diese oder diese oder diese Service-Klasse und wo ist eigentlich jetzt wirklich noch der Unterschied.

Mein Tipp wäre hier ganz klar, fangt mit einer oder dann entstehen zwei Service-Klassen an, einer Urgent und einer Normalen und versucht die Urgent Service-Klasse so wenig wie möglich zu benutzen. Das nützt natürlich nichts, alles in Urgent reinzuhauen, sondern ihr müsst euch wirklich explizit fragen, ist es wirklich so und muss das wirklich jetzt hier in Urgent rein, weil sonst nutzt euch das ganze System einfach nichts.

Das zweite ist, ihr braucht eine klare Definition, die kann man sich auch Schritt für Schritt erarbeiten, wann kommt ein Element in welche Service-Klasse, was heißt denn Urgent. Also klar, Produktionsausfall ist ja auch immer mein beliebtestes Beispiel, ich glaube, das ist ziemlich klar, aber was ist denn mit, das Logo soll ausgetauscht werden. Das kann halt super unwichtig sein oder im Bereich vom Branding auf einmal super wichtig sein und dazu braucht ihr solche Definitionen.

Also, eine Leitplanke kann sein, hat eine Umsetzung eine rechtliche Konsequenz, nur als ein Beispiel oder wirkt sich eine Umsetzung auf das Branding des Kunden aus, wäre eine zweite Definition, die man sich überlegen kann. Der Kunde sagt, ich rede ja immer so, weil aus dieser Sicht, weil wir ja für Kunden viel machen, das ist mir ganz wichtig, ist in meinen Augen gar keine. Also nur einfach hinsagen, es ist ganz wichtig, bringt nichts, das muss man mit dem Kunden gemeinsam erarbeiten, warum ist das wichtig.

Wann Service-Klassen einführen?

Um den Punkt hier eigentlich tatsächlich schon abzuschließen, vielleicht, wann kann ich sagen, sollte man Service-Klassen einführen? Also, wenn du wirklich vom Kanban Starter Guide kommst, du überlegst Kanban einzuführen oder vielleicht gerade damit angefangen hast, bei meiner klaren Empfehlung Service-Klassen noch nicht zu machen.

In dem Moment, wo du feststellst, durch das normale Sortieren von Backlog oder Upnext schaffst du es nicht deinen Flow zu managen, weil du dazu schreiben musst zu einer Story, ja hier die ist jetzt super wichtig oder du sie im Flow nicht mehr ganz nach oben bekommst, dann könnte es ein guter Punkt sein zu sagen, okay vielleicht wollen wir eine Service-Klasse jetzt einführen, das heißt wir haben eine besondere Klasse und dann unsere ganz normale Arbeit und von da aus kann man sich dann Stück für Stück auch weiterentwickeln.

Wie gesagt, versucht nicht fünf, sechs, sieben Service-Klassen zu haben, das ist einfach too much. Könntet auch überlegen eine Service-Klasse einzuführen, wenn ihr gemischte Teams habt, ihr habt die gleiche Arbeit auf dem Board oder alle eure Arbeit auf dem Board, aber verschiedene Teams. Back-end Front-end hatte ich vorhin schon gesagt, aber vielleicht auch sowas wie es gibt Support und es gibt Weiterentwicklung, Development in Projekten, wo Features entwickelt werden.

Vielleicht gibt es dann eine Support Service-Klasse und wenn ihr immer und immer wieder intern, vielleicht sogar auch extern über Prioritäten diskutiert und sprecht, auch dann könnte es vielleicht ganz gut sein, eben das explizit dazu machen, damit man nicht mehr jedes Mal darüber diskutiert, sondern gute Policies zu haben für zwei Service-Klassen oder vielleicht drei und dann ist zu 90 Prozent klar, wenn Arbeit reinkommt, in welche Service-Klasse gehört die.

Abschluss

Ja und das soll es dann auch schon gewesen sein. Wie ihr wisst, ich versuche die Folgen immer kurz zu halten. Mir geht es darum, euch so ein bisschen ins Denken zu bringen, euch zu inspirieren, ob ihr tiefer in ein Thema einsteigen wollt. Service-Klassen ist sicherlich der nächste Schritt in einem Kann-Man-System.

Ich werde da ein bisschen mehr drauf eingehen in dem Advanced-Kan-Man-Guide, an dem ich ja gerade arbeite. Vielleicht da noch mal ganz kurz erklärt, es gibt diesen Starter-Guide, das ist wirklich, ich fange bei 0 an und obendrauf wird es dann den Advanced-Guide geben, der im Prinzip den nächsten Schritt dann erklärt.

Ja, wie gesagt, das soll es dann eigentlich auch schon gewesen sein. Wie immer freue ich mich über dein Feedback. Ich brauche das Feedback, damit ich eben auch gucken kann, was kann ich besser machen. War die Folge inhaltlich gut? Hat sie dir geholfen? Das sind so die Dinge, die mich natürlich immer beschäftigen und insgesamt habe ich auch wie immer noch eine ganz große Bitte, wenn dir das hier gefällt, wenn dir die Folge gefallen hat, wenn sie dir geholfen hat, wenn dir der ganze Podcast gefällt, dann teile das gerne, teile das mit deinen Kolleginnen und Kollegen, teile es auf deinen Social-Media-Kanälen.

Je mehr Leute von dem Podcast erfahren, desto größer wird die Diskussion, desto mehr Feedback bekomme ich, desto mehr Themen kann ich wieder aufnehmen und neue Folgen darüber machen und wenn es gut läuft, kommt dir das einfach auch zugute.

Ansonsten sage ich wie immer, habt eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.