Agilophil-Daily Podcast Episode 25: Kanban STATIK

Herzlich Willkommen zur Folge Nummer 25 – das erste Jubiläum des agilophil-daily Podcasts. Heute schliesse ich die Kanban-Reihe ab und werde am Ende auch noch was in eigener Sache erzählen – also bitte dranbleiben…

Heute gehts um STATIK

Statik bedeutet ja eigentlich was festes, kommt ja auch aus der Mechanik und die Statik eines Hauses gibt darüber Auskunft, ob es hält oder in sich zusammenbricht…

Agil ist allerdings was flexibles und fließendes, daher scheint es zumindest mir etwas unlogisch zu sein, KANBAN mit STATIK einzuführen…

Ich habe ein paar Firmen kennen gelernt – große Konzerne aber auch kleinere IT-Unternehmen – eher noch im Start-Up Modus,. Und bei beiden Typen gab es das Phänomen, dass sie irgendwann eine Stufe des Services erreicht hatten, bei der Scrum tatsächlich begann Probleme zu machen. Das lag natürlich nicht an Scrum selbst, das möchte ich hier nochmal betonen, es lag an der Aufgabenstellung, dies sich geändert hat. Von der Entwicklung eines neuen Services oder Produkts hatte man sich mehr und mehr entfernt…Man war eher dabei einen organisierten stabilen Betrieb dieses Produkts zu gewährleisten und das kombiniert mit einer sachten oder sanften Weiterentwicklung auf Basis dessen, was vorhanden war…Also zu dem neuen Produkt werden neue Funktionen dazu gebaut und es werden Probleme gefixt oder neue Ideen von den Kunden mit aufgenommen und eingebaut. 

Ich bin wirklich ein großer Freund von Scrum, die Klarheit der Methode ist – wenn Du sie auf der grünen Wiese anwenden kannst – einfach überzeugend und es hilft ungemein. Aber die grüne Wiese ist in den allermeisten Fällen ja eher eine Wunschvorstellung als Realität und so kann Kanban im “echten Leben” seine Stärken ausspielen. Nämlich das “Start where you are”…Ich habe immer wieder erlebt, dass es wirklich schwierig ist Scrum einzuführen, weil es so strickt und streng ist und es steht einfach mit den jahrelang gelebten Traditionen und Arbeitsweisen in den Unternehmen in Konflikt! Der Konflikt muss bei Scrum halt ausgetragen werden und das wird er oft halt nicht wirklich…Deswegen hält sich ja auch hartnäckig die Meinung, das “Scrum out of the book bei uns nicht funktioniert und wir es dann anpassen müssen – Der Scrum-Guide ist da sehr kompromisslos und sagt dazu “Du kannst Scrum anpassen, dann ist es aber nicht mehr Scrum” – mit anderen Worten- Mach doch was Du willst, aber dann ist es halt Scheiße – sorry – also nur wenn Du Scrum in Reinform anwendest, wirst Du Erfolg haben. Empirisch gesehen mag das stimmen…In der Realität sehen das halt viele Leute nicht ein…

Daher Kanban – start where you are – alle Rollen und Arbeitsweisen werden zunächst mal gewürdigt und anerkannt- Keiner wird für nicht mehr relevant angesehen und man wertschätzt die bisher getane Arbeit! Die hat die Firma schließlich dahin gebracht hat, wo sie jetzt steht. Und wenn Deine Firma noch am Markt erfolgreich agiert und Kunden hat, die gerne kaufen, dann ist das wirklich was wert und darf nicht vernachlässigt werden!

Aber wir wollen uns ja natürlich trotzdem weiterentwickeln und nicht stehen bleiben und so hat sich auch in Kanban eine Vorgehensweise etabliert, wie wir ein Kanbansystem einführen können und den nötigen Fortschritt auch erreichen – also Start where you are, aber dann bitte mit Kaizen!!!

Mike Burrows hat in seinem Buch “Kanban – verstehen, einführen und anwenden” ein schönes Akronym für den englischen Satz “Systems Thinking Approach to Introducing Kanban“ gefunden – STATIK – womit wir beim Thema wären:

der SystemTheoretische Ansatz zur Einführung von Kanban (auf Deutsch würde dann übrigens STAEK bei rauskommen – wenn wir das mal ein bisschen umdrehen und es “System Theorie EinführungsAnsatz für Kanban—-dann kämen wir auf STEAK…nun ja – du siehst – diese Spielerei macht hier keine Sinn…) Egal – zurück:

Also lassen wir es bei STATIK, denn der Begriff hat sich in Kanban-Kreisen auch schon etabliert. der Ansatz besteht aus 6 Schritten, die ich hier mal kurz aufzähle:

1. Du musst zuerst die Quellen der Unzufriedenheit verstehen
2. dann die Anforderungen und Fähigkeiten analysieren
3. Und dann den Workflow deiner Arbeit modellieren, und zwar so wie er in echt ist…
4. Dann entdecke die Serviceklassen
5. und designe Kanban-Systeme dazu (denke an die Flight-Levels aus der letzten Folge) – die können irgendwo sein – am besten allerdings auf Flight Level 3 – also wo die Teams koordiniert werden. 
6. und dann führe es ein! (Also MACHEN und immer wieder machen!)

So was heißt da praktisch?

Die Quellen der Unzufriedenheit – Du kennst es ja – wenn du den Sinn einer Sache nicht verstehst, wirst Du es auch nicht tun…ganz klar – das ist eine der wesentlichen Quellen der Motivation: Man kann auch sagen “Start with why” – Also wir sind irgendwie unzufrieden und wir müssen erstmal verstehen warum…und dann: was ist ist es, was wir abstellen oder erreichen wollen?

Also besteht der erste Schritt aus Kommunikation – wir müssen verstehen und verstehen kann man Dinge nur, wenn man über Dinge spricht: Da gibt es nun im allgemeinen 2 Standpunkte, aus denen man etwas betrachten kann: Entweder Du sitzt im Glashaus…also im System oder Du sitzt draussen…

Du kennst das und ich kenne das auch – im Team beschwert man sich über andere Teams oder über die unklaren Anforderungen oder was weiß ich…Außen sieht man die lange Bearbeitungsdauer und vielleicht die mangelnde Kommunikation des Teams bei Tests beispielsweise…

Du kannst das Ganze kurz mit zwei Fragen erledigen: Welche Bedürfnisse habt ihr? (also die Frage im Team gestellt und dann noch aussen – also z. B.im Kreis der Abteilungsleiter bzw. Verantwortlichen. – Hier bekommst Du Antworten, die dir sagen, was fehlt um zufrieden zu sein…also “Wo wollen wir hin?”

die zweite Frage ist einfach: was frustriert Dich – die Frage zielt etwas mehr auf das Team…hier bekommst du als Antwort, die Dinge genannt, die “schlecht” sind – und was Du in Zukunft ändern sollst.: also “wovon wollen wir weg?”

Und jetzt bitte vorsichtig sein: Achte bitte darauf, dass nicht der Versuchung nachgibst, sofort irgendwelche Lösungen anzubieten. Ich kenne das – es liegt einem ja auf der Zunge und du willst ja nur helfen – ABER Hier geht es erstmal darum das Anliegen zu verstehen…Du kannst das – ganz auf Coaching Art natürlich auch verbinden indem du fragst: was frustriert dich? und als nächste Frage: was möchtest Du statt dessen?

Du kannst das als Workshop machen oder als Einzelinterviews – Das Ende dieses ersten Schrittes ist – wie gesagt – nicht das Präsentieren von Lösungen, sondern erstmal das Sammeln und aufzeigen der Dinge, die geändert werden sollen. Also in welchem Kontext bewegen wir uns und was nehmen wir hier war?

Im zweiten Schritt geht es nun darum die Anforderungen von jeder Seite zu analysieren und die Fähigkeiten die dafür gebraucht werden…Sind die denn überhaupt klar? vor allem sind die allen klar und gibt es ein gleiches Verständnis davon? – sowohl im System als auch von aussen betrachtet?

Allein diese Frage zu stellen finde ich total interessant – Wissen wir eigentlich was “die da draussen “ von uns verlangen oder erwarten, haben wir da wirklich mal drüber gesprochen? oder denken wir uns nur unseren Teil? – und das bedeutet ja meistens nichts Gutes!

Also wir müssen erstmal herausfinden wem wir was liefern und warum…Und sag nicht, das wäre zu banal! Diese all zu banalen Fragen werden ja nie geklärt! Das erlebe ich immer wieder… es wird erwartet, dass alle diese Dinge ja wissen müssten und es gibt Aussagen wie “wenn Du sowas fragst, wirst Du gleich rausgeschmissen…Das stimmt nicht!

Ich finde es ist total essenziell zu fragen: Was machen wir hier überhaupt?

und Wem liefern wir es aus? Du wirst feststellen, dass es durchaus verschiedene Sichtweisen gibt, wer eigentlich unser “Kunde” ist: ist das sozusagen “der Betrieb” – oder Operations – die unsere Anwendung übernehmen oder ist das der Erdkunde, der unsere Anwendung benutzt?

Und jetzt kommt noch die alles entscheidende weitere Frage dazu : Warum? Warum machen das ? Was ist der Nutzen davon? (die erkennst hier sicherlich wieder die Analogie zu Userstories, die wir in Scrum benutzen – wer will was und warum – genau darum geht es…)

dann komme ich mal zum 3. Schritt des STATIK Ansatzes:

Wir müssen nun den Workflow modellieren. Also das, was wirklich getan wird, und nicht das, was wir meinen, das getan werden sollte…

Und das können wir jetzt einfach sukzessive aufmalen oder mit Post-Its an die Wand kleben: gemeinsam mit dem Team kannst Du herausfinden, wie wirklich gearbeitet wird…unter Umständen kommt hier etwas bei raus, was so nicht in der offiziellen Prozessdokumentation der Firma steht. Das musst Du aushalten!

Der 4. Punkt ist: die Serviceklassen finden. Über die Serviceklassen habe ich jetzt noch gar nicht gesprochen. Serviceklasse ist letztlich ein Begriff, der die Kundenerwartung klassifiziert. Du kennst das ja bestimmt auch – da gibt es Standard-Service und dann die teureren Gold Variante bei der Du bevorzugt behandelt wirst. Das ist natürlich nicht nur die einzige Sichtweise – gerade im Support kommt ja  noch die Dringlichkeit dazu – daher gibt es hier gerne den Begriff der Expedite – also der beschleunigten Arbeitspakete -also die bekannten Prio 1 Tickets, für die die Arbeit an anderen Tickets unterbrochen wird. Hier musst Du dir halt wieder die echte Welt ansehen – also wie wird das bei Dir gelebt? Was gibt es denn bei Dir da so? Werden alle Tickets auf Prio 1 gesetzt und sind dadurch alle gleich unwichtig oder gibt es wirklich eine Unterscheidung, die sich auch auf die Arbeitsweise im Team auswirkt? Und wie schnell seid ihr wirklich bei den Goldenen Tickets? Was wird dem Kunden angeboten? Gibt es bereits verschiedene SLAs (also service level agreements?). Könnt ihr aus der Vergangenheit vielleicht auch ein paar Muster erkennen, so dass ihr ableiten könnt welche Service Level Agreements ihr am besten anbieten könnt?

Und nun kommt der fünfte Teil: die Kanban Systeme gestalten.

Das bedeutet wir müssen jetzt die Boards an die Wand bringen und uns überlegen, welchen Arbeitsfluss wir darin abbilden. Und in welchem Flight Level wir uns bewegen. Ich habe ja bereits in der letzten Folge darüber gesprochen, dass Kanban universell für alle Ebenen funktioniert und wir so natürlich auch verschiedene Boards erfassen können. Nicht jedes Board passt zu jedem Team! Die Boards repräsentieren den Workflow und insofern ist es ganz einfach in einem Workshop mit dem Team zusammen zu überlegen…(also hier das Ergebnis aus Schritt 3 nutzen und auch auf anderen Ebenen durchführen – was wird genau getan?…Das hängen wir jetzt an die Wand, machen es sichtbar und führen für jede Stufe ein „open“ und „fertig“ ein, so dass wir das Pull-Prinzip anwenden können. Dann kommen noch die WIP-Limits dazu also die Beschränkung der aktuell sich in Arbeit befindlichen Stücke ein und dann sind wir eigentlich auch schon fertig.

Mit der Zeit wird sich das auch noch ändern, wenn Du feststellst, dass vielleicht zu viele Abhängigkeiten mit eingebaut sind.

Der 6. Schritt besteht nun daraus das Kanban System einzuführen: also es WIRKLICH zu TUN. Können kommt ja bekanntlich nicht von Wissen, sondern vom TUN. Vom Bücherlesen hat schließlich noch niemand Fahrrad fahren gelernt. 

Wir können das grob als dreistufigen Prozess sehen – zuerst planen wir den Einsatz, dann stellen wir die Agenda zusammen und dann schauen, das wir kontinuierliche Veränderung in dem System etablieren. Jetzt kommt das Kaizen zum Einsatz und sollte seine Macht entfalten. Wir beschäftigen uns jetzt mit dem  Management der Veränderungen – wir wollen ja Veränderungen zum Guten herbeiführen und daher müssen wir jetzt viel messen –  ich hab ja in der Folge über die KPIs darüber gesprochen und diese Messungen müssen wir letztendlich visualisieren und daraus ableiten wie man es besser machen kann.  Das ist jetzt ein kontinuierlicher Prozess –  Kaizen hört niemals auf und das ist doch letztendlich die Macht der ständigen Verbesserung…Das ist das, was Du jetzt verstehen musst – Kanban ist kein Projekt – ein Projekt hört irgendwann auf. Kanban – also die konsequente Anwendung des Kaizen, hört niemals auf…das wird sich ab jetzt in die Genetik Deiner Firma einbrennen und dafür sorgen, dass die Firma wächst und gedeiht. Als wesentliche Triebkraft und inneres Brennen. Das wird die Quelle der Energie in Deiner Firma. So wie ein Baum sein ganzes Leben lang wächst…und wenn er nicht mehr wächst, geht er ein…

Soweit jetzt erstmal mal zum Kanban…

Ich komme jetzt noch mal zu den Infos in eigener Sache, wie am Anfang schon kurz angedeutet: 

Ich mache heute die vorerst letzte Folge der Kanban Reihe, was natürlich nicht heißt, dass es nicht in Zukunft nochmal weitere Folgen dazu geben kann…

apropos Zukunft…Dies ist ja heute die 25. Folge des agilophil-Daily Podcasts und daher auch eine gute Gelegenheit einen kleinen Schnitt zu machen – An meinem Geburtstag, dem 14.02. bin ich mit den ersten Folgen live gegangen. So hatte ich es mir vorgenommen, so ist es passiert.

Passiert ist in der Zwischenzeit allerdings auch sehr viel, allen Voran die Corona-Krise, die über uns und die ganze Welt hereingebrochen ist. Und das hat nun eine gewisse Veränderung mit sich gebracht, daher wird sich auch inhaltlich etwas in diesem Podcast ändern:

Ich werde also jetzt nach 25 Folgen eine kleine Pause einlegen und dann mit einer zweiten Staffel des Agilophil-Daily Podcasts neu starten. Keine Angst, das wird nicht lange dauern. Dabei wird es etwas mehr um Deine persönliche Weiterentwicklung gehen, also nicht nur im Sinne einer Weiterentwicklung zum Agilisten, sondern mehr zum IT-Unternehmer, der ein agilophiles und unternehmerisches Mindest braucht, um wirklich erfolgreich und wohlhabend zu werden. Agile Themen werden da natürlich weiterhin dabei sein. Aber der Podcast wird mehr ein Coachingprogramm – als ein Bildungsprogramm – sein und sich daher ein bisschen anders ausrichten. Sei also gespannt auf das, was da kommt. 

Ich wünsche Dir jedenfalls viel Erfolg bei allem was Du machst egal ob Scrum, Kanban, Scrumban oder irgendwas eigenes. Hauptsache Dein gesunder Menschenverstand bleibt eingeschaltet und wird nicht durch unsinnige Prozessbeschreibungen gekillt…Und bleibe dran!

Bis zur nächsten Folge dann…in Kürze…

Dein agilophiler Frank