Kommentierte Links (CXXVIII)

Grafik: Pixabay / Brian Penny - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Itamar Gilad: The Product Operating Model Explained

Seit der Begriff des Product Operating Model 2023 von Marty Cagan eingeführt wurde, gilt es in der Product Management-Community als anzustrebendes Zielbild. Für alle, die die Bücher und Blogposts von Cagan nicht in Gänze durchlesen wollen, hat Itamar Gilad die wesentlichen Punkte zusammengefasst. Praktisch aus meiner Sicht ist dabei vor allem die von ihm entwickelte grafische Darstellung, die einen schnellen und einfachen Zugang ermöglicht.

Liam Kane: An Agile Transformation Dashboard

Apropos grafische Darstellung. Liam Kane hat vier Kernelemente des agilen Arbeitens zu einem Dashboard zusammengefasst, mit dem sich der Fortschritt einer agilen Transformation verfolgen lässt: Agile Practice Adoption, Value Delivery, Team Health und Strategic Outcomes. Wie diese im Detail gemessen werden, kann (und sollte) im Einzelfall angepasst werden, als übergreifende und messbare Kategorien sind sie aber gut geeignet.

Mike Bowler: The big rewrite

Wer etwas Zeit in grösseren IT-Organisationen verbracht hat kennt die Situation, die Mike Bowler hier beschreibt - ein Bestandssystem ist schwer bedienbar, wartbar und weiterentwickelbar, also wird ein Ablöse-Projekt gestartet, dessen einziges Ergebnis ein neues schwer bedienbares, wartbares und weiterentwickelbares System ist. Wo das passiert ist, ist zwar der Code ausgetauscht worden, die Entwicklungspraktiken, die zu seiner schlechten Qualität geführt haben, sind aber geblieben.

Maret Kruve: ADEPT - The Product Discovery Framework that Fits on a Sticky Note

Was ist eigentlich aus der Steuererklärung auf dem Bierdeckel geworden, die uns mal versprochen wurde? Naja, so lange wir sie noch nicht haben nehmen wir stattdessen das Product Discovery Framework, das auf ein Post-It passt, entwickelt von Maret Kruve. Natürlich dient diese Grösse dabei nur dem Erklären der fünf Dimensionen Attractive, Doable, Effective, Practical und Targetable, im Detail ist es etwas grösser, aber immer noch schlank.

Celine Nguyen: The Perils of ‘Design Thinking’

Als letztes ein Longread. Celine Nguyen bespricht zunächst Maggie Gram's Buch The Invention of Design, leitet daraus aber eine grundsätzliche Kritik des Konzepts des Produkt-Designs ab. Nicht in dem Sinn, dass sie es für schlecht erklärt, sondern dahingehend, dass sie seine Begrenzungen und Risiken aufzeigt - vor allem solche, die entstehen, wenn versucht wird, Design Thinking und ähnliche Praktiken ausserhalb der Produktentwicklung anzuwenden.

Agilität, dort wo man sie nicht vermutet (III)

Dass die öffentliche Verwaltung an manchen Stellen agiler ist als man vermuten würde, habe ich schon an der einen oder anderen Stelle geschrieben. Ich muss aber zugeben, dass jeder neue Fall auch mich etwas überrascht, so viele sind es schliesslich auch wieder nicht. Die aktuelle Überraschung tritt dabei an einer besonders prominenten Stelle auf, nämlich in der Bundesregierung, genauer gesagt im neuen Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

Die erste Anwendung agiler Praktiken findet dabei gleich im Rahmen des Organisationsaufbaus statt. Statt möglichst lange möglicht im Verborgenen an einem möglichst perfekten Organigramm zu arbeiten, das dann nicht mehr verändert werden soll, hat das BMDS bewusst einen noch unfertigen Entwurf veröffentlicht, in gewisser Weise ein MVP. Dadurch sollen möglichst viele der zukünftigen Mitarbeiter früh Wünsche und Feedback äussern können, die dann in spätere Versionen einfliessen können.

 

Und damit nicht genug - diese Transparenz und Offenheit für Rückmeldungen soll nicht nur einmal stattfinden sondern mehrfach, das Ministerium plant "die Umsetzung in eine feste Struktur [...] in Form eines iterativen Prozesses", es wird also mehrere Veröffentlichungs-, Feedback- und Ansassungs-Schleifen geben, bis irgendwann ein Organisationsaufbau in einer Form definiert worden ist, die eine zeit lang stabil bleiben kann (so ähnlich habe ich auch schon einmal gearbeitet).

Alleine das ist für eine Behörde bereits beeindruckend genug, bei der Süddeutschen Zeitung kann man aber nachlesen, dass noch weitergehende Organisationsdesign-Prinzipien umgesetzt werden sollen: in einer Abkehr von sonst üblichen Paradigmen sollen die entstehenden Abteilungen nicht in Form von Silos auf Fach- oder Aufgabenteilungs-Basis entstehen, sondern um so genannte "Missionen" gruppiert sein, also um konkrete Modernisierungs- und Digitalisierungs-Aufgaben.

 

Dazu sollen diese neuen Einheiten nicht einfach über längere Zeiträume vor sich hinarbeiten, sondern stattdessen in überschaubaren Zeiträumen kleinere, aber dafür fertige Ergebnisse abliefern. Die Rede ist dabei von "Projekten mit einer Laufzeit von maximal sechs Monaten". Derartige Intervalle wären sogar mit verschiedenen klassischen agilen Praktiken kompatibel, etwa den Objectives aus OKRs oder den Product Goals aus Scrum. Und im Vergleich zu vielen anderen Behörden sind sie bemerkenswert kurz.

 

Eher der Umbruchssituation geschuldet, trotzdem aber bemerkenswert ist der Improvisationsgeist, von dem die Süddeutsche Zeitung berichtet. Statt sich lange mit den in der öffentlichen Verwaltung legendär langwierigen und komplizierten Bestellprozessen aufzuhalten werden Büroausstattungen gebraucht gekauft oder geliehen, unbürokratisch verteilt und bei Bedarf zweckentfremdet. Und noch etwas erinnert mich an ein eigenes Erlebnis: die pragmatische Beschaffung von dringend nötigem Klopapier.

Ob sich der "agile Geist" in diesem neuen Ministerium halten wird, ist natürlich noch nicht absehbar. Bestenfalls wird er in die Organisationskultur übergehen, schlimmstenfalls wird er sich nach und nach verflüchtigen. Aber alleine dass Agilität an einem solchen Ort, an dem man sie nicht vermuten würde, möglich ist, ist schon für sich genommen eine bemerkenswerte Geschichte. Eine die man durchaus weitererzählen könnte, wenn wieder jemand undifferenziert auf Behörden schimpft.

Why We Confuse Building to Learn with Building to Earn

Ich bin ein Fan der Vorträge von Jeff Patton, zum einen wegen der inhaltlichen Tiefe, zum anderen wegen seines besonderen Stils, Life Visualisierungen für seine Ausführungen zu erstellen. In diesem Fall zum Thema des Minimum Viable Product (MVP).

Spannend an diesem Vortrag ist unter anderem, dass er durch die Erläuterung des MVP scheinbare Gewissheiten der agilen Produktentwicklung in Frage stellt, zum Beispiel die Definition of Done - aber nicht etwa, weil er in dieser Idee keinen Sinn sieht, sondern weil er aufzeigen kann, dass sie nur Teile dessen abdeckt, was man unter agil verstehen kann. 

How agile crossed the chasm

Grafik: Wikimedia Commons / Craig Chelius - CC BY 3.0

Die Geschichte der Agilität ist voller Missverständnisse, besonders dann wenn es darum geht, wie das, was wir heute die agile Bewegung nennen, entstanden ist. Das liegt zum Teil einfach daran, dass die "agiler Vor- und Frühgeschichte" der 80er und 90er Jahre mittlerweile schon etwas länger her ist, zum anderen aber auch daran, dass sie sich zu Beginn in den Schatten abgespielt hat, ohne Namen und ohne Bekanntheit. Und an dieser Stelle wird es interessant.

Bevor wir dazu kommen aber kurz zu den beiden verbreitetsten Missverständnissen über die Entstehung des agilen Produkt- oder Projektmanagements: das erste ist, dass sie 2001 in Snowbird, Utah entstanden sind, als dort das Manifest für agile Softwareentwicklung verfasst wurde. Das zweite erkennt zwar an, dass Frameworks wie Scrum, Crystal und XP deutlich älter sind als das Manifest, geht aber davon aus, dass ihre Erfinder erst in Snowbird ihre Gemeinsamkeiten erkannten (und einen Namen dafür suchten).

Dass die Wahrheit nochmal anders geartet war, kann man im Podcast The Pragmatic Engineer erfahren, genauer gesagt in der Episode TDD, AI agents and coding, in der Kent Beck zu Gast ist, der Erfinder von XP (Extreme Programming) und der erste Unterzeichner des agilen Manifests. Neben XP-Praktiken und seinen Erfahrungen mit dem Einsatz von künstlicher Intelligenz teilt er auch Geschichten rund um die Verfassung des besagten Manifests, unter anderem, das dieses einem bestimmten Zweck diente.

Und damit kommen wir zurück zur Zeit, in der die agile Bewegung keinen Namen und keine Bekanntheit hatten, denn laut Beck sollte die Zusammenkunft in Snowbird genau das ändern. Es war nämlich kein gegenseitiges Kennenlernen, das dort stattfand (fast alle Beteiligten kannten sich bereits) und auch kein Erarbeiten von Gemeinsamkeiten (das war bereits früher passiert, u.a. bei einer gemeinsamen Hurtigruten-Kreuzfahrt einiger Teilnehmer). Es ging um Marketing und Brand Building.

Die angehenden Verfasser des agilen Manifests waren sich bewusst, dass sie bereits über eine kleine aber treue Gruppe von Anhängern verfügten, der Grossteil ihrer Zielgruppe (Software-Entwickler und IT-Manager) aber noch nicht bereit war, sich auf die neuen Arbeitsweisen einzulassen. In Anlehnung an das Technology Adaption-Modell aus dem Buch Crossing the Chasm suchten sie nach einem Weg, um die Lücke zwischen den ersten Anhängern und der Mehrheit der Anwender zu überwinden.

"Agile" oder die anderen in Snowbird erwogenen Namen, wie "Adaptive" oder "Lightweight" waren bewusst gedacht als einfache, attraktive und wirkmächtige "Dachmarken", mit deren Hilfe es einfacher werden sollte, die verschiedenen dahinterstehenden Frameworks bekannt und populär zu machen und so dafür zu sorgen, dass möglichst viele Softwareentwickler zu deren Anwendern werden konnten, wollten und in ihren Firmen auch durften.

Die Ironie dieser Geschichte liegt darin, dass der gewählte Vermarktungsansatz am Ende zu erfolgreich war - zumindest in der rückwirkenden Betrachtung von Kent Beck. Dadurch, dass fast ausschliesslich die positiven Effekte im Mittelpunkt der Aussendarstellung standen, wollten plötzlich auch Menschen und Organisationen dieses Label tragen, die die notwendigen Kriterien gar nicht erfüllten. Hierin liegt sicherlich einer der Ursprünge von Cargo Cult Agile und dem agil-industriellen Komplex.

Wie es besser gegangen wäre hat im Übrigen ebenfalls Kent Beck gezeigt, und auch darüber berichtet er im Pragmatic Engineer-Podcast. Für sein eigenes Framework Extreme Programming hat er einen Namen gefunden, der einerseits gut vermarktbar ist, andererseits aber klar macht, dass es anspruchsvoll und anstrengend sein kann, so zu arbeiten. Man kann lange darüber spekulieren, welchen Weg die agile Bewegung wohl gegangen wäre, wenn man sie auf diese Weise vermarktet hätte.

Der Überbau von OKRs

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) einfach. Man setzt ein abstraktes, mittelfristiges Objective (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen messbaren Key Results (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Eine Herausforderung, die dadurch entsteht ist aber die Verbindung der OKRs mit der übergreifenden Unternehmensstrategie.

 

Um klarer zu machen warum das eine Herausforderung ist: eine übergreifende Strategie setzt sich zusammen aus Entscheidungen, auf welche Märkte, Produkte, Preissegmente und Produktionsprozesse sich ein Unternehmen in der länger- und langfristigen Zukunft konzentrieren will, was in der Regel einen Zeithorizont von Jahren oder sogar Jahrzehnten bedeutet. Zwischen einer solchen auf Jahre ausgerichteten Strategie und den nur wenige Monate umfassenden OKR-Zyklen klafft eine Lücke.

 

Versucht man diese Lücke zu schliessen entsteht die nächste Herausforderung: so wie OKRs gedacht sind, sollten die Objectives keine bereits lange im Voraus festestehenden Teile eines Work Breakdown aus einem Strategie-Umsetzungsplan sein, sondern noch kurz vor jedem Zyklus verfasst oder angepasst werden können. Das Ziel sollte also sein, eine Verbindung zwischen Strategie und OKRs zu schaffen, die zwar für eine übergreifende Ausrichtung sorgt, dabei aber möglichst wenig einengend ist.

 

Wie das im Einzelfall aussehen kann hängt vom jeweiligen Kontext ab. Wenn der z.B. eher von Product Discovery geprägt ist, also von einer Neu- oder Weiterentwicklung mit schnellen Feedback-Zyklen, kann es Sinn machen, Outcome-orientierte längerfristige Ziele zu formulieren (z.B. "langfristige Power User werden für ihre Treue belohnt"), ohne vorzugeben, durch welche Massnahmen, mit welcher Belohnung oder oder in welchen Systemen das erreicht werden soll.

 

Wenn es dagehen eher um die kontinuierliche Optimierung etablierter Produkte oder Services geht, kann es ein guter Weg sein, North Star-Metriken zu definieren (z.B. je nach Produkt Anzahl der Buchungen, Interaktionsraten, Nutzungsdauern, etc) und deren dauerhafte und langfristige Optimierung anzustreben, auch hier ohne eine länger im Voraus verfasste Vorgabe, wie das stattzufinden hat. Und natürlich gibt es neben diesen beiden Kontexten noch viele weitere mögliche.

 

Da es auch im Umfeld der OKRs zur Entwicklung einer eigenen Fachsprache gekommen ist, gibt es auch für diese Verbindungselemente zwischen Strategie und Objectives einen eigenständigen Namen. Man spricht von "Moals",  wobei es sich um eine Abkürzung für "mid-term Goals" handelt, also um mittelfristige Ziele im Sinn von Jahreszielen, o.Ä. Wie immer im Fall solcher Begriffe kann man sich auch bei diesem über Sinnhaftigkeit und Originalität streiten, zumindest ist er aber OKR-spezifisch.

 

Ob man den Begriff benutzt oder nicht ist am Ende auch relativ egal, viel wichtiger ist, dass die Lücke zwischen Strategie und OKRs überhaupt geschlossen wird. Und eine letzte wichtige Faustregel kann man sich merken: immer wenn versucht wird, Prozesse und Formate rund um diese Verbindungsschicht vorzugeben (formalisierte Moal Plannings, zu befogende Moal Templates, etc) hat das nicht mehr viel mit der ursprünglichen Idee der OKRs zu tun, sondern ist Teil des agil-industriellen Komplexes.

Scrum Guide Expansion Pack

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

 

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

 

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

 

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

 

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

 

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf¹). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

 

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

²Und der Product Owner auch nicht, und mindestens ein Entwickler auch nicht. Fun Fact: für die Stakeholder gilt das nicht, die könnten im Extremfall alle KI sein.

Agile Success Stories: ein wirklich crossfunktionales Team

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

 

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

 

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

 

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

 

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Der Change-Prozess als bewusste Machtkampf-Arena

Eine häufige Beschwerde bei Veränderungsvorhaben in grossen Organisationen ist, dass unverhältnismässig viel Zeit in Meetings aller Art verloren geht. Workshop folgt auf Workshop, Steuerungskreis auf Steuerungskreis, Entscheidungsrunde auf Entscheidungsrunde - nur damit am Ende ein Ergebnis steht, für dessen Festlegung bereits ganz am Anfang alle Informationen zur Verfügung gestanden hätten. Warum tut man sich das an?

Eine interessante Erklärung dafür bietet der Soziologie-Professor Stefan Kühl im wie immer hörenswerten Podcast "Der ganz formale Wahnsinn". Ihm zufolge dienen derartiger Meetings nicht nur der rationalen Entscheidungsfindung, sondern auch dem Austragen von Machtkämpfen, deren Stattfinden zu derartigen Anlässen nicht nur möglich, sondern sogar gewünscht ist, die dort aber nach Möglichkeit auch abgeschlossen werden sollen - etwas, was ich mehrfach genau so erlebt habe.

Um das zu verstehen holen wir zunächst etwas aus: Veränderungen führen in sehr vielen Fällen dazu, dass es Gewinner und Verlierer gibt. Ein Abbau von Hierarchien reduziert Bürokratie, verknappt aber dafür die Karriereoptionen; die Schaffung von Spezialistenlaufbahnen ermöglicht individuellen Statusgewinn, das aber auf Kosten der Gleichbehandlung in Teams; etc. etc. Das ist meistens schon früh erkennbar und löst bei den negativ Betroffenen die erwartbaren Widerstände aus.

Werden Veränderungen jetzt (zu) schnell beschlossen, finden diese Widerstände im Rahmen der bereits neu geordneten Organisation statt, was diese von Beginn an lähmen kann. Gelingt es dagegen, die Widerstände (und die Anstrengungen zu ihrer Überwindung) vor die Entscheidung zur Neuordnung zu legen, und zwar so, dass die Gewinnerseite des dadurch entstehende Machtkampfes diese Entscheidung prägen darf, dann kann die Startphase der neuen Organisation weitgehend ungestört beginnen.

Die verschiedenen Workshops, Steuerungskreise und Entscheidungsrunden bilden in dieser Betrachtungsweise eine Arena, in der die verschiedenen Parteien vor den Augen der restlichen Organisation gegeneinander antreten, einzelne Auseinandersetzungen gewinnen, andere verlieren, nach und nach ermüden, neue Kraft schöpfen, Bündnisse schliessen und Rückzugsgefechte führen, bis letztendlich eindeutig klar ist, wer sich in welchem Bereich durchgesetzt hat.

Am Ende dieser Vorgänge stehen gleich mehrere Ergebnistypen: zum einen die Entscheidungen der Machtkämpfe, und mit ihnen auch die über das Ausmass und die Weiterführung der Veränderungen, zum anderen aber auch eine Legitimation und Delegitimation von Standpunkten. Die Gewinner können sich zukünftig auf den langen und ausführlichen Entscheidungsprozess berufen, den Verlierern kann vorgehalten werden, dass sie trotz ausreichender Zeit keine Mehrheiten für ihre Ideen finden konnten.

Was mit dieser Art einer Change-Herbeiführung verbunden ist, ist natürlich das Risiko einer hochemotionalen Konfliktaustragung, da jede Seite befürchten muss, nach einer Niederlage auf unabsehbare Zeit kein Gehör für Ihr Anliegen mehr zu finden. Schlimmstenfalls kann sogar das Gegenteil des Angestrebten erreicht werden, einer belasteter statt eines unbelasteten Neustarts, nur mit einer Belastung durch Verbitterung und Verletzungen statt durch weitergehende Widerstände.

Um das zu vermeiden kann es sich anbieten, Veränderungen nicht in seltenen, grossen Programmen durchzuführen, sondern in einer stetigen Reihe von kleineren Vorhaben. Der Arena-Effekt verschwindet dadurch zwar nicht, dadurch dass die Auseinandersetzungen kleiner und reversibler werden, gehen aber die zur Schau Stellung und die potentielle Emotionalität zurück. Und als ein Seiteneffekt sind in jedem einzelnen Fall auch weniger Meetings nötig, was wiederum zu weniger Beschwerden führt.

Digitales Working Out Loud als Alternative zum Daily

Bild: Pexels / Polina Tankilevitch - Lizenz

In den meisten agilen Teams sind die Daily Meetings (Daily Scrum, Daily Standup, Daily Symc, etc) ein fester Bestandteil ihrer Arbeitsweise. In einzelnen Fällen stösst dieses Konzept aber an Grenzen, etwa wegen nicht gegebener gleichzeitiger Verfügbarkeit, wegen Introvertiertheit oder (bei remote-Arbeit) wegen schlechter Internet-Verbindung. Um trotzdem im engen Austausch bleiben zu können, gibt es für solche Teams eine mögliche Alternaltive: digitales Working Out Loud (WOL).

Um Missverständnissen vorzubeugen: bei Working Out Loud handelt es sich in diesem Fall nicht um die seit 2015 entwickelte formalisierte Social Learning-Methode gleichen Namens, sondern um die dahinterstehende, 2010 von Bryce Williams entwickelte Grundidee, die lediglich aus zwei Prinzipien besteht: die eigene Arbeit sichtbar zu machen und sie in Erzählform zu vermitteln. Diese Prinzipien lassen sich auch in Team-interne Kommunikation übertragen.

Um das (in einer nicht-verbalen Form) zu tun braucht es zunächst einen gemeinsamen digitalen Kommunikationskanal. Das kann in der rudimentärsten Form eine Whatsapp-Gruppe sein. in den meisten Firmen sind aber professionelle Tools vorhanden (Teams, Slack, etc.), in denen sich eigene Kanäle für ein Team anlegen lassen. In diesen Chat kann man dann alles eintragen, woran man gerade arbeitet. Damit ist bereits das erste Prinzip erfüllt, die Sichtbarkeit.

Das zweite Prinzip, die Erzählform, ist nötig um die Information über die eigene Arbeit mit dem nötigen Kontext zu versehen. "Ich arbeite an Komponente XY" würde z.B. nicht klar machen, warum diese Arbeit stattfindet. "Ich arbeite wie besprochen an Komponente XY, damit unser Hauptkunde rechtzeitig die Exportfunktion bekommt die wir ihm bis Ende des Monats versprochen haben" macht dagegen den Hintergrund und die Prioritäten deutlich klarer.

Wichtig ist dabei, dass diese Information im Voraus stattfindet. Falls eines der anderen Teammitglieder Einwände, Fragen, Hinweise oder Verbesserungsvorschläge hat, können die dann noch eingebracht werden bevor die Arbeit begonnen wurde. Das Risiko, versehentlich unnötige oder in Relation unwichtige Arbeiten zu beginnen wird so minimiert. Und natürlich kann der Chat bei Unklarheiten auch für schnelle Klärungen und Abstimmungen genutzt werden.

Mit ein bisschen Übung kann diese Art des Working Out Loud einen Grossteil der Kommunikation ersetzen, die sonst in einem Daily Meeting stattfinden würde. Bei entsprechender Nutzung können die ausgetauschten Informationen sogar noch weiter angereichert werden, etwa durch Links zu Anforderungen oder Build Reports, durch angehängte Dateien oder in den Text eingebettete Screenshots und Diagramme. An diesen Stellen kann ein Chatt sogar besser sein als ein Meeting.

Schlechter als in einem Meeting lassen sich in einem Chat dagegen Stimmungen, Emotionen und sonstige soziale Aspekte sichtbar machen. Schlimmstenfalls kann es sogar zu Konflikten kommen, da Sorgen, Ungeduld oder Verärgerung nicht erkannt werden. Ein weiterer wichtiger Punkt ist, dass digitales WOL eine ständige Beachtung des Chats erfordert, was ggf. störend für Konzentration und Produktivität sein kann und zu Stress führen kann.

Digitales Working Out Loud kann also eine brauchbare Alternative zum klassischen Daily Meeting sein, es kommt aber mit einem Preis, dessen man sich bewusst sein sollte. Wenn nicht die oben genannten Gründe (oder ähnlich schwerwiegende) gegeben sind sollte man daher vor einer Umstellung die Vor- und Nachteile gegenüberstellen, und ggf. in einer Testphase erproben, wie der neue Modus funktioniert und mit welchen Effekten er verbunden ist.