Charisma als Scrum Master-Eigenschaft (II)

Bild: Pexels / Andrea Piacquadio - CC0 1.0

Wir müssen noch einmal über das Thema Charisma sprechen, bzw. ob ein Scrum Master es haben sollte und warum. Dass er charismatisch sein muss um von seinem Team als Servant Leader akzeptiert zu werden, sollte für die meisten fachkundigen Menschen verständlich sein, es ist aber nur die Hälfte der ganzen Geschichte. Es gibt noch einen zweiten Bereich in dem Charisma dringend benötigt wird wenn ein Scrum Master seinen Job richtig machen will - in seiner Zusammenarbeit mit dem Management.

Zum besseren Verständnis zuerst ein kurzer Exkurs: Charisma ist anders als oft angenommen keine "überwältigende Ausstrahlung" sondern etwas Komplexeres. Geprägt vom Soziologen Max Weber verbirgt sich dahinter der Glaube anderer Menschen an das Führungsvermögen der als charismatisch wahrgenommenen Person. Soll dieser Glaube nicht nach kurzer Zeit wieder verschwinden muss er regelmässig durch positive Erbebnisse verstärkt werden, die dieser Führung zugeordnet werden. Charisma ist also keine Eigenschaft sondern eine soziale Beziehung.

Zurück zum Thema. Warum jeder Scrum Master dringend auf das gerade beschriebene Charisma angewiesen ist wenn er mit dem Management redet wird bei einem Blick in den Scrum Guide klar: Leading and coaching the organization in its Scrum adoption und  Planning Scrum implementations within the organization sind nur die am offensichtlichsten systemverändernden Tätigkeiten die er ausüben muss, weitere kommen noch dazu. So gut wie jeder Manager der sich dessen bewusst wird, wird sich die gleiche Frage stellen - "Warum sollten wir den das tun lassen?"

Die Antwort darauf muss lauten "Weil wir glauben, dass er unsere Organisation zum besseren verändern kann." Und genau hinter diesem Satz verbirgt sich die Grundidee des Konzeptes, der Glaube anderer Menschen an das Führungsvermögen der als charismatisch wahrgenommenen Person. Hilfreich bei der initialen Erlangung dieses Vertrauensvorschusses ist übrigens ein Seitenaspekt, das so genannte Amts-Charisma, also die Neigung der Menschen an das Führungsvermögen einer Person zu glauben, die eine bestimmte Rolle innehat. Durch sie kann ein charismatischer Status sogar erstaunlich einfach erreicht werden.

Wesentlich schwerer (und in der Konsequenz auch entscheidender) ist es dagegen diesen Status auch dauerhaft zu erhalten. Sollten sich durch das Wirken des Scrum Masters mit der Zeit keine Veränderungen ergeben wird mit grosser Wahrscheinlichkeit die Bereitschaft zurückgehen ihm weiter diese Freiheiten zu lassen. Im schlimmsten Fall wird er dadurch zurückgeworfen auf die Position des reinen Teambetreuers ohne Anteil an der Organisationsentwicklung (mit der Folge einer starken Verkrüppelung von Scrum).

Um es nicht dazu kommen zu lassen muss es zu den ersten Schritten gehören dem Management zu vermitteln was die zu erwartenden Veränderungen sind (incrementelle Produktentwicklung und kontinuierlicher Verbesserungsprozess), dass die Ergebnisse in zwar kontinuierlichen aber kleinen Lieferungen kommen werden (und dass das so gewollt ist) und dass es auch immer wieder dazu kommen kann, dass eine Lieferung ausfällt oder die Erwartungen nicht erfüllt (was aber durch den kleinen Lieferumfang keine schwerwiegenden Folgen haben wird).

Lässt die Organisation sich auf dieses Vorgehensmodell ein kann es zu dem kommen was Max Weber die "Veralltäglichung" des Charismas genannt hat. In diesem Zustand hat sich der Vertrauensvorschuss für das Management schon so oft ausgezahlt, dass sie ihn auch bei Fehlschlägen und Schwächephasen nicht in Frage stellen. Für jeden Scrum Master der Zustand auf den er hinarbeiten sollte.

Feature Bloat

Bild: Flickr / Tiger Girl - CC BY 2.0

Es gibt Begriffe mit denen man Kommunikation unglaublich beschleunigen kann, da sich in sich einen immensen Bedeutungsumfang beinhalten. Einer von ihnen ist der Feature Bloat, bzw. die Bloatware. Er ist bereits für sich genommen sprechend, beinhaltet bei näherer Betrachtung aber noch eine ganze Reihe weiterer Antipattern und Fehlerquellen. Auf ihm bauen verbreitete Leidensgeschichten auf aber auch eines der bekanntesten IT-Memes. Es lohnt also zu wissen was das eigentlich ist.

Zur Semantik: unter diesem Begriff versteht man das "Aufblähen" (→ to bloat) von Produkten mit immer neuen Funktionen. Die Gründe dafür liegen häufig im Marketing oder Vertrieb, die hoffen, dass dadurch neue Kunden gewonnen oder bestehende Kunden gehalten werden können. Eine vor allem in der IT verbreitete Ursache kann auch technische Verspieltheit sein, eine weitere ist, dass neue Features in bestehende Produkte eingebaut werden um die Kosten einer Neuentwicklung zu sparen. Und es gibt noch viele weitere.

Was sie alle gemeinsam haben: ihre Intention mag gut sein, tatsächlich geht diese Art von Produktentwicklung aber so gut wie immer am Markt vorbei. Die wenigsten Anwender wollen "das eine Werkzeug das alles kann", alleine deshalb nicht weil mit der steigenden Anzahl an Funktionen Navigation und Bedienung immer komplizierter werden, was früher oder später unverhältnismässige Nutzungsaufwände und ständige versehentliche Fehlbedienungen zur Folge hat. Und eine am Bedarf vorbeigehende Entwicklung ist Überproduktion, eine Verschwendung in Reinform.

Als zusätzlicher Punkt kommt dazu, dass die Produktentwicklung mit steigendem Funktionsumfang immer aufwändiger in der Entwicklung wird. Bei arbeitsteiligen Teams führt das dazu, dass sie mit immer weiteren Teams immer granularere Abstimmungen vornehmen und gegenseitig auf Zulieferungen warten müssen. Bei crossfunktionalen Teams kann das vermeidbar sein (es sei denn Arbeit wird parallelisiert, in der Hoffnung schneller zu werden), dafür kommt es hier fast zwangsläufig zur gleichzeitigen Arbeit an verschiedenen Stellen, mit den bekannten Effizienzverlusten.

Zuletzt wird die Entwicklung selbst immer komplexer wenn immer weitere Features eingebaut werden. Eine grosse Anzahl von Schnittstellen und Abhängigkeiten erhöht das Risiko, dass einige von ihnen übersehen werden. Die Folge ist ein immer grösserer Aufwand für Integrations- und Regressionstests, der immer weniger Zeit für die eigentlich wertschöpfende Arbeit lässt. Und ab einem bestimmten Komplexitätsgrad finden auch die nicht mehr alles, dann werden Fehlerhafte Produkte erzeugt und erfordern zusätzlichen Reparaturaufwand.

Zusammengenommen führen diese Faktoren dazu, dass mit immer grösserem Aufwand immer geringere Ergebnisse entstehen. Damit fällt Feature Bloat genau in die Kategorie der Ideen von denen man sich möglichst schnell verabschieden sollte.

Warum crossfunktionale Teams bessere Aufwandsschätzungen machen

Bild: Pexel / Fauxels - CC0 1.0

Zu den heiligen Gralen der agilen Bewegung gehört mit grosser Prominenz das crossfunktionale Team. Im Vergleich zu Teams die einzelnen Technologien oder Bearbeitungsphasen zugeordnet sind gelten sie als deutlich effektiver, und das nicht ohne Grund: sie haben wenige Abhängigkeiten und sind darum weniger darauf angewiesen sich an komplizierten teamübergreifenden Planungen zu beteiligen, sie haben einen ganzheitlichen Blick auf ihr Produkt und können darum Zusammenhänge und potentielle Fehlerquellen schon früh erkennen und sie sind diverser und darum weniger anfällig für Group Think und ähnliche Phänomene. Ein weiterer Aspekt wird dagegen selten genannt, obwohl er ähnlich wichtig ist - crossfunktionale Teams machen bessere Aufwandsschätzungen.

Um zu verstehen warum das so ist empfiehlt sich eine Annäherung von der Gegenseite. Warum sollen komponenten- und technologiebasierte Teams nicht genau so gute Schätzungen abgeben können, reicht es denn nicht aus wenn jeder Teil seinen Aufwand schätzt und das danach addiert wird? Die Antwort: leider nein, es reicht nicht. Nicht crossfunktionale Teams geben überproportional häufig unrealistisch niedrige Schätzungen ab. Und zwar deshalb weil auf die Arbeit an einem Produkt das alte Sprichwort zutrifft - sie ist mehr als die Summe ihrer Teile.

Es beginnt damit, dass in "verteilten Schätzungen" Verständnisprobleme und Missverständnisse zwischen den (Teil)Teams selten berücksichtigt werden. Dem liegen sehr menschliche Verhaltensweisen zu Grunde: vorgelagerte Teams gehen zu oft davon aus alles verständlich übergeben zu haben (schliesslich haben sie selbst ja alles problemlos verstanden) und nachgelagerte Teams sind zu häufig der Meinung alles verstanden zu haben (schliesslich können sie nicht wissen was sie noch nicht wissen). Sobald diese Fehlkommunikation sichtbar wird muss neue, ungeschätzte und ungeplante Arbeit erledigt werden.

Ein weiterer Grund ist die kaum gegebene Machbarkeit reibungsloser Übergaben. Fast nie wird das nachgelagerte Team genau dann mit seiner bisherigen Tätigkeit fertig sein wenn das vorgelagerte Team seine Zulieferung fertiggestellt hat. Dann bleiben nur drei Möglichkeiten: 1.) das vorgelagerte Team fängt mit seiner nächsten Arbeit an und macht die Übergabe später, 2.) das nachgelagerte Team nimmt die Übergabe sofort an, beginnt die Arbeit aber erst später oder 3.) das nachgelagerte Team unterbricht seine bisherige Arbeit, nimmt die Übergabe an, erledigt die sich daraus ergebenden Tätigkeiten sofort und geht danach zur vorher begonnenen Aufgabe zurück. In allen drei Fällen kommt es zu Multitasking und Kontext-Switching, wodurch die Arbeit ineffektiver und langsamer wird als anfangs geschätzt.

Zuletzt besteht das Risiko, dass die Egoismen der einzelnen beteiligten Teams das gemeinsame Ziel in den Hintergrund drängen. Wenn vorgelagerte Teams ihre Aufwandsschätzungen "einhalten" können indem sie nachgelagerten Teams unfertige, schlecht getestete oder schlecht dokumentierte Zulieferungen übergeben, dann kann das eine Verlockung sein. Umgekehrt können nachgelagerte Teams versucht sein ihre Schätzungen "wahr werden zu lassen" indem sie Zulieferungen nicht anzunehmen solange darin nicht umfangreiche Vorarbeiten enthalten sind die sie sonst selbst machen müssten.

Diese Faktoren, die für die meisten der zu niedrigen Schätzungen ursächlich sein dürften, treten bei crossfunktionalen Teams deutlich seltener auf. Verständnisprobleme und Missverständnisse lassen sich in gemeinsamen Schätzungsterminen früh erkennen, ohne Abhängigkeiten von anderen Organisationseinheiten entfallen die Probleme mit den Übergaben und das Zusammenlegen von Teamziel und Produktziel verhindert, dass diese gegenläufig werden. Sowohl im Vorfeld als auch während der Umsetzung gibt es dadurch deutlich weniger mögliche Ursachen für eine falsche Aufwandsschätzung.

Nur um es klar gesagt zu haben - auch crossfunktionale Teams können sich natürlich verschätzen. Die Wahrscheinlichkeit dass das passiert ist aber deutlich geringer als bei Teams die einzelnen Technologien oder Bearbeitungsphasen zugeordnet sind.

Does Agile Make Us Less Secure?

Deutlich unterhaltsamer als man anhand des Titels denken sollte. Und von der Aufbereitung her so wie ich es auch aufbauen würde: erst das Problem, dann die (agile) Lösung.

Resilienz

Bild: Pxhere - CC0 1.0

In der besten aller denkbaren Welten können agil agierende Organisationen von grösseren Erschütterungen verschont bleiben. Sobald sich die Realität anders entwickelt als vorher angenommen setzt ein schnelles Inspect & Adapt ein, Strukturen, Abläufe und Produkte passen sich an und die Veränderung wird ohne Krise bewältigt. In der Realität passiert das leider nicht immer. Schwarze Schwäne (Veränderung von vorher nicht vorstellbarer Art und Tragweite) können Unternehmen und ganze Volkswirtschaften völlig aus der Bahn werfen, sei es durch technische Disruptionen, soziale Umwälzungen oder globale Pandemien. Ist das geschehen benötigen sie neben der Agilität eine zweite Eigenschaft: Resilienz.

Hiner diesem aus der Soziologie und der Psychologie übernommenen Begriff (abgeleitet vom lateinischen resilire: abprallen, zurückspringen, nicht anhaften) verbirgt sich die Fähigkeit Störungen, Behinderungen und Krisen zu überstehen ohne dass die grundlegende Funktionsfähigkeit dabei Schaden nimmt. Die Resilienz bildet damit den Gegenpol zur Verletzlichkeit, einem Zustand in dem selbst kleine Störungen zu grossen und bleibenden Schäden führen können. Da Resilienzforschung bereits seit den 50er Jahren betrieben wird gibt es mittlerweile gute Definitionen, anhand derer sich bestimmen lässt bis zu welchem Grad sie ausgeprägt ist.

Eine der bekanntesten stammt aus dem Global Risks Report 2013 des Weltwirtschaftsforums, das sich schon damals (sieben Jahre vor der Covid 19-Pandemie!) mit der Frage beschäftigte wie wirtschaftliche Strukturen beschaffen sein müssen um grosse Krisen mit möglichst geringen Schäden überstehen zu können. Grundlage war die Aufteilung in die Teilbereiche Robustness (Robustheit), Redundancy (Redundanz), Resourcefulness (Erfindungs- und Einfallsreichtum), Response (Reaktionsvermögen) und Recovery (Erholungsvermögen), die wie folgt beschrieben wurden:

• Robustness
  Robustheit ist die Widerstandsfähigkeit gegen Störungen und Krisen. Sie besteht aus den Unterbereichen Modularität, Transparenz und Anpassungsfähigkeit. Die Modularität eines Systems sogt dafür, dass beschädigte Subsysteme andere nicht mitreissen können, die Transparenz sorgt dafür, dass Probleme früh erkannt werden, die Anpassungsfähigkeit hilft dabei negative Auswirkungen abzuschwächen und einzuschränken.
• Redundancy
  Redundanz liegt in zwei Formen vor, Redundanz der Infrastrukturen und Redundanz der Entscheidungsstrukturen. Die Redundanz der Infrastrukturen sorgt dafür, dass Ausfall oder Überlastung eines (technischen, logistischen oder wirtschaftlichen) Systems durch andere kompensiert werden kann, die Redundanz der Entscheidungsstrukturen sorgt dafür, dass das Gleiche bei Ausfall oder Überlastung von entscheidungsbefugten Personen passiert.
• Resourcefulness
  Auch der Erfindungs- und Einfallsreichtum manifestiert sich in zwei Bereichen. Zum einen müssen die Angehörigen einer Organisation über Qualifikation und Übung im Finden kreativer Lösungen verfügen, zum anderen (und das ist wichtig) müssen sie das auch nach kreativen Lösungen suchen dürfen ohne vorher um Erlaubnis fragen zu müssen. Ist das Zweite nicht gegeben bringt das Erste nicht viel Nutzen (oder erst wenn es zu spät ist).
• Response
  Reaktionsvermögen ist hier so gemeint, dass Anpassungsmassnahmen schnell umgesetzt werden können. Dazu gehört zum einen die Fähigkeit zu schneller, direkter und unkomplizierter Kommunikation, zum anderen die Einbeziehung aller betroffenen Subsystemein Entscheidungs- und Umsetzungsschritte, um Abhängigkeiten und Flaschenhälse früh erkennen und beheben zu können. Auch hier ist der zweite Teil wichtig, da sonst die Gefahr besteht, dass sich im Schnellschuss für eine nur schwer (oder gar nicht) umzusetzende Idee entschieden wird.
• Recovery
  Unter Erholung wird die (Wieder)Herstellung von Normalität verständen, auch hier unterteilt in zwei Unterbereiche, die ständige Überprüfung und die ständige Anpassung der Prozesse und Regelwerke. Wenn die Krisen- und Störungsauswirkungen zurückgehen führt diese Form des Inspect & Adapt dazu, dass sich nach und nach Arbeitsroutinen und Planungsstrukturen herausbilden auf denen dann die "neue Normalität" beruht.

Das Resilienz-Modell des Weltwirtschaftsforums muss jeweils für einzelne Anwendungsfälle ausdetailliert werden, geht also nicht auf deren Spezifika wie Lieferketten, Arbeitsreserven, angewandte Technologien, etc. ein. Dafür ist es universell anwendbar, also auf Unternehmen (und Teil-Unternehmen) genauso wie auf die staatliche Verwaltung, ganze Volkswirtschaften und sogar die Weltwirtschaft. Und das Beste daran: man kann es sogar im voraus nutzen um herauszufinden ob die eigene Organisation für die nächste Krise gerüstet ist oder nicht.

Agile Coach

Bild: Pexels / Fauxels - CC0 1.0

Zu den einschneidensten Veränderungen die die agile Bewegung in den letzten Jahren durchlaufen hat gehört die Einführung einer Rolle die in keinem der gängigen Frameworks zu finden ist, die aber trotzdem zu hoher Prominenz und Bedeutung aufgestiegen ist. Die Rede ist vom Agile Coach. Während er als Begriff nahezu jedem der in irgendeinem agilen Kontext arbeitet bekannt sein dürfte ist aber eine auch nur halbwegs verbreitete Rollenbeschreibung nicht existent. Man kann sich also fragen - was für ein Beruf ist das eigentlich?

Um mit dem Naheliegendsten anzufangen: in den Ursprungs-Dokumenten der Agilität ist er nicht zu finden. Weder im Manifest für agile Softwareentwicklung von 2005 noch in den dahinterliegenden Prinzipien taucht irgendeine Rolle auf und auch Agile Coaching als Tätigkeit wird dort nicht erwähnt. Grundsätzlich scheint der Begriff des Agile Coach damals völlig unbekannt gewesen zu sein, wie man aus den Statistiken von Google Trends ablesen kann. Erst seit Herbst 2007 wird er in erkennenswertem Ausmass gesucht und erst seit ca. 2016 in grösserem Umfang.

Quelle: Google Trends

Was dagegen schon damals vorhanden war, war das Selbstverständnis mehrerer Verfasser als Coach. Arie van Bennekum bezeichnete sich auf der Autorenseite des Agilen Manifestes als "Facilitator and Coach", Ron Jeffries als "the first Extreme Programming coach" und Mike Beedle nannte als seine Spezialisierung "to coach companies". Wie sich aus diesem Verständnis (und dessen Übernahme durch andere) die Bezeichnung "Agile Coach" entwickeln konnte ist nachvollziehbar. Es bleibt aber die Frage: was ist damit gemeint?

Ein kurzer historischer Exkurs: die ursprüngliche Bedeutung von Coach ist "von Zugtieren gezogener Wagen" und leitet sich genau wie das deutsche Wort "Kutsche" von der ungarischen Stadt Kocs ab, dem ehemals wichtigsten Standort des europäischen Kutschen- und Wagenbaus. Basierend darauf wurde es im 19. Jahrhundert an der Universität von Oxford und später an anderen Hochschulen zu einem Slang-Ausdruck für einen Tutor oder Repetitor, also jemanden der einen "durch die Prüfungen zieht". Wiederum abgeleitet davon wurden Coach-Berufe in verschiedenen Arbeitsgebieten ehemaliger Studenten: im Sport, im Gesundheitswesen, in der Kunst oder in der persönlichen Weiterentwicklung.

Was alle diese Berufe gemeinsam haben ist die externe Positionierung des Coaches. Er ist kein Teil der von ihm betreuten Gruppe, Mannschaft oder Organisationseinheit, nimmt nicht an deren Tätigkeit teil und leitet sie nicht an. Er ist nicht verantwortlich für die Genehmigung oder Abnahme eines Arbeitsergebnisses, ist kein Arbeitgeber, Kunde oder Käufer. Genau wie die Tutoren und Repetitoren aus denen seine Rolle hervorgegangen ist bietet er Wissen, Hilfe und Unterstützung an, ob diese dann angenommen wird liegt dann bei den gecoachten Personen und Gruppen selbst.

Zurück zur agilen Arbeitswelt. Analog zu den anderen Coach-Berufen wird auch der Agile Coach normalerweise so verstanden, dass er ein externer, helfender Begleiter für Teams und Organisationen ist. Um noch einmal die Analogie zu Tutoren und Repetitoren zu nennen: genau wie diese den Studenten vermitteln was das nötige Prüfungswissen ist und wie man wissenschaftlich arbeitet, vermittelt der Agile Coach das Wissen um die agilen Frameworks und Prinzipien sowie das Verständnis von iterativem, incrementellem, datengetriebenem Arbeiten. Was seine Coachees daraus machen liegt dann bei ihnen.

Um das stärker zu konkretisieren: sowohl die Rollen-Ausprägungen als auch die Themengebiete lassen sich bei näherer Betrachtung auf (teilweise überlappende) Schwerpunkte verdichten. Ohne Anspruch auf Vollständigkeit - bei den Rollen können das z.B. Trainer, Berater, Mentor oder Auditor sein, bei den Themengebieten Methodiken (XP, Scrum, etc), technische Praktiken (TDD, Microservices, etc), Skalierung (Scrum@Scale, Flight Level-Kanban, usw) und weitere. Sowohl für Organisationen als auch für Agile Coaches selbst kann es hilfreich sein sich anhand dieser verschiedenen Dimensionen einen Überblick über den Coaching-Bedarf und das Coaching-Angebot zu verschaffen. Zum Beispiel so:

Beispiel für eine Matrix-Darstellung

Was man durch diese Aufteilung erahnen kann: selbst die drei oben genannten Verfasser des agilen Manifests würden in einer solchen Aufteilung ihre Position finden: als XP-Coach, als Facilitator und als Scaled Agile- bzw. Company Coach. Vor allem bei Auftragsklärungen, aber auch beim Erstellen von Angeboten und Ausschreibungen kann eine solche Darstellung eine wertvolle Hilfe sein um sicherzustellen, dass Coach und Coachee zusammenpassen. Umgekehrt führt bei fehlender Konkretisierung die nicht festgelegte Rolle mitunter zu Missverständnissen bei der Besetzung.

Was ausserdem bei derartigen Bestandsaufnahmen häufig auffällt ist, dass es in vielen Unternehmen bereits eine Rolle gibt die die meisten dieser Themen bereits abdeckt: die Tätigkeiten des Agile Coaches und des Scrum Masters können sich stark überschneiden, bis hin zur völligen Deckungsgleichheit. Warum das immer wieder so ist wäre nochmal ein eigenes Thema, zumindest ist es aber ein Phänomen mit dem man sich beschäftigen sollte wenn man einen Agile Coach sucht. Mit ein bisschen Glück wird sich herausstellen, dass er unter einem anderen Jobtitel schon längst da ist.

#Remotework als goldenes Zeitalter für Scrum Master und Agile Coaches

Bild: Wikimedia Commons / Levan Nioradze - CC BY-SA 2.0

Auf seiner Seite Führung erfahren hat Marcus Raitner eine Blogparade zum Thema #Remoteworks angestossen, einen Aufruf zum gemeinsamen Reflektieren über die Erfahrungen die in den letzten Wochen und Monaten mit der plötzlich allgegenwärtigen geografisch verteilten Arbeit gemacht wurden. Mein Beitrag dazu dreht sich um die Rolle der Scrum Master und Agile Coaches in der plötzlich veränderten Arbeitswelt. Denn während viele von ihnen sich nach der schlagartigen Verlagerung ins Homeoffice erschrocken gefragt haben wofür sie jetzt noch gebraucht werden ist es meine Überzeugung (die sich auch durch meine gegenwärtige Arbeit als Remote-Scrum Master ergibt), dass sie dringender benötigt werden als je zuvor.

Um das Offensichtlichste zuerst zu nennen: die Unsicherheit ist zurück. Ausgerechnet kurz nachdem es den Unternehmen (scheinbar) gelungen war die neue Strukturen verlangenden Innovationsprozesse in "Digitale Tochterunternehmen" auszulagern und die agilen Arbeitsweisen durch Hybrid-Ansätze wie SAFe zu "zähmen" wird die Arbeitswelt mit Wucht durcheinandergeworfen. Das Bonmot, dass Covid-19 ein stärkerer Veränderungstreiber ist als alle CEOs und CTOs ist nicht von der Hand zu weisen, und die noch immer gegebene Neuartigkeit und Ergebnisoffenheit der Situation lässt fürs erste nur ein tastendes, ausprobierendes Vorgehen zu. Ob unter diesem Namen oder nicht, Firmen müssen sich jetzt agil verhalten um zu überleben und brauchen dafür Fachkräfte die wissen wie das geht.

Es gibt einen grossen Sprung nach vorne in der Digitalisierung: die vorher im gemeinsamen Büro stattfindende Kommunikation muss in online-gestützte Tools verlagert werden. Dabei ist es nicht damit getan Zoom, Slack und Jira einzuführen, es geht auch darum zu verhindern, dass sie Informationsflüsse einengen oder verfremden, es muss den Teams dabei geholfen werden Vereinbarungen zu treffen was auf welchem Kanal kommuniziert wird und es müssen Möglichkeiten erarbeitet und ständig optimiert werden Formate wie Refinements oder Retrospektiven mit ihnen abzuhalten. Und als wäre das nicht schon genug zu tun kommt dazu manchmal noch der Punkt, dass Manager daran gehindert werden müssen die digitalen Tools für übergriffige Überwachungsmassnahmen zu benutzen.

Weniger sichtbar aber mindestens genausowichtig ist die menschliche Seite der verteilten Zusammenarbeit. Auch hier gibt es mehr und weniger offensichtliche Aspekte. Zu den ersten gehört, dass auch introvertierten und leisen Kollegen die Möglichkeit gegeben wird sich online in Diskussionen und Entscheidungen einzubringen, zu den zweiten gehört das Erkennen und Kompensieren möglicher negativer Auswirkungen der heimischen Isolation. Dass diese existieren ist bekannt: der Wegfall informeller Kommunikation sowie die Unpersönlichkeit und Künstlichkeit der "Unterhaltung mit dem Bildschirm" können belastend sein und im schlimmsten Fall krank machen. Dem durch Einzelgespräche, Online-Teamevents oder ähnliche Massnahmen zu begegnen muss in einem Remote-Setting zum Repertoire eines Scrum Masters oder Agile Coaches gehören.

Als weiteres Themengebiet kommt die Erhaltung der Liefer- und Reaktionsfähigkeit der Entwicklungsteams und -abteilungen dazu. Eine erste Studie lässt befürchten, dass Remote-Arbeit hier negative Effekte haben kann: ihr zufolge werden Releases grösser und seltener, Durchlaufzeiten steigen und Nacharbeiten werden häufiger. Den Entwicklern diese (sich oft schleichend entwickelnden) Probleme und ihre möglichen Konsequenzen bewusst zu machen und mit ihnen Gegenmassnahmen zu erarbeiten dürfte von zentraler Bedeutung für Effektivität, Produktivität und Qualität der Arbeitsergebnisse sein und damit auch Auswirkungen auf Markterfolg und Zukunftsfähigkeit des ganzen Unternehmens haben. Gerade in der gegenwärtig angespannten wirtschaftlichen Lage ein gewichtiges Argument dafür, "den Methodiker" nicht wegzusparen sondern aufzuwerten.

Zusammengefasst: auch und gerade in der neuen Remote-Arbeitswelt gibt es mehr als genug zu tun für Scrum Master oder Agile Coaches, alleine das sollte Grund genug sein sie willkommenzuheissen. Es kommt aber noch ein weiterer dazu - wir werden zur Zeit aus unserer Komfortzone herausgestossen. Denn machen wir uns nichts vor, sich nicht mit Tools zu beschäftigen, Moderationen ins Team zu delegieren und sich aus technischen Themen herauszuhalten kann zwar gut begründet werden, es ist aber für den der all das unterlässt auch sehr bequem. Diese Bequemlichkeit gegen eine ungewohnte, fordernde und lernintensive Arbeitswelt einzutauschen mag Manchen erschrecken, es ist aber nicht das Schlechteste was uns passieren konnte, ganz im Gegenteil.

Kommentierte Links (LXI)

• Matt Philip: Leadership-Standup Questions

Zu den grössten Problemen die Scrum mit sich bringt gehören die (seit 2017 nicht mehr verpflichtenden) drei Fragen für Daily- und Standup-Meetings. What did I do yesterday that helped the Development Team meet the Sprint Goal?, What will I do today to help the Development Team meet the Sprint Goal? und Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? waren gutgemeint, führen aber häufig dazu, dass Output wichtiger wird als Outcome. Dass sie sich trotzdem so hartnäckig halten liegt nicht zuletzt daran, dass sich viele Teams schwer damit tun bessere Fragen zu finden die man sich regelmässig stellen kann. Matt Philip bringt einige wirklich gute Vorschläge ein, die er für Leadership-Standups für geeignet hält, die sich aber auch jeder andere regelmässig stellen sollte.

• Greg Satell: Why We Fail To Plan For The Future

  Einer der Hauptgründe für den Einsatz agiler Frameworks ist, dass die Zukunft sich häufig anders entwickelt als geplant und dass man in der Lage sein muss auf diese Änderungen zeitnah zu reagieren. Greg Satell geht noch einen Schritt weiter - selbst dort wo die Zukunft (einigermassen) berechenbar ist sind Menschen reglmässig nicht in der Lage (oder daran interessiert) realistische Planungen aufzustellen. Er sieht sowohl biologische als auch wirtschaftliche und charakterliche Gründe die zu diesem Phänomen führen, der Hauptgrund ist für ihn aber ein anderer: er ist überzeugt, dass es das Fehlen inspirierender langfristig verfolgbarer inspirierender Visionen ist die zu einer Konzentration auf die kurzfristige Planung führt. Ein interessanter Gedankenanstoss.

• Jason Yip: My journey from “Agile” to “product teams”

  Die Diskussion darüber was denn nun unter den "crossfunktionalen Teams" zu verstehen ist, die in agil arbeitenden Organisationen meistens angestrebt werden, dürften so alt sein wie der Begriff selbst. Basierend auf einem älteren Text von John Cutler, in dem dieser die Abdeckung der Wertschöpfungskette als entscheidendes Kriterium definiert, erklärt Jason Yip sein eigenes Verständnis. Lesenswert ist das wegen Yips beruflicher Vergangenheit: er war schon in den 90ern Teil der XP-Bewegung und hat später bei den agilen Vorzeigefirmen Thought Works und Spotify gearbeitet. Die Zuordnung dieser Stationen zu den unterschiedlichen Graden an Crossfunktionalität bringt einen Praxisbezug ein der bei diesem Thema sonst häufig fehlt.

• Marty Cagan: Spotify vs. Fitbit

  Apropos agile Vorzeigefirma Spotify. Dass man die Squad- und Matrix-Struktur von Spotify nicht einfach kopieren sollte ist hier schon mehrfach Thema gewesen. Aus ihrem Zusammenhang gerissen ergeben die dort geschaffenen Strukturen wenig Sinn. Die Ironie der Geschichte: viele Versuche das zu thematisieren verfallen selbst in dieses Antipattern indem sie sich an scheinbar negativen Einzelaspekten abarbeiten ohne deren Kontext zu beachten. Marty Cagan zeigt das an einem Beispiel auf das in den letzten Wochen viral gegangen ist, der Abrechnung des ehemaligen Spotify-Angestellten Jeremiah Lee mit seinem Ex-Arbeitgeber. Gleichzeitig zeigt Cagan auf wie es besser geht: er negiert Lee nicht, er bettet dessen Argumentation in einen Zusammenhang ein der verständlich macht warum sie nicht schlüssig ist.

• Sjoerd Nijland: The Theory of the Dead Horse in Scrum

  "Wenn Du merkst, dass das Pferd auf dem Du reitest tot ist - steig ab." Aus diesem scheinbar schlichten indianischen Sprichwort einen langen, pointierten und nuancierten Artikel zu machen ist ein Kunststück. Sjoerd Nijland ist es gelungen. Klare Lese-Empfehlung.