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 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 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