NBA81: Wertvoll: (Kanban)-Board-Regeln explizit machen

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 habe ich über Kanban-Flightlevel gesprochen. Wenn

00:00:14: ihr das nicht sagt, das ist ein Modell, damit man sich ein bisschen besser

00:00:17: vorstellen kann, wie denn, ich sag mal, strategisch von oben nach unten die

00:00:23: Unternehmensausrichtung in Kanban, meiner Meinung nach nicht nur in Kanban,

00:00:28: funktioniert. Wir haben ganz oben im Flightlevel 3 die strategische Ebene, das

00:00:32: Management, die Koordination. Dann haben wir, wenn ihr mehr als ein Team seid, dann

00:00:38: die zweite Ebene, Flightlevel 2. Hier geht es um die übergreifende Koordination und

00:00:43: dann sind wir auf Flightlevel 1, relativ weit unten, tatsächlich auf jedem

00:00:48: einzelnen Team. Und Flightlevel ist ein sehr schönes Konzept, um sich vorzustellen,

00:00:52: okay, wie funktioniert ein gesamtes Unternehmen im agilen Arbeiten und

00:00:58: wie spielen diese einzelnen Ebenen, die es ja eigentlich immer gibt, dann zusammen.

00:01:02: Wenn dich das interessiert, hör da gerne rein. Den Link zu der Folge sowie alle

00:01:06: weiteren Links, die ich hier erwähne, findest du in den Shownotes. Das hier ist

00:01:10: die Folge 81 und heute will ich dir einen kleinen Denkanstoß geben, dass du ein

00:01:14: bisschen mehr über dein Board und vor allem über die Boardregeln nachdenken

00:01:18: kannst. Diese Denkanstöße, das ist ja so der

00:01:21: Hauptgrund für diesen Podcast. Ich versuche immer so Häppchen mal rein zu

00:01:24: schmeißen und hoffe, dass es bei dir irgendwie resoniert und du sagst, okay,

00:01:28: da hat der Thomas einen Punkt. Ja, ich würde sagen, wir steigen mal ein.

00:01:32: Begleitend zu dieser Folge gibt es übrigens einen Artikel, den werde ich

00:01:37: natürlich auch in den Shownotes entsprechend verlinken.

00:01:40: Ich glaube halt, das Szenario ist gar nicht so selten. Ich erlebe es auch immer

00:01:45: wieder. Man sitzt da und überlegt, okay, wann kann die Story denn von der Spalte

00:01:50: A in die Spalte B und es macht wenig Sinn, dass man lange darüber nachdenkt.

00:01:56: Es wäre viel besser, diese Regeln explizit zu machen.

00:02:00: Also, mir geht es heute darum, ihr schaut auf unser Board. Wir haben ein Board, das

00:02:06: hat verschiedene Spalten, die hoffentlich euren Flow abbilden und warum zieht man

00:02:13: eine Story von der einen in die andere Spalte? Wir haben also unser Board und

00:02:18: das hat verschiedene Spalten und ich gehe gleich auf die Spalten auch noch ein und

00:02:23: es wäre doch schön, wenn man halt im Team, gerne auch regelmäßig darüber

00:02:29: sprechen, festlegen kann, wann kann ein Element von A nach B wandern, denn das

00:02:36: Board mit seinen Spalten bildet unseren Flow ab. Das sind die Stationen unserer

00:02:41: Fabrik und wir wollen den Flow in Kanban permanent optimieren.

00:02:47: Das bedeutet eben, es sollte möglichst wenig Reibung auch geben bei diesem

00:02:54: Thema des Statusübergangs einer Arbeit. Und ich komme nachher auch noch mal kurz

00:03:01: auf Jira. Jira bietet leider keine Möglichkeit, zumindest habe ich bisher

00:03:05: keine gefunden. Wenn du eine kennst, sag mir gerne Bescheid. An den Spalten noch

00:03:10: weitere Informationen zu hinterlegen oder am liebsten sogar zwischen den

00:03:14: Spalten. Ich beschreibe jetzt mal ein Board, damit wir uns das alle ein bisschen

00:03:19: besser vorstellen können. Das hat folgende Spalten. Diese Spalten, die wären

00:03:26: mein Tipp, wenn du mit Kanban startest. Das habe ich alles in diesem No-Bullshit-

00:03:31: Kanbans-Data-Guide festgehalten. Auch den Link findest du übrigens in den

00:03:35: Shownotes. Also wir stellen uns folgendes Board mal vor. Wir haben ein Backlog.

00:03:40: Hier kommt unsere Arbeit rein. Wir sammeln hier unsere Arbeit. Die ist erst

00:03:46: einmal vielleicht ein bisschen unsortiert und die ist auch noch nicht perfekt

00:03:49: spezifiziert. Es geht in dieser Spalte darum, eben die Arbeit zu sortieren und

00:03:55: sie perfekt vorzubereiten. Perfekt. Ich mache Gänsefüßchen in der Luft. Ich weiß,

00:04:00: Perfektionismus und perfekt gibt es auch nicht. Aber so gut es eben geht. Das ist

00:04:04: also unser Eingangskorb, so nenne ich das mal. Wir sind hier, kleiner Hinweis auf

00:04:10: den Kanbans-Data-Guide nochmal, im Upstream kann man. Über Upstream und

00:04:15: Downstream habe ich übrigens in der Folge 79 gesprochen. Gut, wir haben also

00:04:20: unser Backlog. Die nächste Spalte, die ich in dem Starter-Guide vorschlage, lautet

00:04:25: Up Next. Hier wartet die vorbereitete Arbeit, die vom Team bearbeitet werden

00:04:31: kann. Das ist unsere zweite Spalte. Die dritte Spalte ist jetzt Konzept. Hier

00:04:36: arbeitet das Team das Konzept, die Software-Architektur und klärt auch

00:04:41: offene Fragen, die vielleicht aus technischer Sicht entstehen.

00:04:44: Das ist mir deswegen so wichtig, dass es diese Spalte gibt, weil ich nicht möchte

00:04:51: oder wir alle nicht möchten, dass Arbeit in Development auf On-Hold geht. Weil, oh

00:04:58: wie soll das denn sein? Oder ach, da müssten wir uns nochmal was überlegen.

00:05:02: Das möchte ich in diesem Kern, in Development, das ist ja mehr oder weniger

00:05:07: die Hauptspalte, in der unsere Arbeit stattfindet, vermeiden und es ist besser,

00:05:13: das vorher zu tun. Das ist also die Konzept-Spalte. Und wenn etwas fertig

00:05:16: konzeptioniert ist, kommt es in die Spalte Ready for Development. Das ist so

00:05:20: eine Wartespalte, sage ich mal. Wartestatus. Das Team kann sich aus Ready

00:05:26: for Development dann Dinge nehmen, um sie in der nächsten Spalte Development

00:05:30: dann zu entwickeln. Und dann kommt die letzte Spalte. Die habe ich versucht

00:05:34: möglichst allgemein zu formulieren. Die heißt hier Release, denn ich weiß,

00:05:38: Release-Prozess, Freigabe, alles was da hinten dran hängt, das ist super

00:05:43: individuell, je nach Kunde, je nach Situation, je nach Team. Und wenn dann

00:05:48: etwas released ist, ist die Arbeit erstmal abgeschlossen. Wir sind im

00:05:52: Downstream kann man und erwarten jetzt Feedback und das fließt dann wieder ein

00:05:57: in das Backlog. Das heißt, das ist unser Board. Nochmal ganz kurz, wir haben

00:06:04: Backlog, wir haben Upnext, wir haben Konzept, wir haben Ready for Development,

00:06:08: wir haben Development und dann Release. Und meine Frage ist jetzt an dich, denk

00:06:14: mal kurz drüber nach, kannst du Kriterien festlegen, wenn, wann kannst du Arbeit von

00:06:21: Upnext in Konzept ziehen oder von Development nach Release? Und das sind

00:06:27: die typischen Fragen, aus meiner Praxis zumindest, die sich Teams auch immer

00:06:32: wieder stellen. Und wie ich schon gesagt habe, es wird blöd, wenn das Team jedes

00:06:36: Mal wieder diskutiert und auch jedes Mal wieder ein bisschen anders entscheidet

00:06:40: und die Kriterien eben nicht so klar sind, die Regeln nicht explizit sind. Wann

00:06:46: können wir etwas von einer Spalte in die andere ziehen? Was sind unsere Kriterien,

00:06:50: für diesen Statusübergang? Ja, wie ich schon gesagt habe, die

00:06:55: Lösung ist eigentlich ziemlich einfach. Ich kann das verstehen, wenn du meine

00:06:59: Frage von eben nicht beantworten kannst. Es geht eben genau darum, wir wollen

00:07:05: jetzt definieren, wie sind die Regeln für jeden Statusübergang. Und ich greife

00:07:11: jetzt einfach mal mein Beispiel von eben gerade auf, meine Frage von eben gerade,

00:07:15: wie können die Regeln lauten von Upnext zu Konzept? Nochmal kurzes Recap, Upnext

00:07:22: bedeutet, da ist Arbeit, die ist eigentlich fertig definiert, die kann

00:07:26: begonnen werden und in Konzept wollen wir jetzt die Softwarearchitektur machen.

00:07:31: Und die Regeln könnten jetzt, das ist natürlich hypothetisch, aber sie

00:07:35: könnten jetzt wie folgt lauten, die Regeln von Upnext nach Konzept, keine

00:07:40: Arbeit ist mehr in Spalten weiter rechts, Stop Starting, Start Finishing, wir wollen

00:07:44: zuerst versuchen, unser Board leer zu bekommen.

00:07:48: Wir wollen ja natürlich einen Wert auf die Straße kriegen. Also erste Regel, keine

00:07:52: Arbeit mehr in Spalten weiter rechts. Zweite Regel, ein weiteres Teammitglied

00:07:57: steht zur Verfügung. Bei uns zumindest ist es so, dass wir diesen Architekturteil

00:08:02: zu zweit machen. Es kann sein, dass einer die Architektur

00:08:05: vorbereitet, aber dann einen zweiten dazu holt und die Architektur erklärt, um dann

00:08:10: zu sagen, okay wir haben zu zweit drauf geguckt, wir sind uns ziemlich sicher, dass

00:08:13: das so funktionieren wird. Die dritte Regel, die Beschreibung der

00:08:17: Story erscheint auf den ersten Blick vollständig.

00:08:20: Natürlich ist es so, dass gerade auch in diesem Bereich Konzept viele Fragen

00:08:26: nochmal aufkommen. Das ist ganz normal und ganz typisch und

00:08:31: trotzdem sollte man sich das angucken, bevor man es in Konzept zieht und sagen,

00:08:35: okay auf den ersten Blick, da sind die richtigen Links dabei, keine Ahnung Doku

00:08:40: ist da, Screenshots sind da, was auch immer ihr braucht.

00:08:43: Grundsätzlich mal scheint diese Story im Bereich Konzept jetzt erarbeitbar zu

00:08:49: sein. Und mit diesen drei Stichpunkten und ich würde auch empfehlen, das als

00:08:53: Stichpunkte und nicht als große Prosa zu machen, ist eigentlich erst mal jedem

00:08:58: klar, okay und deswegen kann ich diese Story von abnächst nach Konzept ziehen.

00:09:04: Ist ehrlich gesagt jetzt nicht besonders kompliziert, aber ich glaube trotzdem da

00:09:09: steckt viel Potenzial drin. Wenn wir solche Regeln für alle unsere

00:09:13: Spaltenübergänge haben, dann haben wir mal zumindest zwei Dinge erreicht.

00:09:18: Das erste ist Transparenz und damit schaffen wir eine Sicherheit. Jeder im

00:09:23: Team weiß, was sind unsere Regeln und das zweite ist, wir haben einen

00:09:29: wunderschönen Anker uns erarbeitet, um unseren Flow zu verbessern, denn erst wenn

00:09:33: wir das sehen, was sind eigentlich unsere Regeln, können wir zum Beispiel

00:09:37: feststellen, die Regeln sind kompletter Quatsch oder uns fehlt eine Regel, wir sind

00:09:42: dreimal hier und da auf die Klappe gefallen, lasst uns mal eine ergänzen oder

00:09:46: diese Regel hat sich überholt, unser Workflow ist anders geworden, deswegen

00:09:50: müssen wir die anpassen. Und es gibt wunderschöne Stellen, um über sowas zu

00:09:55: sprechen, zum Beispiel die Retro. Ihr könntet ja als

00:10:00: institutionalen Bestandteil eurer Retro zwei Minuten opfern, sage ich mal, um einen

00:10:08: Spaltenübergang oder die Regel eines Spaltenübergangs zu diskutieren. Passt

00:10:12: das noch, um ein bisschen aktiver darüber nachzudenken.

00:10:15: Und insofern finde ich, das lohnt sich total, sowas zu machen.

00:10:19: Alleine dieses Gespräch rund um, okay was sind denn wirklich die Regeln, ist total

00:10:25: wertvoll. Und die Regeln gibt es sowieso, sie sind halt nur implizit. Jeder hat so

00:10:29: seinen Teil der Regeln im Kopf, warum dann nicht aufschreiben.

00:10:32: An dieser Stelle ein Einschub oder ein Rant, das könnt ihr nehmen, wie ihr wollt, über

00:10:37: Jira. Wir nutzen Jira und wie ich vorhin schon gesagt habe, ich verstehe es

00:10:43: einfach nicht, dass Jira mir die Möglichkeit nicht bietet, da so einen

00:10:47: kleinen Infoknopf zu haben zwischen den Spalten, den ich mit Text befüllen kann,

00:10:53: um eben solche Regeln genau in Jira auch festzuhalten.

00:10:57: Wir haben uns das in Confluence aufgeschrieben, das ist auch okay, aber es wäre halt viel,

00:11:01: viel schöner, das einfach direkt in Jira zu haben.

00:11:05: Jira, ja, zwingt mich an dieser Stelle schon wieder nicht agil zu sein. Also ja,

00:11:12: wie gesagt, ich habe letztens auch so Mastodon-Post gesehen, da musste ich auch

00:11:15: lachen. Keine Panik, auch ohne Jira kann man agil

00:11:19: sein oder so weiter. Das war ein sehr schöner Satz, ja. Okay und ja, ehrlich gesagt, das

00:11:25: war es schon. Ich weiß, das ist nicht hochtrabend, aber ich weiß auch, da steckt

00:11:30: wie gesagt viel Potenzial drin. Es ist gar nicht so schwer, das umzusetzen und

00:11:35: meine Erfahrung ist, in diesen Gesprächen, gerade am Anfang, aber auch

00:11:39: zwischendurch, hat man so viele Chancen, seinen Float zu optimieren. Denkt auch

00:11:44: dran, wenn ihr mal ein neues Teammitglied bekommt, das schafft Sicherheit, weil

00:11:48: Transparenz, pass auf, guck es dir an, das sind unsere Übergangsregeln, ist eine

00:11:52: ganz tolle Sache, kostet nicht super viel Zeit, vor allem, wenn man permanent

00:11:56: daran arbeitet und wer hat ganz klar einen Tipp von mir. Und das soll es dann

00:12:02: für heute auch schon gewesen sein. Mich interessiert wie immer euer Feedback.

00:12:06: Nutzt ihr sowas, habt ihr sowas schon, kennt ihr vielleicht sogar einen Trick, wie man

00:12:09: das in Jira reinkriegt? Das wäre ganz toll, melde ich einfach gerne bei mir und

00:12:14: ansonsten habe ich wie immer noch eine ganz große Bitte, wenn dir diese Folge

00:12:18: gefallen hat, vielleicht hast du schon mehr gehört oder gelesen und dir gefällt

00:12:21: sogar noch mehr, dann tu mir einen ganz großen Gefallen und teile das, teile das

00:12:25: mit deinen Kolleginnen und Kollegen, teile das auf deinen Social Media Kanälen, je

00:12:29: mehr Leute hier von dem Podcast erfahren, desto mehr Input kriege ich, das kann ich

00:12:34: alles für neue Folgen verarbeiten und ja, das kommt dir schlussendlich auch zu

00:12:38: Gute. Vielen, vielen Dank an dieser Stelle.

00:12:41: Ansonsten sage ich, habt noch eine ganz tolle Woche und bis zur nächsten Folge