Sonntag, 31. Mai 2020

Kommentierte Links (LXII)

FS
  • 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.

  • 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

FS

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)

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

Donnerstag, 21. Mai 2020

Feature Bloat

FS
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

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

Freitag, 15. Mai 2020

Does Agile Make Us Less Secure?

FS
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

FS
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

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

Montag, 4. Mai 2020

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

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

Donnerstag, 30. April 2020

Kommentierte Links (LXI)

FS
  • 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.

Montag, 27. April 2020

Scrum Master oder Team Coach? (revisited)

FS
Bild: Pexels / Jopwell - CC0 1.0
Bemerkendwerte fünf Jahre ist es her, dass auf dieser Seite der Artikel Scrum Master oder Team Coach veröffentlicht wurde. Seine Inhalte: es gibt bei Teams unterschiedliche Reifegrade des Verständnisses von Scrum, diese Reifegrade erfordern unterschiedliche Vorgehensweisen des Scrum Masters, in fortgeschrittenen Teams etabliert sich die Rollenvariante eines Team Coaches. Zeit für einen Blick zurück - macht das was dort steht auch aus heutiger Sicht noch Sinn, oder ist das alles mittlerweile überholt und neu zu bewerten? Die überraschende Antwort - es macht noch Sinn, aber trotzdem ist es irgendwie anders gekommen. Aber der Reihe nach.

Dass es unterschiedliche Reifegradstufen von Teams auf ihrer Reise in Richtung Scrum gibt dürfte weiterhin unbestritten sein, das ist noch heute genauso richtig wie es damals offensichtlich gewesen ist. Und auch dass diese unterschiedlichen Reifegrade unterschiedliche "Betreuungsansätze" erfordern ("Master" und "Coach") dürfte unverändert zutreffen. In dieser Hinsicht kann der alte Artikel also noch immer unverändert stehen bleiben.

Über die dort beschriebenen Reifegradmodelle für Scrum Master und Teams konnte man schon damals ausgiebig diskutieren. Wie bei fast allen Modellen trifft auch für diese beiden zu, dass sie vereinfachen und generalisieren müssen um allgemein anwendbar zu sein, dazu kommt noch, dass sie bewusst plakativ und kontrovers formuliert wurden um Diskussionen anzustossen. Mit diesen Informationen im Hintekopf sind sie auch heute noch anwendbar.


Bis hierher könnte man also sagen, dass alles so geblieben ist wie damals gedacht. Kann man also einen Haken daneben setzen und sich darauf vorbereiten in fünf weiteren Jahren eine erneute Überprüfung zu machen? Nun, ganz so einfach ist es auch wieder nicht. Denn eines ist anders gekommen: die Bezeichnung "Team Coach" hat sich nicht durchgesetzt, stattdessen spricht man eher vom "Agile Coach". Und dieser Begriff ist zwar einerseits besser, entwickelt sich aber mitunter in merkwürdige Richtungen.

Zunächst zum Positiven. Dass heute nur noch selten bis nie von Team Coaches gesprochen wird ist auf zwei Schwächen dieses Begriffs zurückzuführen. Zum einen hat er keinen erkennbaren Bezug zu den Themen Agilität/Scrum mehr, was gegebenenfalls seine Legitimation als Antreiber der agilen Transition untergraben kann. Zum besteht durch die explizite Benennung als Coach des Teams das Risiko, dass die (notwendigen) Tätigkeiten ausserhalb des Teams in Frage gestellt werden. In beiden Hinsichten ist der mittlerweile etablierte Agile Coach besser.

Die andere, problematische Seite besteht darin, dass viele Scrum Master und Agile Coaches sich heute prinzipiell immer in der fragenden, begleitenden und reflektierenden Coach-Rolle sehen, selbst dort wo der Reifegrad des Teams eher den (ebenfalls vor fünf Jahren beschriebenen) bestimmenden Scrum Master brauchen würde. Wie viele dogmatisch/kategorischen Ansätze bringt auch dieser Probleme mit sich, die schlimmstenfalls dazu führen, dass dem Team dringend nötige Unterstützung verwehrt bleibt.

Die spezifischen Ausprägungen eines heutigen Agile Coaches wären nochmal einen eigenen Artikel wert, wenn man die zuletzt genannten Antipattern weg lässt kann er aber die Rolle einnehmen die vor fünf Jahren noch als Team Coach beschrieben wurde. Ob das in fünf Jahren noch immer so sein wird oder ob auch hier Begriffs- und Verständnisänderungen eintreten werden wird spannend zu beobachten sein.

Donnerstag, 23. April 2020

A Safety Net for the Champions of Change

FS
Noch immer viel zu selten: Reflektionen über agile Transitionen aus der Sicht eines Managers. Dawie Oliver von der australischen Westpac Bank sagt es zu Beginn seines Vortrages selbst - am Anfang der meisten Transitionsvorhaben steht die Ansicht, dass das Management Teil oder sogar Ursache der zu überwindenden Probleme ist. Dass eine derartige Frontenbildung nicht hilfreich ist sollte offensichtlich sein, Oliver zeigt aber darüber hinaus auf wie wichtig die Rolle der Führungsebene in derartigen Phasen ist.



Zu den wichtigsten unter den von ihm genannten Aufgaben des Managements in Transitionsphasen gehören:
  • Den agilen Enthusiasten dabei zu helfen sich nicht an den zu erwartetenden Widerständen bis zum Burnout aufzureiben
  • Der umgebenden Organisation zu vermitteln, dass der auf sie ausgeübte massive Veränderungsdruck nichts Bedrohliches ist und sie ggf. daran zu hindern mit Gegendruck zu reagieren
  • Anderen Managern auf von ihnen akzeptierter Augenhöhe vermitteln, dass, warum und wie sie ihre Berufsausübung verändern müssen
  • Mitarbeitern die sich in der neuen Arbeitswelt unwohl fühlen einen für sie gesichtswahrenden Ausstieg zu bieten
  • Toxischen Mitarbeitern ihre Grenzen aufzuzeigen und sie ggf. aus den Teams zu entfernen um andere vor ihnen zu schützen
Dass in einem letztendlich zu erreichenden Zielzustand all das auch weitgehend hierarchiefrei erreicht werden kann ist übrigens kein Gegenargument gegen seine Ausführungen. Wie er explizit sagt: es geht ihm um die Rolle des Managements in Zeiten des Umbruchs, in denen noch viel von der alten Welt vorhanden ist. In solchen Situationen kann es durchaus helfen wenn das Change Management nicht nur eine Tätigkeit ist sondern auch eine Personengruppe.

Montag, 20. April 2020

Die Probleme des Home Office

FS
Bild: Kaboompics / Karolina Grabowska - CC0 1.0
Man soll jede Krise auch als Chance sehen, heisst es in einem alten chinesischen Sprichwort. Ganz in diesem Sinn wird das erzwungene Homeoffice während der Corona-Pandemie von New Work-Befürwortern auch mit der Hoffnung willkommengeheissen, dass jetzt endlich alle die Vorteile des Arbeitens von zu Hause kennenlernen und nicht mehr vermissen wollen. Aber wird es wirklich so kommen? Man sollte nicht zu optimistisch sein.

Der offensichtlichste Grund der dagegen spricht, dass sich das Homeoffice dauerhaft durchsetzen wird ist die Infrastruktur. Anders als z.B. in den Niederlanden oder Südkorea ist die in Deutschland geprägt von Kupferkabeln und Funklöchern. Sowohl die Übertragung grösserer Datenmengen als auch die Durchführung von Remote-Meetings sind dadurch oft schwer bis unmöglich. Vor allem auf dem Land aber auch in erstaunlich vielen Städten ist man zu Hause praktisch von der Zusammenarbeit mit Arbeitskollegen, Kunden und Geschäftspartnern abgeschnitten.

Der zweitwichtigste, dafür aber am meisten unterschätzte, ist der, dass die Homeoffice-Fähigkeit stark vom sozialen Status abhängt. Berufe in den verschiedenen Niedriglohnsektoren (Telefonisten, Journalisten, Werbetexter, Sicherheitskräfte, Klicktester) haben häufig Wohnungen in denen ein gewisser Geräuschpegel herrscht (v.A. Verkehrslärm) oder die so klein oder so ungünstig geschnitten sind, dass ergonomische Arbeitsplätze sich hier nur schlecht einrichten lassen. Ist der Job ein freiberuflicher gibt es das zusätzliche Problem, dass die technische Ausrüstung oft nicht finanzierbar ist.

Selbst bei besser bezahlten Berufen kommt dazu, dass Heimarbeit vor allem dann funktioniert wenn man alleine und ungestört zu Hause ist. Arbeitet auch der Ehepartner aus der gemeinsamen Wohnung drohen die Telefonate und Meetings des jeweils anderen die eigenen zu überlagern oder die konzentrierten Ruhephasen zu stören. Und wenn sich ausserdem noch Kinder oder Haustiere in der Wohnung befinden kann von regelmässigen Unterbrechungen fest ausgegangen werden.

Sobald es um Berufe geht in denen mit sensiblen Daten gearbeitet wird tauchen noch Themen wie Datenschutz und Datensicherheit auf. Das beschränkt sich nicht nur auf technische Aspekte wie VPN oder Intranet-Zugriffe sondern hat erneut eine soziale Dimension: durch geöffnete Fenster und dünne Türen kann bereits mehr nach draussen dringen als man denkt, von den Kindern die Freunden und Mitschülern unbedacht von zu Hause erzählen ganz zu schweigen.

All diese Aspekte des Home Office sind bereits für sich genommen problematisch genug, dennoch muss man sich bewusst machen, dass sie nur an der Oberfläche kratzen. Bei genauerer Betrachtung zeigen sich noch weitere schwerwiegende Schwierigkeiten wie der Verlust von Reaktionsgeschwindigkeit, Produktivität, Kommunikations-Qualität und sozialem Zusammenhalt (mehr dazu hier und hier). Zusammengenommen tragen alle diese Punkte dazu bei, dass viele Menschen und Firmen die Heimarbeit so schnell wie möglich wieder gegen das Büro eintauschen werden. Nicht weil New Work schlecht ist, sondern weil Home Office Voraussetzungen erfordert die oft nicht gegeben sind.

Freitag, 17. April 2020

Altsysteme (II)

FS
Bild: Deutsche Fotothek / Eugen Nosko - CC BY-SA 3.0
Dass veraltete IT-Systeme aufgrund fehlender Funktionen, erschwerter Wartbarkeit und nur unter hohen Aufwänden machbarer Erweiterbarkeit ein Problem darstellen ist bekannt und durch Beispiele belegbar. Dass Anwendungen die vor Jahrzehnten in Betrieb genommen wurden trotzdem immer noch genutzt werden wird häufig damit begründet, dass sie wenigstens stabil laufen würden. Ein aktuelles Beispiel zeigt aber, dass das ein gefährlicher Trugschluss ist.

Wie verschiedene amerikanische Medien berichteten sind die Behörden mehrerer US-Staaten zur Zeit nicht in der Lage die Beiträge der Arbeitslosen-Unterstützung zu erstatten, darunter auch die von New York State, New Jersey und Connecticut, in deren Gebiet der zur Zeit besonders stark von Arbeitslosigkeit betroffene Grossraum New York mit über 20 Millionen Einwohnern liegt. Der Grund: die Erstattungssysteme sind mit Cobol programmiert, einer mehr als 60 Jahre alten (!) Programmiersprache, die heute kaum noch jemand beherrscht.

Dieser Zustand führt seit dem Ansteigen der Beschäftigungslosigkeit auf Rekordniveau zu den erwartbaren Problemen. Die Systeme brechen unter der ungewohnten Last zusammen, es zeigt sich, dass die Frontends nicht mit modernen Endgeräten kompatibel sind und der gestiegene Bedarf an Wartungs- und Reparatur-Tätigkeiten kann vom bisherigen Personal nicht mehr bewältigt werden. Der Notstand ist mittlerweile so gross geworden, dass COBOL-Entwickler in öffentlichen Aufrufen gebeten werden sich zu melden und zu helfen.



Was sich hier bemerkbar macht ist, dass es sich bei der Ablösung von Altsystemen ähnlich verhält wie beim Abschluss von Versicherungen. Solange es keine Probleme gibt scheint es (für unreflektierte Menschen) so als wäre es eine gute Idee Geld einzusparen indem auf sie verzichtet wird. Sobald der Krisen- oder Schadensfall eintritt fällt ihr Fehlen dann aber um so stärker auf. Es zeigt sich dann, dass die scheinbare Stabilität in der Regel nur darauf beruht, dass lange Zeit einfach keine Änderungen vorgenommen wurden durch die die in Wirklichkeit gegebene Instabilität offensichtlich geworden wäre.

Das Problem: da eine Systemablösung schwierig ist und lange dauert kann sie im Krisenfall nicht schnell nachgeholt werden. Sie braucht Zeit. Und währenddessen sind nicht nur die IT sondern auch die von ihr abhängige Organisation gelähmt. Welche schwerwiegenden und zum Teil existenzbedrohenden Folgen das haben kann lässt sich zur Zeit in Amerika beobachten.

Dienstag, 14. April 2020

Maslow's Hammer

FS
Bild: Pixabay / Mr. Ninko - CC0 1.0
"Ich glaube, es ist verlockend, wenn das einzige Werkzeug, das man hat, ein Hammer ist, alles zu behandeln, als ob es ein Nagel wäre." Dieses in den 60er Jahren entstandene Zitat des amerikanischen Psychologen Abraham Maslow (bzw. seine Kurzform "Wer einen Hammer hat sieht in jedem Problem einen Nagel") dürfte mittlerweile weltberühmt sein. Es beschreibt die auch als "Law of the Instrument" bekannte Neigung, einmal erfolgreiche Vorgehen immer wieder anzuwenden - und zwar selbst dann wenn gar nicht klar ist ob es auch in diesem Fall Sinn macht.

Ein prominentes Beispiel für Maslow's Hammer ereignete sich in den letzten Tagen: Jeff Sutherland, einer der Begründer von Scrum, veröffentlichte bei Twitter diese (mittlerweile wieder gelöschte) Aussage:


Passend zum Twice the Value-Versprechen von Scrum unterstellte er also einem (angeblich) nach Scrum arbeitenden Forschungsinstitut die doppelte Leistungsfähigkeit im Vergleich zu anderen Einrichtungen. Bemerkenswert ist aber der mittlere Teil der Aussage. In ihm wird die vermeintlich geringere Leistungsfähigkeit der anderen Einrichtungen begründet mit "because they are not doing Scrum and unable to function". Mit anderen Worten: wenn es nicht Scrum ist funktioniert es nicht. Starker Tobak. Und grober Unfug!1

Um hier keine Missverständnisse aufkommen zu lassen: Sutherland ist ein hochintelligenter Mensch, der ein weltweit geschätzter Experte für Organsationsformen und Prozesse ist. Dass er sich trotzdem derartig versteigt macht diesen Vorfall zu einem guten Beispiel für den Hintergründ von Maslow's Hammer. Der besteht nämlich keineswegs darin, dass es dem der ihn anwendet an grundsätzlichem Verständnis fehlt (selbst wenn das in Einzelfällen so sein kann), es ist komplizierter als das.

Bei Maslow's Hammer handelt es sich um ein Phänomen das in der Psychologie als Kognitive Verzerrung, bzw. Cognitive Bias bezeichnet wird. Dieses spielt sich unterbewusst ab und täuscht dem Betroffenen eine derartige Schlüssigkeit und Offensichtlichkeit vor, dass ein Hinterfragen dieser scheinbaren Tatsachen nicht mehr stattfindet. Als Folge dessen lässt das Bewusstsein diese Falschannahmen ungehindert passieren und gibt sie an die Umgebung weiter. Genau das dürfte hier passiert sein.

Als Ursache kommt eine ganze Reihe möglicher Faktoren zum Tragen. Häufig sind Bestätigungsfehler (die Neigung, Informationen so zu interpretieren, dass diese die eigenen Erwartungen erfüllen), Professionelle Deformation (die Neigung eine berufsbedingte Perspektive über ihren Geltungsbereich hinaus anzuwenden), Korrelations-Fehlschluss (die Annahme, dass gemeinsam auftretende Phänomene voneinander abhängen) und Blind Spot Bias (die Negierung der Möglichkeit nicht objektiv zu sein), es gibt aber unzählige weitere.

Ihnen allen ist gemeinsam, dass sie klar erkennbar sind, sobald man die eigenen Standpunkte ernsthaft auf sie überprüft (was sowohl aufgrund von Selbstreflektion als auch aufgrund einer externen Intervention geschehen kann). Mit ein bisschen Selbstüberwindung kann Maslow's Hammer dann zurückgenommen werden, oder (wie in diesem Fall) der Tweet gelöscht.



1Scrum ist ein weit verbreiteter, zigtausendfach erfolgreicher und seit Jahrzenten optimierter Ansatz. Aber weder ist es der einzig richtige noch der grundsätzlich überlegene Weg

Donnerstag, 9. April 2020

Limit the Blast Radius

FS
Eine eigentlich naheliegende Erkenntnis: um hohe Stabilität zu erreichen ist nicht etwa eine (ohnehin nicht machbare) Reduzierung von Fehlern auf Null der beste Weg sondern das Begrenzen möglicher negativer Auswirkungen auf das kleinstmögliche Ausmass. Und um das zu erreichen sollten nicht etwa möglichst umfassende Kontrollen geschaffen werden (die alles langsam und bürokratisch machen würden) sondern Strukturen in denen Änderungen in abgekapselten Bereichen möglich sind und die über eine einfache (De-)Aktivierbarkeit verfügen. Wer das einleuchtend findet wird diesen Vortrag von Dave Karow mögen.



Was dieses Video zu einem guten macht: es führt die Diskussion über Agilität weg von Rollen und Prozessen und hin zu Liefer- und Reaktionsfähigkeit. Letztenendes also wieder zurück dahin wo sie eigentlich immer geführt werden sollte.

Montag, 6. April 2020

Wer hat in Scrum die Prozessverantwortung?

FS
Bild: Pexels / Christina Morillo - CC0 1.0
Es ist eine häufige Diskussion in der Einführungsphase von Scrum: wenn wir beginnen so zu arbeiten, bei wem liegt dann eigentlich die Prozessverantwortung? Bei der Produktverantwortung ist es klar, die liegt beim Product Owner. Auch die Lieferverantwortung lässt sich schnell klären, für die ist das Umsetzungs- (bzw. Development-)Team da. Aber die Prozessverantwortung? Die könnte doch beim Scrum Master liegen, oder? Das scheint auf den ersten Blick naheliegend, ist es aber nicht unbedingt. Bei näherer Betrachtung zeigt sich nämlich, dass Prozessverantwortung ein erstaunlich vielschichtiger Begriff ist.

Beginnen wir mit dem Scrum Master. Wegen des Scrum Guide, der als offizielles Regelwerk scheinbar eine klare Richtung vorgibt, gibt es häufig die Auffassung, dass ganz klar er es ist der die Prozessverantwortung haben muss. Sowohl bei den Aufgaben der Rolle als auch an anderen Stellen könnte man es herauszulesen, dass er bei diesem Thema den Hut auf hat. Also, ist es so? Nun ja, Jein. In die umgebende Organisation wirkt der Scrum Master nur um zu verhindern, dass das Umsetzungsteam gehemmt wird. Und das was das Scrum-Regelwerk für seine Arbeit im Team vorgibt ist lediglich die Verantwortung für einen Prozess-Teilbereich, den des Scrum-Prozesses nämlich. Der ist zwar von zentraler Bedeutung, er gibt aber nur den groben Rahmen für den eigentlichen Arbeitsprozess vor.

Dieser eigentliche Arbeitsprozess ist losgelöst vom Scrum-Prozess (und der Scrum Master-Rolle) zu sehen. Wer macht was wann mit welchem Ziel und mit welchen Werkzeugen? Solange dabei am Sprintende ein funktionierendes Produktinkrement entsteht sollte der Scrum Master da für alles offen sein, genau gesagt muss er es sogar. Der Scrum Guide ist hier sehr eindeutig: Development Teams [...] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. Da bleibt kein Platz für Missverständnisse, verantwortlich ist das Umsetzungsteam und sonst niemand.

Über die Scrum- und Arbeitsprozesse hinaus gibt es aber noch einen weiteren Prozessbereich, der üblicherweise mit Namen wie Compliance, Governance oder Betriebsorganisation überschrieben wird. Auf ihn bezogen ist die Natur der Prozessverantwortung wieder eine andere als in den beiden zuvor genannten Fällen. Wenn hier davon gesprochen wird, dass jemand für den Prozess verantwortlich ist, verbirgt sich dahinter in der Regel der feine aber wichtige Unterschied, dass es die Einhaltung der Prozesse ist, für die jemand die Verantwortung trägt. Gestaltet werden sie in der Regel von irgendeiner zentralen Abteilung.

An dieser Stelle dürfen wir uns nichts vormachen - in den meisten Unternehmen ist nur dieser Bereich gemeint wenn von Prozessverantwortung gesprochen wird. Das ist nicht per se schlecht, die meisten Vorschriften beruhen im Grundsatz auf irgendeinem Sinn oder gehen sogar auf Gesetze zurück, dass sie durch Willkür oder Unsinn entstehen ist ein klischeehafter aber seltener Fall. Auch für die Existenz der zentralen Abteilung kann es gute Gründe geben, etwa eine nötige juristische Qualifikation. Es gibt aber sehr oft eine unnötig bürokratische Umsetzung, und auf die gehen meistens die wahrnehmbaren Probleme zurück. Und hier kommen wir zurück zu Scrum, zuerst wieder zum Scrum Master.

Wenn die Prozessverantwortung im Sinne des Sicherstellens der Prozesseinhaltung dem Scrum Master übergeben wird, dann mag das auf den ersten Blick naheliegend erscheinen, es stürzt ihn aber in einen tiefen Intra-Rollen-Konflikt. Auf der einen Seite erwartet Scrum von ihm, dass er dem Umsetzungsteam dabei hilft stetig effektiver zu werden, auf der anderen Seite soll er auf die Einhaltung ineffektiver Arbeitsvorgaben dringen? Und wenn der von aussen vorgegebene, unnötig komplizierte Prozess ein Hindernis für die Arbeitsfähigkeit des Teams ist, soll er zeitgleich versuchen ihn abzuschaffen und für seine Einhaltung sorgen? Das kann nicht funktionieren.

Genau umgekehrt ist es mit dem Umsetzungsteam, bei dem es auf den ersten Blick sinnvoll erscheinen mag es vom Prozessmanagement zu entlasten, damit es "richtige Arbeit" machen kann. Weit gefehlt. Damit würde es nicht nur aufhören crossfunktional zu sein, es wäre auch nicht mehr in der Lage Prognosen oder Commitments für die Sprints abzugeben, da es diese aufgrund der Abhängigkeit zu den externen Prozessverantwortlichen nicht mehr selbst vervollständigen und beenden könnte. Eine der Grundvoraussetzungen von Scrum, die Lieferfähigkeit des Umsetzungsteams, wäre ausgehebelt.

Aus alldem ergibt sich in Scrum folgende Verteilung in der Prozessverantwortlichkeit: der Scrum Master ist verantwortlich für den Scrum-Prozess, das Umsetzungsteam für den Arbeitsprozess. Alle sonstigen Prozessvorgaben (sofern deren Einhaltung eine Voraussetzung für die Lieferfähigkeit des Umsetzungsteams ist) fallen ebenfalls in dessen Verantwortung, wobei es die Aufgabe des Scrum Masters ist so auf das Team und die umgebende Organisation einzuwirken, dass an dieser Stelle Bürokratie und Ineffizienz nicht entstehen können.

Glücklich schätzen kann sich dagegen der Product Owner, an dem die Prozesse weitgehend vorbeigehen. Die einzige grosse Ausnahme davon liegt vor wenn es einen vorgelagerten Anforderungsprozess gibt, was aber nochmal ein Thema für sich ist.

Freitag, 3. April 2020

Dezentrale Krisenbekämpfung

FS
Grafik: Pixabay / Geralt - CC0 1.0
Im Rahmen des gegenwärtigen Coronavirus-Ausbruchs gibt es eine Forderung die immer wieder auftaucht: die nach weniger Föderalismus und einer stärkeren Zentralregierung. Im ersten Moment scheint es auch naheliegend - je weniger Abstimmungen nötig sind, desto schneller kann auf Herausforderungen reagiert werden. Bei näherer Betrachtung differenziert sich das Bild aber, gerade am Beispiel der Krankheitsbekämpfung kann man die Vorteile dezentraler Entscheidungssysteme erkennen. Schauen wir es uns näher an.

Dezentrale Systeme ermöglichen die parallele Erprobung verschiedener Lösungsstrategien

Das eigentlich Naheliegendste: bei Krisen die ohne historische Vergleichsfälle sind müssen verschiedene Vorgehen erprobt werden um herauszufinden welche besser geeignet sind und welche nicht. So geht das aktuell am stärksten befürwortete "Flatten the Curve"-Vorgehen wesentlich auf den Vergleich der unterschiedlichen Massnahmen zurück mit denen amerikanische Städte 1918/1919 die Spanische Grippe bekämpft haben. Ähnliches dürfte für die verschiedenen Massnahmen zur Bekämpfung des Coronavirus in Deutschland gelten, erst rückwirkend wird sich zeigen ob es Ausgangssperren, Betretungsverbote oder Kontaktverbote gewesen sind die am wirksamsten waren.

In dezentralen Systemen können die Massnahmen besser an lokale Probleme angepasst werden

Eine verbreitete Argumentation ist, dass davon ausgegangen werden könne, dass sich Regierungen verantwortungsvoll verhalten und die "einzig richtigen" Massnahmen auswählen würden. Die Realität widerlegt das leider. Egal ob in Italien, in Frankreich oder in Grossbritannien - die jeweiligen Regierungen haben hier schwere Falschentscheidungen getroffen, die unter anderem deshalb so verheerend waren weil durch sie Massnahmen flächendeckend ausgerollt werden sollten die nur unter bestimmten Voraussetzungen hilfreich gewesen wären, unter anderen aber Schaden anrichteten. Als Gegenbeispiel kann Deutschland dienen, wo die Reaktionen auf die Verbreitung des Virus von Beginn an den lokalen Gegebenheiten angepasst waren, was vor Ort zu Erfolgen führte.

Dezentrale Systeme können schneller reagieren

Ein Gegenargument zu der häufigen Annahme, dass zentralisierte Systeme eine höhere Reaktionsfähigkeit hätten. Tatsächlich ist es so, dass die Konzentration von Entscheidungsbefugnissen in der Regel zu Flaschenhals-Effekten führt. In der Theorie kann zwar schnell reagiert werden, da sich vor der Entscheidungsstelle aber schnell ein Stau bildet dauert im Endeffekt alles länger. Auch hier können Beispiele genannt werden: auf der einen Seite Grossbritannien mit seinem langsam reagierenden nationalen Gesundheitssystem und Japan, dessen zentralisiertes Vorgehen als "Zugentgleisung in Zeitlupe" bezeichnet wurde, auf der anderen Seite nochmal Deutschland, wo lokale Behörden nicht auf Genehmigungen warten mussten sondern schon früh mit Tests und Eindämmungen beginnen konnten.

In dezentralen Systemen können Fehlentscheidungen besser ausgeglichen werden

Letzten Endes die berühmten Checks and Balances. In Ländern wie China und dem Iran wurden die Krankheitsfälle von den Regierungen vertuscht und kleingeredet, mit desaströsen Auswirkungen und tausenden Toten. Auch in der westlichen Welt gibt es leider ähnliche politische Entscheidungen, hier können sie aber ausgeglichen werden. In den USA, Mexiko und Brasilien sind die Relativierungen und die Tatenlosigkeit der jeweiligen Bundesregierungen durch Massnahmen der einzelnen Bundesstaaten ausgeglichen worden, wordurch die Ausbrüche abgeschwächt werden konnten.

Mit etwas mehr Recherche würden sich noch weitere Aspekte finden lassen, die zentrale Erkenntnis sollte aber klar sein - dezentrale Systeme haben in der Krisenbekämfung klare Vorteile.

Dienstag, 31. März 2020

Kommentierte Links (LX)

FS
  • Michael Küsters: Remote Agile Coaching

  • Um es gleich zu Beginn klar zu sagen: egal welche Tools und Techniken man einsetzt, egal weit Mindset und Maturity sind - als Scrum Master oder Agile Coach wird man remote nie so effektiv arbeiten können wie vor Ort. Das bedeutet aber nicht, dass es nicht gehen würde, im Gegenteil. Es ist möglich und es ist unter diesen Umständen sogar dringender nötig als im Rahmen der meisten vor Ort-Konstellationen. Für alle die jetzt zum ersten mal gezwungen sind auf diese Art zu arbeiten hat Michael Küsters einige gute Ideen formuliert. Wie immer in solchen Fällen gilt zwar, dass das keine Blaupause sein kann die man einfach auf sich übertragen kann, wertvolle Impulse sind aber auf jeden Fall dabei.

  • Mareike Andert: Firma im Ausnahmezustand

    Ein sehr anschauliches Beispiel für eine Firma die über eine hohe Agilität verfügt (möglicherweise sogar ohne diesen Begriff zu kennen). Laut dieses TAZ-Artikels war TIB Molbiol die erste Firma der Welt die einen Test auf Covid-19 entwickeln konnte, und wer ihn liest ahnt warum. Die Prozesse sind schlank, die Hierarchien flach, die Erfahrung und Expertise gross, aber auch die Experimentierbereitschaft und der Pragmatismus. Auch eine zitierbare Anekdote aus der Praxis findet sich hier: die ersten Test-Sets in die Einsatzgebiete zu schicken und die Beipackzettel erst während des Transports zu produzieren und hinterherzumailen ist ein grossartiges Beispiel für die Beschleunigung langwieriger Prozesse. Man kann sich nur mehr Geschichten wie diese wünschen.

  • Mark Graban: Covid-19 - Don’t Blame Toyota or “Just in Time” for Your Risky Supply Chain Strategy

    Zu den unschönen Begeiterscheinungen des Corona-Ausbruchs gehört, dass teilweise eher unreflektiert Schuldzuweisungen ausgesprochen werden. Dass diese mitunter auch in Richtung Lean Management, bzw. Toyota Production System gehen nimmt Mark Graban zum Anlass für eine Verteidigungsschrift. Selbst wenn es so gewesen sein sollte, dass die Verflechtung der globalen Liefer- und Produktionsketten zur Verbreitung der Krankheit beigetragen haben, so ist das nichts was man als Argument gegen die Lean-Bewegung in Position bringen sollte. Diese zielt nämlich eben nicht darauf ab möglichst grosse Teile der Produktion in Billiglohnländer zu verlagern, ganz im Gegenteil. Kundennähe kann hier auch im engeren Wortsinn verstanden werden, als Produktion in möglichst grosser Nähe zum Absatzmarkt. Auch wenn die Löhne da teurer sind ist das in der Gesamtsicht billiger, da es Transport-, Reise- und Wartezeiten reduziert.

  • Davide Sher: Italian hospital saves Covid-19 patients lives by 3D printing valves for reanimation devices

    Dass 3D-Druck Agilität in die Hardwarefertigung bringt ist schon seit Jahren ein wachsender Trend, mittlerweile zeigt sich, dass dieses Vorgehen nicht nur effektiv sondern sogar lebensrettend sein kann. Mitten in einem der schlimmsten Ausbruchsgebiete des Corona-Virus können mit Hilfe eines 3D-Druckers jetzt medizinische Werkzeuge produziert werden die von den Krankenhäusern dringend gebraucht werden. Zuerst Reanimationsgeräte, seit kurzem auch Beatmungsmasken. Letztere sind auch aus einem weiteren Grund nennenswert: statt hier alles neu herzustellen werden nur Einzelteile angefertigt, mit deren Hilfe man handelsübliche Tauchmasken umfunktionieren kann. Ein erstaunlich effektiver Weg um schnell zu einem benutzbaren MVP zu kommen.

  • Christoph Prantner: Das Coronavirus testet die Widerstandsfähigkeit Europas

    Ein bemerkenswerter Artikel über die Widerstandskräfte die einen Staat befähigen mit Pandemien wie Covid-19 umzugehen. Bemerkenswert deshalb weil hier Begriffe benutzt werden die sich normalerweise bei der Beschreibung von Unternehmen wiederfinden die gerade Transitions- oder Disruptionsprozesse durchlaufen: Resilienz, Robustheit, Agilität, Lernfähigkeit, Bounce Back/Bounce Forward. Und bemerkenswert auch weil hier dem gerade verbreiteten reflexhaften Ruf nach mehr Zentralstaat nicht nachgegeben wird sondern er stattdessen als das benannt wird was er in der Realität häufig ist - ein Hindernis für schnelle Reaktionsfähigkeit.

Donnerstag, 26. März 2020

Backlogs

FS
Bild: Pixabay / Pandapotter - CC0 1.0
Sprachen sind komplizierte Konstrukte. Selbst die mit der wir aufgewachsen sind hält Unklarheiten und Doppeldeutigkeiten bereit, bei Fremdsprachen ist es noch einmal schwieriger. Wenn dann auch noch spezifische Fachbegriffe dazukommen besteht die grosse Gefahr von Fehldeutungen. Ein Fall in dem das leider immer wieder vorkommt ist einer der zentralen Begriffe der Agilität: das Backlog.

Würde man eine beliebige Anzahl von Product Ownern um eine Erklärung bitten was das denn überhaupt ist, dieses Backlog, käme in fast allen Fällen eine ähnliche Antwort zu Stande. Die meisten würden sich darauf einigen, dass es sich um einen Vorrat an Arbeit, Herausforderungen oder Aufgaben handelt, aus dem sich das Team bedient um durch die Umsetzung Mehrwert zu schaffen. Viele würden noch Ergänzungen anbringen wie User Stories, Sprint-Ziele oder priorisiert, aber der Grundtenor wäre gleich.

Das Problem dabei: das ist nicht das was der Begriff eigentlich bedeutet und es wird der Intention auch nicht gerecht mit der er in Scrum übernommen wurde. Diese "überraschende" Bedeutung (die jeder problemlos in jedem beliebigen Wörterbuch nachschlagen könnte) ist nämlich eine andere: Backlog bedeutet ins Deutsche übersetzt Rückstau. Und dieses Wort ist etwas komplett anderes als ein Arbeitsvorrat.

Ähnlich wie im Strassenverkehr ist ein Rückstau etwas was man eigentlich nicht haben möchte. Er bildet sich hinter Engpässen, Blockaden oder in überlasteten Systemen, er steht sinnbildlich für verlorene Zeit und ungenutzte Ressourcen und - am schlimmsten - er ist selbst Ursache für noch mehr Verzögerungen. Um das zu verstehen reicht es aus sich neben eine Bahnschranke zu stellen. Geht sie hoch fahren die aufgestauten Autos nicht sofort alle los sondern erst nach und nach, je weiter entfernt desto später. Ähnliche Phänomene zusätzlicher Verspätungen gibt es auch bei der Arbeitsplanung.

Aus diesem Grund1 ist es ein zentraler Aspekt eines Backlogs, dass es so kurz wie möglich sein sollte. Je besser das gelingt desto geringer sind die negativen Auswirkungen. Natürlich bedeutet das nicht, dass ohne Plan einfach losgearbeitet wird. Es muss eine langfristige Produktvision geben und um die zu erreichen muss im Just in Time-Verfahren immer so viel Arbeit abgeleitet und heruntergebrochen werden, dass in der nächsten Zeit genug zu tun ist.

Aber: das sollte nur in einem Ausmass passieren, das klein genug ist um einen grösseren Rückstau zu vermeiden. Und sollte der doch einmal entstehen muss man das nicht hinnehmen sondern kann ausmisten.


1Und ausserdem zu zu verhindern, dass ggf. für eine Zukunft geplant wird die so gar nicht eintritt.
Powered by Blogger.