NBA78: Kanban Serviceklassen (Classes of Service)

00:00:00: Hallo und herzlich willkommen bei No-Bullshit-Agile. Mein Name ist Thomas. Jede Woche spreche ich hier

00:00:07: kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge habe ich euch

00:00:12: den No-Bullshit-Kanban Starter Guide vorgestellt. Wenn du darüber nachdenkst, ob Kanban was für

00:00:18: dich ist, dann höre gerne in die Folge. Schau dir gerne den Artikel dazu an und auch die Infografik.

00:00:24: Alle Links dazu und alle weiteren Links, die ich erwähne, findest du in den Shownotes. Heute

00:00:30: in Folge 78 will ich einen Randaspekt von Kanban aufgreifen. Nämlich was machst du in Kanban,

00:00:37: wenn du unterschiedlich wichtige Arbeit hast. Um einzuführen ein kleines Beispiel. Du arbeitest

00:00:44: für verschiedene Kunden, intern oder extern und du hast Vereinbarungen mit den Kunden,

00:00:51: wann du etwas lieferst oder in welcher Geschwindigkeit du etwas lieferst. Und das

00:00:56: ist zwischen diesen Kunden unterschiedlich. Jetzt ist es in Kanban so, dass wir grundsätzlich ja

00:01:01: nur, in Anführungszeichen, den Flow managen. Und eigentlich bedeutet das, das nächste Element,

00:01:08: was oben ist, wird gepullt, wenn denn die Kapazität im Team dafür vorhanden ist. Und

00:01:16: wie dieser ganze Flow funktioniert, wie gesagt, dafür gibt es diesen Kanbans Starter Guide.

00:01:20: Schau da gerne rein. Was machen wir jetzt? Klingt ja theoretisch sehr gut. Wir nehmen

00:01:26: einfach das nächste Element. Wenn wir festlegen müssen, wenn dieser Fall eintritt, also wir machen

00:01:34: etwas für diesen Kunden oder auch noch ein kleiner Ausblick, wenn denn ein Produktionsproblem auftritt,

00:01:41: dann ist es wichtiger oder anders zu behandeln, als in anderen Situationen. Wie wollen wir das

00:01:49: im Flow repräsentieren? Natürlich ist es so, wir sortieren ja das Backlog. Wir sortieren auch das

00:01:57: Up Next. Auch da wieder der Verweis auf das Board, was ich als Beispiel, als Vorschlag im Kanbans

00:02:03: Starter Guide habe. Schon nach Priorität, sprich eigentlich müsste das Team die nächste wichtigste

00:02:10: Story von oben pullen und es tut das Team auch. Doch was passiert, während wir das auf dem Board

00:02:17: reflektieren? Und um das zu steuern, gibt es die sogenannten Service Klassen, Classes of Services.

00:02:26: Ich kann definieren, dass eine bestimmte Art von Arbeit wichtiger ist als eine andere. Und damit

00:02:34: kann ich unter anderem Folgendes tun. Gerade wenn man mit Kunden arbeitet, ist es so, dass man mit

00:02:41: den Kunden unterschiedliche Service Level Agreement Vereinbarungen hat, sprich in bestimmten

00:02:48: Situationen definiert ist, was für erste Reaktionszeiten zum Beispiel da sind. Und das ist eine Art der

00:02:55: Kategorisierung und auch eine Art von Service Klasse, die ich benutzen kann. Im echten Leben ist es

00:03:02: ebenso, wenn etwas in eine bestimmte Klasse fällt, ich also eine bestimmte Geschwindigkeit brauche, um

00:03:10: ein Problem zu lösen oder eine erste Reaktion zu haben, dann ist das aufgrund einer vertraglichen

00:03:15: Vereinbarung und das ist auch alles ganz normal. Und die Frage ist jetzt, wie bilde ich das in

00:03:20: Kanban ab? Und die Antwort darauf ist eben Service Klasse. Eine zweite Art kann sein, ich brauche die

00:03:28: Möglichkeit, dass bestimmte Elemente andere überholen können. Also vielleicht ist es so, dass ich sage,

00:03:37: alles was zu diesem Projekt gehört, ist wichtiger als bei einem anderen Projekt. Oder ich sage, alles

00:03:45: was von diesem Kunden kommt, ist wichtiger als ein anderes. Oder ich sage, alles was ein

00:03:51: Produktionsproblem ist, ist wichtiger als etwas anderes. Eine Analogie kann sein, stellt euch vor,

00:03:58: ein Kunde kann einen Express-Versand buchen oder einen Standard-Versand und das muss ich jetzt auf

00:04:03: meinem Board abbilden. Das Fundament ist also grundsätzlich mal, nicht alle Arbeit, die wir haben,

00:04:10: ist gleich. Sie ist nicht gleich wichtig und nicht gleich dringend. Heißt also, das sehr vereinfachte

00:04:19: Pull-Prinzip funktioniert in Kanban sehr gut, manchmal vermisst man aber eben eine weitere

00:04:27: Strukturierung. Jetzt hatte ich schon ein paar Beispiele genannt, trotzdem vielleicht noch mal

00:04:31: durchgehen, was können typische Service-Klassen sein, damit du weißt, passt das für mich, kann ich

00:04:37: davon was gebrauchen, macht das für mich Sinn. Die erste Klasse ist halt wirklich, es gibt irgendeinen

00:04:43: Notfall, also ein Produktionsausfall, eine Sicherheitslücke, vielleicht hat sich irgendwas in

00:04:49: einem rechtlichen Kontext verändert und deswegen ist es auf einmal ganz wichtig. Vielleicht ist es

00:04:54: auch so, dass jetzt ein Wettbewerber im Markt auf einmal etwas implementiert hat und für den Kunden

00:05:01: es super wichtig ist, jetzt schnell zu sein. Also nenne ich jetzt erst mal Notfall, manchmal hört

00:05:08: man das Wort Expedite. Das zweite ist, es gibt vielleicht bestimmte Dinge, die haben ein fixes

00:05:14: Datum. Es gibt eine Marketing-Kampagne für ein Jubiläum beim Kunden oder gesetzliche Anforderungen,

00:05:21: die sich zu einem bestimmten Stichpunkt ändern. Auch das könnte eine Art von Service-Klasse sein.

00:05:27: Eine ganz andere Kategorie von Service-Klasse kann sein, welche Services habt ihr denn? Also

00:05:33: vielleicht gibt es einen Service-Backend und einen Service-Frontend oder einen Service-Datenbank oder

00:05:40: einen Service-Firewall oder was auch immer ihr tut und diese Services haben unterschiedliche

00:05:45: Kapazitäten und eventuell sogar unterschiedliche Prioritäten. Dann könnte man auch auf dieser

00:05:51: fachlichen Ebene Service-Klassen einführen. Gut, wir sind also an einem Punkt, wir haben ein

00:05:57: schönes Kann-Mann-System, unsere Arbeit fließt und wir stellen jetzt fest, nicht jede Arbeit ist

00:06:02: gleich aus den diversesten Gründen, die ich gerade genannt habe. Und die Lösung innerhalb von Kann-Mann

00:06:08: ist dann halt in dem Moment zu sagen, okay, dann gucken wir uns unsere Services an und wir führen

00:06:13: diese Service-Klassen ein und wir definieren in den Service-Klassen jetzt alle Parameter, die wir

00:06:19: kennen. Also vor allen Dingen den Parameter Web-Limit. Unterschiedliche Service-Klassen können

00:06:26: jetzt unterschiedliche Work-in-Progress-Limits haben. Das zweite ist, man kann diese Service-Klassen

00:06:32: in den meisten Tools, also zum Beispiel Jira, so einstellen, dass sie optisch anders dargestellt

00:06:40: werden. Nehmen wir ruhig diese Service-Klasse Expedite, also Produktionsausfall oder etwas in

00:06:46: dieser Art, dann würde ich den natürlich über alle anderen Service-Klassen setzen. Und das würde

00:06:53: bedeuten, oder das ist dann so, dass auf dem Board alle Elemente, die zu dieser Klasse gehören, auch

00:07:00: auf dem Board ganz oben stehen. Das heißt, dem Team ist halt sofort auch klar, okay, das ist dann

00:07:06: augenscheinlich unsere höchste Priorität und das macht inhaltlich natürlich dann auch entsprechend

00:07:10: Sinn. Speaking of Board-Darstellung, das hilft euch natürlich auch beim Daily und auch hier

00:07:16: nochmal der klare Hinweis darauf, nutzt dieses Format Walk the Board fürs Daily, denn auch genau

00:07:24: da hilft euch jetzt wieder dieses von oben nach unten und vor allen Dingen von rechts nach links

00:07:29: arbeiten. Ihr seht aufgrund der Service-Klasse und aufgrund der optischen Darstellung, zum Beispiel

00:07:36: in Jira, dass ihr etwas ganz Wichtiges oben habt. Mit diesen Service-Klassen kann man jetzt noch

00:07:42: deutlich mehr machen. Ihr könntet überlegen, ob ihr bestimmte dedizierte Regeln für diese

00:07:49: Service-Klassen einführt und sagt, wenn etwas in der Service-Klasse 1 zugeordnet ist, dann müssen

00:07:56: wir dem Kunden innerhalb von vier Stunden eine Antwort schicken. Reaktionszeit im Bereich SLA.

00:08:02: Könntet auch überlegen, wenn etwas in der Service-Klasse B ist, bedeutet das für uns, wir müssen eine

00:08:10: ausführlichere technische Dokumentation dazu schreiben. Sprich, die Service-Klassen erweitern

00:08:16: jetzt das Standard Kann-Mann-Modell um eine Organisation, eine weitere Unterteilung und

00:08:25: damit Organisation eurer Arbeit. Ihr könnt euch übrigens überlegen und das sollte man auch tun,

00:08:31: ob ihr Metriken, wenn ihr sie denn erfasst, also zum Beispiel eine Cycle-Time, dann an Service-Klassen

00:08:39: festmacht. Die Cycle-Time in der Service-Klasse 1 ist anders als die Cycle-Time in der Service-Klasse

00:08:46: 2 und das gilt nicht nur für Cycle-Time, das kann auch für andere Metriken, die ihr benutzt, relevant

00:08:53: sein. Was euch wahrscheinlich klar ist, ich will aber trotzdem darauf eingehen, es gibt so ein paar

00:08:58: Pitfalls mit Service-Klassen. Also, wenn ihr zu viele Service-Klassen auf einmal habt, dann ist das

00:09:05: schlecht, weil ihr immer wieder überlegen müsst, ist das jetzt diese oder diese oder diese Service-Klasse

00:09:10: und wo ist eigentlich jetzt wirklich noch der Unterschied. Mein Tipp wäre hier ganz klar, fangt

00:09:16: mit einer oder dann entstehen zwei Service-Klassen an, einer Urgent und einer Normalen und versucht

00:09:25: die Urgent Service-Klasse so wenig wie möglich zu benutzen. Das nützt natürlich nichts, alles in

00:09:32: Urgent reinzuhauen, sondern ihr müsst euch wirklich explizit fragen, ist es wirklich so und muss das

00:09:38: wirklich jetzt hier in Urgent rein, weil sonst nutzt euch das ganze System einfach nichts. Das

00:09:44: zweite ist, ihr braucht eine klare Definition, die kann man sich auch Schritt für Schritt erarbeiten,

00:09:49: wann kommt ein Element in welche Service-Klasse, was heißt denn Urgent. Also klar, Produktionsausfall

00:09:57: ist ja auch immer mein beliebtestes Beispiel, ich glaube, das ist ziemlich klar, aber was ist denn

00:10:02: mit, das Logo soll ausgetauscht werden. Das kann halt super unwichtig sein oder im Bereich vom

00:10:09: Branding auf einmal super wichtig sein und dazu braucht ihr solche Definitionen. Also, eine

00:10:15: Leitplanke kann sein, hat eine Umsetzung eine rechtliche Konsequenz, nur als ein Beispiel oder

00:10:23: wirkt sich eine Umsetzung auf das Branding des Kunden aus, wäre eine zweite Definition, die man

00:10:29: sich überlegen kann. Der Kunde sagt, ich rede ja immer so, weil aus dieser Sicht, weil wir ja für

00:10:36: Kunden viel machen, das ist mir ganz wichtig, ist in meinen Augen gar keine. Also nur einfach

00:10:42: hinsagen, es ist ganz wichtig, bringt nichts, das muss man mit dem Kunden gemeinsam erarbeiten,

00:10:46: warum ist das wichtig. Um den Punkt hier eigentlich tatsächlich schon abzuschließen,

00:10:52: vielleicht, wann kann ich sagen, sollte man Service-Klassen einführen? Also, wenn du wirklich

00:10:59: vom Kanban Starter Guide kommst, du überlegst Kanban einzuführen oder vielleicht gerade damit

00:11:06: angefangen hast, bei meiner klaren Empfehlung Service-Klassen noch nicht zu machen. In dem

00:11:12: Moment, wo du feststellst, durch das normale Sortieren von Backlog oder Upnext schaffst du es

00:11:21: nicht deinen Flow zu managen, weil du dazu schreiben musst zu einer Story, ja hier die ist jetzt super

00:11:29: wichtig oder du sie im Flow nicht mehr ganz nach oben bekommst, dann könnte es ein guter Punkt sein

00:11:35: zu sagen, okay vielleicht wollen wir eine Service-Klasse jetzt einführen, das heißt wir haben

00:11:39: eine besondere Klasse und dann unsere ganz normale Arbeit und von da aus kann man sich dann Stück

00:11:45: für Stück auch weiterentwickeln. Wie gesagt, versucht nicht fünf, sechs, sieben Service-Klassen zu

00:11:51: haben, das ist einfach too much. Könntet auch überlegen eine Service-Klasse einzuführen, wenn

00:11:57: ihr gemischte Teams habt, ihr habt die gleiche Arbeit auf dem Board oder alle eure Arbeit auf

00:12:02: dem Board, aber verschiedene Teams. Back-end Front-end hatte ich vorhin schon gesagt, aber

00:12:08: vielleicht auch sowas wie es gibt Support und es gibt Weiterentwicklung, Development in Projekten,

00:12:16: wo Features entwickelt werden. Vielleicht gibt es dann eine Support Service-Klasse und wenn ihr

00:12:22: immer und immer wieder intern, vielleicht sogar auch extern über Prioritäten diskutiert und

00:12:29: sprecht, auch dann könnte es vielleicht ganz gut sein, eben das explizit dazu machen, damit man

00:12:35: nicht mehr jedes Mal darüber diskutiert, sondern gute Policies zu haben für zwei Service-Klassen

00:12:41: oder vielleicht drei und dann ist zu 90 Prozent klar, wenn Arbeit reinkommt, in welche Service-Klasse

00:12:48: gehört die. Ja und das soll es dann auch schon gewesen sein. Wie ihr wisst, ich versuche die

00:12:54: Folgen immer kurz zu halten. Mir geht es darum, euch so ein bisschen ins Denken zu bringen, euch

00:12:58: zu inspirieren, ob ihr tiefer in ein Thema einsteigen wollt. Service-Klassen ist sicherlich der nächste

00:13:04: Schritt in einem Kann-Man-System. Ich werde da ein bisschen mehr drauf eingehen in dem Advanced-Kan-Man-Guide,

00:13:11: an dem ich ja gerade arbeite. Vielleicht da noch mal ganz kurz erklärt, es gibt diesen Starter-Guide,

00:13:16: das ist wirklich, ich fange bei 0 an und obendrauf wird es dann den Advanced-Guide geben, der im

00:13:22: Prinzip den nächsten Schritt dann erklärt. Ja, wie gesagt, das soll es dann eigentlich auch schon

00:13:28: gewesen sein. Wie immer freue ich mich über dein Feedback. Ich brauche das Feedback, damit ich eben

00:13:34: auch gucken kann, was kann ich besser machen. War die Folge inhaltlich gut? Hat sie dir geholfen? Das

00:13:39: sind so die Dinge, die mich natürlich immer beschäftigen und insgesamt habe ich auch wie

00:13:44: immer noch eine ganz große Bitte, wenn dir das hier gefällt, wenn dir die Folge gefallen hat,

00:13:49: wenn sie dir geholfen hat, wenn dir der ganze Podcast gefällt, dann teile das gerne, teile das mit

00:13:54: deinen Kolleginnen und Kollegen, teile es auf deinen Social-Media-Kanälen. Je mehr Leute von

00:13:58: dem Podcast erfahren, desto größer wird die Diskussion, desto mehr Feedback bekomme ich,

00:14:02: desto mehr Themen kann ich wieder aufnehmen und neue Folgen darüber machen und wenn es gut läuft,

00:14:07: kommt dir das einfach auch zugute. Ansonsten sage ich wie immer, habt eine ganz tolle Woche

00:14:12: und bis zur nächsten Folge bei No Bullshit Agile.