NBA77: No Bullshit Kanban Starter Guide

00:00:00: Hallo und herzlich Willkommen bei No Bullshit Agile, mein Name ist Thomas.

00:00:06: Jede Woche spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten.

00:00:10: In der letzten Folge ging es um das Thema Burnout und vor allen Dingen auch darum,

00:00:14: wie man in agilen Arbeiten nachhaltiges Tempo halten kann und dass es unter anderem auch

00:00:20: sogar in den 12 agilen Prinzipien erwähnt ist. Wenn dich das interessiert, den Link dazu wie

00:00:25: alle weiteren Links, die ich hier erwähne, findest du in den Show Notes. Heute in Folge

00:00:29: 77 spreche ich über den No Bullshit Kanban Starter Guide von mir. Okay, wir steigen mal ein. Was ist

00:00:36: die Situation? Warum bin ich darauf gekommen zu sagen, okay, ich würde ganz gerne mal das

00:00:43: zusammenfassen, was meine Erfahrung mit Kanban ist. Und ich fange mal ein bisschen davor an.

00:00:48: Wir haben in der Firma, das ist schon Ewigkeiten her, irgendwann mal firmenweites Kanban eingeführt.

00:00:54: Da war die Firma tatsächlich auch noch ein bisschen kleiner. Und wir sind dann nach ein

00:00:59: paar Jahren gewechselt auf Ein-Team-Macht-Scrum. Das heißt, da habe ich einige Erfahrungen,

00:01:04: glaube fünf oder sechs Jahre, so Scrum als Methode benutzen und sind dann irgendwann zu

00:01:10: dem Punkt gekommen, eigentlich passt das für uns als Agentur nicht. Wenn ihr den Podcast verfolgt,

00:01:15: habt ihr das sicherlich mitgekriegt, was ich so denke, warum für uns als Agentur Scrum nicht

00:01:22: passt. Und wir sind dann wieder zurück zu Kanban, aber dann teamweise. Jedes Team hat sein eigenes

00:01:28: Kanban. Und ich hatte schon ein bisschen länger die Idee, meine Erfahrung mal zusammenzuschreiben.

00:01:33: Und dann kam eben die Idee zu sagen, okay, warum nicht eine Infografik machen, die das Ganze mal

00:01:39: runterkondensiert und einen begleitenden Artikel. Und diese Infografik und der begleitende Artikel,

00:01:44: das ist der Kanban Starter Guide. Bevor wir einsteigen, was ist der Starter Guide und was

00:01:51: sind meine Gedanken dahinter? An dieser Stelle nochmal ganz, ganz vielen Dank an Marco von

00:01:54: Scrumshow, Sebastian und André für das ganze Feedback zu meinen Alpha-Versionen dazu. Auch

00:02:01: da komme ich gleich nochmal, wie geht es weiter, in einem zweiten Schritt drauf. Kleiner Sneak-Peak,

00:02:06: es gibt den Starter Guide und es wird auch noch einen Advanced Guide geben. Wenn man sich mit

00:02:12: Kanban beschäftigt, findet man natürlich unheimlich viel Literatur. Das ist auch toll

00:02:16: und schön. Was der Kanban Starter Guide sein soll, ist tatsächlich ein Startpunkt, wo du sofort

00:02:24: loslegen kannst mit Kanban. Wie gesagt, da stecken so meine Erfahrungen drin, da steckt viel von dem

00:02:29: drin, was ich mit dem Team erarbeitet habe. Das funktioniert für uns, so wie ich es hier jetzt in

00:02:35: der Infografik habe, sehr gut. Und deswegen habe ich mir gedacht, wenn du in der Situation bist,

00:02:41: okay, ich will mir das Kanban mal angucken. Wenn du vielleicht sogar in der Situation bist,

00:02:45: ich würde eigentlich gerne mit Kanban starten, dann ist der Starter Guide genau das Richtige

00:02:53: für dich. Und die Ergänzung wird dann oben drauf kommen oder drumherum kommen, sagen wir mal so. Das

00:02:58: passt glaube ich ein bisschen besser. Das wird dann der Advanced Guide sein, der die Dinge drumherum

00:03:04: noch erläutert. Okay, also Situation ist, du hast dich vielleicht schon ein bisschen mit Kanban

00:03:10: beschäftigt und du denkst dir, okay, cool, wie fange ich an? Ganz grundsätzlich sagt Kanban

00:03:16: tatsächlich, fange einfach da an, wo du stehst und beobachte deinen Flow und leite Maßnahmen

00:03:23: daraus ab. Das ist richtig, dass es so allgemein formuliert ist. Der Starter Guide jetzt von mir,

00:03:30: der ist halt deutlich detaillierter. Du findest die Übersicht, du findest den Artikel dazu und

00:03:38: innerhalb des Artikels auch einen Download zu dem PDF von der Übersicht. Alles in den Shownotes,

00:03:44: die passenden Links dazu. Schaust dir gerne an. Schaust dir vielleicht an,

00:03:48: während du den Podcast hörst oder auch danach. Gut, ich gehe den jetzt einfach mal von oben nach

00:03:53: unten durch und versuche so ein bisschen zu erklären, warum ich diese Elemente ausgewählt

00:03:58: habe und was die Elemente bedeuten. Das allererste ist für mich, kein System funktioniert gut,

00:04:05: wenn es nicht gute Storys hat. Das trifft Scrum jetzt genauso. Für mich ist das eine ganz zentrale

00:04:11: Komponente. Und für mich ist es wichtig, dass eine Story klein gehalten werden muss. Ich schreibe in

00:04:18: dem Starter Guide ein bis drei Tage. Ich glaube, es wird schwer für einige unter diesen einen Tag

00:04:23: zu kommen. Ich finde fünf, acht oder zehn Tage für eine Story viel zu groß. Und ich gebe dir

00:04:30: auch einen kleinen Tipp hier. Auch darüber habe ich im Podcast schon gesprochen und dazu habe ich

00:04:34: einen Artikel geschrieben. Wie kriegt man eine Story klein? Man muss sie am Prozessanfang klein

00:04:40: machen. Und dazu gibt es eine sehr schöne Methode, die augenscheinlich gar nicht so viele Leute

00:04:45: kennen, nämlich Dimensional Planning. Dimensional Planning kann man sich wie folgt vorstellen. Das

00:04:51: Beispiel findest du auch in der Infografik. Stell dir einfach vor, du sollst eine Straße bauen

00:04:55: zwischen Ort A und Ort B. Da gibt es noch keine Verbindung. Die Leute wollen schnell von A nach B

00:05:01: kommen. Jetzt kann man mit einem riesen Feststellungsplan überlegen, wie baue ich da jetzt

00:05:05: eine Autobahn. Man kann es aber auch anders machen. Und das ist eben Dimensional Planning. Du fängst

00:05:11: mit der allereinfachsten Art eines Wegs an. Sagen wir, es ist ein Feldweg. Damit kommt man schon mal

00:05:17: deutlich schneller von A nach B, weil man nicht mehr durch Wald und Wiese muss. Das wäre also

00:05:22: unsere allererste, unsere fundamentalste Story. Und dann überlegst du dir, wenn die fertig ist und du

00:05:28: Feedback dazu bekommst, welche Teile musst du weiter ausbauen. Also es könnte jemand sagen, ja,

00:05:34: schön dein Feldweg, aber an dieser Stelle ist ein kleiner Fluss und ich kriege jedes Mal nasse Füße.

00:05:41: Und dann sagst du, alles klar, dann bauen wir doch über den Fluss eine Holzbrücke. Und das

00:05:46: wird die Version 2 deiner Story. Und es kann hingehen bis zu, die ganze Strecke wird eine

00:05:51: Autobahn oder nur Teile. Und du stellst fest, die Teile, die du jetzt implementiert hast,

00:05:57: Autobahn, ich sag mal, beste Stufe für so einen Weg, die reicht vollkommen aus. Mehr Geld willst

00:06:04: du auch gar nicht ausgeben. Der Nutzen deiner Story ist erfüllt. Und dann hast du mit drei, vier oder

00:06:10: fünf Stories eben, ja, dein Feature entwickelt. Mit drei, vier, fünf Versionen. Du hattest jeweils die

00:06:16: Chance zu lernen aus dieser Version, aus der Vorgängerversion, um das einfließen zu lassen,

00:06:22: in, ja, deine nächste Version. Und das ist das Fundament für das, was jetzt kommt. Deswegen

00:06:30: steht es ganz oben. Für mich ist das Allerwichtigste, eine gute Story, mehrere gute Stories. Die sollten

00:06:37: übrigens auch abgestimmt sein. Mit den Endkunden, mit den Stakeholdern, mit allen, die daran beteiligt

00:06:43: sind. Das nächste ist jetzt, du willst deine Arbeit ja auf einem Board repräsentieren. Und

00:06:49: gerade im Design von Boards gibt es natürlich unheimlich viele Möglichkeiten. Das meine ich

00:06:55: jetzt gar nicht im Sinne von Jira, sondern im Sinne von Darstellung. Unter anderem, welche

00:07:01: Spalten du hast. Und da haben wir auch super viel daran gearbeitet. Und gemeinsam mit dem Team,

00:07:07: finde ich zumindest, muss ich mich beim Team auch ganz klar bedanken, haben wir sehr tolle Spalten,

00:07:15: mit denen man anfangen kann. Ich gehe die einmal kurz durch. Ich würde sagen, schau dir gerne den

00:07:21: Artikel und die Erklärung dazu an. Wir haben folgende Spalten. Die Arbeit kommt von irgendwo

00:07:28: und wir sammeln sie zuerst im Backlog. Und wir bereiten hier die Story soweit vor, unter anderem

00:07:36: mit dimensional planning, mit dem Kunden, mit Stakeholdern zusammen, mit Usern zusammen,

00:07:40: dass man sie entwickeln könnte. Und dann kommen sie in eine nächste Spalte. Diese Spalte heißt

00:07:48: Up Next. Hier fokussieren wir uns auf die wichtigsten Storys, die wir jetzt als nächstes

00:07:54: angehen wollen. Das Up Next priorisieren wir auch kontinuierlich. Das ist eben der ganz,

00:08:00: ganz, ganz große Unterschied zu Scrum. Wir arbeiten in einem permanenten Fluss. Wir nehmen

00:08:06: uns immer die nächste wichtige Story, wenn wir mit etwas fertig sind. Und dazu dient diese Spalte

00:08:11: Up Next. Das ist auch der Übergang hin zum Team. Das Team pullt ab Up Next dann die Storys in den

00:08:20: nächsten Status. Vorne sorgt noch jemand anders dafür. Auf der Infografik findest du auch so einen

00:08:27: kleinen Hinweis zu, welche potenziellen Rollen es in Scrum, genau, welche potenziellen Rollen es

00:08:33: in Kanban geben kann. Das ist der Service Request Manager und der Service Delivery Manager. Da gehe

00:08:39: ich heute auch nicht groß drauf ein. Wie gesagt, wir gehen mal zurück zum Board. Wir haben das

00:08:44: Backlog und das Nächste ist die Spalte Up Next. Hier priorisieren wir permanent aufgrund von

00:08:51: Feedback. Die oberste Story ist für das Team die wichtigste. Und ab Up Next pullt das Team aus der

00:08:59: Spalte in die nächste Spalte. Und die nächste Spalte nennen wir Konzept. Hier erarbeitet das

00:09:05: Team alles das, was auch technisch nötig ist. Hier prüft das Team, ist die ready? Können wir die

00:09:11: entwickeln? Und können wir sie so entwickeln, dass sie nicht gleich auf On Hold geht, wenn wir sie

00:09:17: bearbeiten? Das heißt, hier zerteilen wir unsere Arbeit ein bisschen. Wir nehmen den Teil Konzeption,

00:09:25: Architektur, Rückfragen klären, raus aus dem reinen Development und packen es vor das Development.

00:09:33: Das Team tut das, damit eben nur Storys, die so gut man es eben kann, ready sind. Damit nur die

00:09:42: in Development wandern. Gut, aus Konzept holen wir uns dann das Team in diesem Fall. Die Dinge,

00:09:50: die bearbeitet sind, wo das Konzept abgeschlossen ist und parkt sie in einer Spalte, die heißt

00:09:57: Ready for Development. Hier warten also die fertig vorbereiteten Storys auf die Umsetzung.

00:10:04: Diese Storys sollten jetzt also ohne On Hold durchgehen durchs Development. Sie sind relativ

00:10:11: klein. Wie gesagt, ein bis drei Tage durch dimensional Planning zerteilt. Dann gibt es

00:10:18: eine oder mehrere Spalten. Ich nenne das jetzt einmal umfassend Development. Hier kann mehr

00:10:24: drin passieren. Es könnte hier sowas wie Dokumentation entstehen oder Customer Feedback

00:10:29: schleifen oder, oder, oder. Wie gesagt, das ist für mich jetzt erstmal ein Platzhalter und diese

00:10:35: Spalte heißt Development. Hier findet die Arbeit statt. Das Team pullt sich aus Ready for

00:10:40: Development die nächsten Storys anhand der Reihenfolge und setzt diese Storys auf Basis

00:10:47: des Konzepts, das das Team sich ja davor erarbeitet hat, um. Bei uns ist es so, dass wir tatsächlich

00:10:53: ein zweites Board haben. Also wir nutzen Jira und im Prinzip ist dieses zweite Board eine Lupe

00:11:00: auf dieses Development und da drin sind dann wirklich weitere Spalten. Gehe ich jetzt nicht

00:11:04: drauf ein. Ich habe das hier abstrahiert. Es gibt die Spalte Development und wenn die Arbeit

00:11:09: abgeschlossen ist, dann wandert sie in eine Spalte, die ich hier bei uns Release nenne. Das heißt,

00:11:15: das kann das Release in Produktion sein, das kann Release Vorbereitung sein, das kann vielleicht

00:11:19: erstmal Release nur auf Staging sein. Das hängt wieder ganz stark von euren Prozessen ab und das

00:11:24: ist eben ein sehr gutes Design für ein Board, das bei uns sehr gut funktioniert und genauso ist

00:11:30: dieser Kanban Starter Guide jetzt auch gedacht. Er soll dir ermöglichen sofort loszulegen und

00:11:37: deswegen schlage ich hier auch ein Board Design vor. Du wirst dieses Board anpassen. Das ist auch

00:11:43: ganz normal. Da kommen wir auch gleich noch mal drauf. Das heißt, wir haben die Storys. Die sind

00:11:49: schön klein. Wir haben unser Board. Da habe ich hier Vorschläge, die sich in der Praxis bewährt

00:11:55: haben, gemacht, wie so ein Board aussehen kann und wir kommen jetzt zur nächsten wichtigen Komponente,

00:12:01: nämlich VIP-Limit. Du willst deine Arbeit beschränken. Es ist wichtig zu verstehen, je

00:12:08: mehr man startet, desto länger dauert alles. Little's Law nennt man das. Ist egal, vergiss es einfach

00:12:14: wieder. Wichtig ist nur zu wissen und das kennst du höchstwahrscheinlich aus der Praxis auch, je

00:12:19: mehr Bälle du in der Luft hast, desto schwieriger wird es sich auf jeden Einzelnen zu konzentrieren

00:12:24: und deswegen dauert einfach alles viel länger und deswegen wollen wir mit VIP-Limit unsere

00:12:30: Spalten beschränken. Wie viel Arbeit nehmen wir auf? Gerade auf der Development Spalte solltest

00:12:37: du von vornherein VIP-Limit setzen. Das kann man ja später ändern, aber es macht halt so viel

00:12:43: Sinn. Auch zu VIP-Limit habe ich eine eigene Folge gemacht. Da habe ich sogar ein Give-Dive gemacht. Auch

00:12:48: den Link findest du in den Show Notes. Mein Vorschlag ist hier, starte mit Teamgröße plus eins, also ihr

00:12:54: seid fünf Leute, dann macht ihr ein VIP-Limit von sechs. Du solltest die Cycle Time dann auf jeden

00:13:00: Fall monitoren. Wie lange dauert es, von einer Story wird angefangen, bis eine Story ist released,

00:13:05: in Tagen oder Stunden, was auch immer für eine Maßeinheit bei dir gut passt. Je mehr Daten dann

00:13:11: du da sammelst, desto besser, weil du dann sehen kannst, Einflüsse die du hast, zu viele Storys zum

00:13:19: Beispiel, wirken die sich auf die Cycle Time aus. Auch dazu habe ich eine ausführliche Folge gemacht,

00:13:25: die verlinke ich natürlich auch in den Show Notes. Gut, wir haben also unsere Storys, wir haben ein

00:13:31: Board, wir haben auf den strategisch wichtigen Spalten, in meinem Fall auf jeden Fall auf

00:13:37: Development, unsere VIP-Limits, wir erfassen die Cycle Time. Jetzt fehlen im Prinzip nur noch zwei

00:13:43: Komponenten und dann hast du schon ein sehr, sehr gutes Kann-Mann-System. Die nächste Komponente,

00:13:49: die fehlt, ist das Daily. Du möchtest ein Daily haben, das soll 15 Minuten sein und das ganze

00:13:56: Team soll im Daily in Sync bleiben und auch Blocker identifizieren. Auch da kann ich dir

00:14:03: wirklich nur ganz dringend empfehlen, die Methode Walk the Board zu nehmen. Walk the Board bedeutet,

00:14:08: du hast nicht diese Runde, wo jeder seine drei schicken Fragen beantwortet, sondern alle gucken

00:14:16: gemeinsam aus Board und wir arbeiten von rechts nach links. Wir schauen uns die oberste Story an

00:14:21: und schauen uns den Status an. Ist da etwas, was wir tun können, damit diese Story schnell

00:14:28: released werden kann? Jemand muss noch QA machen, jemand muss noch eine Doku schreiben. Das gehst du

00:14:35: für alle Storys durch und du achtest immer darauf, dass du guckst, dass die Storys, die kurz vor

00:14:41: Release sind, fertig werden. Getting things done. Und wie gesagt, diese Methode beschreibe ich auch

00:14:49: in einer expliziten Folge. Auch da verlinke ich diese Folge in den Shownotes und auch da kann ich

00:14:54: dir nur ganz dringend empfehlen, nutzt gleich diese Methode. Die hat den großen Vorteil, dass du eben

00:15:00: das, was du entwickelst, in den Mittelpunkt stellst und nicht die Leute, die es entwickeln,

00:15:05: die klassische, ich mache Gänsefüßen in der Luft Scrum Methode, diese drei klassischen Fragen,

00:15:11: was habe ich gemacht, was werde ich machen, was blockiert mich, stellt immer mehr den Menschen

00:15:16: in den Mittelpunkt und darum geht es nicht. Wir wollen nicht Menschen managen, sondern wir wollen

00:15:20: das Produkt managen, das wir releasen. Okay, dann fehlt uns eigentlich nur noch ein Baustein und

00:15:26: dieser Baustein ist Kaizen. Japanisches Wort, der permanente Verbesserungsprozess. Hier geht es darum,

00:15:33: jeder ist aufgefordert permanent zu gucken, was kann ich in meinen Prozessschritten, da wo ich

00:15:39: beteiligt bin, vielleicht verbessern und du findest zwei ganz klassische Events, die genau

00:15:48: dafür gedacht sind. Das eine ist das Refinement, du triffst dich einmal die Woche oder du machst

00:15:53: das regelmäßig, um auf technischer Ebene zu gucken, okay, was können wir an der Story verbessern,

00:15:59: was können wir hier weglassen, was müssen wir nachtunen und die zweite institutionelle

00:16:05: Verbesserungsmethode ist die Retrospektive. Hier geht es dann um Menschen und Prozesse,

00:16:11: aber hier steckt ja auch Potenzial drin, was können wir denn in der Zusammenarbeit verbessern

00:16:16: mit uns, mit den Kunden oder welche Art von Prozessen können wir verbessern, wie wir

00:16:21: dokumentieren zum Beispiel. Und ehrlich gesagt, das war es dann schon. Das sind die Kernkomponenten,

00:16:29: mit denen du loslegen kannst, ganz konkret, um Kanban an den Start zu kriegen. Ich wiederhole es

00:16:35: noch mal kurz. Wir haben halt Storys, die sind klein, die sind mit Dimensional Planning zerlegt.

00:16:41: Wir haben ein sehr gutes Board als Startpunkt, du wirst es sicherlich verändern. Wir haben

00:16:47: VIP Limits, die dir helfen, dein Flow zu managen. Wir haben das Daily, um uns abzustimmen und wir

00:16:53: haben den permanenten Verbesserungsprozess und auch den Willen, uns zu verbessern. Das japanische

00:16:59: Wort dafür ist eben Kaizen. Jetzt gibt es auf der Infografik und auch im Artikel noch ein,

00:17:06: zwei kleine Hinweise. Das Erste, weil ich weiß, dass viele sagen, Rollen sind schon wichtig und

00:17:13: ich kann das auch verstehen, sind potenziell gibt es zwei Rollen, die sind so ein bisschen

00:17:19: von Microsoft mit eingeführt, als Microsoft mit Kanban angefangen hat. Das ist der Service

00:17:25: Request Manager, das ist eher die Seite hin zum Kunden, der managt mit dem Kunden zum Beispiel,

00:17:33: welche Storys sind gerade wichtig und wie kriegen wir diese Storys in einen guten Reifegrad und

00:17:39: spricht mit dem Team über diese Requests. Daher auch das Wort Service Request Manager. Wenn ihr

00:17:47: das so wollt, der Service Request Manager ist also eher ein bisschen mehr so links auf dem

00:17:52: Bord unterwegs und der Gegenpol dazu ist der Service Delivery Manager. Der hat die Aufgabe,

00:18:00: den Arbeitsablauf zu beobachten und zu gucken, ob es da Optimierung gibt, dem Team dabei auch zu

00:18:07: helfen. Welche Optimierung des Kanbansystems finden wir? Vielleicht hat er eine Anregung

00:18:13: dazu, wie das Bord aussieht. Eine Spalte sollte wegfallen oder eingeführt werden, weil das mehr

00:18:18: eurem Prozess entspricht. Oder ein Vorschlag dazu, auf eine bestimmte Spalte vielleicht sogar noch

00:18:24: ein Wibble mitzusetzen. Das macht der Service Delivery Manager. Er ist dafür zuständig,

00:18:30: oder sie, eben zu liefern und den Prozess des Lieferns zu begleiten. Damit ist nicht ein Release

00:18:36: Manager gemeint, um das auch klar zu sagen. Es geht hier um die Organisation und um eine

00:18:41: unterstützende Rolle für das ganze Team. Wie gesagt, die Rollen müsst ihr nicht einführen,

00:18:45: deswegen habe ich sie so ein bisschen inaktiv gestaltet und im Artikel findet ihr auch ein

00:18:50: paar mehr Hinweise dazu. Sie könnten euch aber helfen, wenn ihr sagt, eigentlich sind wir mit

00:18:55: Rollen gut gefahren. Ich wollte vor allen Dingen sagen, auch Kanban kennt solche Rollen. Okay,

00:19:01: das soll es dann eigentlich zu dem Fundament, zu diesem No-Bullshit-Kanbans-Data-Guide schon sein.

00:19:09: Im Artikel findest du noch ein paar mehr Hinweise. Die will ich zumindest einmal ganz kurz anreißen

00:19:14: und die sind unter anderem aufgrund des Feedbacks von Leuten entstanden und da bin ich, wie gesagt,

00:19:20: hatte ich vorhin ja schon gesagt, super dankbar für. Das funktioniert auf Mastodon vor allen

00:19:26: Dingen halt sehr gut. Da habe ich wirklich das Gefühl, dass wir auch eine Community sind. Schöne

00:19:30: Grüße nochmal an alle und ganz, ganz lieben Dank dafür. Also, oft genug geht es darum,

00:19:37: erster Punkt jetzt, dass man eine gewisse Prognose machen möchte. Wann ist denn etwas fertig? Das ist

00:19:43: ein typischer Need, den sehe ich auch. In Scrum diskutiert ihr oft über eine Velocity und da bin

00:19:50: ich gar kein Fan von. Und es gibt zumindest in Kanban einen Ansatz dazu. Ich bin da auch

00:19:58: kein riesen Fan von und ich werde da eine gesonderte Folge drüber machen. Ich will ihn

00:20:01: der Vollständigkeit halber aber hier erwähnen. Nämlich erwähnen, sorry, Server-Level-Expectation.

00:20:06: Also aufgrund deiner Daten kannst du Aussagen treffen, 85 Prozent aller unsere Arbeitselemente

00:20:13: sind in drei Tagen oder weniger fertig. Das geht zum Beispiel aufgrund der Cycle-Time oder aber

00:20:18: auch der Lead-Time. Grundsätzlich geht das. Das Problem wird sein, wenn du das kommunizierst,

00:20:23: 85 Prozent Wahrscheinlichkeit sind wir in drei Tagen mit etwas fertig, dass die Leute

00:20:29: die 85 Prozent Wahrscheinlichkeit nicht mehr hören oder nicht gehört haben oder nicht hören haben

00:20:33: wollen. Und 85 Prozent sagt ja eben auch, in 15 Prozent der Fälle trifft das nicht zu und die

00:20:40: Ausreißer können eure Norm sein. Also die Ausreißer können normalerweise, sagst du,

00:20:45: drei Tage, auch 20 Tage sein oder 50 Tage. Sprich, wie gut es ist, mit solchen Zahlen zu

00:20:51: hantieren, hängt ein bisschen davon ab, wem nennt man diese Zahl und warum möchte diese andere

00:20:55: Person diese Zahl wissen. Ich mache dazu eine gesonderte Folge. Ich wollte es hier der

00:21:00: Vollständigkeit halber gerne mit drin haben. Das Nächste, was du machen kannst, auch darüber

00:21:05: werde ich eine gesonderte Folge machen, wollte ich schon länger, jetzt passt es ziemlich gut,

00:21:09: Service-Klassen. Du kennst es vielleicht, nicht alle deine Arbeit, die so in das System reinschließt,

00:21:14: ist gleich, sondern es gibt vielleicht Vertragsvereinbarungen für bestimmte Kunden

00:21:19: oder es gibt bestimmte Klassen von Risiken, die du hast. Ein Bug in Produktion ist wichtiger als

00:21:27: eine Ergänzung eines bestehenden Features und genau das sind Service-Klassen. Du vereinbarst

00:21:34: eben etwas, was in dieser Klasse ist, ist höher gewichtet als etwas anderes und das kann man

00:21:41: tatsächlich in den Boards, also z.B. in Jira auch einstellen, solche Service-Klassen und dann hat

00:21:46: man auf einmal eine Ansicht, wo bestimmte Dinge, obwohl sie eigentlich in der Reihenfolge weiter

00:21:50: unten wären, sehr explizit ganz oben dargestellt werden. Das sind Service-Klassen. Service-Klassen

00:21:56: können auch sein, deine Services, die du im Team hast. Also eine Service-Klasse könnte Frontend

00:22:02: sein und eine Service-Klasse könnte Backend sein. Das hängt ganz stark davon ab, wie deine Arbeit

00:22:08: aussieht und es ist auch nicht im Simple Guide, weil ich es für zu kompliziert halte zum Anfang,

00:22:14: es wird auf jeden Fall im Advanced Guide auftauchen. Und das dritte grundsätzliche Prinzip,

00:22:19: das ich hier auch weglasse, aber im Artikel erwähne, ist, es sollten eigentlich, in Kann man

00:22:25: die Regeln explizit gemacht werden. Wann darf eine Story von einer Spalte in die andere? Da

00:22:30: würde man über diesen Spaltenübergang dranschreiben, folgende Bedingungen müssen erfüllt sein. Also,

00:22:36: zwei Leute müssen sich das angeguckt haben. Wäre vielleicht eine Bedingung dafür, dass etwas von

00:22:42: der Spalte Concept in Ready for Development gehen darf. Regeln explizit machen. Und dann,

00:22:47: das sind ja Teile jetzt schon vom anderes, von diesem Advanced Kanban Guide, den ich da vorhabe,

00:22:54: kommen wir ein bisschen tiefer in diesen Advanced Guide. Steht auch was im Artikel zu drin. Was wir

00:23:01: jetzt gerade gemacht haben, ist, wir haben uns unsere Insel angeguckt. Unsere kleine Fabrik,

00:23:07: die Dinge, in denen wir etwas schaffen. Uns fehlen aber zwei ganz wichtige Komponenten. Nämlich,

00:23:12: unsere Insel müsste einen Hafen haben, in dem was angeliefert wird. Und wir dürfen nicht vergessen,

00:23:19: dass wir Kunden auf dem Festland haben, die etwas mit den Dingen tun, die wir auf unserer Insel

00:23:24: produzieren. Dieser Hafen ist dann die sogenannte Upstream-Schnittstelle. Was kommt wie in unser

00:23:32: Kanban-System rein? Sehr wichtiges Element. Das muss man in der ganzheitlichen Betrachtung auch

00:23:38: mit aufnehmen und mit betrachten. Und ja, das nenne ich jetzt den Hafen der Insel. Und das

00:23:44: zweite, unsere Kunden auf dem Festland. Wer empfängt unsere Arbeit und wie ist die Reaktion

00:23:51: dieser Leute? Auch das sollte ich definitiv in meinem Kanban-System berücksichtigen. Zwei sehr

00:23:58: schöne Themen, die ich, wie gesagt, in diesem Advanced Guide mit aufnehmen werde. Das passt

00:24:03: ganz wunderbar tatsächlich dann noch in einen anderen Blick auf ein komplexeres Kanban-System,

00:24:10: nämlich die sogenannten Flight Level. Auch die greife ich im Advanced Guide dann auf. Der Klaus

00:24:17: Leopold, der hat so ein Modell dazu entwickelt und es passt halt sehr, sehr schön. Ich habe jetzt

00:24:22: ganz viel, es gibt drei Flight Level, auf dem Flight Level 1 gesprochen. Das ist also die

00:24:29: niedrigste Stufe, die das Flugzeug fliegt, wenn wir jetzt mal bei Flight Level brauchen. Und da

00:24:34: geht es um das einzelne Team. Das ist im Prinzip jetzt das Zuhause von dem No-Bullshit-Kanban-Starter-

00:24:41: Guide, über den ich hier geredet habe und zu dem es diese Infografik auch gibt. Wenn wir jetzt über

00:24:47: dieses Downstream-Upstream sprechen, also über den Hafen und das Festland und nicht mehr nur über

00:24:53: unsere Insel, dann fliegen wir schon eine Ebene höher. Das ist der Flight Level 2. Hier geht es

00:25:00: darum, dass wir das Gesamtsystem betrachten. Wo kommt die Arbeit her? Wie verarbeiten wir sie? Und

00:25:07: wie shippen wir und wie ist dann das Feedback? Das wäre der Flight Level 2. Dann gehen wir noch

00:25:14: eine Ebene höher, der Flight Level 3. Dann sind wir schon auf einer strategischen Ebene. Hier

00:25:21: schauen wir uns insgesamt an, wenn wir zum Beispiel mehrere Teams haben, die kann man machen, wie ist

00:25:29: unsere Unternehmensstrategie? Arbeiten alle Teams auf diese Unternehmensstrategie hin? Das heißt,

00:25:37: wir haben einen Überbau, der dann über Teams hinweg koordiniert und beobachtet. Und das wäre

00:25:47: dann der sogenannte Flight Level 3. Ja und damit sind wir dann für heute auch durch. Heute ist die

00:25:53: Folge ein bisschen länger, wenn ich das so richtig hier beim Recording gerade sehe. Ich will ja gerne

00:25:59: eigentlich immer so 15-20 Minuten, aber ich denke, ja, also ich glaube, das ist nicht schlimm, einfach auch mal

00:26:06: eine bisschen längere Folge zu haben. Mir wäre es lieb, wenn dir das gefällt und du mit dem Kanban-Starterguide

00:26:14: was anfangen kannst, dass du das auf deinen Social Media Kanälen teilst. Ich möchte halt ganz gerne,

00:26:21: dass möglichst viele Leute das mitbekommen, weil ich glaube, dass da viel Potenzial für viele Teams

00:26:27: drin steht, die vielleicht da sitzen und sich denken, ja, jetzt kann man was für uns, was Neues

00:26:33: anfangen und Kanban ist so ein schönes System. Es ist so praxisnah, es ist so praxisrelevant und

00:26:42: mithilfe von dem Starterguide habt ihr einfach meiner Meinung nach einen so guten Startpunkt,

00:26:47: einfach auch loszulegen, dass es schade wäre, ja, wenn zu wenig Leute davon erfahren. Deswegen,

00:26:54: gib dir einen Ruck, teil das gerne hier, schreib selber einen Social Media Post,

00:26:59: sprich mit deinen Kolleginnen und Kollegen darüber und gib mir halt super, super gerne Feedback,

00:27:04: was dir vielleicht fehlt, was du anders siehst. Bei Feedback rede ich auch immer gerne davon. Ich

00:27:11: freue mich auch gerade über kritisches Feedback, nur so kann ich auch lernen. Deswegen meine ganz

00:27:16: große Bitte an dieser Stelle, wenn du glaubst, der Kanban-Starterguide ist cool, ja, dann mach

00:27:24: dir ein bisschen die Mühe und teil das gerne. Mach gerne ein Mastodon auf oder dein Twitter

00:27:29: oder dein LinkedIn oder was auch immer du benutzt und teil den Link einfach. Das wäre super,

00:27:35: super cool und dafür sage ich ganz, ganz vielen Dank. Ansonsten sage ich wie immer,

00:27:39: habt noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.