Donnerstag, 17. Oktober 2019

Toyota Flow System

FS
Manchmal kommen grosse Neuigkeiten überraschend an. In einem zunächst eher unspektakulären Artikel erwähnt der Forbes-Journalist Steve Denning etwas Bemerkenswertes: nach 70 Jahren hat die Firma Toyota ihr legendäres Toyota Production System (den Ursprung des Lean Management) weiterentwickelt zu etwas Neuem, dem Toyota Flow System. Der Name ist fast gleich geblieben, der Inhalt dagegen hat sich spürbar verändert - es finden sich jetzt deutliche Spuren agiler Frameworks in ihm.

Grafik: Toyota Connected / Thurlow, Turner, Rivera - CC BY 4.0 (zum Vergrößern klicken)
Vor allem in der linken Säule taucht einiges auf was aus der agilen Welt bekannt ist. Scrum, the Toyota Way hat bereits 2018 für Aufsehen gesorgt, und auch andere bekannte Konzepte finden sich hier, etwa Cynefin und OODA-Loops. Die mittlere Säule greift eher Ideen aus dem Coaching-Umfeld auf, wie z.B. psychologische Sicherheit, aktives Zuhören und Mentoring, während die rechte Säule sich auf die sozialpsychologischen und organisatorischen Aspekte der Teamarbeit konzentriert. Zusammen mit den beiden Grundlagen Toyota Way und Toyota Production System kommt ein Gesamtbild zu Stande, dessen Einzelbestandteile es ermöglichen genug Lesestoff für Wochen zusammenzugoogeln. Auf jeden Fall spannend.

Montag, 14. Oktober 2019

Frameworks und Werte

FS
Bild: Wikimedia Commons / ChinaFlag - CC0 1.0
Wer schon einmal in einem Workshop war in dem es darum ging agile Vorgehensmodelle zu erklären oder ihre Einführung vorzubereiten wird dort mit grosser Wahrscheinlichkeit auch über Werte gesprochen haben. Egal ob Extreme Programming (Communication, Simplicity, Feedback, Courage,  Respect), Scrum (Courage, Commitment, Focus, Openness, Respect) oder Kanban (Transparency, Balance, Collaboration, Customer Focus, Flow, Leadership, Understanding, Agreement, Respect) - jedes bekannte Framework betont, dass es wertebasiert ist. Aber warum ist das so?

Die Antwort hat mit genau dieser Selbstbezeichnung zu tun. XP, Scrum & Co legen Wert darauf keine Methoden zu sein sondern Frameworks, wohinter sich ein völlig anderes Konzept verbirgt. Während durch Methoden relativ genaue Vorgaben erfolgen wer wann was mit welchem Ziel zu tun hat wollen die agilen Frameworks genau das vermeiden. Die darunterliegende Annahme: je strikter die Vorgaben desto unwahrscheinlicher, dass sie der komplexen Realität gerecht werden. Im Zweifel schaden sie sogar mehr als sie nutzen, da plötzlich der Plan nicht mehr zur Realität passt.

Um derartige Konstellationen zu vermeiden lassen die Frameworks bewusst grosse Lücken, die jeder so füllen kann wie er es für sinnvoll hält. Beispiele dafür sind Anforderungsformate und die Abnahmen fertiger Arbeit: XP, Scrum und Kanban gehen nicht darauf ein wie sie ausgestaltet sein sollen, jedes Team kann das für sich selbst festlegen. Das daraus entstehende Problem - diese Offenheit bringt das Risiko mit sich, dass versehentlich unflexible und bürokratische Strukturen (wieder)eingeführt werden, etwa indem besonders detaillierte Spezifikationen möglichst früh im voraus verfasst werden, die dann zu erfüllen sind.

Die Lösung für dieses Dilemma sind die zu Beginn genannten Werte. Sich im Zweifel an ihnen zu orientieren lässt den Beteiligten genug Freiraum um den Arbeitsprozess nach ihren Bedürfnissen auszugestalten, zeigt ihnen aber auch wo sie sich von der angestrebten Agilität entfernen. Um beim Beispiel der Abnahmen anhand von lange im voraus verfassten Detailspezifikationen zu bleiben - wer ernsthaft Simplicity, Openness und Balance als Werte verfolgt wird sich von diesem Vorgehen schnell verabschieden.

Um zuletzt einen häufigen Einwand aufzugreifen: natürlich bedeutet das auch, dass der Arbeitsprozess weniger stabil ist und häufiger geändert werden muss, nämlich immer dann wenn er sich aufgrund geänderter Realität plötzlich im Widerspruch zu den Werten befindet. Aber das ist etwas Gutes - es verhindert, dass die Menschen durch unnötige Vorgaben eingeengt werden.

Donnerstag, 10. Oktober 2019

Die agile Filterblase

FS
Bild: Flickr / Serge Melki - CC BY 2.0
Eine Frage die beim letzten bonner Scrumtisch intensiv diskutiert wurde war die: "Befindet sich die agile Community in einer Filterblase?" Natürlich lautet die Antwort im Zweifel immer "Kommt darauf an", aber ganz von der Hand zu weisen ist es nicht - eine Abkapselungstendenz ist da. In dem Punkt waren sich die Teilnehmer einig.

Zunächst zur Begrifflichkeit. Filterblasen sind ein Konzept aus der Kommunikationswissenschaft in dem davon ausgegangen wird, dass durch technische Mechanismen (personalisierte Suchmaschinen) bewussten Medienkonsum (Echokammer) oder unbewusste psychologische Vorgänge (Confirmation Bias) vor allem die Informationen wahrgenommen werden die die eigene Meinung bestätigen. Abweichende Ansichten werden ausgeblendet.

Auf die agile Community übertragen erkennt man deutliche Züge von Filterblasenhaftigkeit. Die bekannteren Agilisten gehen auf die gleichen Konferenzen, lesen die gleichen Autoren, hören die gleichen Podcasts, abonnieren die gleichen Youtube-Kanäle, folgen sich gegenseitig auf Twitter und Facebook und kennen sich untereinander schon seit Jahren. Das lässt sich sowohl auf der internationalen als auch auf der nationalen und lokalen Ebene beobachten und zeigt sich daran, dass viele der eigentlich fachlichen Zusammenkünfte mittlerweise einen Klassentreffen-Charakter haben.

Die damit verbundenen Effekte sind bedenklich: bestimmte Glaubenssätze werden kaum noch hinterfragt (z.B. "mittleres Management ist überflüssig"), bestimmte Vorzeigeunternehmen wie Spotify werden gehypt während andere wie Mercadona trotz hochinnovativer Ansätze nahezu unbekannt sind, die Berührungspunkte zu verwandten Disziplinen wie dem klassischen Projektmanagement nehmen ab, wichtige Themenfelder wie Finance oder Legal werden weitgehend ignoriert.

Das zu ändern liegt bei jedem Einzelnen selbst. Warum nicht mal auf eine Projektmanagement-Konferenz gehen, ein BWL-Buch lesen oder sich mit Lean Manufacturing beschäftigen? Und wenn das zu weit ausserhalb der eigenen Komfortzone ist - warum nicht auf dem nächsten Agile Meetup ein ungewohntes Thema einbringen wie Compliance, Budgeting oder Procurement? Das würde nicht nur zur Weitung des eigenen Horizonts führen sondern auch neue Teilnehmer anlocken. Auch so liesse sich die agile Filterblase öffnen.

Montag, 7. Oktober 2019

ScrumBut und ScrumAnd

FS
Bild: Flickr / David Molloy - CC BY 2.0
So schlicht Scrum auch ist, so viel kann man bei seiner Umsetzung falsch machen. Das meiste davon dürfte unbewusst passieren und den Handelnden gar nicht bewusst sein, also in die Kategorie fallen für die sich der schöne Name Cargo Cult eingebürgert hat. Es gibt aber auch Fälle in denen absichtlich am Vorgehen herumgedoktort wurde. Auch für die beiden hierbei möglichen Varianten gibt es mittlerweile Bezeichnungen: ScrumBut und ScrumAnd.

ScrumBut ist abgeleitet von der Aussage "We do Scrum, but ...", also "Wir machen zwar Scrum, aber ...". Hinter diesem "aber" verbergen sich dann die Einschränkungen denen das Vorgehen unterworfen wurde. "Wir machen zwar Scrum, aber nur auf Teamebene.", "Wir machen zwar Scrum, aber ohne Scrum Master." oder "Wir machen zwar Scrum, aber nur für die IT." sind klassische ScrumBut-Aussagen, wie man sie überall dort wiederfinden kann wo vor einer wirklichen Einführung zurückgeschreckt wurde.

Das irritierende an dieser Variante - selbst bei offensichtlich eingeschränktem Umfang bleiben die an Scrum gerichteten Ansprüche meistens unverändert hoch. Dass auch diese proportional zum Rückbau der Methode sinken müssten wird selten eingesehen, und selbst wenn es erkannt wird kann eine überzogene Erwartungshaltung dazu führen, dass eine ernsthafte Organisationsveränderung blockiert wird. "Das soll erstmal auf Teamebene für Verbesserung sorgen bevor wir es woanders einführen" entspricht etwa der Aussage "Die Glühbirne soll erstmal zeigen, dass sie Licht machen kann, bevor sie Strom bekommt." Kann man so sehen, bringt einen aber nicht weiter.

ScrumAnd geht dagegen ist die genau andere Richtung: Scrum wird zwar wie vorgesehen eingeführt (zumindest weitgehend), gleichzeitig aber mit zusätzlichen Inhalten überfrachtet. Ein Beispiel dafür wäre ein Geschäftsführer, der zusätzlich die Rolle eines Product Owners übernimmt (und aus Zeitmangel fast alle damit verbundenen Tätigkeiten ins Team delegiert). Ein anderes Beispiel wäre die Integration so vieler Randaspekte in die Produktentwicklung (Werbekampagnen, First Level Support, etc.), dass das Team kaum noch focussiert arbeiten kann.

Rein formal lässt sich gegen diese Auslegung in vielen Fällen nichts sagen, der Scrum Guide erwähnt zwar nichts Derartiges, untersagt es aber auch nicht. In der Realität führt eine solche Überladung erfahrungsgemäss aber fast immer zu Reibungsverlusten, Zielkonflikten und Motivationsrückgang. Gleichzeitig kann es auch im Fall von ScrumAnd zu unrealistischen Erwartungshaltungen kommen. "Aber in den Regeln steht doch, dass der PO delegieren darf und dass dass Team crossfunktional sein muss." wäre eine klassische Begründung dafür, auch in solchen Konstellationen reibungslose Performance zu erwarten.

Sowohl bei ScrumAnd als auch im Fall von ScrumBut sind die Erwartungshaltungen auch der Punkt an dem angesetzt werden sollte um an Verbesserungen zu arbeiten. Dass stark beschnittene oder überfrachtete Vorgehensweisen ihre positiven Effekte nicht voll entfalten können wird fast jeder nachvollziehen können, wer an diesen Effekten interessiert ist wird daher erkennen, dass er ein Zurückfahren der Missstände zumindest erwägen muss. Und wer von den alten Strukturen und breiten Aufgabenspektren nicht ablassen kann (wofür es gute Gründe geben kann) dem kann man vermitteln, dass Scrum seinen Ansprüchen nicht genügen wird und er einen anderen Ansatz ausprobieren sollte.

Dass auch ein anderer Ansatz mit hoher Wahrscheinlichkeit an diesen Ansprüchen scheitern dürfte steht dann auf einem anderen Blatt, hat aber mit den beiden hier beschriebenen Scrum-Antipattern nichts mehr zu tun.

Freitag, 4. Oktober 2019

Die fünf Zeitdiebe

FS
Die Ähnlichkeit zwischen den fünf Zeitdieben und den Mudas des Toyota Production System dürfte kein Zufall sein, beiden ist die Herkunft aus dem Lean Thinking deutlich anzumerken. Dementsprechend präsentiert Dominica DeGrandis hier nichts völlig Neues, betrachtet einige Aspekte aber aus einem neuen Blickwinkel.

Montag, 30. September 2019

Kommentierte Links (LIII)

FS
  • Troy Magennis - Story Point Velocity or Throughput Forecasting: Does it matter?

  • In Bezug auf das in der (IT-)Kanban-Bewegung beliebte statistikbasierte Forecasting bin ich gleichermassen Fan und Skeptiker. Natürlich hat eine auf der Story Point-Velocity beruhende Planung grosse Schwächen, von denen Troy Magennis hier einige aufzählt. Zu beachten ist dabei aber: er geht von nicht-idealen agilen Teams aus, die aufgrund nicht gegebener Crossfunktionalität und fehlender Focussierung starke Abhängigkeiten nach aussen haben. Das ist zwar durchaus realistisch, völlig unabhängige Teams sind selten. Umgekehrt wird aber bei dem als Alternative vorgeschlagenen Durchsatz-Modell nicht erwähnt, dass auch das ideale Rahmenbedingungen braucht, z.B. ein stabiles System, in dem Arbeiten nicht abgebrochen werden und in dem das Leistungsvermögen der Teams nicht schwankt. Auch das ist in der Realität aber selten. Ein bisschen wird hier also mit ungleichem Mass gemessen. Letzten Endes gilt für beide Ansätze, dass sie Unplanbares nicht planbar machen können, weshalb man sich von Anfang an auf Planänderungen einstellen sollte.

  • François Knuchel: Why aren’t Lean and Agile Collaborating?

    Mal wieder ein Artikel über die absoluten Basics. Die Unterschiede zwischen Agile und Lean dürften zwar schon oft erörtert worden sein, vermutlich aber selten so ausführlich wie hier von François Knuchel. Neben den offensichtlichen Besonderheiten arbeitet er auch einige heraus die in den meisten Betrachtungen untergehen, z.B. das Agile-Kanban ein eher linearer Prozess einzigartiger Einzelaufgaben ist, während Lean-Kanban aus wiederkehrenden Schleifen gleichartiger Arbeit besteht. Auch die Beobachtung, dass Agile aufgrund der Affinität zu IT und Open Source eine offenere Community hat als Lean ist ein interessanter Gedanke, vor allem in Verbindung mit der Hypothese, dass das eine Ursache der im Vergleich stärkeren Sichtbarkeit und Verbreitung ist. Wirklich zum Nachdenken anregend ist aber die Vermutung, dass die beiden Bewegungen sich kaum austauschen, weil sie sich zu parallelen Silo-Strukturen entwickelt haben. Damit wären sie genau da gelandet wo sie nicht hinwollen.

  • Mark Lambertz: Matrjoschkas und das Prinzip der losen Kopplung

    Noch mehr zum Nachdenken. Wie oben in anderem Zusammenhang hervorgehoben wurde geht auch Mark Lamberts davon aus, dass Teams mit zu grossen Abhängigkeiten letztendlich nicht agil sein können. Sein Betrachtungsschwerpunkt liegt dabei allerdings nicht auf den "horizontalen Abhängigkeiten" von anderen Teams sondern auf den "vertikalen Abhängigkeiten" von höheren Hierarchiestufen. Konkret geht es um die von dort vorgegebenen globalen Aufgabenschnitte, aus denen die unteren Ebenen ihre lokalen Aufgabenschnitte ableiten müssen. Dass das Selbstorganisation hemmt ist offensichtlich, dass es irgendwie zu einem Zusammenwirken aller beteiligten Einheiten kommen muss aber auch. Mark Lamberts' Idee von "lebensfähigen Systemen, welche in ein übergeordnetes lebensfähiges System eingebettet sind" ist ein interessanter Ansatz um diesen Widerspruch aufzulösen, dürfte aber in der Umsetzung sehr anspruchsvoll sein.


  • Oliver Staley: Whatever happened to Six Sigma?

    Eine Vorstellung von dem was manche Kritiker der agilen Bewegung voraussagen bietet das Schicksal von Six Sigma. Einst ähnlich gehypt ist mittlerweile nicht mehr viel davon übriggebliebben. Die von Oliver Staley genannten Ursachen sind auch tatsächlich die, die gerade bei Scrum, SAFe & Co zunehmend zu betrachten sind: Kommerzialisierung, Hype-getriebene Anwendung auf unpassende Bereiche, Wahrnehmung als Mode-Erscheinung. Dass Agile den selben Weg gehen wird ist nicht zwangsläufig, ein warnendes Beispiel für das was schlimmstenfalls passieren könnte ist Six Sigma aber auf jeden Fall.

Donnerstag, 26. September 2019

Deine Muda: Langfristige Detailplanung

FS
Grafik: Pxhere / Mohamed Hassan - CC0 1.0

Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.

Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren1) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.2 Die bereits in sie investierten Aufwände waren umsonst.

Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).

Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.

Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.


1Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
2In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.

Montag, 23. September 2019

Jack of all trades, Scrum Master of none

FS
Bild: Pixabay / Moise Theodor - CC0 1.0
Liest man im Scrum Guide nach welche Aufgaben ein Scrum Master alles übernehmen soll kann einem schnell schwindelig werden. Er soll das Team in Richtung Selbstorganisation coachen, soll Hindernisse beseitigen, Meetings moderieren, den Product Owner methodisch unterstützen und Change Management in der umgebenden Organisation betreiben. Je nach Umfeld sind noch weitere Themenfelder nötig: XP-Techniken, Liberating Structures, Design Thinking, Konflikt-Mediation, Skalierung, etc. etc. etc.

Es ist zwar nicht ausgeschlossen, dass es Menschen gibt die all das aus dem Stand beherrschen, viele sind es aber nicht. Da es den Beruf noch nicht lange gibt kommen meisten Scrum Master ursprünglich aus einem anderen Betätigungsfeld, Klassiker sind dabei Softwareentwicklungs-Spezialisierungen (Entwickler, Konzepter, Tester), Projektmanager oder IT-ferne Coaching-Berufe. Aus einem solchen Hintergrund heraus zu einem "universal gebildeten Spezialisten für alles" zu werden ist schwer, und vor allem dauert es Zeit.

Wenn man nicht den Luxus hat in einer Gruppe von Scrum Mastern zu arbeiten, in der einzelne Mitglieder sich unterschiedliche Schwerpunkte suchen können, bleibt die Wahl zwischen zwei Ausrichtungen: Spezialisierung und Generalisierung. Entweder man geht in einem (oder wenigen) Wissensgebieten in die Tiefe oder man erwirbt ein Grundwissen in möglichst vielen. In der überwiegenden Zahl der zu beobachtenden Fälle1 fällt die Entscheidung auf Variante Eins.

Dass das problematisch ist, ist intuitiv ersichtlich, schliesslich werden wichtige Felder bewusst nicht beackert. Die wahre Dimension erschliesst sich aber wenn man bedenkt, dass in den meisten Fällen die Spezialisierung in den "teamnahen" Themenfeldern stattfindet. Um nicht falsch verstanden zu werden - gekonnte Meeting-Moderation und gute Coaching-Techniken sind wichtig, wenn für sie aber (agil) strukturiertes Produktmanagement und das Alignment mit der umgebenden Organisation wegfallen ist nichts gewonnen. Die Scrum-Implementierung wird dann schwere Dysfunktionen haben.

Die Alternative ist vielversprechender: ein Grundverständnis aller relevanten Bereiche sogt zum einen dafür, dass sich nicht irgendwo unbemerkt Antipattern ausbreiten können, zum anderen ist es die Ausgangslage dafür, zielgerichtet andere Teammitglieder zur eigenen Entlastung einbinden zu können. Zum Beispiel kann die Meeting-Moderation in den meisten Fällen von Teammitgliedern selbst übernommen werden, so dass dort nur noch eingesprungen werden muss wenn ein neutraler Vermittler nötig ist.2

Zuletzt ist ein breites Grundverständnis die Voraussetzung dafür, dass in späteren Phasen der Selbstentwicklung entschieden werden kann wo eine Vertiefung der Kenntnisse den grössten Mehrwert stiften kann. Wichtig ist dabei aber die Reihenfolge: erst das breite Verständnis, dann die Vertiefung in einzelne Themen. Nicht umgekehrt.


1Basierend auf der eigenen Beratungserfahrung und dem Austausch in der agilen Community im Rheinland
2Ironie der Geschichte: diese Tätigkei zu delegieren fällt vielen Scrum Mastern besonders schwer
Powered by Blogger.