Sonntag, 31. Mai 2020

Kommentierte Links (LXII)

Bild: Unsplash / Dayne Topkin - Lizenz
  • Cal Newport: Why Remote Work Is So Hard - and How It Can Be Fixed

  • Ein Longread aus dem New Yorker für den man sich Zeit nehmen sollte. Basierend auf zahlreichen Quellen und verwoben mit Exkursen in die Technologie- und Wirtschaftsgeschichte breitet Cal Newport ein differenziertes Bild der Heimarbeit aus. Was ihre Vorläufer waren, wie sie entstanden ist, wie sie zurückgedrängt wurde und wie sie durch die Corona-Pandemie einen erneuten Schub erhalten hat wird hier nacherzählt, es geht aber auch um das grosse Dilemma das diese Arbeitsform schon immer umgibt: sie gibt den Angestellten (unter gewissen Voraussetzungen) eine bessere Work Life-Balance, führt aber auch zu einem spürbaren Rückgang von Effektivität, Effizienz und sozialem Zusammenhalt. Interessant ist dabei vor allem eine These: Newport ist der Überzeugung, dass der agil arbeitende Teil der Software-Industrie der einzige Sektor der Wirtschaft ist, der es geschafft hat die negativen Aspekte der Heimarbeit spürbar abzuschwächen. Dass trotzdem auch andere Branchen darüber nachdenken ihre Mitarbeiter dauerhaft zu Hause arbeiten zu lassen hat einen Grund der im New Yorker zu kurz etwas kommt, dafür aber von der New York Times und Vanity Fair aufgegriffen wird: viele Büros sind heute arbeitsfeindliche Umgebungen. Nochmal eine Geschichte für sich.

  • Matt Philip: NoEstimates, Applied

    Es kann natürlich täuschen und der individuellen Filterblase geschuldet sein, gefühlt ist es aber in den letzten Jahren um das Thema NoEstimates ruhiger geworden (vielleicht wegen des aus Marketing-Gesichtspunkten eher unglücklich gewählten Namens?). Dass die dahinterstehende Bewegung noch immer da ist zeigt dieser Beitrag von Matt Phillip, in dem er erklärt wie er sich mit diesem Ansatz an einer grösseren Ausschreibung beteiligen würde. Wer sich mit dem Thema bereits näher beschäftigt hat wird seinen Ausführungen nur zustimmen können, wer grosse Organisationen kennt wird aber auch wissen, dass er es sehr schwer haben dürfte mit diesem Vorgehen erfolgreich zu sein. Es wäre sicher hochgradig spannend einen solchen "Sales Pitch" einmal mitzuerleben.

  • Roman Pichler: Six Types of “Product” Owners

    Wer die Arbeit von Roman Pichler verfolgt wird wissen, dass er schon seit längerem versucht die Rollen im Produktmanagement auszudifferenzieren. In der Vergangenheit führte das unter anderem zur Gegenüberstellung von Product Manager und Product Owner und zur Entwicklung des Balanced Product Leaders, mit diesem Artikel kommt die Aufschlüsselung des Product Owners auf die sechs Typen Scrum Product Owner, Feature Owner, Component Owner, Platform Owner, SAFe Product Owner und Portfolio Owner dazu. Für jeden der eine PO-Rolle innehat sollte es interessant sein sein Stellenprofil mit diesen Typen abzugleichen. Was ebenfalls kurz angesprochen wird ist die Auswirkung des Scrum-Schismas auf die Product Owner-Rolle, hier besonders durch die stark voneinander abweichende Ausgestaltung im klassischen Scrum und in SAFe.

  • Willem-Jan Ageling: SAFe Scrum Master vs ‘Scrum’ Scrum Master

    Apropos Scrum-Schisma zwischen klassischen Scrum und SAFe - auch Willem-Jan Ageling nimmt sich dieses Themas an, allerdings mit Focus auf der anderen herausragenden Rolle, dem Scrum Master. Ähnlich wie Pichler arbeitet auch er heraus, dass die beiden Ausprägungen sich zwar auf den ersten Blick ähneln mögen, sich bei genauerer Betrachtung aber deutlich unterscheiden. Was den grossen Unterschied zur PO-Rolle ausmacht ist, dass der Scrum Master in viel intensiverer Weise in der namensgebenden Methodik verankert ist. Da diese aber in SAFe je nach Sichtweise abgeschwächt oder optional ist kann es zur paradoxen Situation kommen, dass ein nicht nach Scrum arbeitendes Team einen Scrum Master hat. Dass das sogar eine offiziell mögliche Variante ist zeigt, wie weitreichend die Veränderungen sind die hier vorgenommen wurden. [Nachtrag 02.06.: Es gibt eine Erwiderung von Paddy Corry]

  • Todd Lankford: If Your Scrum Is Not Fun, You Are Doing It Wrong

    Eine Wahrheit die man gar nicht oft genug aussprechen kann. (Richtig umgesetztes) Scrum liefert Entwicklungsteams Vieles was sie sich schon immer gewünscht haben: die Möglichkeit unrealistische Arbeitslasten abzuwehren, einen unmittelbaren Wertschöpfungsbeitrag, Kontakt und Austausch mit dem Anwender, die Erlaubnis systemische Dysfuntionen der Organisation anzusprechen und zu beheben, und das auch noch in einer ansprechenden Verpackung. Fast immer führt das dazu, dass die Freude an der Arbeit spürbar steigt. Der Zusammenhang ist sogar so offensichtlich, dass man Todd Lankfords Aussage wörtlich nehmen kann - wenn die Arbeit mit Scrum keinen Spass macht ist das Framework mit zimlicher Sicherheit falsch implementiert worden.

Donnerstag, 28. Mai 2020

(Keine) Stützräder


Bild: Wikimedia Commons / Masahiko Ohkubo - CC BY 2.0
Zu den vermutlich folgenschwersten Missverständnissen rund um Scrum gehört die Ansicht, dass man dieses Framework mit einem Paar Stützräder vergleichen könnte. Genau wie die Stützräder verhindern, dass ein ungeübter Radfahrer umfällt würde Scrum demnach dafür sorgen, dass ein "ungeübter Agilist" nicht versehentlich in den Wasserfall zurückfällt. Obwohl oft gehört und weit verbreitet ist diese Analogie hoch schädlich und falsch.

Um das Offensichtlichste zuerst zu nennen: die Anwender von Scrum werden durch solche Aussagen infantilisiert. Egal ob man ihnen unterstellt zu unerfahren für "unregulierte Agilität" zu sein oder ob ihnen vorgehalten wird sich ohne Not mit "Kinderkram" abzugeben, in beiden Vorhaltungen kann man ein hochproblematisches Menschenbild erkennen. Die Abwertung ganzer Gruppen ist etwas was niemand tun sollte, vor allem dann nicht wenn er sich auf die in der agilen Community verbreiteten Werte Respekt und Augenhöhe berufen will.

Fast ebenso offensichtlich ist, dass fast alle Teams in der "Anfängerphase" ihrer agilen Transition noch nicht zu wirklichem Scrum in der Lage sein werden. Das regelmässige Liefern von Mehrwert und das regelmässige Verbessern der eigenen Prozesse sind anspruchsvolle Aufgaben die man zuerst erlernen und einüben muss. Zu glauben, dass der Arbeitsmodus während dieser Lernphase bereits Scrum ist zeugt von grobem Missverstehen (oder Missverstehen wollen?) dieses Frameworks. Mit dem Einüben kann man zwar früh anfangen, die korrekte Umsetzung ist aber etwas für Fortgeschrittene.

Als weiterer Aspekt kommt dazu, dass man mit derartigen Aussagen den eigenen Handlungsspielraum unnötig einschränkt. Mit den regelmässigen Lieferzyklen, den für Aussenstehende klar erkennbaren Ansprechpartnern, der Positionierung von Scrum Master und PO ausserhalb der Aktualitätszwänge, der Möglichkeit für das Team sich auf die Entwicklung zu konzentrieren und der durch die weite Verbreitung gegebenen niedrigen Eintrittsschwelle gibt es gute Argumente für den Einsatz von Scrum. Sich diese Option dogmatisch zu verbauen ist kein rationales Verhalten.

Eine weitere Problemdimension der Stützrad-Apologeten ist die Missachtung der Schwäche der menschlichen Natur. Das abgeklärt agierende Entwicklungsteam, dass alles selbst in der Hand hat, sich ständig vernünftig verhält und zu nicht zielführenden Wünschen auch Nein sagt ist zwar ein Idealbild, in der Realität findet man es aber eher selten. Zu beobachten ist wesentlich öfter, dass es aus Bequemlichkeit und Konfliktscheue zu einer Erosion der eigentlich angestrebten Verhaltensweisen kommt, sobald kein "Produkt- oder Methodenmensch" warnend die Hand heben kann.

Eine zusätzliche (und leider weit verbreitete) negative Folge ist ausserdem, dass den in Unternehmen weit verbreiteten "Sparfüchsen" ein Argument für Personaleinsparungen in die Hand gegeben wird. Wenn Scrum nur in der "Stützradphase" gebraucht wird, dann kann der Scrum Master danach ja gehen. Dass seine Arbeit nicht mit ihm verschwindet sondern vom verbleibenden Personal zusätzlich zu den bestehenenden Tätigkeiten übernommen werden muss fällt meistens erst auf wenn es zu spät ist.

Um nicht falsch verstanden zu werden - natürlich können sich Teams gegen Scrum entscheiden, mit allen damit verbundenen Möglichkeiten und Konsequenzen. Sie können aber auch dauerhaft dabei bleiben oder es sogar trotz gegebener Agilität spät einführen. Jedem der das mit abwertenden Worten bedenken will sei Selbstreflektion empfohlen.

Montag, 25. Mai 2020

Charisma als Scrum Master-Eigenschaft (II)

Bild: Pexels / Andrea Piacquadio - Lizenz
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.

Donnerstag, 21. Mai 2020

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.

Montag, 18. Mai 2020

Warum crossfunktionale Teams bessere Aufwandsschätzungen machen

Bild: Pexel / Fauxels - Lizenz
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.

Freitag, 15. Mai 2020

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.

Montag, 11. Mai 2020

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.

Donnerstag, 7. Mai 2020

Agile Coach

Bild: Pexels / Fauxels - Lizenz
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 (mehr dazu hier). 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.

Montag, 4. Mai 2020

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