Andon

Bild: Pxhere - CC0 1.0

Zu den grossen Inspirationsquellen für jeden der seinen agilen Prozess verbessern will gehört zweifellos das Toyota Production System (TPS). Selbst wenn es ursprünglich für die Industrieproduktion von Autos vorgesehen war enthält es zahlreiche Elemente, die auch in der Software-Programmierung oder Wissensarbeit von Nutzen sein können. Eines dieser Elemente ist das so genannte Andon (行灯, übersetzt rote Laterne, bzw. Papierlaterne).

Unter diesem Begriff versteht man Systeme oder Prozesse mit denen ganze Produktionsketten (in der Regel Fliessbänder, aber auch alles andere) schlagartig zum Stillstand gebracht werden können sobald ein Fehler auftritt. In den meisten Fällen erfolgt das durch Zugschnüre oder grosse Druckknöpfe (auch bekannt als Toyota-Buttons) die überall entlang der Fertigungsstrassen zu finden sind. Im weiteren Sinn gehören auch Signaltöne und Datenerfassungssysteme zu den Andon-Installationen dazu.

Bemerkenswert sind an diesem Konzept vor allem zwei Aspekte. Zum einen wird das Wesen eines Fehlers hier anders verstanden als üblich. Der Fehler ist nicht mehr die Beschädigung oder Minderwertigkeit des "fehlerhaften" Produkts sondern die Dysfunktion des vorhergegangenen Herstellungsprozesses. Dementsprechend folgt auf das Anhalten der Produktionskette auch eine Neukonfiguration des Prozesses und nicht eine Reparatur des Produkts (die soll überflüssig werden).

Zum anderen sind die Zugschnüre oder Druckknöpfe nicht nur überall angebracht sondern auch für jeden zugänglich - und es hat auch jeder die Berechtigung sie zu benutzen. Darüber hinaus ist ihre Benutzung auch prinzipiell nicht mit negativen Folgen verbunden, auch dann nicht wenn der Produktionsausfall auch Gewinnrückgänge nach sich zieht. Es soll alles vermieden werden was von ihrer Benutzung abhält, damit nichts der Idee einer möglichst fehlerfreien Auslieferung im Weg steht. Die Idee dahinter: der langfristige Nutzen ist weit grösser als ein kurzfristiger Verlust.

Übertragen auf die Softwareentwicklung wären vor allem die Tolerierung "unkritischer Bugs" oder die dauerhafte Durchführung zu vieler (potentiell fehlerhafter) manueller Prozesse Gründe für das Auslösen eines Andon-Systems. Da derartige Verhaltensmuster fast immer die Durchführung von langen, nachgelagerten Regressionstest- und Bugfixing-Phasen zur Folge haben verhindern sie die kontinuierliche Auslieferung von Geschäftswert und sind damit kritisch genug für einen Produktionsstop.

Das Gegenargument ist an dieser Stelle das selbe wie in der Fabrik: "Aber damit verhindert man doch das Einhalten der Produktionsquote, bzw. der Deadline!" Allerdings ist das nur bedingt richtig. Wenn zwar die Menge und das Zieldatum stimmen, die Arbeitsergebnisse aber defekt sind, dann ist der Erfolg nur ein scheinbarer. In Wirklichkeit sind Kosten und dauer sogar höher, sie werden nur in späteren Phasen versteckt.

Um das nicht geschehen zu lassen macht ein roter Knopf an jedem Arbeitsplatz absolut Sinn.

Rebound-Effekt

Grafik: Public Domain Pictures / Witali Smoligin - CC0 1.0

In Change-Vorhaben (egal ob agil oder klassisch) gibt es Phänomen das gleichermassen häufig wie ärgerlich ist: ineffektive Prozesse haben in der Vergangenheit dazu geführt, dass sich vor den umsetzenden Einheiten (Fertigung, IT, etc) ein Rückstau gebildet hat, dessen Sichtung und Verwaltung Ressourccen bindet und zu Bürokratie führt. Prozessverbesserungen sollen helfen diesen Stau durch schnellere Bearbeitung abzubauen, und tatsächlich wird der Durchsatz erheblich gesteigert. Und trotzdem: die Menge an wartender, unerledigter Arbeit bleibt gleich.

Die dahinter stehende Ursache ist der so genannte Rebound-Effekt. Ursprünglich aus der Energiewirtschaft kommend lässt er sich folgendermassen beschreiben: ein Verbraucher konsumiert eine bestimmte Ressource. Eine Effizienzsteigerung des Ressourcenverbrauchs sorgt dann dafür, dass der Verbraucher weniger konsumieren muss als bisher. Da sein Budget aber unverändert bleibt benutzt er die frei gewordenen Mittel um zusätzliche Ressourcen zu konsumieren, wodurch der Gesamtverbrauch gleich bleibt.

Dieses Phänomen lässt sich auf Fertigungsprozesse übertragen. In der alten, ineffizienten Prozesswelt hatten der Produktion vorgelagerte Einheiten (Vertrieb, Innovation, etc.) einen doppelten Aufwand: sie mussten zum einen neue Anforderungen erstellen und zum anderen den sich anstauenden Berg der fertigen, aber auf die Umsetzung wartenden Anforderungen dokumentieren, aktuell halten und umpriorisieren. Wenn dieser Berg jetzt durch effizientere Produktionsprozesse verschwindet haben die vorgelagerten Einheiten plötzlich mehr Zeit, die sie nutzen können um noch mehr Anforderungen ins System zu geben, durch die sich trotz der schnelleren Abarbeitung ein neuer Stau bildet, der neue Bürokratie generiert.

Da eine solche Entwicklung sämtliche effizienz- und effektivitätssteigernden Massnahmen wirkungslos machen kann ist ein Gegensteuern dringend nötig. Die zunächst einfach klingende Massnahme: die Menge der neuen Anforderungen darf nur so stark steigen, dass kein neuer Rückstau entsteht. Der Fachbegriff dafür ist das Work in Progress Limit. Das umzusetzen kann aber zu einer Herausforderung werden, da die freigewordenen Kapazitäten ja auch nicht ungenutzt bleiben sollen. Die Konsequenzen (Versetzungen, Umschulungen, Personalabbau in den vorgelagerten Einheiten  oder Personalaufbau in den nachgelagerten Einheiten) sind schwerwiegend, zur Vermeidung des Rebound-Effekts aber nötig.

Denn sie wissen nicht, wen sie rekrutieren (IV)

Bild: Flickr / Amtec - CC BY-SA 2.0

Angeregt vom neuesten Artikel des geschätzten Marcus Raitner wird es Zeit die etwas eingeschlafene Reihe "Denn sie wissen nicht, wen sie rekrutieren" wieder fortzuführen. Im Artikel geht es um die (autobiografische?) Geschichte eines Menschen der sich zum ersten mal im Leben bei einem Konzern bewirbt, und von seinem Befremden angesichts der ihm dort begegnenden Formalismen und Bürokratien. Obwohl er natürlich nur einen Einzelfall beschreibt ist er symptomatisch für ein grundlegendes Phänomen.

Seit auch die grossen Organisationen die Agilität für sich entdeckt haben (und umgekehrt) prallen bei den Ausschreibungs- und Einstellungsprozessen zwei Welten aufeinander. Auf der einen Seite die Personalabteilungen, die mit grösster Selbstverständlichkeit davon ausgehen, dass das "seit langem bewährte" Vorgehen auch weiterhin das Richtige ist, auf der anderen Seite die in der agilen Bewegung sozialisierten Fachkräfte, die diesen von ihnen als anachronistisch empfundenen Routinen mit Fassungslosigkeit gegenüberstehen.

Beide Sichtweisen lassen sich nachvollziehen. Die Personalstellen sind jahrzehntelang durch Taylorismus und (Pseudo-)Lean Management so optimiert worden, dass sie die eingehenden Bewerbungen in möglichst einheitlichem Format erwarten. Das ist schliesslich die Voraussetzung dafür, dass sie alle möglichst schnell den selben Bearbeitungsvorgang durchlaufen können. Branchenerfahrung? Check. Führungserfahrung? Check. Budgetverantwortung? Check. Ab in die zweite Auswahlstufe. Um sich jeden Kandidaten genau anzusehen fehlt einfach die Zeit.

Darüber hinaus sind sie (oft unbewusst) in einen beruflichen Standesdünkel hineinsozialisiert worden. Bei einem Automobilbauer zu schaffen, Banker zu werden oder bei einem Verlag zu arbeiten ist Errungenschaft und Ehre, dafür soll sich der Bewerber ruhig anstrengen, und zwar so, dass man es sieht. Mit makellosem Lebenslauf und überzeugenden Argumenten warum man denn gerade ihn nehmen sollte. Flüssig formuliert, ansprechend formatiert und auf hochwertigem Papier eingereicht bitteschön.

Auf der anderen Seite die vom Fachkräftemangel selbstbewusst gemachten Bewerber. Im eigenen Projektportfolio steht doch übersichtlich und nachvollziehbar drin was man gemacht hat, welchen Wert soll es haben das chronologisch anzuordnen? Und dann die Kategorien. Budget- und Führungsverantwortung sind doch für Lead Developer und Scrum Master irrelevant. Und warum gibt es trotz so vieler geforderter Pflichtangaben keine in die die Mob Programming Skills und der Link zum eigenen Open Source-Projekt passen würden?

Auch der Standesdünkel ist da, allerdings umgekehrt. Konzern? Allein der Begriff klingt schon nach Cobol. Da kann man gespannt sein ob die auch nur annähernd den gleichen Techstack bieten können wie das Fintech in der Innenstadt. Und hoffentlich halten die nicht an solchen Relikten des 19. Jahrhunderts fest wie Krawatten und festen Arbeitsplätzen. Zumindest kann man ja wohl erwarten, dass für Bewerbungen auch eine 40 Jahre alte Technologie wie die Email akzeptiert wird.

Sollte es dann trotz all dieser Hindernisse doch zu einem Job-Interview kommen, werden die Differenzen häufig erst richtig sichtbar. Während die Konzern-Seite davon ausgeht, dass der Bewerber hier nach seiner Lebensstellung sucht will dieser nur "ein paar spannende Jahre" erleben, und während die Personalerin stolz von der Betriebsrente und der Betriebssportgemeinschaft erzählt will ihr Gegenüber über Homeoffice und Slacktime reden. Das alles gerinnt in Wortwechseln wie diesem hier: "Wo sehen sie sich in drei Jahren?" "Keine Ahnung, so lange will ich hier nicht bleiben."¹

Bis vor nicht allzulanger Zeit hätten diese Differenzen dazu geführt, dass diese "unpassenden" Bewerber einfach aussortiert wurden. Aber das ist vorbei, die zunehmende Agilisierung, Digitalisierung, Automatisierung und Cloudifizierung sorgt dafür, dass grosse Firmen froh sein können wenn sie ihren Bedarf überhaupt gedeckt bekommen. Und jetzt stehen die Personalabteilungen vor einem Problem: nicht nur können sie die Ansprüche der begehrten Fachkräfte kaum befriedigen ohne die eigenen, "seit langem bewährten" Vorgehensweisen in Frage zu stellen, oft wissen sie gar nicht welche Ansprüche das sind. Und dann das Schlimmste: sobald diese ermittelt wurden ändern sie sich.

Um die in der agilen Bewegung sozialisierten Arbeitnehmer verstehen zu können und um auf ihre Ansprüche eingehen zu können bleibt den Personalern letztendlich nur ein Weg übrig: selbst agil werden. Das ist nicht immer einfach und nicht immer angenehm, wenn es nicht stattfindet drohen aber immer mehr Geschichten wie die von Marcus Raitner. Und dann mit der Pointe dort nicht angeheuert zu haben.


¹Der Verfasser dieser Zeilen war amüsierter Zeuge.

You need to stop implementing someone elses model

Ein mitreissend vorgetragener Vortrag mit einigen bedenkenswerten Ideen, aber auch einer bei dem Sander Hoogendoorn es sich sehr einfach macht. Irgendwo zwischendrin sagt er, dass er nicht für grosse Firmen arbeitet - damit braucht er sich folgerichtig auch nicht damit beschäftigen, dass vieles von dem was er vorstellt (kurz gesagt: Strukturen abschaffen) dort nicht funktionieren würde. Trotzdem ein sehenswerter Auftritt. Und er sagt es selbst: man sollte ohnehin nicht einfach die Ideen anderer Leute zu sich übernehmen sondern vorher überprüfen ob sie in der aktuellen Situation passen.

FLEAT - die agile Flotte

Bild: Wikimedia Commons / U.S. Department of Defense Current Photos - CC0 1.0

Viel Neues tut sich in den letzten Jahren nicht mehr im Bereich der Agilität. Seit der Vorstellung von Nexus im Jahr 2015 hat es keine nennenswerten Versuche mehr gegeben ein neues Vorgehensmodell zu entwickeln, weshalb im letzten Monat die Einladung zum Kölner PO-Meetup sofort Aufsehen erregt hat.

Dieses Mal geht es um "FLEAT", ein neues agiles Enterprise Framework: Das Enterprise-Unternehmen als Flottenverband ... eine vielversprechende Metapher. Das Buch von Thorsten Schaar und Uwe Habicher dazu kommt gerade in den Handel. Praktiziert wird FLEAT bei haufe schon. Aber was steckt dahinter?

Freundlicherweise hat Uwe mir im Anschluss auch ein Exemplar seines Buches zukommen lassen, das ich in letzter Zeit durchgelesen habe und jetzt besprechen kann.

Was ist FLEAT?

Ein bei Haufe-Lexware erfundenes agiles Framework, dessen Name unabgekürzt "Fluid Enterprise Agility Transformation" lautet. Was es interessant macht: es konzentriert sich auf einen Bereich der von den gängigen Ansätzen noch nicht besetzt ist. Während es in Scrum, SAFe, Nexus und LeSS um Lieferzyklen, Rollen und Meetings geht, in Design Thinking um Kreativität, in Kanban um die Optimierung von Arbeitsflüssen und in XP um technische Praktiken steht bei FLEAT etwas anderes im Vordergrund: Investitionsentscheidungen.

Die verschiedenen "Schiffstypen"

Je nach Fortschrittsgrad wird unterschieden zwischen der Startbahn, dem Floss, dem Ruderboot, dem Dampfschiff und dem Kreuzfahrtschiff. Ideen für ein neues Fahrzeug darf dabei jeder im Unternehmen haben, ob darin investiert wird ist aber eine Management-Entscheidung. Die Investition in die Startbahnphase besteht noch aus der Arbeitszeit die den Mitarbeitern für die Ausarbeitung von Ideen zur Verfügung steht, das Floss enthält eine Frühfinanzierung (die ggf. klein genug für eine schmerzfreie Abschreibung ist), das Ruderboot erhält bereits in nennenswertem Ausmass Ressourcen, das Dampfschiff ist schon eines der wichtigen Investments, das Kreuzfahrtschiff ist gross genug um Kern einer eigenen, neuen Flotte zu werden.

Wer ist die Zielgruppe?

Auf den ersten Blick "Leute mit Budget". Ob das die Geschäftsführung ist, der Chief Innovation Officer oder sonst jemand - er muss die Investitionen tätigen (und ggf. die Verluste verantworten) können auf denen der Ansatz beruht. Hier liegt eine Stärke von FLEAT, da sich diese Gruppe in den anderen, eher operativen Frameworks nicht immer wiederfindet. Auf den zweiten Blick stehen aber auch die Mitarbeiter im Mittelpunkt, denen es durch das Einbringen und Verwirklichen von ihren Ideen ermöglicht wird zu Intrapreneuren zu werden.

Ist das denn agil?

Ja, ist es. Es mag eine andere Art der Agilität sein als die die man mit Scrum, Kanban, XP und den Skalierungsframeworks verbindet, es hat aber das entscheidende Element: Reaktionsgeschwindigkeit. Neue Ideen sollen schnell aufgegriffen werden, schnell validiert werden und schnell (und früh) scheitern können - überwiegend schon in den frühen Phasen. Um das zu erreichen sollen die "Schiffe" an den aus anderen Frameworks bekannten Prinzipien ausgerichtet sein: kundenzentriert, End-to-End-verantwortlich, autonom, sich kontinuierlich verbessernd, etc.

Ist es wirklich neu?

Nur eingeschränkt. Die Idee durch die Investition in kleine, innovative Einheiten das Risiko von grösseren Verlusten zu minimieren ist aus Ansätzen wie der Effectuation schon länger bekannt, Konzepte wie Intrapreneurship und Minimum Viable Products (möglichst früh validierbare Produktumfänge) kommen auch im Lean Startup vor, autonome und crossfunktionale Teams gibt es auch in Scrum, bzw. seinen Skalierungsframeworks. Was man FLEAT lassen kann ist, dass diese Elemente zu einem in sich konsistenten Ganzen paketiert wurden. Und was ist schon wirklich neu?

Gibt es Probleme?

Wo gibt es die nicht? Ins Auge springt vor allem, dass die Mitarbeiter in den frühen Evolutionsstufen (Startbahn, Floss, Ruderboot) nur in Teilzeit für das Vorhaben arbeiten und in der restlichen Zeit in ihren bisherigen Jobs. Die damit verbundenen Effizienzverluste (durch Kontextwechsel, Terminüberschneidungen, Priorisierungskonflikte, etc.) haben dazu geführt, dass derartige Arbeitsmodelle in der agilen Bewegung eigentlich verpöhnt sind. Auch die geringe Kompatibilität mit den typischen Organisationsprinzipen von Konzernen (organisatorische Silos, "mittelfristige" Finanzplanung, funktionale Querschnittsorganisationen) dürfte eine Herausforderung werden. Und die angestrebte Kommerzialisierung (siehe hier) dürfte bei weiten Teilen der anti-komerziell entstandenen agilen Community zu Abstossungsreaktionen führen.

Wie gross/erfolgreich wird FLEAT werden?

Eine spannende Frage. Sicherlich würde vielen Firmen dieser Ansatz mehr als nur gut tun (und das Ansetzen an der Finanzierung hätte eine gewaltige Hebelwirkung), die zuvor genannten Probleme dürften aber in den meisten Fällen beachtliche Hindernisse für eine öffentlichkeitswirksame Umsetzung sein. Sollte trotzdem eine gelingen wäre das ein Verkaufsargument auf dem sich aufbauen liesse. Eine "Massenbewegung" wie Scrum oder Kanban dürfte aufgrund der oben genannten anti-komerziellen Reflexe zwar auch dann nicht entstehen, aber vielleicht muss es das auch gar nicht. Und selbst wenn es nur dazu kommen sollte, dass FLEAT als weitere verfügbare Alternative dafür sorgt, dass "Enterprise Agility" nicht mehr automatisch mit SAFe gleichgesetzt wird - allein das wäre ein grosser Fortschritt.

Ein Bild sagt mehr als 1000 Worte (XXVI)

Stack Overflow releases its own keyboard. pic.twitter.com/Nw7ts0Rf4V

— Khalil Sehnaoui (@sehnaoui) June 21, 2019

Kommentierte Links (XXXXXI)

• DACH30: Agile Rollen - Kompetenzen

Wenn man auf die Verbreitung, das Verständnis und die Akzeptanz agiler Vorgehensweisen blickt gibt es im deutschsprachigen Raum zunehmend Grund zum Optimismus. So auch hier: Vertreter von über 50 Unternehmen aus Deutschland, Österreich und der Schweiz haben gemeinsam versucht Mindeststandards für agile Rollen aufzustellen, mit einem Ergebnis das sich sehen lassen kann. Für die (Framework-neutral benannten) Rollen des Team Facilitators, des Value Verantwortlichen, des Umsetzungsteams und der Agilen Führungskraft gibt es jetzt grundlegende Tätigkeitsbeschreibungen und Shu Ha Ri-Stufen. Sollte sich das so durchsetzen wäre damit einen grosser Schlag gegen die Verbreitung von Cargo Cult gelungen.

• Ron Jeffries: Fixed-Everything - Agile?

  Keine andere Website kommt so häufig in den kommentierten Links vor wie die von Ron Jeffries, und das aus gutem Grund. In gewohnter Weise eloquent und langatmig erörtert er die Frage ob es innerhalb eines "eisernen Dreiecks" aus unveränderbarem Umfang, Zeitrahmen und Budget noch Agilität geben kann. Seine Antwort: ja. Was man an dieser Stelle allerdings anmerken muss - er beschreibt hier die gelebte Realität, in der es eben doch zu der teilweisen Aufweichung der drei Dimensionen kommt. Dann wiederum - womit, wenn nicht mit der Realität, soll er sich auch auseinandersetzen? Ein echtes eisernes Dreieck ist schliesslich ähnlich häufig wie ein Albino-Panda.
  

• Joe Dunn: Tribes And Tribal Conflicts In A Tech Company

  Der Mensch ist ein irrationales Wesen, trotz aller Zivilisiertheit getrieben von Instinkten, Gruppendynamiken und unbewussten Verhaltensmustern. Das zu erkennen gehört zu den Voraussetzungen guter Organisationsentwicklung, und zu diesen Erkenntnissen gehört auch die, dass grosse Organisationen in "Stämme" zerfallen die ähnliche Konflikte austragen wie vor langer Zeit ihre Vorfahren. Statt den Goten, Langobarden und Vandalen stehen sich heute Vertrieb, IT und Rechtsabteilung gegenüber und begegnen sich mit Vorurteilen und Feindseligkeit. Joe Dunn versucht sich an der Deutung interner Auseinandersetzungen als Stammeskonflikte und an der Frage wie sie aufzulösen sind. Und das Ganze hat nichts mit Spotify zu tun.

• J. Meadows: Waste Not, Want Not - A Simplified Value Stream Map for Uncovering Waste

  Ein Blick auf die Lean Management-Seite der Softwareentwicklung. Ausgehend von den Mudas des Toyota Production System stellt J. Meadows zwei fiktive Unternehmen einander gegenüber: Wasteful Inc. und Efficient Inc. Ein schönes Beispiel für die Möglichkeiten des Flussoptimierung, aber auch eines das mit Vorsicht zu betrachten ist. Bei zu unbedachter Weiterverwendung droht die grosse Gefahr des Lean Management: dass auch ein vom Markt gar nicht nachgefragtes Produkt immer schneller und effizienter produziert wird, mit genau dem Ergebnis das eigentlich vermieden werden soll - Waste.

• Dagmar Bott: Agiles Bar Camp – oder einfach Agile Session Time

  Bar Camps und Open Spaces gelten als eines der besten Werkzeuge für die selbstorganisierte Durchführung von (Un)Konferenzen, Workshops und Wissenstransfer-Veranstaltungen. Wie das in der Praxis aussehen kann erklärt Dagmar Bott anhand der in ihrem Unternehmen stattfindenden Agile Session Time. Ein Ansatz den man jeder anderen Firma sehr zur Nachahmung empfehlen möchte. Um die Klammer zum ersten kommentierten Link zu schlagen: auch die zunehmende Etablierung derartiger Formate trägt dazu bei, dass man die agile Transition der deutschen Unternehmenslandschaft mit Optimismus beobachten kann.

Raus aus dem Hamsterrad

Bild: Wikimedia Commons / Mylius - CC BY-SA 3.0

Wenn Scrum irgendwo neu eingeführt wird kann man davon ausgehen, dass es eine der ersten aufkommenden Diskussionen sein wird: müssen denn diese Rollen Product Owner und Scrum Master wirklich sein? Können diese Aufgaben nicht von jemand anderem nebenher gemacht werden? Die Antwort: wenn das Ergebnis wirklich Scrum sein soll, dann nicht. Allerdings nicht als Selbstzweck sondern weil es Sinn macht.

Welcher das ist zeigt sich vor allem dort wo das "nebenher machen" stattfindet, etwa wenn die PO-Aufgaben von einem Business Analysten oder Fachabteilungs-Mitarbeiter übernommen werden und die Scrum Master-Aufgaben von einem Teammitglied. Wie gesagt, nebenher, also zusätzlich zu dem was ohnehin schon zu dem bisherigen Job gehört. Das Ergebnis wird fast immer das gleiche sein - die neuen Aufgaben werden stark vernachlässigt werden. Und das mit gutem Grund.

Der entscheidende Punkt ist hier, dass die Arbeit der Product Owner und Scrum Master im Gegensatz zu der der meisten anderen Mitarbeiter zu einem nicht Grossteil nicht anlassgetrieben ist. Sowohl die Konzeption und Validierung neuer Produktumfänge als auch die Evolution eines Teams in Richtung Crossfunktionalität und Selbstorganisation brauchen in der Regel Monate um umgesetzt zu werden, Sprints oder operative Tätigkeiten erfordern dagegen die Konzentration auf die Gegenwart.

Die Folgen sind immer die gleichen. "Um die langfristigen Themen kümmern wir uns wenn es mal im täglichen Betrieb nicht so viel zu tun gibt" heisst es dann. Dieser Zeitpunkt kommt aber praktisch nie, denn zu tun gibt es immer. Die Verschiebung der PO- und Scrum Master-Themen führt sogar zu mehr Arbeit im Alltag, da die stockende Weiterentwicklung des Teams und die unklare Produktstrategie den Beteiligten immer wieder auf die Füsse fallen und neue kurzfristige Reaktionen erforderlich machen. Ein Teufelskreis.

Um eben das zu verhindern ist es nötig in kurzen, regelmässigen Abständen aus dem operativen Hamsterrad herauszusteigen, einige Schritte zurückzutreten, das Große Ganze auf sich wirken zu lassen und sich Sinn- und Perspektivfragen zu stellen. "Wird das neue Feature wirklich so angenommen wie wir dachten?" "Wird der aktuelle Arbeitsmodus auch in einem Vierteljahr noch so funktionieren?" Etc. Wenn die Antwort darauf unklar ist sollten auch die anderen Teammitglieder aus dem Rad herausgeholt werden um sie auf das aufmerksam zu machen was von dort aus nicht sichtbar ist.

Den Product Ownern und Scrum Mastern diese Möglichkeit zu geben ist eine der Grundvoraussetzungen dafür, dass Scrum wirklich zum Greifen kommt. Und da das im Rahmen einer Zusatzaufgabe nicht funktioniert sollte die Rolle so eingeführt und ausgestaltet werden wie sie gedacht ist.