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

Agilophil-Daily Podcast Episode 24: Im Hubschrauber durch Kanban?

Was ist eigentlich Wertschöpfung? wo wird denn Wert geschöpft?

Nun bin ich – ich weiß nicht, ob ich das schon mal erwähnt habe – Sohn eines Konditormeisters und ich schlage mal vor, dass wir uns mal gedanklich in eine Backstube begeben…

Also – nehmen wir mal den Konditormeister – also jetzt nicht meinen Vater, der ist ja in seinem verdienten Ruhestand, aber einen aktuellen Konditormeister in Berlin…Der kauft Ware ein – z. B. Mehl, Eier, Sahne, Früchte, Hefe, Butter, Zucker, Salz und Vanille. Dann braucht er Energie für Maschinen, da er ja heutzutage nicht alles mit der Hand macht und natürlich für den Ofen. Er hat eine Ausrollmaschine, den Ofen, eine Kochstelle/bzw. Herde und einen großen Tisch. Dann hat er auch verschiedene Materialien, wie Unterlegscheiben, Tortenringe, Messer, Spritztüten und Tüllen (also die kleinen Metallspitzen, die man da vorne reinsteckt)…Und letztlich setzt er seine Arbeitskraft ein, um aus den vielen Zutaten, der Energie und seinem Wissen, Können und seiner Erfahrung eine leckere Torte zu  machen. Die Torte verkauft er für -sagen wir mal 60,-€, sie ist ja auch handgemacht und mit Liebe verziert…Wenn man mal überlegt, wieviel die Rohstoffe für die Torte gekostet haben, also sagen wir mal 5,-, dann hat er den Wert der Rohstoffe um 55,- gesteigert. Das heist jetzt natürlich nicht, dass er 55,- Gewinn gemacht hat, denn er muss ja die Energie, die Werkzeuge, seine Angestellten, ggf. Pacht für die Backstube und seine eigene Arbeitskraft noch bezahlen. Es kann also sein, dass er überhaupt keinen Gewinn erwirtschaftet (das wollen mir mal nicht hoffen, aber in der jetzigen Zeit ist das ja alles nicht mehr so einfach) . Trotzdem hat er Wert geschöpft…

So und nun wieder die Frage – was hat das jetzt wieder mit dem agilophil-daily Podcast zu tun?

Nun – wie sind ja noch in der Kanban – Serie – inszwischen ist es die 5. Folge zu dem Thema und Kanban beschäftigt sich ja mit Wertschöfung – genauer gesagt mit dem Wertfluß…Der Wert wird ja im Zuge des Arbeitsprozess geschaffen…und zwar in einzelnen Schritten. Beim Konditor wird der Teig für den Tortenboden gemischt und gebacken, die Sahne geschlagen und mit Früchten, Zucker gewürzt. Dann wird die Torte im Tortenring eingesetzt und erstmal stehen lassen damit sie fest wird (also Gelantine oder Aga-Aga muss dazu natürlich auch noch rein). Nach einiger Zeit kann die Torte aus der Form genommen werden um sie “einzustreichen” – sie wird also mit einer äusseren Schicht Sahne bestrichen und noch verziert…dann wird die Torte eingeteilt und zu guter Letzt kommen noch die bekannten roten Kirschen auf jedes Stück…Bei jedem Schritt handelt es sich um einen Schritt, der den Wert der Ware erhöht…Also kann man jeden Schritt als einen Service betrachten, der an dem Werkstück gemacht wird. 

Ziel von Kanban ist es ja die Arbeit sichtbar zu machen, also die Schritte der Arbeit und was gerade passiert: also es ist ein System, um Transparenz zu schaffen:

– wo wird Wert geschaffen?

  • wie und warum kommt Arbeit überhaupt in das System?
  • und wie fließt die Arbeit durch die einzelnen Schritte – also Serviceeinheiten?

Wenn wir jetzt den Fokus mal ein bisschen vergrößern, dann wird in einem größeren Unternehmen der Wert auf vielen verschiedenen Ebenen geschaffen. Das Management leistet “services” für die Mitarbeiter, die HR-Abteilung stellt Mitarbeiter ein – auch das ist ein Service für die Firma. Einzelne Abteilungen, wie die Buchhaltung leisten wichtige Beträge – also  Services – für die Firma, denn ohne Bilanz bekommt man keine Kredite und geht eher in den Knast als man gucken kann…(jedenfalls wenn es eine Kapitalgesellschaft ist). 

Du siehst – die Services können auf verschiedenen Ebenen Wert erzeugen. Und das ist ein wesentlicher Vorteil von Kanban. Es ist universell und kann eben auf allen Ebenen eingesetzt werden: Kanban fokussiert eben nicht auf Teams sondern auf Wertschöpfung…

Klaus Leopold, der großen Meister des Kanban im deutschsprachigen Raum, hat dafür den Begriff der Flughöhe oder genauer gesagt die “Flight-Levels” eingeführt. Er unterscheidet dabei 4 – man kann sich sicherlich noch ein paar weitere ausdenken, je nachdem wir groß das Unternehmen oder der Konzern ist, für den man das betrachtet. Wichtig ist hierbei ist es zu verstehen, dass die Flight-Levels keine Gütebezeichnung für ein Kanban-System darstellen. Sie sind mehr eine Hilfe, um besser herausfinden zu können wo Kanban überall eingesetzt werden kann und wo man mit Verbesserungen am besten starten kann, um am meisten Effekt zu erzielen.

Die niedrigste Flight Level ist ein Team mit unreguliertem Input und Task-Fokus. Also sozusagen der Klassiker in der realen Arbeitswelt.  Das bedeutet, das von allen Seiten Arbeit in das Team gekippt wird und dass die Aufgaben meist von einzelnen Leuten abgearbeitet werden, statt in einem Teamprozess. Sowas sehe ich oft auch in meinen Projekten, wenn ich beginne: Wir haben ein Team von Spezialisten – vielleicht auch ein cross- funktionales Team, das viele Dinge in seinem Aufgabenbereich wuppen kann. Und dann kommen von allen Seiten die Aufträge oder Anforderungen rein. Es gibt keine Instanz, die was vorsortiert, oder priorisiert, sondern der, der am lautesten Schreit, bekommt seinen Wunsch als erster umgesetzt und wenn dann einer noch lauter schreit, dann wird das von dem zweit lautesten erstmal hinten angestellt…Meist arbeiten diese Teams auch nicht wirklich miteinander, sondern jeder macht irgendwie seins…

So wird natürlich genau das produziert, was wir im Kanban und überhaupt beim Arbeiten vermeiden wollen – Waste – Verschwendung…Denn es bleiben Dinge liegen und der Fluß der Arbeit wird unterbrochen. Ein Beispiel für sowas ist ein aufgesetztes Scrum-Team ohne wirklichen Product-Owner, bei dem die Leute keine Schulung bekommen habe und kein Verständnis aufbauen konnte, was agiles Arbeiten eigentlich heisst. So ein kaputtes Scrum, kannst Du  durchaus mit ein bisschen Kanban reparieren…Mache den Prozess zum Beispiel etwas transparenter, in dem du das minimalistische Task Board in ein Kanban Board verwandelst, welche den Workflow etwas feiner abbildet, als mit dem bekannten “open, in arbeit und fertig”…Und du kannst das Pull-Prinzip, WIP-Limits und einen Product-Owner einführen…Dann wird sich bei der Effektivität und auch bei der Effizienz viel tun…Auf Flight Level 1 läufst Du aber noch innerhalb des Teams, also ziemlich lokal. Veränderungen hier haben eher keine Auswirkungen auf die Organisation oder andere Teams

Womit wir bei der zweiten Flugebene sind, Flightlevel 2: Ein Team mit Türsteher – also in Fachsprache “mit einer limitiertem Input-Queue” und einem etablierten Arbeitsfluß: Hier haben wir etwas sehr wichtiges erreicht. Es gibt einen Eingangskanal, über den die Arbeit in das Team gekippt wird – und nicht von allen Seiten. Hier ist also sowas wie ein Türsteher, der über die Arbeit wacht und aufpasst, das das, was da rein kommt auch passt zu dem was schon drin ist (das ist ja auch die Arbeit eines Türstehers. Ich erinnere da nur mal an Sven…den berühmten Türsteher vom Berghain in Berlin). Es gibt also ein Nachschubmeeting und bestimmte Leute sitzen da drin und beschließen den Nachschub zu begrenzen. 

Bei Klaus Leopold sind das übrigens die Spice Girls – Du kennst vielleicht den Song “Wanna be” – -> Tell me what you want, what you really really want”…

Und hier passiert nun auf einmal etwas…dadurch, dass Du den Türsteher hast und der zusammen mit den Spice-Girls verhandelt, was nun in die Input-Queue rein darf, hast Du plötzlich Auswirkungen auf die Umwelt  – also ausserhalb Deines Teams. Denn es kommt die Erkenntnis hoch, dass man nicht einfach unendlich viel Arbeit in das Team reinschütten kann…Man muss sich also was überlegen…was ist sinnvoll zu tun, in welcher Reihenfolge ist es sinnvoll zu tun. Und diese Erkenntnis muss in manchen Köpfen erstmal durchsickern…und mancher machtgewohnte Manager bekommt hier plötzlich einen Gegenwind, den er früher nicht hatte…Das ist nicht schlecht, aber es bedeutet, dass Du hier erklären musst, warum das notwendig ist. Der Manager ist ja nicht bösartig, er kennt das so nur nicht – Du brauchst also sowas wie “Change Management”…

Ein Äquivalent zu dem Türsteher ist in Scrum das Sprintplanungsmeeting. In Scrum sind ja die Rollen klar definiert (aber nicht immer klar verstanden) und so haben wir hier den Product-Owner als maßgebliche Person, der weiß was er will und das Dev-Team als Spice-Girls, die wissen wollen, was wer wirklich will…und dann kommt als Ergebnis halt ein Sprint-Backlog heraus.

Ein anderer Punkt auf Flight Level 2 ist ein Arbeitsfluß – also ein Workflow, der sich im Team etabliert hat – im Gegensatz zu Flight Level 1, in dem alle nur “irgendwie im Raum sitzen”…Das Team arbeitet zusammen und organisiert sich selbst – so wie es auch von Scrum Teams erwartet wird. Hier wendet das Team auch das Pull-Prinzip an – das habe ich ja mal in einer der letzten Folgen besprochen. 

Die Flight Levels 1 und 2 kümmern sich aber immer noch um das Team als solches…vielleicht erkennst Du hier auch den Unterschied in der Vorgehensweise von Scrum und Kanban. Beide sind hier sehr ähnlich, aber der Unterschied ist, wie es erreicht wird. In Scrum wird es erklärt, es gibt den Scrum-Master, der dem Team erklärt, was es zu tun hat und wie es arbeiten soll. Das führt oft zu Widerstand, da – und das Phänomen kennst Du ja auch: Wenn mir ein anderer sagt, was ich zu tun habe, dann glaube ich das erstmal aus Prinzip nicht…

In Kanban beginnen wir immer da wo wir stehen, also wir gehen rein in ein Team, das – sagen wir mal ganz klassisch auf einem Flight Level 1 unterwegs ist und fangen evolutionär an und optimieren an den Punkten, die halt nicht so gut laufen und das zusammen mit dem Team – das Team kommt also (sozusagen mit Deiner Unterstützung) idealerweise selber auf die Themen und Ideen, die zu einer Verbesserung führen und das ist natürlich nachhaltiger – kann aber auch etwas dauern…Aber wie gesagt, der Vorteil des evolutionären Ansatzes ist: da das Team das als eine eigene Idee erarbeitet hat, wird es auch so weiter arbeiten, wenn Du – vieleicht als externer Berater – die Firma wieder verlässt…Bei Scrum ist es ja oft so, dass das Team nur in Scrum arbeitet, solange der Scrum-Master da ist…es ist also nicht in die Genetik des Teams übergegangen…

Nun ist es ja gut und wichtig die Teams lokal zu optimieren, aber wesentlich wichtiger ist es den Workflow insgesamt zu betrachten, denn jedes Team ist ja meist auch nur ein Rädchen in einem wesentlich größeren Getriebe…und wenn jetzt ein Team besonders gut ist und sich besonders schnell dreht, dann hakt es plötzlich im Gesamten…

Daher gehen wir in die nächste Flughöhe, das Flight-Level 3: In den meisten größeren Firmen haben wir ja mehrere Teams, die an einem Projekt arbeiten, da gibt es beispielsweise Architekten, Realisierer, Tester, dann gibt es einen Betrieb. In Flight-Level 3 geht es darum zu optimieren wie diese Teams zusammen arbeiten, so dass jedes Team genau dann das Richtige macht, wenn es gerade dran ist. Also – ich komme nochmal zu dem Konditormeister zurück: Wenn es bei ihm ein Team gibt, das sich nur um das Backen der Tortenböden kümmert und ein weiteres Team kümmert sich um die Sahne und dann das nächste Team kümmert sich um die Verzierung der Torte, dann macht es halt keinen Sinn, wenn das Back-Team hunderte von Tortenböden backt und das Sahneteam immer mehr Sahne schlägt…es wird dabei zuviel Rohstoff verwendet. Der Boden wird hart und die wird Sahne sauer, wenn es nicht rechtzeitig durch das Verzierungsteam fertiggestellt und in den Verkauf gebracht wird. Lokale Optimierung führt hier also zu Verschwendung von wertvollen Lebensmitteln. Aber wenn die Teams genau zur richtigen Zeit den Tortenboden backen, der dann, wenn er gerade abgekühlt und frisch ist, zur weiteren Station kommt und die Sahne frisch geschlagen ist wenn sie dazu kommt und es dann – nach der notwendigen Standzeit – zum Verzieren geht…dann wurde nur soviel Rohstoff verbraucht, wie für die Torte nötig war und der Kunde bekommt eine wunderbar frische Torte, die leicht und locker schmeckt…

Das erreichst Du damit, dass die Input-Queues – also die Türsteher – eines jeden Teams ihre Arbeit koordinieren und so die Teams zum richtigen Zeitpunkt die richtigen Dinge machen. Arbeit wird also durchgehend limitiert und das gesamte Arbeitssystem kann so optimiert werden. 

An den Schnittstellen musst Du weniger lange warten und Du kannst Engpässe sehr deutlich sehen. Das coole bei dem 3. Flight level ist, dass die Teams erstmal gar nicht sonderlich optimiert sein müssen – es müssen nur die richtigen Aufgaben zur richtigen Zeit an das richtige Team verteilt werden und es geht alles viel geschmeidiger…daher bringt es sehr viel auf diesem Level anzufangen, wenn Du etwas wirklich bewegen willst. Sehr oft schwärmen ja alle von den hyperprodukiven Teams, die mit Scrum erreicht werden sollen – aber das wäre ja dann nur eine lokale Optimierung, die gar nichts bringt und sogar schädlich sein kann…

Und jetzt gibt es noch eine weitere Flughöhe – die Nummer 4: Flight Level 4 kümmert sich um die Vielzahl von Projekten oder Produkten, an denen in einem Unternehmen normalerweise gearbeitet wird. Meist gibt es mehr Ideen als Teams oder Ressourcen und so muss man sich auch hier entscheiden: was machen wir zuerst? Was ist jetzt wichtig – wo wollen wir hin? Eine Firma hat ja keine unendlichen Ressourcen, daher muss klug ausgewählt werden, welche Produkte entwickelt werden und welche Projekte durchgeführt werden müssen. Hier haben wir also ein Kanban auf Topp-Management-Ebene, wenn Du so willst.

Diese Flight Levels beschreiben keine Reihenfolge, die eingehalten werden muss, das habe ich ja eben schon mal angedeutet. Es ist sehr gut mit Level 3 zu beginnen, oder über Level 4 auf ein Team auf Level 2 zuzugehen und so weiter. Starte aber möglichst nicht alleine auf Level 1, dann hast Du zu wenig Einfluss auf das Große und Ganze…Und jetzt verrate ich Dir was: ich bin ja oft als externer Scrum-Master eingekauft worden und bekam genau diese Aufgabe. “Mache aus dem Team XY ein hoch produktives Team”…das bringt nur Frust! Denn es bringt gar nichts. Das ist lokale Optimierung die spätestens bei Themen, bei denen Abhängigkeiten zu anderen Teams bestehen, nicht mehr funktioniert…Daher halte ich diese Art von Aufgabenstelllung für Scrum-Teams auch für gefährlich…passiert leider fast immer…

Tja  

So und nun steige ich mal wieder aus, aus meinem Hubschrauber und bin am Ende dieser Folge. Ich wünsche Dir viel Erfolg bei Deinen Höhenflügen, egal auf welchem Level Du gerade fliegst…Die Welt ist überall interessant und es gibt immer was zu tun..

Insofern

bleib fröhlich

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 23: Engpässe finden und Ursachen suchen mit nur 5 Fragen…

Herzlich Willkommen bei dieser neuen und tiefschürfenden Folge des agilophil -Daily Podcasts…Heute geht es um Ursachen…

Ursachen sind Dinge, die es Wert sind, herausgefunden zu werden, damit ein Problem, ein Engpass, ein Fehler oder irgendwas nachhaltig behoben oder gelöst werden kann. Normalerweise halte ich mich ja lieber im Lösungsraum auf – also da wo man fragt „Wie kann ich etwas erreichen?“ oder „was kann ich tun, damit…etwas passiert“ oder „wozu ist das gut?“…Aber manchmal ist es eben notwendig und von Vorteil sich doch mal mit dem Problemraum zu beschäftigen. Zum Beispiel wenn Probleme nicht das erste Mal da sind, sondern öfters wieder hochkommen…..dann ist es ratsam, sich mal mit den Ursachen auseinander zu setzen…

Und – was natürlich auch sehr wichtig ist – hilft es sehr beim Beseitigen von Engpässen – und über Engpässe habe ich ja auch in den letzten Folgen gesprochen – ist die Ursachenforschung sehr wichtig.

Aus Kanban-Sicht – um mal bei dem Thema zu bleiben – ist jeder Engpass nur eine Teilmenge von vielen weiteren Engpässen und wir fangen immer mit dem Offensichtlichsten an und konzentrieren uns voll auf diesen…Das ist – wie eigentlich alles, was ich hier erzähle – nicht wirklich neu…Auch Anfang der 40er Jahre war das bekannt und wurde von Technikern und Ingenieuren angewendet.  Lass uns dazu mal in eine dunkle Vergangeheit abtauchen…im wahrsten Sinne des Wortes…

Anfang der 40er Jahre nahm der U-Boot-Krieg im Atlantik eine für die deutsche Marine unschöne Wendung. Die Briten hatten das Sonar und Echolot entwickelt und eingesetzt und konnten so die deutschen U-Boote viel besser orten und aufspüren. Vorher waren sie scheinbar schutzlos der deutschen Marine ausgeliefert und nur ein paar Zufallstreffer gelangen ihnen…von einem echten Geleitschutz für die Frachter war keine Rede und es war nicht möglich die Versorgungsschiffe, die aus aller Welt aber hauptsächlich aus USA auf dem Weg nach England waren, wirksam vor den Torpedos zu schützen. 

Doch plötzlich verlies die Deutschen ihr Glück – Immer mehr Treffer konnte die englische Marine setzen…das Ziel der Deutschen war ja eigentlich England von den Versorgungswegen abzuschneiden um sich so auf eine Invasion auf die Insel vorzubereiten – aber dieses Ziel geriet in weite Ferne…

Die Deutschen versuchten natürlich darauf zu reagieren und fanden auch schnell die Ursache…Die U-Boote waren zu laut! – Der Lärm, der in den U-Booten entstand, führte dazu, dass das Sonar anschlug und die Schallwellen orten konnte. Also musste man die Lärmquellen finden…und beseitigen. Die Leute gingen also mit Mikrofonen im Boot hin und her und maßen die Lärmquellen…und konzentrierten sich immer auf die lautesten. Diese wurde dann beseitigt und dann kam die nächst lauteste und so weiter und so weiter. Natürlich wurden die U-Boote nicht völlig lautlos – das kann ja bekanntlich nur Major Tom….Also – das Ergebnis ist ja bekannt und wir profitieren noch heute davon: die deutsche Marine musste den U-Bootkrieg aufgeben, und hat verloren…England wurde nicht von den Deutschen besetzt und wir leben alle in Freiheit…(ist vielleicht jetz ein wenig weit hergeholt, aber immerhin…)

…Ich wollte ja nur damit nur nochmal erwähnen, dass alles, was in den agilen Methoden steckt nicht wirklich neu ist – mit gesunden Menschenverstand kommt man halt drauf und es hat sich bewährt…

Aber ich gehe jetzt einen Schritt weiter…

…wir haben ja jetzt erstmal nur die Lärmquellen gefunden.-..wie kann man sie denn beseitigen? Und hier setzt nun die 5 mal warum-Methode ein…ob die bei der deutschen Marine Anfang der 40er Jahre genaus angewendet wurde, weiß ich nicht, aber das ist ja auch egal…tauchen wir also mal wieder aus der dunklen Vergangenheit auf und begeben wir uns in die Gegenwart:

Die gängigste Methode zur Fehler-Ursache-Analyse ist bekannt als die fünf Warum-Fragen oder 5 times why… hier gleich mal ein Beispiel…

Zwei Stunden lang konnten die Mitarbeiter in seiner Firma keine E-Mails senden oder empfangen. Nun möchte der Chef wissen, was da passiert ist. Das IT-Team soll sich um die Fehler-Ursache-Analyse kümmern. Mit den Fünf-Warum-Fragen  versuchen sie der wahren Ursache auf die Spur zu kommen…:

1.Warum: Warum haben E-Mails nicht mehr funktioniert? 

Weil der Nachrichtenfluss gestoppt wurde.

2.Warum: Warum hat der Mail-Fluss angehalten? 

Weil jemand tagsüber Patches installiert hat.

3.Warum: Warum hat dies zu einem zweistündigen Ausfall geführt? 

Weil ein Patch einen Dienst deaktiviert hat und es während des Stillstands so lange gedauert hat, den Fehler zu finden und den Dienst wieder zu starten.

4.Warum: Warum wurde der Patch tagsüber eingespielt? 

Weil der Administrator die Regeln der IT-Prozesse nicht eingehalten hat, die besagen, nach man nach den Geschäftszeiten patchen soll.

so – wir sind jetzt beim vermeidlich Schuldigen, und man könnte meinen, das wars dann…man könnte ihn bestrafen, aber die wahre Ursache kommt erst beim 5. Warum…also

5. Warum hat der Administrator die Regeln der IT-Prozesse nicht eingehalten?

da gibt es jetzt mehrere Möglichkeiten…vielleicht hat er abends keine Zeit gehabt, ein lang geplanter Theaterbesuch mit seiner Frau oder er hatte Karten für das Champions-League Finale…Was auch immer: für mich ist es klar: Wahrscheinlich gab es nur den einen Administrator und der war sowieso schon überlastet – wahrscheinlich musste er auch schon den ganzen Tag über irgendwelche Telefonkonferenzen über sich ergehen lassen und hat das dann einfach gemacht…und halt Pech gehabt, denn er hat das bestimmt nicht das erste Mal gemacht, und das hat bisher immer geklappt. Aus diesem Beispiel würde ich jetzt mal folgendes ableiten: Statte Deine IT-Abteilung mit genügend befähigten Personen aus, die auch motiviert und ausgeruht genug sind, um die IT-Prozesse einzuhalten..Dann wird das so schnell nicht mehr passieren…(Du könntest natürlich auch auf eine andere Lösung kommen…das überlasse ich ganz Dir…)

Ich mach mal ein anderes Beispiel, daran können wir die Macht der 5 why’s gut verstehen:

Es geht um das Jefferson Memorial in Washington. Das Gebäude ist bei Touristen beliebt, war aber in einem schlechten Zustand – die Steine waren stark angegriffen und mussten immer wieder gereinigt und erneuert werden. Es waren sogar schon Bruchstücke runter gefallen und hatten die Menschen in dem Gebäude gefährdet.  Nun war es nicht so, dass man das Gebäude nicht gepflegt hatte, aber nach jeder Reparatur ging es wieder von vorne los…

Warum war das so?

Die Root-Course Analyse brachte folgende Erkenntnisse:

  1. Warum ist der Zustand der Steine im Memorial so schlecht?

Antwort: weil scharfe chemische Mittel zur Entfernung des Taubendrecks eingesetzt wurden

2. Warum gibt es da so viele Tauben?

weil die Tauben durch die vielen Spinnen angezogen werden, die es da gibt.

3. Warum gibt es so viele Spinnen?

weil die Spinnen sich von den vielen Insekten ernähren, die da rum schwirren

4. Warum gibt es da so viele Insekten?

weil die in der Nacht vom Licht angezogen werden

5. Warum werden die in der Nacht vom Licht angezogen

Weil die Frequenz des Lichts die Insekten anzieht und es nachts brennt…

Was lernen wir daraus?

Wir hätten natürlich auch die Tauben vertreiben können, oder die Spinnen vergiften können, alle Insekten einfangen können – aber hätte das das Problem nachhaltig gelöst?

Nein – natürlich nicht…Du siehst, alle Maßnahmen, die sich sich um die Symptome kümmern,  aber nicht um die wirkliche Ursache kosten nur Geld und lösen das Problem nicht nachhaltig. Denn die Insekten kommen ja immer wieder…

Es sei denn, man schaltet einfach das Licht aus in der Nacht…,dann bleiben die Insekten weg…damit bleiben die Spinnen weg, damit wird es den Tauben zu langweilig und sie fliegen woanders hin und …kacken nicht alle auf das Memorial…

Dann braucht man auch keine teuren und schädlichen chemischen Keulen mehr, die die Steine angreifen und alles hält viel länger, man muss nicht mehr so oft ausbessern und spart eine Menge Geld!..-.

Wenn nun aber das Gebäude in der Nacht leuchten soll? – nimm Leuchten, die Insekten nicht anziehen…wie zum Beispiel Gaslaternen…Das weiß ich zufällig, weil ich in Berlin in einem sogenannten Gaslaternen Schutzgebiet wohne, in dem die Straßenbeleuchtung eben noch mit 100 Jahre alten Gaslaternen funktioniert…die haben tatsächlich einige  Vorteile – unter anderen, dass das Licht der Gaslaternen keine Insekten anzieht und es keine Spinnweben um die Laternen herum gibt…

So kann man es für alle möglichen Themen immer wieder machen:

1. Warum ist das Auto liegen geblieben?

weil der Keilriemen gerissen ist

2. Warum ist der Keilriemen gerissen

weil er spröde und alt war

3. Warum war er spröde und alt?

weil er nicht rechtzeitig gewechselt worden war

4. Warum war er nicht rechtzeitig gewechselt worden?

Weil die Wartungsintervalle nicht eingehalten wurden und das Auto nie  zur Inspektion in der Werkstatt war.

5. Warum war das Auto nie bei der Inspektion?

Weil der Besitzer/Fahrer nie daran erinnert wurde…

Auch hier kann man wunderbar feststellen, was das Problem auf dauer lösen würde…Ein Servicevertrag mit Erinnerung an die Serviceintervalle, davon hat die Werkstatt was und der Fahrer hat ein zuverlässiges Auto…Teure und unter umständen auch gefährliche Kollateralschäden werden vermieden und alle sind glücklich.

So – ich denke, noch mehr Beispiele brauchen wir jetzt hier nicht…nach 5 mal Warum kommt der Wahre Grund hervor…und die Lösung liegt dann meistens auf der Hand..

Das wusste übrigens auch schon Albert Einstein, der mal sagte:

“Wenn ich eine Stunde habe, um ein Problem zu lösen, dann beschäftige ich mich 55 Minuten mit dem Problem und 5 Minuten mit der Lösung.“

Was meinst Du, hat er da die 55 Minuten lang gemacht?

In diesem Sinne – viel Spaß beim Finden der Ursachen…und verwechsle nicht Ursachen mit Gründen, denn Du weiß ja…wer will findet Wege, wer nicht will findet Gründe…

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 22: Metriken in Kanban – was sollen wir messen, sieben Tage lang… was sollen wir messen, so ein Frust…

Kennst Du das noch? Von den Bots…Was sollen wir trinken, sieben Tage lang, was sollen wir trinken so ein Durst…witzig oder?  Kam mir gerade so in den Sinn…liegt wahrscheinlich daran, dass ich älter bin – ich glaube, die kennt keiner mehr…

Aber das ist natürlich keine Geschichte für heute, nein Ich beginne anders:

Ich starte heute etwas weniger fröhlich – ein bisschen nachdenklich…ich habe heute einen Artikel im Spiegel gelesen – also online, da ging es um einen taub-blinden Jungen und wie er gefördert werden kann…ich nehme Dich mal mit in diese Thematik, wir gehen da mal gedanklich rein…

Stell Dir mal vor, Dein Name ist Jan (ich habe den Name geändert)…Du kommst auf die Welt und kannst weder sehen noch hören…Dein Gehirn ist aber vollkommen ok – ich habe ja in agilophilosophischen Folge schon mal über die Leistungsfähigkeit des Gehirns gesprochen…was für ein Supercomputer das eigentlich ist. Dein Supercomputer ist aber  – um es mal so auszudrücken – weder an die Kamera, noch an das Mikrofon angeschlossen. Sehen und hören sind – für mich jedenfalls klar die wichtigsten Sinne – 

Was passiert, wenn Du diese nicht nutzen kannst?

Ohne Hören, keine Sprache, keine Musik, kein sich ausdrücken können…, keine Zukunft? Keine Vergangenheit? Nichts in Worte fassen können – nicht mit Dir selbst reden können…Keine Wünsche äussern? Wie teilst Du mit, dass Du dir etwas wünschst? Einen Wunschzettel zu Weihnachten? Nicht vorstellbar – gibt es überhaupt Wünsche? Keine Bedürfnisse mitteilen – wie teilst Du mit, dass Du Hunger oder Durst hast? Freude, kannst Du über deinen Gesichtsausdruck mitteilen..das geht. Aber es wird nie konkret – Du kommst ja nie ins Detail…wie kannst Du etwas genau erklären, was Du haben oder erreichen willst? wie soll das gehen?

Ohne Sehen, keine Farben, Keine Bilder, Keine Filme – wir denken nicht in Bildern…wir denken in Filmen…wir träumen in Filmen…wie träumst Du? Wie denkst Du? Wie stellst Du dir etwas vor? Alles, was wir realisieren, was wir tun oder erreichen startet mit einem Bild im Kopf, mit einer Vorstellung, einer Vision, einem Tagtraum….wie soll das gehen? Wie soll das gehen, wenn Du diese Bilder nicht hast – keine Vorstellung davon, was das überhaupt ist…es gibt keinen Eingangskanal dafür…Dein Supercomputer kann keine Nervenbahnen dafür ausbilden und trainieren…es ist schwarz und still….

Dein Input kommt über das Fühlen, riechen und schmecken, das funktioniert ja – Wärme, Oberflächen – Räume – Gerüche, und Geschmäcker, da entwickelt sich auch ein Vorstellungsvermögen für Deine Umwelt…ja…und da Du es nicht anders kennst, wirst Du auch nichts vermissen…es gibt keine Information in deinem Gehirn, dass da jemals entwas anderes draussen existiert, als das, was Du über Deine Haut und Deine Nase und deine Zunge wahrnimmst.

Es entsteht eine völlig andere Wahrheit in Dir…und vor allem…alles entsteht sehr langsam…Ohne Stimulation von aussen, kann nicht viel passieren – das Gehirn verknüpft Nervenbahnen auf Grund von äusseren Reizen…diese werden dann zu Kompetenzen und Erfahrungen. Und je mehr Reize es gibt, desto schneller arbeitet auch das Gehirn – Du kannst Das Gehirn nicht überfordern…jedenfalls nicht als Kind. Das siehst Du auch an den Kindern, die zweisprachig aufwachsen. Wenn Vater und Mutter eine unterschiedliche Sprache mit dem Kind sprechen, lernt es einfach beide…wenn dann die Kinder im Kindergarten vielleicht noch eine andere Sprache sprechen, lernt es diese auch noch dazu…kein Problem. Das Hirn kann das…

So und wie kommen wir jetzt zu meinem eigentliche Thema? Warum fahren wir eigentlich unsere Projekte oft so, als ob wir uns unserer Sinne beraubt hätten? Warum nutzen wir nicht die Eingangskanäle und – ich nenne es mal – Sinnesorgane – die wir eigentlich zur Verfügung hätten? Wir fliegen blind und hören nicht auf die Signale….

Kein Wunder, dass sich manche Projekte seltsam und von allem sehr langsam entwickeln…

Kanban ist daher sehr datengetrieben – und dadurch auch durchaus  beliebt bei den Teckis… 

Und um Daten sichtbar zu machen, müssen wir sie messen. Und wir brauchen- ausser vielleicht einer Uhr und einem Kalender noch nicht einmal spezielle Messgeräte dazu. Die Sinne sind alle vorhanden…

Also: Wir sehen Veränderungen und Verbesserungen aber auch Verschlechterungen am besten dann, wenn wir die Kennwerte dafür durchgehend messen. Und zur Beurteilung des Zustandes unseres Projekts oder Kanban-Systems benutzen wir Kennzahlen – sogenannte KPIs oder Key Performance Indicators. Wichtig hierbei ist, dass nur das System gemessen wird, nicht aber die Leistung einzelner Mitarbeiter. Das ist etwas, was gerne mal falsch interpretiert wird. Wir beurteilen nicht die Leistungen der Mitarbeiter, sondern des gesamten Systems. Also des Teams und wie das Team sich organisiert. Denn – seien wir mal ehrlich – in den allermeisten Fällen liegt es  nicht an der Performance Einzelner, wenn etwas stockt, sondern daran, dass das System durch irgendwas ausgebremst wird. Doch dazu mehr in einer der nächsten Folgen.

Ich betrachte das jetzt mal sozusagen Low-Tech mässig – also ganz analog: Ich weiß, dass es für alles gute Tools gibt – sehr verbreitet ist ja bekanntlich Jira von Atlassian, aber es geht ja nicht um die elektronischen Tools, sondern um den Inhalt. Und der lässt sich hier – finde ich zumindest – im Podcast am einfachsten an analogen Beispielen erklären. 

Um richtig messen zu können, brauchen wir Informationen und die müssen gespeichert bzw. festgehalten werden. Viele davon können wir einfach auf unserer Signalkarte (also dem Ticket) notieren. Was gehört also auf das Ticket?

  • Da wäre zunächst mal der Aufgabentitel. Titel und eine Kurzbeschreibung der Aufgabe sollte für das Team verständlich sein – auch für die Leute, die nicht daran arbeiten. In Scrum nehmen wir hierfür ja auch gerne das Format der Userstory – ich empfehle das hier auch, es muss aber nicht sein, da wir ja auch in einem anderen Kontext arbeiten können. 
  • Wenn es einen festen Liefertermin für die Aufgabe gibt, dann gehört der auch gut lesbar auf die Karte
  • Wer macht es : hier kann der Bearbeiter bzw. Die Bearbeiterin wechseln, daher ist es gut, wenn Du dazu Magnete oder kleine Klebemarker/(oder Post-IT’s) nimmst, die sich austauschen lassen. 
  • Status-Veränderungen: und das ist jetzt besonders wichtig – Notiere das Datum bzw. Die Uhrzeit, wann die Karte von einem Status (also Prozessschritt) in den nächsten übergeht. (elektronische Systeme machen das natürlich automatisch…). 
  • Größe (oder Komplexität) der Aufgabe: In Scrum verwenden wir gerne Storypoints – es geht aber auch anders z. B. Mit T-Shirt-Größen – also S, M, L, XL – das wäre eine sehr einfache Variante dafür. 

Eben schon kurz angedeutet – eine der wesentlichen Kenngrößen eines Kanban-Systems ist die Durchlaufzeit – auch (Lead-Time genannt): Das ist die Zeit, die es braucht von dem Zeitpunkt, an dem eine Aufgabe geplant wird – also in den Arbeitsvorrat oder die Input-Queue aufgenommen wird – bis zu dem Zeitpunkt, an dem die Aufgabe erledigt ist. Also streng genommen die Zeit die es braucht, bis eine Aufgabe durch das Kanban-System geflossen ist.

Bei den Begriffen müssen wir jetzt ein bisschen aufpassen, die gehen gerne mal durcheinander. 

Die Durchlaufzeit wird auch als System-Durchlaufzeit oder System lead time bezeichnet, dann gibt es aber noch eine Kunden-Durchlaufzeit oder customer lead time: die beschreibt wie lange der Kunde auf sein Ding wartet – also von seiner Anforderung oder seinem Auftrag bis zur Erledigung. Es kann ja sein, dass ein Auftrag sehr lange in einem Auftragsstapel liegt, bis er überhaupt in Arbeitesvorrat unseren Kanban Systems aufgenommen wird. Das ist nämlich der Zeitpunkt der Zusage (Commitment). Ich habs in der letzten Folge ja schon mal erwähnt. Im Replenishment Meeting wird der Arbeitsvorrat besprochen – alles was hier beschlossen wird, wird ja dann auch umgesetzt und in die Input-Queue getan – daher gibt es erst ab diesem Zeitpunkt überhaupt das Commitment. Was davor passiert – kümmert uns jetzt erstmal nicht – aber das kann natürlich eine Quelle von großem Kundenfrust sein, wenn die Aufträge ewig auf diesem undefinierten Stapel herumliegen. 

Dann gibt es noch den Begriff Cycle Time, der leider nicht eindeutig belegt ist und einfach beides bedeuten kann – also entweder die Durchlaufzeit oder die Kundendurchlaufzeit. Also – bitte immer vorher die Begriffe genau klären, damit ihr nicht aneinander vorbei sprecht…

Mit der Durchlaufzeit können wir schon eine ganze Menge anfangen: Es gibt eine sehr schöne Darstellung mit der wir mehrere Informationen im Blick haben: Das kumulatives Flussdiagramm…wenn man sich mal ein bisschen dran gewöhnt hat, ist es eigentlich ganz einfach:

Auf der y-Achse – also die senkrechte, die Ordinate, die nach oben geht….tragen wir an jedem Tag ein, wieviele Karten jeweils in den Prozessschritten stecken…und das summieren wir von Tag zu Tag auf – daher heißt das ja auch kumulativ…Die Zeitachse ist dann auf der x-Achse, also auf der Waagerechten, die dann nach rechts weggeht…

Fangen wir mal an: Nehmen wir an, am ersten Tag unserer Betrachtung haben wir insgesamt 75 Karten auf unserem Kanban-Board System. Davon sind dann also 15 im Arbeitsvorrat (bzw. In der Input-Queue), dann 7 in der Analyse, 8 in der Entwicklung, 17 im Test und 28 sind bereits fertig. Diese bekommen jeweils unterschiedliche Farben (oder Muster), so dass man die auf eine Blick leicht unterscheiden kann. 

Am nächsten Tag haben wir 11 im Arbeitvorrat, 6 in der Analyse, 9 in der Entwicklung, 14 im Test und demnach 35 fertig…so läuft das  jetzt jeden Tag und jede Woche… Die Linien gehen immer nach oben, da das ja immer aufaddiert wird. Aber die Bereiche zwischen den Linien werden unterschiedlich breit sein. Und so bekommen wir dann ein genaues Bild, wie lange sich die Karten im Prozess befinden und wieviele Karten pro Tag in Arbeit waren. Dazu müssen wir nur die Karten auf der Y-Achse zusammenzählen, die in den Schritten „Analyse“, „Entwicklung“ und „Test“ waren. Am Tag 1 waren das 32 und am Tag 2 waren das 29.

Und wenn wir einen waagerechten Strich ziehen, können wir sehen, wie lange eine Karte gebraucht hat um von der Input-Queue bis zu Fertig zu kommen. Der Verlauf der Bereiche zwischen den Linien zeigt uns auch gleich wo es Problemstellen geben könnte – je dicker ein Bereich, desto langsamer scheint es da zu fließen. 

So ein CFD (wird meist so genannt aus der englischen Bezeichnung heraus – also cummulative flow diagram) kannst Du tatsächlich jeden Tag an der Wand vom Teamraum manuell aktualisieren und damit machst Du die Arbeit transparent. In Jira wird dir das auch angeboten, natürlich automatisch – die Problematik dabei ist nur – da guckt halt niemand ständig drauf…

Aus dem CFD kann man auch sehr einfach die Flusseffizienz ermitteln – das ist das Verhältnis der Bearbeitungszeit zur Gesamtdurchlaufzeit (also wie oft wurde an einer Karte wirklich gearbeitet und wie lange liegt sie z.B. in der Input-Spalte…Also – man kann es aus anders Ausdrücken: die Arbeitszeit und die Summe aller Wartezeiten ergibt letztlich die Gesamtdurchlaufzeit.

Ein anderes Diagram, was auch noch sehr einfach zu erstellen ist – und praktisch zugleich – ist ein Historigramm aus den fertigen Karten. Du musst einfach nur die Karten wenn sie fertig sind in ein Diagramm legen auf dem in der X Achse die Tage notiert sind. Also du zählst einfach hoch 1 Tag, 2 Tage, 3 Tage usw. (oder Wochen) und legst die Karten entsprechend der Bearbeitungsdauer ab. Die ast du ja auf der Karte notiert!

Was siehst Du darauf?: Du siehst wieviele Tag die Karten im Durchschnitt so brauchen – Du siehst Peak – also Gipfel – und kannst so sehr leicht und transparent machen, wie lange ihr im Durchschntt so braucht – Du siehst die Verteilung der Karten – gibt es Häufungen? gibt es breitere Verteilungen?

Die Frage – wann bekomme ich es geliefert lässt sich so gut beantworten…Nimm einfach die Gesamtzahl der erledigten Karten und schaue, bei welchem Tag Du 80% davon erledigt hast. Dann kannst du sehr einfach eine für den Kunden meistens hinreichend genaue Antwort geben: Mit 80% Wahrscheinlichkeit ist Ihr Auftrag in 3 Wochen erledigt (beispielsweise).

So – Du siehst – mit sehr einfachen Mitteln wirst Du und wird auch das gesamte Team aussagefähig. Du musst also nicht mehr blind und taub durch das Projekt irren und kannst sehr schnell und einfach deine Sinne einsetzen um einen klaren Blick über die Situation zu bekommen. Ich will das hier in dem Podcast nicht noch weiter vertiefen.  Ich wollte dir nur zeigen:  nimm die Metriken, die es gibt und benutze sie,  so dass du und dein Team sehen und hören könnt. Das ist weitaus weniger gefährlich als nur nach dem Prinzip Hoffnung – es wird schon gut gehen – zu fahren. 

So weit mit der heutigen Folge zu den Metriken in Kanban – ich weiß, dass das hier nicht vollständig ist und dass es noch eine ganze Reihe von Dingen gibt, die Du auswerten kannst. Du findest aber im Internet viele Beispiele dafür, wenn DU einfach mal nach „Kanban-Metriken“ googelst. 

Insofern wünsche ich Dir stets klare Sicht und guten Klang bei Deiner Projektarbeit.

Viel Erfolg beim Messen

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 21: die Magie der WIP Limits

Wenn ich Scrum-Teams oder allgemein agile Teams betreue stelle ich immer wieder fest, dass es von aussen eine gewisse Erwartungshaltung gibt, einzelne Prozessschritte zu optimieren. Dazu habe ich folgende Geschichte…die im Dezember letzten Jahres in der USA-Today stand:

Es ist die Geschichte von Flippy, dem Burger- Wende Roboter, der von Cali-Burger in Kalifornien eingeführt wurde. Was war passiert? Die Cali-Gruppe – also der Betreiber der Burger-Restaurants, hatte Schwierigkeiten, die Mitarbeiter in der Küche zu halten. Cali verkauft Hamburger nach „Southern California-style“ für $3,99. Der Markt ist umkämpft, die Margen gering und die Löhne dementsprechend. Es verwundert also nicht, dass die Leute, die bei Cali arbeiten nur mäßig Erfüllung in ihrem Job finden. 

„Wir bilden sie aus, sie arbeiten am Grill, sie merken, dass es keinen Spaß macht … und so gehen sie und fahren Uber“, sagt John Miller, CEO der Cali Group.

Die Lösung lag also auf der Hand – ein Roboter sollte es richten:

In einer Stunde könnte das Gerät bis zu 150 Burger bearbeiten – was an einem Tag ca. 2000 Hamburger bedeutete und so könnte er bis zu 50 Mitarbeiter ersetzen, so die Planung der die Restaurantkette und des Herstellers Miso Robotics.

Doch nach nur zwei Tagen wurde Flippy erstmal vom Dienst suspendiert. Allerdings lag das wohl auch auch am starken Andrang in dem Restaurant in Pasadena in dem die Kette den ersten Roboter einsetzte. Die Leute waren halt doch zu neugierig.

Allerdings war der Roboter ja nur ein Roboter – und wie wir wissen sind Computer ja bekanntlich „Doof“. Flippy war vor allem deshalb zum Flop geworden, weil er miserabel mit seinen menschlichen Kollegen zusammengearbeitet hatte, „Es geht ums Timing“, sagte in dem Zeitungsartikel  Cali-Technik-Chef Anthony Lomelino. „Alle müssen ihren Arbeitsrhythmus an Flippy ausrichten.“ 

Normalerweise kommunizierten die Leute ständig untereinander und stimmten so die Arbeitsgeschwindigkeit aufeinander ab, das war mit Flippy nicht möglich – die Schnittstelle zum Grill – also das Vorbereiten der Burger-Patties und das Belegen der Brötchen mit Salat – wurde zum Problem. Und so war es insgesamt nicht möglich einen kontinuierlichen Arbeitsfluss sicherzustellen und erst recht nicht, eine den Output an Burgern zu erhöhen. 

Die Restaurantkette will wollte dann ihre Mitarbeiter besser für die Zusammenarbeit mit dem in sozialen Dingen unfähigen Roboter trainieren. Erst dann sollte dieser wieder den Arm um seine sechs Achsen kreisen lassen um die Burger Patties zu flippen….also umzudrehen

Was aus Flippy bis heute wurde, kann ich nicht sagen. Aber das ist ein gutes Beispiel dafür, wie der Ansatz in einem Workflow einzelne Workflowschritte zu optimieren dafür sorgen kann, dass die Performance des gesamten Workflows sogar sinkt. Und diese Erkenntnis ist nicht neu – es ist sogar die Regel.

Und das liegt letztlich daran, dass zu viel Arbeit im System ist. Mit lokalen Optimierungen wird dafür gesorgt, dass an einzelnen Stellen noch mehr Arbeit ins System gepumpt wird, so dass der Durchsatz im Gesamtsystem sogar sinkt. Erinnere Dich nochmal an das Beispiel mit den Einkaufswagen aus der letzten Folge: Der Supermarkt kann nur eine begrenzte Anzahl von Kunden verkraften – sonst sinkt der Umsatz pro Person oder – wie aktuell – es steigt das Infektionsrisiko in Coronazeiten…

Die Lösung liegt also in einer Limitierung der Arbeit, die sich im System befindet. 

Um die Arbeit im System zu limitieren gibt es mehrere Möglichkeiten – eine weit verbreitete ist einfach die Limitierung der Arbeit in jedem einzelnen Workflowschritt. 

Ich hatte ja in der letzten Folge schon über Push und Pull gesprochen – in Kanban wird nach dem Pull Prinzip gearbeitet -und in Scrum sollten wir das übrigens auch tun- wird nur oft vergessen. Also pull bedeutet ja – ich lasse meine Sachen auf meinem Schreibtisch, bis sie der nächste abholt – wenn mein Schreibtisch voll ist, kann ich nicht mehr weiter arbeiten…Push war – ich packe meine fertigen Dinge auf den Schreibtisch des Nächsten und kann so immer weiter machen, auch wenn der nächste bereits überlastet ist. Je nachdem wie hoch der Stapel bei ihm ist – er wird ja nicht schneller arbeiten können, wenn er die Qualität halten will – wird es bei ihm ewig dauern, bis die Dinge, die ich ihm eben gerade gegeben habe abgearbeitet sind, weil da ja noch die Dinge liegen, die ich da gestern hingegeben habe und vorgestern und vorvorgestern…

Wenn wir in einem Pull-System mal überlegen was passiert, dann fällt uns auf dem Kanban-Board etwas auf: wir arbeiten von rechts nach links!

Also wenn wir mal mit unserem geistigen Auge auf das Board schauen..stell Dir das mal jetzt mal so bildlich vor: jeder der Arbeitsschritte kann nur starten, wenn der nach ihm laufende Prozessschritt fertig ist, damit wir keinen Waste – also “Verschwendung” produzieren – also wenn wir nicht mit unfertigen Dingen unser System vollstopfen. D.h.nach dem letzten Schritt – also der Fertigstellung eines – ich nenne es mal “Teils” wird das nächste Teil vom vorletzten Workflowschritt genommen, was wiederum ermöglicht ein Teil vom vor-vor-letzten Arbeitsschritt zunehmen und so weiter. Wir arbeiten also sozusagen von hinten nach vorne. Wir ziehen quasi die Arbeit hinten aus dem System raus und schaffen so Platz für Neues.  Ein beliebter Begriff dafür ist “Stop starting, start finishing”. Es macht als keinen Sinn immer nur neue Sachen zu starten und keine fertigzustellen. Wir beenden erst eine Aufgabe, bevor wir eine neue anfangen. Also wir dürfen oder können gar nichts beginnen, wenn wir nicht vorher etwas fertig gestellt haben. 

Ich wiederhole mich…glaube ich…

Seltsamerweise erlebe ich das andersrum aber sehr oft. (und kann das auch gut nachvollziehen, denn ich denke, wir alle kennen das Gefühl, dass man Dinge beginnt und irgendwie nichts fertig bekommt. Es scheint also irgendwie in unserer Natur zu liegen, mehr anzufangen als abzuschließen. Vielleicht liegt es ja auch daran, dass man geschäftig wirken will und den Kunden beruhigen will mit den Worten: “wir haben schon angefangen”…klingt ja auch besser als – “das liegt noch im Backlog”   Doch wohin führt dies?

Wenn wir uns einen Flughafen vorstellen, an dem immerzu Maschinen landen aber keine mehr abheben, dann ist der in kürzester Zeit überall mit Flugzeugen vollgestellt. (Ich spreche jetzt natürlich von Zeiten, als wir noch Luftverkehr hatten – aktuell – also bei Aufnahme dieses Podcasts – leben wir ja noch in der Corona-Phase und da passiert auf den Flughäfen ja eher gar nichts…)

Aber komme ich mal zurück: kannst Du dir vorstellen, wie lange es braucht bis ein Teil durch einen Engpass geht? Ich hatte mal einen Kollegen, der hat seine Arbeit in Form von Stapeln auf seinem Schreibtisch strukturiert… diese Stapel erreichten teilweise höhen von 40-50cm – also ein halber Meter Papier – das war echt schwer, der Schreibtisch bog sich schon fast. Er war ständig überlastet und wurde nicht fertig….Und es ist ja nicht so, dass an den Dingen, die auf seinem Schreibtisch lagen gearbeitet wurde – die lagen halt nur da…es handelte sich meist um Konzeptpapiere, die irgendwie fertig gestellt werden mussten für kleine Anforderungen oder Störungstickets für Fehler im System (die meist nicht kritisch waren, denn die kritischen wurden ja schon vorrangig behandelt.) 

Klaus Leopold, der große Meister und in nenne ihn mal “Guru” des Kanbans im deutschsprachigen Raum hat in seinem Buch “Kanban in der Praxis” das mal schön aufgezeigt. Er hat – um sowas mal sichtbar zu machen –  beispielhaft mit einem Team ein Board erstellt mit zwei Schwimmbahnen (also diesen Swimlanes) – eine für die Dinge, die wirklich gerade in Arbeit sind („aktive Arbeit“ genannt) und eine mit den Dingen, die auf irgendwas warten (das war dann die Swimlane „inaktive Arbeit“) – also in einem unlimitierten System mit Engpässen. Und wenn jemand eine Karte bearbeitet hat, dann wanderte die von inaktiv in aktiv und wenn er wieder was anderes gemacht hat , wanderte die Karte wieder zurück in inaktiv…und dabei stellte sich auch heraus, dass sich einige Karten quasi nie von inaktiv zu aktiv bewegten  – einige waren auch durch andere Dinge blockiert und konnten sich gar nicht bewegen. Und er hat mal ausgerechnet, wie lange es dauert, bis eine Aufgabe bzw. eine “Karte”   da so durch geht…Das Ergebnis ist total beeindruckend, denn wir haben ja irgendwie die Vorstellung, dass – wenn etwas in arbeit ist – dass sich dann auch etwas fortbewegt. Aber weit gefehlt – der Stillstand lag bei 98,6%.  Also nur 1,4% der Karten wurden gerade bearbeite und die anderen lagen unbeachtet rum. Du siehst…unlimitierte Systeme hören irgendwann auf zu fließen…und nähern sich dem Stillstand – je mehr Arbeit wir in das System stecken, desto langsamer wird es…

Es geht also nicht darum schneller zu arbeiten, sondern schlauer zu arbeiten.

Und dafür brauchen wir die Limits also die Beschränkung der aktuell in Arbeit befindlichen Dinge. Also die WIP-Limits.

Aber wie Du Dir vorstellen kannst – die Argumentationskette macht hier oft Probleme. Wenn wir uns einen Arbeitsprozess vorstellen und den in einem Workshop an der Wand transparent machen, dann sehen wir – und es ist dann nicht mehr zu übersehen – wo sich die Karten häufen – also wo ein Engpass vorliegt. Leider reagiert hier ein handelsübliches Management bzw. die Führungsebene meist mit einer Erhöhung des Drucks auf diese Situation – also wenn es irgendwo klemmt, dann muss ich nur fest genug drücken bis der Pfropfen durch das Rohr geht…Mit der Logik ist die vermeintliche Lösung: wenn zuviel Arbeit da ist, dann müssen wir eben mehr arbeiten! Das kann dazu führen, dass die Mitarbeiter Überstunden machen oder dass sogar noch neue Leute eingestellt werden – oder Task-Forces ins Leben gerufen werden, damit dieser entstandene Berg endlich mal abgearbeitet werden kann. 

…Leider geht das nicht! Das funktioniert nicht…Die Lösung liegt darin, Druck herauszunehmen – das weiß schon die Physik, also die Arbeit zu limitieren, die im System steckt. Und das – hier wieder ein weit verbreitetes Missverständnis – erreichst Du, in dem du die Arbeit, die im System steckt beschränkst – das heißt nicht, dass Du weniger arbeiten sollst. 

Also – die Einführung von WIP-Limits bedeutet nicht, dass Dein Team nun weniger arbeiten soll, sondern dass ihr mit Eurer zur Verfügung stehenden Arbeitskraft die Arbeit, die im System steckt auch schafft. 

Aber woran liegt diese immer wiederkehrende Fehleinschätzung?

Vielleicht an einem weiteren Aspekt, der sich auch hartnäckig in den Köpfen der Menschen hält. Dem Märchen vom Multitasking. Versuche mal, Deinen Namen 5x untereinander zu schreiben und und jeweils 5x nur den ersten, dann den zweiten Buchstaben und dann den dritten zu schreiben usw. Und dann schreibe mal 5x Deinen Namen untereinander, so wie Du es gewöhnlich machen würdest und vergleiche die Zeit, die Du bei beiden Varianten gebraucht hast. Durch das ständige Umschalten im Kopf brauchst Du Zeit. Mann und auch nicht Frau kann nicht zwei Dinge gleichzeitig tun – es wird im Kopf dann immer umgeschaltet – es muss sich auf die neue Situation wieder eingestellt werden und das kostet immer Zeit. Daher ist es eben sinnvoll sich solange auf eine Sache zu fokussieren, bis sie fertiggestellt ist. Das spart Zeit – eben die Umstellungszeit. (diesen Fokus, denn kennen wir natürlich auch aus Scrum)

Also – dann komme ich mal so langsam zum Ende…

Ich fasse mal zusammen: wenn wir die Arbeit im System begrenzen, werden wir schneller. 

Also müssen wir für jeden Arbeitsschritt, den wir uns für unseren Workflow ausgedacht haben einen Wert festlegen, der nicht überschritten werden darf.  – Also wir müssen sozusagen die Größe des Schreibtisches festlegen. Und daran müssen wir uns halten

Es hat sich bewährt einfach nach folgender Faustregel zu beginnen: 

WIP Limit ist entsprechend der Anzahl der Teammitglieder, die in dem Workflowschritt zusammenarbeiten und deren Auslastung bei 80% liegt…Dann schauen, wie es funktioniert und justieren den Wert, wenn wir feststellen, dass es nicht so gut läuft.

Damit halten wir zuviel Arbeit aus dem System heraus, so dass der Fluß ungestört fließen kann. 

Damit schaffen wir es verlässliche Aussagen zu machen, wann denn eine Arbeit (also eine Karte) fertig sein wird, denn wir können diese Zeit ja dann messen und – da der Fluß nicht ständig unterbrochen ist , wird diese Zeit auch einigermaßen realistisch eingehalten. Und eine verlässliche Aussage wie „Dein Ticket wird zu 80% in 5 Tagen gelöst sein“ wird deinen Kunden sicherlich zufrieden stellen und besser sein als „wir haben schon angefangen…“ mit der darauf folgenden Frage „und wann wird es fertig sein“  naja – wir haben noch so viele Dinge, dass ich das jetzt nicht genau sagen kann . Das hängt davon ab…Du weißt beziehungsweise kennst das flaue Gefühl in der Magengegend, wenn Du solche Unterhaltungen führen musst…

Ich wünsche Dir viel Erfolg beim Limitieren…Du wirst sehen, das macht dich frei… und Freiheit ist ja ein hohes Gut.

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 20: Kanban für Scrum Teams?

In der letzten Folge habe ich über die Prinzipien und Praktiken von Kanban gesprochen, das war vielleicht etwas theoretisch…daher frage ich mich heute mal – was muss man als Scrum-Team eingentlich ändern, wenn man mal ein bisschen Kanban machen will…oder macht das überhaupt Sinn?

Die Entstehung von Kanban geht ja auf das Jahr 1940 zurück. 

Das System wurde von Taiichi Ohno, einem Ingenieur und Geschäftsmann, der die Kanban-Methode für Toyota in Japan entwickelte, geschaffen. Für die Methodik ließ er sich von einer völlig anderen Branche inspirieren — von Supermärkten und ihren Lagerbeständen. 

Supermärkte verwalten ihren Bestandsfluss, indem sie nur ausreichend Produkte auf Lager haben, um die Nachfrage der Verbraucher zu befriedigen. Toyota hatte ein ähnliches Problem mit der Bestandsverwaltung. Daher entwickelte Ohno das Signalkartensystem „Kanban“, um die Lagerbestände an den tatsächlichen Materialverbrauch für die Automobilherstellung anzupassen. 

Und so funktionierte die ursprüngliche Idee:

1. Die Fabrikmitarbeiter kommunizierten ihre Kapazitäten in Echtzeit, indem eine „Kanban-Karte“ zwischen den einzelnen Montage-Teams weitergegeben wurde.

2. Wenn Materialien in der Produktionslinie aufgebraucht waren, wurde eine „Kanban-Karte“ an das Lager übergeben, um dem Team mitzuteilen, was genau benötigt wurde.

So entstand eine Kommunikationskette: Das Lager konnte dann diesen Bedarf dem Lieferanten mitteilen, der das Material dann zum Lager versenden konnte. Es konnte also nicht zu viel geliefert werden da immer nur dann geliefert wurde, wenn etwas benötigt wird. Du kannst das vergleichen mit dem einfachen Verfahren, was aktuell – also in der Corona-Zeit – in den Geschäften und Supermärkten angewendet wird. Jeder Kunde muss einen Einkaufswagen oder einen Einkaufskorb mitnehmen. Da es nur eine begrenzte Anzahl von Einkaufswagen gibt, kann man so sehr leicht die Anzahl der Kunden im Geschäft limitieren. Es darf immer nur ein Kunde rein, wenn ein anderer Kunde fertig ist und seinen Einkaufswagen wieder abstellt. Einfach – aber genial..(das geniale ist ja immer einfach…)

Dieser Prozess wird auch als „Just-in-Time“ bezeichnet. Ein wesentlicher Aspekt, den ich noch erwähnen möchte, ist, dass in der Industrie der Auftrag für die Produktion erst an die Fabrik gegeben wird, wenn die Bestellung eingegangen ist. Das bedeutet, dass es vermieden wird, auf Verdacht und auf Vorrat zu produzieren – es wird immer genau das produziert, was wirklich gebraucht wird. – ein blaues Auto, wenn ein blaues bestellt ist und ein rotes, wenn ein rotes bestellt ist…

Das Kanban-System wurde dann auf für die Softwareentwicklung populär, nachdem sie von David J. Anderson in seinem Buch Kanban: Evolutionäres Change Management für IT-Organisationen auf die IT übertragen wurde.

Um es mal zusammenzufassen, Kanban ist eine visuelle Methode zur Aufgabenverwaltung und Aufgabenverarbeitung. Es geht bei „Kanban“ um den Arbeitsfluss also darum die „Bewegung von Arbeit zu optimieren. Dazu werden die Aufgaben visualisiert, die laufenden Arbeiten begrenzt und damit wird die Effizienz (oder den Ablauf) optimiert. Kanban-Teams konzentrieren sich also darauf die Zeit vom Start bis zur Vollendung einer Aufgabe (oder einer „User Story“) zu verkürzen. Die Kernprinzipien von Kanban sind auf nahezu jede Branche anwendbar und durch den Grundsatz „Start where you are“ auch an keine Voraussetzungen geknüpft.  Daher verwundert es auch nicht, dass die Methodik bei allen Arten von Teams wie im Marketing, Vertrieb, in der Personalbeschaffung und im Betriebsablauf immer beliebter wird.  

Ich komme eigentlich aus der Scrum-Welt und Scrum ist ja auch zumindest in der IT aktuell das weiter verbreitete System…

Wenn Du natürlich selbst ein echter Kanbañero bist oder in der Industrie schon mal mit Lean Manufacturing in Kontakt gekommen bist, wirst Du das wahrscheinlich genau anders herum sehen. Wie ich ja schonmal gesagt habe – für mich sind Scrum und Kanban wie Bruder und Schwester mit durchaus unterschiedlichen Charaktereigenschaften (also Kanban mit dem Flußkonzept und Scrum mit der empirischen Prozesssteuerung) aber doch sehr verwandt. Und einer von den beiden ist nun mal der oder die ältere… In der Tat ist ja Kanban – in der Form, die wir im IT-Kontext sehen, jünger als Scrum…der Ursprung von Kanban, der aus der Automobilindustrie kam, ist wiederum älter als Scrum und kann als wesentlicher Input für die Entwicklung von Scrum angesehen werden.

Wie läuft das denn nun eigentlich in der Praxis?

Insbesondere wenn Du in einem Scrum Team arbeitest, (wie gesagt, aktuell arbeiten ca 80% der IT-Teams im Scrum-Framework), macht es Sinn mal drüber nachzudenken, ob Du nicht ein paar Dinge aus Kanban übernehmen möchtest oder ob Du nicht sogar ganz auf Kanban wechseln willst. 

Dieser Wechsel ist im Prinzip gar nicht schwer, da wesentliche Elemente analog funktionieren. Nehmen wir zum Beispiel das Sprint-Planning – In Kanban wird jede Woche der Nachschub im Backlog geplant – der Begriff aus Kanban dazu ist „Replenishment“ ( also Nachschub)- Angenommen wir haben ein Scrum-Team mit einer Sprintlänge von einer Woche – dann ist das Ziel hier analog – wir planen wöchendlich, was wir uns an Arbeitsvorrat vornehmen. (Ich blende hier mal bewusst ein paar Details aus – wie das Sprintziel oder das Commitment des Teams, was es so explizit in Kanban nicht gibt). Aber Du wirst mir zustimmen, dass wir hier ein grundsätzlich analoges Vorgehen haben. Grooming Meetings in Scrum sind mit Release Planning Meetings in Kanban vergleichbar, die in bestimmten Abständen hier vorgesehen sind. Ebenso die Daily Standups- die es in beiden Frameworks gibt. Eine Sprint Retrospektive hat ihre Verankerung in Scrum am Ende des Sprints – in Kanban sind Retrospektiven in bestimmten Abständen auch vorgesehen – nur nicht explizit jede Woche. Doch auch hier gibt es Parallelen. Das einzige, was in der Form wegfällt sind Review-Meetings, die in Kanban nicht so wie in Scrum durchgeführt werden. Feedback der Stakeholder wird in Kanban eher im Sinne einer Flußkontrolle durchgeführt – hier also mit sogenannten Operations Reviews, in denen der Kanban-Fluß an Hand von KPIs  also Messwerten – überprüft und ggf. Ideen zu Verbesserung entwickelt werden. Das Feedback zum Produkt selbst steht in Kanban im Hintergrund, da wir hier eher einen „Produktions-„ als einen Produktentwicklung-Kontext haben. In Kanban gehen wir davon aus, dass das „Produkt“ an sich schon fertig ist und es „nur“ Wartungsarbeiten oder kleinere Anpassungen daran gibt. Daher ist ein Stakeholder in einem Kanban System halt daran interessiert, dass seine Anforderung schnell umgesetzt – also schnell produziert wird oder anders ausgedrückt – dass die Verweilest seiner Anforderung im System möglichst kurz ist. 

Es ergeben sich aus meiner Sicht noch eine Reihe von weiteren Fragen und die erste, die sich mir – und wahrscheinlich jedem, der mit seinem Team agil arbeiten möchte — in den Sinn kommt, ist

Wie analysiert man den Arbeitsprozess? – also den Workflow des Teams?

Da Kanban letztlich ein visueller Workflow ist, wird für die Aufgabenplanung und die Aufgabenverfolgung entweder ein physisches oder digitales Board verwendet. Ein Kanban-Board verwendet Karten, Rubriken und das Konzept der kontinuierlichen Verbesserung. So kann sich ein Team ständig selbst kontrollieren und für anstehende Arbeiten koordinieren. 

In Anlehnung an David J. Anderson, den ich ja schon erwähnt habe, gibt es folgende Komponenten in einem Kanban-Board: 

  • Visuelle Signale (normalerweise Karten) 
  • Spalten oder Listen 
  • Pull System
  • Work-in-Progress-Limits 
  • Einen Verpflichtungspunkt 
  • Eine Lieferstelle

Die Spalten oder Listen werden für die Darstellung des Workflows verwendet: Einer der häufigsten und einfachsten Workflows ist „To Do“, „In Bearbeitung“ und „Done“. Dieser Workflow ist meist auch die Basis in einem Scrum-Board. Kanban geht hier allerdings etwas genauer vor:

Wenn wir uns jetzt mal überlegen, welche grobe Tätigkeiten in der Spalte „In Bearbeitung“ stecken, können wir den Workflow detaillieren. Hier kannst Du zum Beispiel Dinge wie „Analyse, Konzeption, Programmierung, Dokumentation und Test einfügen um den Workflow des Teams zu beschreiben.

Voraussetzung ist, dass jede Karte die festgelegten Arbeitsschritte durchlaufen muss, um am Ende realisiert zu werden. Typisch hierfür sind kleinere Änderungen oder Bug-Fixes an bestehenden IT-Systemen. 

Dann komme ich jetzt mal zum Pull Prinzip: Ein wesentliches Element im Kanban Board ist das Pull System. Pull bedeutet – im Gegensatz zu Push – dass in jedem Prozessschritt derjenige, der die Arbeit vornimmt entscheidet, wann er etwas beginnt. Und das mit der Maßgabe, dass er nicht zu viele Dinge gleichzeitig bearbeiten darf. Dieses Konzept wird die Limitierung des Work in Progress genannt – also WIP-Limit. Wo die Limitierung liegt wird von Team festgelegt und immer mal wieder justiert. 

Auch in Scrum gilt das Pull Prinzip, wird in der Praxis jedoch oft ignoriert, da es nicht mit einem Kontrollmechanismus wie den WIP-Limits verbunden ist. Hier sehe ich zum Beispiel einen guten Ansatz, um Scrum mit einem Element aus Kanban zu erweitern. Ein Punkt, der dabei gleich ins Auge springt, sind die Unterkategorien „in Arbeit“ und „fertig“ in jeder Spalte bzw. In jedem Workflowschritt.  In Scrum bekannt ist ja die „DoD“ -also die Definition of Done: in Scrum verstehen wir hiermit die allgemein gültigen Kriterien, die jede Userstory erfüllen muss um in die Spalte „Fertig“ verschoben zu werden. Gemeint sind hiermit nicht die inhaltlichen Dinge – diese sind in den Akzeptanzkriterien festgehalten – nein gemeint sind hiermit die übergeordneten Dinge wie „test erfolgt, Dokumentation geschrieben, In dem Master ge-merge-t, oder ins Integrationstest-System transportiert…

Wenn wir das Pull Prinzip verankern wollen, müssen wir solche Regeln für jeden Prozessschritt einzeln klar formulieren und damit explizit festlegen, wie die Arbeit durch die einzelnen Stationen fließt. In jeder Station wird die Arbeit dann entsprechend der Kriterien in die Unterkategorie „Fertig“ geschoben und kann dann von dem Kollegen oder der Kollegin, die den nächsten Arbeitsschritt durchführt abgeholt werden. Es ist also was anderes, wenn Du Dein Stück auf den Schreibtisch des nächsten legst im Sinne von „hier, ich bin fertig und jetzt bist Du dran“ – das wäre dann nämlich das Push-Prinzip –  was man ja auch übersetzen kann mit „hier, ich drücke Dir die Arbeit auf“ 

oder 

wenn die fertige Arbeit auf Deinem Schreibtisch liegen bleibt bis sie abgeholt wird. Wenn der eigene Schreibtisch voll ist, darfst oder kannst Du nichts mehr anfangen…das bedeutet, die erzeugst keine Verschwendung, denn es sind aus deinem Arbeitsschritt ja genügend fertige Stücke vorhanden. Der Enpass liegt also hinter dir und Du kannst helfen, den Engpass zu beseitigen, da Du ja in dem Moment nichts zu tun hast. 

Du siehst – anders herum wird es weniger gut funktionieren: wenn du den Schreibtisch deines Nachfolgers zum Überlaufen bringst, verschlimmerst Du ja sozusagen den Enpass, weil der Haufen immer größer wird. Du produzierst unbeirrt Deine Dinge weiter und kümmerst Dich nicht darum, was nach Dir passiert…(das passende Sprichwort dafür ist dann „Nach mir die Sindflut“) – Halb fertige Produktbestandteile liegen herum und die stellen Verschwendung dar, da ja Arbeitskraft dafür eingesetzt worden ist – die aber keinen Nutzen trägt, da die halb fertigen Items eben noch nicht verwendet werden können. Und Verschwendung ist das, was wir in Kanban vermeiden wollen (und übrigens in Scrum auch – nur hier liegt der Fokus auf Dinge, die wir unnötigerweise produzieren und die im Nachhinein nicht gebraucht werden, weil wir sie am Bedarf vorbei produziert haben. )

Relativ einfach bekommst Du das hin, wenn Du zunächst mit Deinem Team definierst was in jedem Arbeitsschritt erfüllt werden muss, damit eine Karte auf „fertig“ gelegt werden kann. Diese Regeln solltest Du dann auch ausdrucken und an das Board hängen, da – wie bei allen agilen Frameworks – die Transparenz ja eine wesentliche Rolle spielt – und – wir haben das ja auch in der letzten Folge gehört – die Dinge transparent machen, gehört zu den Kernpraktiken des Kanban.. 

An dem Beispiel von eben mit den Schreibtischen wird auch klar, welcher Vorteil in der Limitierung von Work in Progress liegt – obwohl das ja eher kontraintuitiv erscheint. Also es klingt zumindest unlogisch. Wieso soll ich mehr schaffen, wenn ich mich beschränke? Ich will mich doch nicht beschränken, sondern ich will mehr schaffen, also kann es doch nur gehen, wenn ich in jedem Arbeitsschritt das Maximum erreiche – oder?

Ich gehe darauf nochmal in der kommenden Folge ein. Hier will ich nur nochmal bemerken, dass  es die „reine Lehre“ in der Realität ja meistens nicht gibt und wir durchaus mit Mischformen experimentieren können. Ich hatte ja am Anfang die unterschiedlichen Charaktereigenschaften der beiden Geschwister Kanban und Scrum erwähnt – Scrum begründet sich auf dem „inspect und adapt“ und Kanban basiert auf „start where you are“ – Scrum ist revolutionär, weil fest vorgeschrieben – Kanban evolutionär, weil sich langsam entwickelnd…Daher gehe ich – wie immer möglichst pragmatisch und offen vor und diskutiere mit dem Team, wie wir vorgehen wollen und was wir ausprobieren wollen – denn eins ist sicher – wir arbeiten ja in einer komplexen Welt – und daher müssen wir Experimente machen um den Weg zu finden. Vor uns war da noch niemand…(also von uns war da noch niemand) – wie auch immer – Du weist schon was ich meine…Und was natürlich auch bei Geschwistern gilt – Pack schlägt sich – Pack verträgt sich…

Danke fürs zuhören und viel Erfolg beim Spiel mit den agilen Elementen, will ich es mal nennen…

Dein 

agilophiler Frank

Agilophil-Daily Podcast Episode 19: Wir sprechen immer über Scrum, was ist eigentlich Kanban?

Ich war letztens in einem Projekt in einem ziemlich großen Konzern in einem ziemlich internationalen Umfeld. Eigentlich war ich als Scrum-Master engagiert und der Scrum-Prozess war auch schon aufgesetzt…aber irgendwie nicht ganz so, wie ich das erwartet hatte. Es gab zum Beispiel kein Review Meeting….auch Retrospektiven gab es immer nur nach Bedarf – aber eigentlich war dafür nicht wirklich Zeit vorgesehen…und es gab eigentlich kein wirklich definiertes Produkt, sondern eine lange Liste von Anforderungen, die in einem in Jira geführten Backlog standen…Da ich als Scrum-Master beauftragt war, fingen wir natürlich an Scrum zu verbessern…Aber das Team und der Product Owner waren nicht wirklich glücklich damit…

Es gab kein wirkliches Produkt, es gab immer wieder ad-hoc Anforderungen, die ins Backlog geschoben wurden – auch während des Sprints, es gab keine Stakeholder, die sich ein Review hätten ansehen können und so gab es noch eine Reihe von Dingen, die für einen Scrum-Prozess nicht optimal waren – wie sagt der Scrum-Guide bei sowas so schön…Du kannst gerne abweichen, aber dann ist es nicht Scrum!

Es war also kein Scrum…und daher machte es nach einer Weile auch keinen Sinn mehr gegen Windmühlenflügel zu kämpfen…Wozu mit aller Gewalt eine Methode umsetzen, wenn die Voraussetzungen und die Notwendigkeit dazu gar nicht gegeben sind?

Also schlug ich dem Team vor, es mal mit Kanban zu versuchen…Kanban ist ja „die andere“ große agile Methode…und sozusagen ein Bruder (oder eine Schwester) von Scrum…

Daher erzähle ich in der heutigen Folge mal ganz grob, worum es bei Kanban eigentlich geht…

Ich sagte ja bereits – Scrum und Kanban sind wir Bruder und Schwester…eng verwandt aber doch unterschiedlich…Während Scrum eine revolutionäre Methode ist, die erst erklärt und dann möglichst so – wie es im Scrumguide steht eingeführt werden sollte, ist Kanban eine evolutionäre Methode…In Kanban entwickeln sich die Dinge auf Basis der aktuellen Situation. Daher ist eines der Grundprinzipien von Kanban auch „Start where you are“ – also „beginne, wo du jetzt bist“.

Da bin ich auch schon beim ersten Thema – Kanban basiert auf 4 Grundprinzipien und 6 Kernpraktiken…die ich jetzt mal kur vorstellen möchte

Hier die Grundprinzipien:

  1. (hatten wir ja schon): Beginne da, wo du stehst – also -> „Start where you are“
  2. Verfolge inkrementelle und evolutionäre Veränderungen
  3. Respektiere und wertschätze die aktuellen Vorgehensweisen, Rollen und Verantwortlichkeiten
  4. Ermutige zur Führung auf allen Ebenen

Was bedeutet das im Einzelnen?

Also das erste Grundprinzip – „Start where you are“ bedeutet, dass Du – anders als in Scrum – nicht einen bestehenden Prozess über den Haufen wirfst um einen Scrum-Prozess neu zu implementieren, sondern, dass es das Ziel ist, den vorhandenen Prozess oder Workflow erstmal weiter zu nutzen. Das hat den Vorteil, dass so Kanban in jedem Unternehmen ohne große Anfangswiderstände eingeführt werden kann, da ja erstmal gar nichts geändert wird. 

Aber was bringt das dann, wenn nichts geändert wird?

Da komme ich auch schon zum 2. Grundprinzip: – Verfolge inkrementelle und evolutionäre Veränderungen ! Darum geht es nämlich – Veränderungen sollen erreicht werden, nur eben nicht in Form einer Revolution  – also mit dem großen Knall – sondern evolutionär, ganz sachte mit kleinen Änderungen…Der Vorteil kann (ist ja nicht immer der Fall) darin liegen, dass Angst und Unsicherheit vermieden wird – die ja oft mit grundlegenden großen Änderungen einher gehen…

In die Gleiche Richtung geht auch das 3. Grundprinzip: Respektiere und wertschätze die aktuellen Vorgehensweisen, Rollen und Verantwortlichkeiten.  Für mich sehr sympathisch ist dieses Prinzip, denn es ist ja was dran. Dein Unternehmen oder Dein Team ist bis heute wahrscheinlich ganz gut mit der bisherigen Arbeitsweise zurecht gekommen und das hat Euch dahin gebracht, wo ihr jetzt seid. Diese Erfolge zu würdigen, ist gerechtfertigt – und hilft natürlich dabei, die kleinen inkrementellen Veränderungen herbeizuführen, die dennoch notwendig sind. Angst behindert Fortschritt und Angst vor Kanban ist nicht notwendig…

Das 4. Grundprinzip „ Ermutige zur Führung auf allen Ebenen“ spricht das Selbstverständnis der Mitarbeiter – also auch Deines – direkt an…Hast Du schon mal von KAIZEN gehört – das aus Japan kommende Konzept der kontinuierlichen Verbesserung ist ein wesentliches Grundelement von Kanban. Die Umsetzung von KAIZEN erfordert ein Mitdenken aller Mitarbeiter -also egal ob Management oder Mitarbeiter – egal ob Unternehmensleitung oder Fließbandarbeiter (jawohl, Kaizen kommt ursprünglich aus der Industrie)…

So – auf Basis dieser 4 Grundprinzipien werden nun die 6 Kernpraktiken gelebt. Diese sind:

  1. Mache den Workflow sichtbar
  2. Begrenze die laufende Arbeit
  3. Mache die Regeln für den Prozess verständlich
  4. Messe, was passiert und kontrolliere den Fluß der Arbeit
  5. Führe Feedbackschleifen ein
  6. Nutze bewährte Modelle und wissenschaftliche Methoden zur kontinuierlichen Verbesserung

In Scrum geht es vorrangig um die Entwicklung eines Produktes und das Lernen auf dem Weg, in Kanban geht es vorrangig einen reibungslosen Arbeitsfluss…Wir möchten also schnell und reibungslos Arbeitselemente durch den Prozess bekommen und dabei unnötige Arbeit weitgehend vermeiden.

Dazu – und jetzt komme ich wieder auf die einzelnen Praktiken: 1. Mache den Workflow sichtbar: wir müssen erstmal sehen, wie unsere Arbeit überhaupt abläuft, also den Workflow darstellen. Am besten versteht man das, was man sieht, daher ist das Kanban-Board eines der wesentlichen Elemente im Kanban. Und das kennen wir im Prinzip auch aus Scrum, wo wir auch ein Scrum-Board oder Task-Board im Sprint verwenden. In Kanban wird das Board meistens etwas ausführlicher gestaltet, aber hier wird die Verwandtschaft von Scrum und Kanban sehr deutlich. Die Arbeit wird Karten dargestellt und wandert im Allgemeinen von links nach rechts über das Board von „offen“ durch die einzelnen Prozessschritte – bis zu „fertig“…

Die 2. Kernpraktik bezieht sich auf einen weit verbreiteten Irrtum…Der Irrtum ist anzunehmen, dass sowas wie „Multitasking“ möglich ist…Ist es nicht! – weder bei Frauen, noch bei Männern. Vielleicht kannst Du als Frau besser umschalten, aber umschalten müssen du auch! – Daher liegt die zweite Kernpraktik in der Begrenzung der laufenden Arbeit. (im englischen „Work in Progress“, also abgekürzt mit WIP). Und die Begrenzung des WIP wird dann WIP-Limit genannt. Wenn jeder nur noch ein oder zwei To Do’s haben darf, dann kann man sich nicht zwischen 10 Projekten aufreiben, das leuchtet ein und darum geht es in dieser Praktik.

Der nächste Punkt ist Praktik Nr. 3: Mache die Regeln für den Prozess verständlich 

Nach dem Sehen des Workflows kommt das Verstehen…Jeder Arbeitsprozess hat Regeln, nach denen entschieden werden kann, wie ein Stückchen Arbeit behandelt wird. Ein bekanntes Beispiel für so eine Regel ist die Definition of Done – die wir auch aus Scrum kennen. Wir müssen alle gemeinsam dasselbe Verständnis davon haben, wann ein Schritt nun fertig ist  und wann nicht…

So komme ich nun zu Praktik Nr. 4: Messe, was passiert und kontrolliere den Fluß der Arbeit

Hier schauen wir der Wirklichkeit in die Augen – Eine der wichtigsten Informationen im Workflow ist zum Beispiel die Durchlaufzeit. Wie lange hat eine Aufgabe gebraucht, um von „offen“ bis zu  „fertig“  zu wandern. Anhand solcher Informationen können wir dann auch verlässliche Aussagen für unsere Kunden treffen – die Durchlaufzeiten werden variieren, aber eine Aussagen, dass wie mit einer 80%igen Wahrscheinlichkeit die Aufgaben in 14 Tagen erledigt haben werden, beruhigt doch ungemein…um solche Aussagen treffen zu können, müssen wir messen und kontrollieren.

Die Nr. 5 der Kanban-Praktiken ist „ Führe Feedbackschleifen ein“

Auch das kennen wir schon aus Scrum – da heißt die Feedbackschleife „Retrospektive“ oder auch das Daily Scrum kann man als Feedbackschleife verstehen…ein Daily Standup gibt es in Kanban auch, den das Team will auch hier wissen, wo jeder steht, und wo ggf. Hilfe notwendig ist oder man vielleicht auch Unterstützung bekommen kann. Retrospektiven sind in Kanban zwar nicht im Prozess fix verankert, aber in bestimmten Intervallen auch auf jeden Fall wichtig, da es ja um kontinuierliche Verbesserung der Teamarbeit geht.

Die letzte Kernpraktik in Kanban ist nun Nr. 6: nutze bewährte Modelle und wissenschaftliche Methoden zur kontinuierlichen Verbesserung

Eine der hier wesentlichen Modelle ist die Enpasstheorie. Wie in der Physik fließt das Wasser auch nur so schnell, wie es an der engsten Stelle fließen kann…daher geht es immer wieder darum, Engpässe zu identifizieren und letztlich auch zu beheben. Da es immer mehrere Engpässe geben wird, startet man mit dem „engsten“….und arbeitet sich dann Stück für Stück vor. Das heißt – die Beseitigung eines Engpasses wird einen neuen Engpass aufdecken. Hier treffen wir wieder auf die Iterationen, die wir ja auch schon aus Scrum kennen.

Fazit: Du siehst, Kanban und Scrum basieren auf ähnlichen Werten und Prinzipien und haben auch teilweise gleiche Elemente. Daher macht es auch aus meiner Sicht keinen Sinn beide gegeneinander auszuspielen…Ich habe – durchaus auch in meiner Kanban-Schulung – Sätze gehört wie – wir müssen ein kaputtes Scrum durch Kanban reparieren….Ich halte da gar nichts von, ehrlich gesagt, letztlich sprechen wir hier nicht von konkurrierenden Methoden, sondern von Geschwistern, die nicht gegeneinander arbeiten sollten, sondern sich wunderbar ergänzen können. Scrum geht eher auf den Nutzen, das Produkt und das Ergebnis, Kanban eher auf den Flow, den harmonischen und schnellen effizienten Arbeitzprozess…

Ob nun Scrum oder Kanban – das kommt ganz drauf an….mal passt das eine besser, mal das andere…

Insofern wünsche ich Dir noch eine schöne Zeit…

Tschüß

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 18: Von Eseln und Menschen – Die Theorie X und die Theorie Y

Herzlich Willkommen zu dieser neuen Folge des agilophil-daily Podcasts. einen Hinweis gebe ich gleich mal am Anfang: Bitte diese Folge bis zum Ende durchhören, sonst entsteht ein falscher Eindruck…

Die heutige Folge handelt von Eseln und Menschen..

Um es mal vorweg zu nehmen – ich habe nichts gegen Esel…Esel sind intelligente und sehr feinfühlige Tiere, die allerdings teilweise bei uns ein schlechtes Image abbekommen haben. Das liegt wahrscheinlich in ihrer Charaktereigenschaft KEINE Fluchttiere zu sein und nicht – wie die vermeintlich viel stolzeren und edleren Pferde – bei jeder vermeintlichen Gefahr sofort wegzulaufen. Nein -Esel bleiben stehen…und analysieren die Situation – ehe sie sich für irgendwas entscheiden. Klingt eigentlich eher positiv. Trotzdem gelten Esel als störrisch. Nun, sie haben in ihren Herden – und sie sind sehr gesellig und leben eben nicht allein – keine ausgeprägten Hierarchien, daher erkennen sie den Menschen auch nicht als Höherrangig an und lassen sich halt auch nichts sagen oder anders ausgedrückt – sie lassen sich nicht so leicht dressieren…und sind eben störrisch. Aber darauf will ich gar nicht hinaus – es geht in der heutigen Folge eigentlich um ganz was anderes – um ein Gedankenexperiment, eines, das sich ein gewisser Douglas Murray McGregor 1960 überlegte:

Die Theorie X und die Theorie Y

Douglas war ein Professor für Management am berühmten Massachusetts Institute of Technology (MIT). Er gilt als einer der Gründerväter des zeitgenössischen Managementgedankens, wurde aber oft völlig falsch interpretiert…

Er hatte sich folgendes Gedankenexperiment überlegt:

Es gibt 2 Menschenbilder, die wir – so seine Vorstellung – in uns tragen.

Das erste Menschenbild ist – sozusagen „Der Mensch als Esel“…er nannte es das Menschenbild nach der X-Theorie:

und dieser Mensch hat folgende Eigenschaften:

  • Menschen bzw. Mitarbeiter sind von Geburt an arbeitsscheu und versuchen diese weitestgehend zu umgehen.
  • Die Menschen müssen zur Arbeit gezwungen oder verführt werden – das nennt man dann auch „extrinsisch motivieren“. 
  • Dem Mitarbeiter sind Routineaufgaben lieber als neue Aufgabenfelder.
  • Mitarbeiter brauchen eine Kontrolle und sie wünschen sich das auch.
  • Strafen und Strafandrohungen sind ein adäquates Mittel, um die Produktivität eines Mitarbeiters zu steigern.
  • Mitarbeiter haben zudem sehr wenig Ehrgeiz, ein hohes Sicherheitsbedürfnis und möchten keine Verantwortung übernehmen.
  • Sie erzwingen ein Management, dass die „Verwaltung und Antreibung“ dieser Mitarbeiter übernimmt.

Um es mal zusammenzufassen: Diese Menschen sind eine dumme, willenlose Masse, die ständig zu ihrem Glück oder zu Leistungen gezwungen werden muss und keine eigene Kreativität und keinen eigenen Antrieb besitzt.

Dem gegenüber gibt es dann das zweite Menschenbild den „Mensch als Mensch“ – genannt das Menschenbild der Y-Theorie:

  • Die Menschen wollen arbeiten und streben dabei nach Entfaltung ihrer Persönlichkeit. Hier ist der Mitarbeiter arbeitswillig und sieht diese persönliche Haltung als wichtigen Bestandteil zum Erlangen seiner eigenen Zufriedenheit an.
  • Aufgaben werden durch den Mitarbeiter selbstständig und pflichtbewusst erfüllt.
  • Eine kontrollierende Führung ist nicht notwendig, da sich der Mitarbeiter mit dem Unternehmen identifiziert.
  • Den Mitarbeitern genügt die Selbstkontrolle, um produktiv daran mitzuarbeiten Unternehmenszielen zu erreichen.
  • Leitet man den Menschen richtig, so entwickelt er besondere Potenziale und übernimmt gerne eigene Verantwortung. 
  • Diese Menschen ermöglichen eine wahre Führung, sind humanistisch aufgeklärt und gehen wertschätzend miteinander um.

Als ich das erste Mal davon gehört habe – ich weiß gar nicht mehr, bei welcher Gelegenheit das war – es muss irgendsoein Führungskräfteseminar gewesen sein, bei dem ich mal bei einem meiner früheren Arbeitgeber war – bekamen wir die Aufgabe uns selbst nach diesen Menschenbildern einzuteilen.. Nun rate mal, wie vielen von uns sich als Menschen der X-Theorie gesehen haben…genau  –  maximal einer und das auch wahrscheinlich nur, weil er den Trainer verarschen wollte…

Das ist doch seltsam – denn wenn wir auf Andere schauen, müsste doch mindestens die Hälfte der Menschen – wenn nicht noch mehr –  der Theorie X angehören – schließlich sind wir ja alle bekanntlich nur von Idioten umgeben…Und wenn wir uns mal die – allerdings vornehmlich Tayloristische Sicht von Arbeitern ansehen, findet man diesen Menschentypus ja wahrscheinlich hier – also bei den Arbeitern – am häufigsten.

Dabei wollen wir doch alle ein Team, das nur aus Y-Leuten besteht, das ist doch klar…Wir selbst gehören ja schließlich auch dazu. Wer wünscht sich das nicht, selbstständig und pflichtbewusst, kreativ und produktiv an der Verwirklichung von größeren Zielen mitarbeiten zu können und diese Vertrauen auch zu bekommen?

Ich Douglas McGregor ging dann noch einen Schritt weiter:

Er entwickelte zu den beiden X und Y Menschenbildern noch ein weiteres Modell – das Menschenbild der Z-Theorie und das beinhaltet folgende Eigenschaften:

  • Die Kontrolle von Mitarbeitern ist möglich, sollte aber nur bedingt eingesetzt werden um Unternehmenszielen zu erreichen.
  • Wenn sich ein Mitarbeiter den Unternehmenszielen verpflichtet fühlt, so wird er auch eigenständig Disziplin entwickeln. 
  • Die Effizienz des Mitarbeiters wird durch ein Mix aus Fremd- und Selbstkontrolle maximal be steigert. 
  • Mitarbeiter sollen generell stärker in Entscheidungsprozesse eingebunden werden. 
  • Wenn ein Unternehmen geeignete Rahmenbedingungen schafft, können selbst durchschnittliche Mitarbeiter Verantwortung übernehmen. 

Wenn man mal genauer hinschaut, dann kommt die Theorie Z dem japanischen Managementstil sehr nahe. Und damit wären wir auch schon beim eigentlichen Zweck der Übung und dem großen Mißverständnis, welches sich Douglas McGregor immer wieder ausgesetzt sah (und nun – da er ja schon eine Weile Tod ist, kann er sich ja auch nicht mehr dagegen wehren). Leider wurde und wird daraus interpretiert, er hätte gesagt, dass man die Menschen in 2 bzw. 3 Kategorien einteilen könne – was aber so überhaupt nicht stimmt! 

Diese Theorien sind Menschenbilder, die aus Sicht der Managementsysteme gebildet werden. Es sind keine Kategorien von Menschen, die wirklich existieren. Das Tayloristische System selbst ist Ursprung dieses Menschenbilds mit seiner Einteilung in „Arbeiter und Angestellte“ – also in die, die die Arbeit als X-Personen ausführen und die, die sich die Arbeit als Y-Personen ausdenken. Die X und Y Menschenbilder entspringen also nur den verbreiteten Managementsystemen. Sie haben nichts mit der Realität zu tun. Es gibt keine Menschen, die einer X-Kategorie entsprechen – die X-Theorie ist nur ein Vorurteil über andere Menschen und eine reine Fiktion – ebenso gibt es keine Z-Menschen – In Wahrheit – und Douglas McGregor hat das auch nie anders behauptet – gibt es ausschließlich Y-Menschen. Es kann allerdings sein, dass wir uns durchaus mal „X-ig“ oder „z-ig“ verhalten! 

Welche Auswirkung hat diese Erkenntnis auf uns und auf das agile Arbeiten? Nun – in agilen Teams ist die Selbstorganisation ein wesentliches Ziel bzw. eine wesentliche Eigenschaft. Agile Teams organisieren sich selbst. Hier greift auch schon meist ein Konflikt – wenn die Organisation des Unternehmes Selbstorganisation nicht vorsieht, kann ein Team auch nicht agil arbeiten. Und „Die Organisation“ – ich spreche hier mal die Anführungsstriche mit – wird ja nicht von außenstehenden Mächten, Göttern oder Naturgesetzen gemacht – auch wenn in letzter Zeit Verschwörungstheorien reichlich zulauf haben –  sondern von uns Menschen – genauer gesagt, von den Menschen, die selbst in der Organisation arbeiten oder leben.

Und die wesentliche Erkenntnis ist: Es gibt keine Menschen, die von Natur aus der Theorie X oder Z entsprechen – alle Menschen entsprechen der Theorie Y – Das „x-ige“ oder „z-ige“ Verhalten wird durch die Organisation gemacht! – Und dabei schließe ich dass Umfeld des Menschen mit ein – also nicht nur die Organisation der Firma ist für sein Verhalten verantwortlich, sondern natürlich auch die Glaubenssätze, die ihm seine Familie oder privates Umfeld mitgegeben haben. Wer ein Leben lang gesagt bekommen hat, dass „die da oben“ die Regeln machen und „wir hier unten“ diese zu befolgen haben, wird sich naturgemäß schwer tun, selbst Regeln aufzustellen. Das liegt aber nicht an seiner Natur gegebenen Charaktereigenschaft, sondern an seiner Erziehung bzw. seinem von außen gegebenen Weltbild. Immanuel Kant nennt das so schön „die selbst verschuldete Unmündigkeit“. Und daher tut Aufklärung auch not – um diesen Schwenk mal zu wagen.

Daher jetzt nochmal konkreter: Wenn Du in Deiner Firma über Mitarbeiterentwicklung, Führungsthemen oder Organisation nachdenkst, dann beachte bitte, dass es ein Argument nicht gibt: Es gibt per se keine „Esel“ in Deiner Firma – wenn Du der Meinung bist, in Deinem Team oder  deiner Firma gibt es zu viele davon, dann hast Du die wahrscheinlich selbst geschaffen.

Wenn Du in einer Firma arbeitest, dann verhalte Dich so, wie es Deinem eigentlichen Wesen entspricht – Mach Dir Deine Regeln selbst – und wenn Deine Regeln mit denen der Firma im Einklang sind, seid ihr auf dem richtigen Weg. Verhalte Dich verantwortungsvoll und tue alles, was Du kannst, um den gemeinsamen Zielen von Dir und deinem Unternehmen ein Stück näher zu kommen. Wenn Du mit den Zielen der Firma nicht einverstanden bist, dann such Dir eine Firma, mit der Du besser klar kommst…Niemand zwingt dich in einem Umfeld zu arbeiten, das Dir nicht gut tut! – Schließlich bist Du selbstverantwortlich für Dich und Dein Glück und Deinen Erfolg und Du kannst handeln. 

Das ist natürlich alles leicht gesagt – und vor allem leichter gesagt als getan – das ist mir bewusst. Es ist auch nur ein Impuls, den ich hier setzen will, ich meine nicht, dass jeder bei dem kleinsten Konflikt gleich die Flinte ins Korn schmeißen und sich eine andere Firma suchen soll…Die Selbstverantwortung besteht ja auch daraus, dass Du das System, in dem Du steckst auch ändern kannst. Du kennst bestimmt den Spruch „love it, change it, or leave it“ – demnach ist die Kündigung das letze Mittel nachdem Du alles versucht hast, was Du kannst, um die Dinge zum Besseren zu ändern. Denn das gehört ja auch zu agilen Arbeiten – Kaizen – die ständige Verbesserung. 

insofern – stelle Dir einfach mal vor:

  • Du willst gerne arbeiten und strebst nach der Entfaltung Deiner Persönlichkeit
  • Du überlegst Dir selbst, was Deine Aufgaben sind und erfüllst sie eigenständig und zuverlässig
  • Du identifizierst Dich mit dem Unternehmen und fragst, was kannst Du tun, um unseren gemeinsamen Ziele zu erreichen
  • Du kontrollierst Dich selbst – und brauchst keine kontrollierende Führung oder Überwachung
  • Du nimmst aber gerne Führung an, da du weißt, dass es Deine Persönlichkeit voran bringt und Du mehr Verantwortung übernehmen kannst.
  • Du möchtest auch gerne in einem Umfeld arbeiten, dass dich fördert und dir hilft und du gehst wertschätzend mit deinen Kollegen um und hilfst ihnen auch und förderst wen Du kannst.

Und um das zu verankern sprich doch – vielleicht vor dem Schlafengehen diese Sätze einfach mal – wie ein Mantra – vor Dich hin…

„Ich möchte arbeiten und entfalte dabei meine Persönlichkeit“

„Meine Ziele und die Ziele meiner Firma sind gleich“

„Ich überlege mir, was ich tun kann um unsere gemeinsamen Ziele zu erreichen!

„Ich helfe gerne meinen Kollegen und nehme auch gerne Hilfe von ihnen an“

Such Dir einfach einen Satz aus, der momentan ab besten passt oder nimm alle – das überlasse ich ganz Dir – Du kannst Dir natürlich auch eigene Sätze ausdenken…

Ich wünsche Dir viel Spaß auf Deinem Weg – hinaus aus der selbst verschuldeten Unmündigkeit…

Dein agilophiler Frank

Agilophil-Daily Podcast Episode 17 – Shu-Ha-Ri

Scrum, Kanban, Lean Manufacturing – diese Dinge haben ihre Wurzeln in Japan, beziehungsweise bauen auf japanischen Traditionen und Werten auf. In der Geschichte von Scrum und agilem Arbeiten hat sich daher eine sehr starke Verbindung zu Japan und zur japanischen Sichtweise ergeben. Das soll natürlich nicht heißen, dass Scrum oder agiles Arbeiten eine japanische Erfindung sei…Viele von diesen Traditionen kommen in anderen – und natürlich auch in unserem Kulturkreis genauso vor…Das Thema der heutigen Folge ist das SHU-HA-RI…

Das Shu-Ha-Ri-Konzept

Der Begriff SHU-HA-RI kommt – wie gesagt –  aus Japan und wird heute meist in Verbindung Kampfsport also AIKIDO oder KARATE gebracht, Dieses alte japanische Konzept des Lernens soll auf KAWAKAMI FUHAKU zurückgehen der im 18.Jhdt lebte (1719-1807) . Es beschreibt die drei Lernstufen zur Meisterschaft. 

Shu-ha-ri heisst übersetzt: “ erst lernen, dann loslösen und endlich übertreffen“.

Und es beschreibt den dreistufigen Prozess zur Erlangung der Meisterschaft, den wir in Deutschland so ähnlich auch als „Lehrling, Geselle, Meister“ kennen. (um mal die älteren deutschen Bezeichnungen dafür zu verwenden), wir durchlaufen also 3 Status um zum Meister zu werden

Die Begriffe selbst bedeuten hier

SHU = KOPIEREN, oder das Lernen der Form

          HA  = ABWEICHEN, oder das Überschreiten der Form

              RI  = FREIE VERWENDUNG, oder eigene Wege finden

Doch grau ist bekanntlich alle Theorie: hier mal ein paar Beispiele, was das bedeutet:

Nicht nur in Japan oder Deutschland sind diese drei Schritte bekannt – gehen wir mal gedanklich nach Westen nach Mexiko…dort gibt es eine Tradition, die sich seit den 40er Jahren zum Touristenmagnet entwickelt hat, die Clavadistas. So werden die Klippenspringer von La Quebrada in Acapulco genannt…Du hast bestimmt von ihnen gehört – der Felsen, von dem sie runterspringen ist ungefähr 35 Meter hoch und fällt nicht senkrecht ab, sondern leicht geneigt in eine Schlucht, die unten nur 7 Meter breit ist. Die Neigung bedeutet, dass der Felsen unten ca. 3,5 m vom Absprungspunkt entfernt ins Wasser geht..Das Wasser dort ist nur wenige Meter tief, so dass der richtige Moment der Brandung abgewartet werden muss um nicht auf den Boden aufzukommen. Man muss also mindestens 4 Meter weit abspringen und den richtigen Moment erwischt haben, um den Sprung zu überleben oder nicht zumindest eine schwere Verletzung zu riskieren…Warum machen die Leute das? Nun ja – wie so oft – früher – also vor den 1930er Jahren war es schlicht eine Mutprobe für die jungen Männer, die sich daraus ergeben hatte, dass früher die Fischer vom Felsen ins Wasser sprangen um verhedderte Angelschnüre zu befreien – das haben sie natürlich nicht von oben gemacht sondern von viel weiter unten – aber die Mutprobe lag ja dann nahe einfach mal zu probieren, ob das auch von weiter oben funktioniert. Heutzutage ist Klippenspringer in Mexiko ein anerkannter Beruf und die Ausbildung ist langwierig…Was meinst Du, auf welcher Höhe die jungen Klippenspringer beginnen? 10meter? 5 meter? 3 meter? – nein. Auf einem halben Meter…Wochenlang üben die Jungs den Absprung ins Wasser – man muss es im Schlaf können, die Technik muss absolut sitzen – schließlich muss man in jedem Fall die Entfernung von 4 Metern überbrücken, um zu überleben…Und lebensmüde sind die Clavadistas nicht – sie sind Meister ihres Fachs…Der Anfang ist das Fundament – der SHU-State: Stand, Sprungkraft, Haltung in der Luft, das wird über Monate trainiert. Die nächste Stufe ist bei 3metern – und das wird nochmal für mindestens 6 Monate trainiert – erst wenn die Technik perfekt sitzt, dürfen die jungen Springer höher und nach 3-5 Jahren springen sie vom obersten Punkt…sie haben dann die Stufe des Meisters erreicht…

Wenn wir also uns die Entwicklung dieser – ich nenne es mal – Kunst vorstellen, dann haben die jeweiligen Meister ihres Fachs es vollbracht immer weiter höher zu steigen, bis sie in der Lage waren vom obersten Punkt des Felsens zu springen. Und dieses Wissen haben sie dann an die nächsten Generationen weiterzugeben. Der RI-State war jeweils Voraussetzung für die Weiterentwicklung der Fähigkeit. Basis war der SHU-State.

Gehen wir mal ein paar Jahre zurück und wieder nach Europa – Wir machen eine kleine Zeitreise ins Jahr 1860 – zu einem Mann nahmens Edouard Manet. Edouard war Maler im Paris in der Mitte des 19.Jahrhunderts.  Man muss sich das mal vorstellen: in einer Zeit, in der es weder Fotografie noch Filme gab, war die Malerei ein beliebtes Mittel für Kopfkino…neben der Literatur natürlich – es wurden Bilder gemalt, die Geschichten erzählten, oder Handlungen, Dinge und Orte detailgetreu darstellten…Mitte des 19. Jahrhunderts war Paris das Zentrum der Kunstwelt und der Maler stand als Beruf auf einer Stufe mit dem Arzt oder Juristen. Die Maler durchliefen eine jahrelange Ausbildung an der Schule für bildende Künste in der sie mit dem Abmalen von alten Meistern begannen und nach vielen Jahren mit Aktmalerei abschlossen – Edouard Manet, den man heute als Wegbereiter der modernen Malerei ansieht, war einer von ihnen. Eine jährlich stattfindende Ausstellung im so genannten „Salon“ war sozusagen die Weltausstellung und Casting-Show der damaligen Kunstwelt. Die Ausstellung dauerte 6 Wochen und es kamen bis zu einer Million Besucher um sich die Werke anzusehen. Die besten Werke wurden mit Medaillen ausgezeichnet und die unerbittliche Jury entschied, welche Bilder in den erlauchten Kreis der Ausstellung aufgenommen oder welche abgelehnt wurden…Wer es in die Ausstellung schaffte war ein gemachter Mann – für die Siegerbilder schossen die Preise in die Höhe. Wer nicht vertreten war und abgelehnt wurde, konnte sich die Kugel geben…was einige Maler auch tatsächlich nach ihrer Ablehnung realisierten…Natürlich waren alle Maler hier in dem Ri State – sie hatten die Grundlagen von der Pike auf gelernt, waren mit allen Techniken vertraut und konnten sie perfekt umsetzen. Warum ich das hier erzähle? Edouard Manet, der mit einigen Freunden Meister seines Fachs war, wagte es   sich vom Mainstream abzuwenden und eine eigene Kunstausstellung zu eröffnen und einen neuen Malstil zu begründen – den Impressionismus – einen Stil, der mit grobem Pinselstrich und ohne feine Details auskam und somit die etablierte Kunst veränderte. Heute hängen die Bilder der modernen Maler in allen großen Museen und sind Millionen wert…Der Meister – im RI-State – ist in der Lage neue Wege zu gehen. Aber das auf der Basis seiner Meisterschaft. Es ist ja nicht so, dass er nicht „fein und detailliert“ malen konnte!…Pablo Picasso, der mit seinen unförmigen Portraits bekannt geworden ist, konnte „normale Bilder“ malen, die Technik hatte er drauf. Aber durch seine Meisterschaft hat er über die Grenzen der reinen Abbildung geschaut und neue Welten und Interpretationen geschaffen, die voher so nicht existierten…

Und Arien Robben – wer kennt nicht den Robben Move, den er über 10 Jahre lang ausgeführt hat, und der die gegnerischen Verteidiger bis an sein Karriereende zur Verzweiflung gebracht hat. Jahrelang hat der kleine Arien geübt und auch im Zenit seiner Karriere hat er jeden Tag 30min nach dem offiziellen Training diesen Move und Schuss trainiert. Jeden Tag über mehr als 10 Jahre hinweg…

Die Erkenntnis daraus ist…es ist noch kein Meister vom Himmel gefallen (altes deutsches Sprichwort…): Wir brauchen Zeit für die Entwicklung, wir dürfen nicht zu ungeduldig sein…

Der Shu-State: bedeutet viel Demut – ich schaue zu und ahme nach. Ich erkenne an, dass es bistimmte Dinge gibt, die ich erstmal lernen muss, bevor ich die Welt verändern kann. Und ich erkenne an, dass ich noch nicht von anfang an alles verstehen kann, manches Verständnis kommt erst mit der ständigen Wiederholung. 

Der Ha-State: bedeutet sein Selbstbewusstsein aufbauen: Ich wende an und kann es und erreiche die gleiche Qualität wie der Meister selbst. Der Bauplan kommt vom Meister aber ich habe die Fähigkeit meinen Stuhl in derselben Qualität und Güte zu bauen, wie er. Und ich erlaube mir erste Experimente etwas zu verändern – in gewissen Grenzen, die noch vom Meister vorgegeben werden. Mit der Gewissheit es zu können werde ich mutiger und kann neues Entdecken – ich steige sozusagen den Fels etwas höher…mit der Erlaubnis des Meisters, der immer noch über mich wacht..

Der Ri-Status: bedeutet Souveränität, Freiheit und Kreativität: Ich kenne den Rahmen und verändere die Regeln und finde neue Wege zum Besseren. Auf Basis meiner jahrelangen Erfahrung kann ich Dinge so einschätzen, dass die Risiken absehbar oder ein völlig neuer Nutzen geschaffen wird. Ich gebe mein Wissen weiter und gebe den Jüngeren zuerst die Wurzeln und dann die Flügel um selbst später die Meisterschaft zu erreichen.

Fazit und Schwenk zurück auf die Agilität:

SHU ist die Stufe des Anfängers, hier schaffst Du dir ein sicheres Fundament – sieh es als eine Art Lebensversicherung an. Wenn das Fundament nicht steht, wackelt das Haus ein Leben lang…Das Fundament erreichst Du durch Nachmachen des Gezeigten und Erklärten. Wenn Du oder ein Team im SHU-Status ist, ist es noch nicht reif für eigene Kreativität und es ist ratsam die Regeln einer agilen Methodik zu befolgen. Das ist kein Mangel, es ist nur ein Status. Viele Dinge werden erst durch Wiederholung klar und dahinter liegende Prinzipien erschließen sich erst mit der Zeit. Im SHU-State solltest Du dich darauf konzentrieren die Rituale, Meetings und Tools wie Backlog, Userstories, Taskboard oder Kanban-Board – Wip-Limits, Planungsmeeting, Dailies und Reviews und Retrospektiven zu etablieren und konsequent durchzuführen und zu optimieren. 

HA ist die Stufe, in der Du die Techniken beherrscht und nun beginnst die Hintergründe der Techniken und Formen zu hinterfragen und zu verstehen. Wenn Du oder Dein Team reifer in der agilen Arbeit mit Scrum oder auch Kanban ist und Du den HA-Status erreicht hast, kannst Du gewisse Regeln anpassen (brechen), um bessere Ergebnisse zu erzielen. Im HA-State geht es dann um Themen wie Struktur in der Arbeit, Kultur und Werte im Unternehmen, Verhalten untereinander und Führung/oder neudeutsch „Leadership“. 

In der RI-Stufe hast Du das Wissen Deines Lehrers vollständig aufgenommen und bist selbst zum Meister gereift. Es ist Dir nun möglich, dich von einem übergeordneten Standpunkt aus sozusagen aus der Vogelperspektive – von dem Bisherigen zu entfernen und deiner eigenen Auffassung über das agile Arbeiten zu folgen. Im RI-State ist das agile Unternehmen in der Lage neue Regeln zu definieren und beste Ergebnisse zu erziehlen. Wir betreten die Welt der lernenden Organisation. Ein Beispiel dafür ist Spotify…es wird nur oft vergessen, dass es eben die EIGENE Sicht von Spotify ist, die zum damaligen Zeitpunkt ein bester Weg war…Das heißt noch lange nicht, dass man den Spotify Weg auf andere Firmen in andern Entwicklungstufen übertragen kann…

Wenn Du in Deiner Firma den Weg zum agilen Unternehmen anstrebst, agiles Arbeiten mit Scrum oder Kanban einführen willst, dann tust Du gut daran erstmal dem Lehrbuch zu vertrauen. Erst wenn, du am eigenen Leib erfahren und gefühlt hast, wie sich Scrum oder Kanban anfühlen, welche Konsequenzen hinter dem befolgen von Regeln und Prinzipien stecken und wenn Du verstanden hast, was die zugrundeliegenden Werte wirklich bedeuten – erst dann wirst Du in der Lage sein, das System auch für Deine Firma weiterzuentwickeln. Ein „bei uns geht das nicht und wir müssen das erstmal anpassen“ ist wenig zielführend. Wenn Du ein System noch nicht verstanden hast und die Vorteile noch nicht gespürt hast, machst Du es ja kaputt, ohne den Nutzen jemals erfahren zu haben. Leider ist das ein Vorgehen, das sehr oft vorkommt und ich auch sehr oft bei meinen Kunden erlebe. Passe also die Regeln an wenn Du die Meisterschaft erreicht hast, wenn das Team viel Erfahrung gesammelt hat und ihr einen hohen agilen Reifegrad erreicht habt – dann ja – voher nicht.

Irgendwie kommt bei mir dann immer das Bild vom abgeholzten und verbrannten Regenwald hoch, den wir in unfruchtbares Ackerland verwandelt haben, ohne verstanden zu haben, dass die Heilmittel für verbreitete Zivilisationskrankheiten gebraucht hätten,  eigentlich in der Pflanzenart steckte, die wir gerade dummerweise ausgerottet haben, ohne sie vorher über haupt kennenzulernen…

Tja – dumm gelaufen…

Also – wir vermeiden das und blicken zuversichtlich in die Zukunft. Ich wünsche Dir viel Erfolg beim Erklimmen der Leiter zur Meisterschaft – ganz egal auf welcher Sprosse Du aktuell stehst.

Vielen Dank fürs zuhören 

Tschüß

dein agilophiler Frank

Agilophil-Daily Podcast Episode 16: Komplexität

Herzlich Willkommen zu einer neuen Folge vom agilophil-daily Podcast – hier erfahrt ihr alles, oder zumindest vieles, was sich mit dem Themenbereich „Agilität“ auseinandersetzt….Ich war gerade vor ein paar Tagen, also kurz nach der Wiedereröffnung der Läden nach dem Corona-Lock-Down hier in Berlin, in einem kleinen Geschäft um ein paar Schrauben zu kaufen…ich kam mit dem Verkäufer wahrscheinlich auch Ladenbesitzer kurz ins Gespräch – natürlich ging es wieder um das C-Wort.PAUSE..Er war nicht wirklich begeistert von der ganzen Situation und sein Fazit war „Wir werden alle verarscht“… nun ja – ich kann natürlich seine Verärgerung über die ganze Situation nachvollziehen, und begann, als ich aus dem Laden kam, mal drüber nachzudenken…Was meint er eigentlich damit?

Wir werden alle verarscht…- natürlich – weiß ich schon, was er meinte – er meinte, dass die Maßnahmen gegen das Coronavirus übertrieben gewesen seien…aber wer sollte uns denn verarschen? Wenn jemand jemanden verarscht, muss er doch einen Vorteil davon haben. Hat irgendein Virologe oder Politiker oder die Industrie einen Vorteil davon, wenn es der Wirtschaft im Land schlecht geht? ich denke nein…daher kam ich auf einen Gedanken…und daher wird die Folge heute mal etwas philosophischer…

Was ist das Leben?

Wie funktionieren wir Menschen?

Wie denken wir?

Wozu sind wir auf der Welt?

Wenn wir uns Fragen wie diese stellen, fällt es uns schwer eine Antwort zu finden. Warum? Was ist denn so schwierig daran die Frage nach dem Leben zu beantworten? – Alles, was wächst, lebt? – ist es das? – alles wo Stoffwechsel stattfindet, lebt – vielleicht auch das? – 

-Komplexität-…..ist das Thema der heutigen Folge

Als komplex bezeichnen wir etwas, das vielschichtig, verwoben, verflochten zusammenhängend und nicht auflösbar erscheint….und viele verschiedene Dinge umfasst….und aus vielen verschiedenen Dingen zusammengesetzt ist, die ineinandergreifen und nicht alleine für sich auftreten… und etwas, das sehr umfassend ist und deren Strukturen und Abhängigkeiten nicht sofort zu erkennen sind…es ist also etwas diffuses, zusammenhängendes, was zwar klar als ein System zu erkennen ist – also ein irgendwie abgeschlossenes Ganzes, in dem aber so viele Elemente zusammenarbeiten und wir auch nicht wissen, wie sie das genau tun. Bemerkenswerter Weise gibt es auch noch komplexe Systeme, die von der Umwelt lernen können und sich anpassen an äußere Gegebenheiten – diese nennt man dann adaptiv….uiuiui…..wenn ich darüber nachdenke, sind komplexe Syteme Wunderwerke, die wir nicht verstehen. Wir können allerdings ihr Verhalten in gewissen Grenzen verstehen – in dem wir beobachten und Erfahrungen sammeln. Manche dieser Systeme verhalten sich in gleichen Situataionen auch gleich oder zumindest ähnlich und so können wir Schlüsse daraus ableiten, auch wenn wir nicht verstanden haben, wie das System eigentlich genau funktioniert.

Diese eben genannten Definitionen habe ich mir aus verschiedenen Quellen zusammengesucht und verbunden – Du sieht daraus eins- selbst die Definition des Begriffes Komplexität ist offensichtlich eine komplexe Anglegenheit – …

Und jetzt schau Dich mal um… wieviele komplexe Systeme siehst Du um dich herum? Welche Beispiele hast Du? – Fangen wir mal einfach an – ich behaupte, der Mensch ist ein komplexes System – das behaupte ich nicht nur, das weiß ich: ein wahres Wunderwerk und wenn Du mal darüber nachdenkst, was diese Kombination aus Kohlenwasserstoffen – organischer Chemie mit ca. 80% Wasseranteil und einem Verbund an symbiotisch miteinander funktionierenden Bakterien  (die wir z. B. zur Verdauung brauchen) und elektrischer Impulse in den Nervenbahnen so zustande bringt und vermag, dann erstarre ich in Ehrfurcht vor mir selbst. Das Gehirn allein ist ein biologischer Supercomputer, der zur Zeit der Entstehung – also noch vor der Geburt  – bereits damit beginnt sich selbst zu programmieren, indem neuronale Verbindungen selbstorganisiert aufgebaut werden, die uns dann in die Lage versetzten unseren eigenen Körper mit unserem Willen zu steuern. – Hebe mal Deinen rechten Arm – siehst Du? – es funktioniert…jetzt erkläre mal genau, wie du das machst…das ist eigentlich in seiner Gänze schon fast unmöglich…also –  wie wird der Gedanke im Kopf geformt? – wie kommt die Informationen über die Nervenbahnen in den Muskeln an – wie wird genau zurück gemeldet, in welchen Maßen sich der Arm bewegt, wann weißt Du wann Du mit der Bewegung aufhören musst…Allein die Grobmotorik und die Feinmotorik zusammen belegen ca. 2/3 der Gehirnkapazität. Dazu kommt das Denken: es gibt das Bewusstsein – sozusagen der Teil im Hirn, den wir von uns selbst kennen, der unser Denken bestimmt, unsere Meinungen und unser Wissen umfasst also das, was sich im präfrontalen Kortex abspielt. Und dann kommt das Unbewusste dazu: Das, was wir gar nicht bewusst wahrnehmen, was uns aber in die Lage versetzt aus dem absoluten Informationsoverkill, der von unseren Sinnen in unserem Hirn ankommt, nur den Teil wahrzunehmen, der für uns relevant ist und daher letztlich dafür sorgt, dass wir überlebensfähig sind, da wir sonst keine Einordnungen und Priorisierungen und Bewertungen treffen könnten – wir letztlich nicht in der Lage wären die Welt um uns herum verstandesgemäß wahrzunehmen und zu  erkennen…. 

Wenn wir einen größenmäßigen Vergleich von Bewusstsein zum Unterbewusstsein machen wollten – angenommen unser Bewusstsein ist so lang wie eine Hand – mal grob gemessen 15cm – dann umfasst das Unterbewusstsein ein Strecke von 15km – also 0,15m zu 15.000m – welch unglaubliche Größe da „unter uns“ schlummert ist schon schwer vorstellbar…eine andere, gar nicht mehr zu fassende Größe ist die Zahl 5,8 Millionen Kilometer…5,8 Millionen Kilometer ist die Strecke, die sich ergeben würde, wenn man alle Nervenbahnen eines erwachsenen Menschen aneinander legen würde…irre, oder? – Das ist ca. 15 mal die Entfernung zwischen Erde und Mond – und das in jedem einzelnen von uns. 

So und jetzt stelle Dir mal vor, 11 von diesen komplexen Systemen bilden ein neues System und verfolgen ein gemeinsames Ziel…Das nennt man dann Fußball  – oder 9 komplexe Syteme bilden ein anderes komplexes System und arbeiten zusammen auf dem Weg zu einem Sprintziel – das nennt man dann Scrum-Team…

Wenn wir uns das mal auf der Zunge zergehen lassen und vor dem Hintergrund mal drüber nachdenken – welche Aufgaben, welche Systeme und welche Konstellationen sind dann eigentlich nicht komplex?

Technische Systeme, Maschinen, Autos, mechanische schweizer Uhren – das sind Systeme, die genau beschreibbar und verstehbar sind. Hier ist klar, welche Reaktion eintritt, wenn man etwas ändert oder wenn ein Teil nicht funktioniert – jedes Teil hat eine klar bekannte Aufgabe, die es erfüllt – wenn etwas nicht funktioniert, kannst du klar die Ursache herausfinden und das defekte Teil austauschen, und danach wird die Maschine wieder funktionieren oder wenn und aber. Diese Systeme sind kompliziert – oder vielleicht auch einfach. Klare Ursache-Wirkungs-Beziehungen und vorhersehbare, klare Ergebnisse.

Aber alles andere ist komplex oder auch chaotisch…Software ist so ein Grenzbereich – die Softwareerstellung ist ein komplexer Prozess – die Software selbst ist mindestens ein kompliziertes System. Aber auch Softwaresysteme können komplex werden, wenn mehrere Komponenten  – also Einzelsysteme miteinander verbunden werden. Dann kann nicht mehr klar vorhergesagt werden, wie sich der Systemverbund verhält, wenn sich einzelne Subsysteme ändern…

Allerdings benehmen wir uns oft so, als ob wir nur von maximal komplizierten Systemen umgeben wären…irgendwie hat sich seit Mitte des 19. Jahrhunderts eine Meinung durchgesetzt, dass wir die Welt verstehen könnten, als wäre sie eine Maschine – Das hat sich beispielsweise auch auf die Medizin übertragen – Der Arzt ist der Mechaniker des Körpers – immer wenn etwas krank ist, gibt er eine Pille und danach läuft der Motor wieder. Oder es wird mal eben die Motorhaube aufgemacht und ein wenig dran rumgeschnippelt – und dann kann die Maschine wieder laufen. Wir erwarten immer, dass Experten alles wissen müssen und immer den Verlauf von Maßnahmen exakt voraussagen können sollen…dafür sind sie ja schließlich Experten – Obwohl ich das Wort ja nicht weiter strapazieren wollte, sehe ich das ganz besonders deutlich im Moment in der Corona Krise: Von den Virologen wird klar erwartet, zu wissen welche Maßnahmen helfen. Von den Politikern wird erwartet, dass sie Maßnahmen nur dann einleiten oder auch wieder aufheben, wenn ganz sicher ist, dass sie auch wirken oder eben welchen Effekt diese Maßnahmen haben…Seltsam, dass in den vielen Fernsehdiskussionen Virologen unterschiedliche Meinungen haben…auch Politker sind sich nicht einig – die müssen ja dann Idioten sein und verstehen vielleicht von ihrem Fach nichts…

Nein – das liegt daran, dass wir es hier mit einem komplexen Problem, zu tun haben, so wie wir es überhaupt bei den meisten Problemen der Fall ist –  dazu zählt dann auch das Projektmanagement. Wir haben es hier mit komplexen Problemen zu tun haben, bei denen Ursache und Wirkung eben nicht exakt voraussehbar ist…

Wir können nur experimentell vorgehen, um komplexe Probleme zu lösen – Anhand der Ergebnisse können wir lernen und weitere Experimente daraus ableiten…Das ist normal

Für Corona heißt das: Alle Maßnahmen und Entscheidungen, die eingeleitet oder getroffen wurden und noch werden, haben den Status von Experimenten…Keiner kann sagen, ob etwas richtig ist…das ist schlicht unmöglich…Und daher kann das auch keiner erwarten – Wir müssen letztlich davon ausgehen, dass zum Zeitpunkt der Entscheidung für oder gegen eine Maßnahme alles zur Verfügung stehende Wissen und guter Wille und Absicht eingesetzt worden sind, um diese Entscheidung zu treffen.  Zum Zeitpunkt der Entscheidung war diese Entscheidung richtig aber auch jede andere Entscheidung wäre richtig gewesen…

Den Effekt und die Auswirkung der Entscheidung sehen wir dann in den nächsten Wochen. Und das ist auch gut so…

Wir hatten bisher halt auch ziemlich viel Glück – ein paar Infektionsherde mehr in Deutschland und eine Situation wie in Italien wäre möglich gewesen oder ein paar Infektionsherde weniger und es liefe so milde ab wie in Schweden – aber alle Länder haben recht mit den Entscheidungen in ihrer jeweiligen Situation. So können wir auch als Vorteil sehen, dass wir eine Förderale Demokratie sind – die Länder können unterschiedliche Experimente durchführen und wir alle lernen voneinander. Die liberale und freizügige Aufhebung von Beschränkungen in einem Bundesland kann wichtige Erkenntnisse bringen – entweder es geht gut – dann hat das Bundesland „recht“ gehabt, oder es geht nicht gut, dann haben wir alle wichtige Erkenntnisse daraus gewonnen und können die anderen Bundesländer wissen, dass sie in ihrem Vorgehen effektiver waren. 

Auch – um hier mal wieder die Brücke zurück zu unserem agilen Themengebiet zu schlagen- im Projektmanagement sehen wir oft die gleiche Erwartungshaltung. Vom Projektmanager eines IT-Projekts wird erwartet, dass er sein Projekt plant, wie einen Hausbau. Der Hausbau ist allerdings eine komplizierte Aufgabe – komplex wird es erst, wenn wirklich was passiert,was nicht vorhersehbar wir – wie Bodenverwerfungen durch alte Bergwerksanlagen vieleicht, oder die beteiligten Firmen keine Erfahrung mit dem Bau von Gebäuden haben – in nenne hier mal den Berliner Flughafen als Beispiel – aber ansonsten ist ein Hausbau etwas, was die beteiligten Firmen schon einige Male geübt haben dürften und damit eine genau planbare Aufgabe mit einem erwartbaren Ergebnis. Softwareentwicklung ist eine komplexe Angelegenheit, da die Entwicklung von Software eine individuelle Leistung für einen speziellen Kunden oder ein neues Produkt ist. 

Fazit und darauf will ich eigentlich hinaus. Ich habe das Gefühl, dass wir zu einfach denken in unserer komplexen Welt. Die Welt ist komplex, war sie immer und wird sie immer bleiben. Wir sollten, nein – wir müssen das anerkennen um schädliche Diskussionen zu vermeiden, die letztlich zu nichts führen. Wir müssen Exprerimente zulassen und zu der Erkenntnis kommen, dass das das probate Mittel ist, um Probleme und Aufgaben zu lösen – und zwar die meisten. Die wenigsten Aufgaben sind kompliziert oder einfach – die meisten sind komplex. Darum sind ja auch Mannschaftssportarten so faszinierend, da alle Aktionen eines Trainers immer nur Experimente darstellen und er nie weiß, ob es funktioniert – denn neben dem hochkomplexen  System aus 11 komplexen Einzelsystemen (also seine Mannschaft) spielt ja auch noch ein zweites hochkomplexes System aus 11 weiteren Einzelsystemen mit, die ihre eigenen Taktik haben..

Wer will da denn noch was vorhersagen?

ich nicht…

soweit mit dieser etwas außergewöhnlichen Folge des agilophil-daily Podcasts – ich hoffe, sie hat Dir Spaß gemacht und regt dich zum philosophieren an…oder war einfach nur interessant…

Vielen Dank fürs Zuhören und viel Erfolg bei den anstehenden Experimenten

wünscht Dir

Dein agilophiler Frank