Donnerstag, 10. Juni 2021

Warum die Menschen nicht zurück ins Büro wollen

Bild: Wikimedia Commons / Peter Bennet - CC BY 3.0

Wenn grosse Organisationen ihre Angestellten für eine längere Zeit ins Home Office geschickt haben (sei es wegen Pandemien, Bauarbeiten, Überbelegung der Büros oder aus anderen Gründen) kommt es gegen Ende dieser Phasen oft zu interessanten Meinungsbildern. Auf der einen Seite gibt es eine starke Unzufriedenheit mit der Ineffektivität und sozialen Isolation die Heimarbeit mit sich bringt, auf der anderen Seite einen starken Widerwillen gegen die Rückkehr zur durchgehenden Präsenzarbeit.


Warum das so ist dürfte sich zwar von Fall zu Fall unterscheiden, nachdem ich in den letzten 15 Jahren eine ganze Reihe derartiger Fälle erlebt habe, habe ich aber eine These entwickelt: dass viele Menschen mittlerweile eine grosse Skepsis gegenüber der Präsenzarbeit haben liegt stark daran, dass das was sie unter diesem Namen kennengelernt haben in Wirklichkeit etwas ganz anderes ist, nämlich schlecht umgesetzte Remote- oder Hybrid-Arbeit.


Um das zu erklären bedarf es zunächst einer Definition: in der Kreativ- und Wissensarbeit findet Wertschöpfung in der Regel nicht durch einzelne Personen statt sondern durch die Zusammenarbeit in Gruppen oder Teams. Präsenzarbeit muss in diesem Kontext also bedeuten, dass alle Beteiligten gemeinsam vor Ort sind. Sind auch nur Teile des Teams an einem anderen Ort wird die Arbeit aller Beteiligten automatisch zu Remote-Arbeit, da die Abwesenden ja einbezogen werden müssen.


Und auch das muss definiert werden: "an einem anderen Ort" bedeutet eben nicht nur in einem anderen Land, einem anderen Standort oder zu Hause in der Wohnung. Es schliesst alles ein was nicht in Sicht- oder Rufweite (oder zumindest mit wenigen Schritten erreichbar) ist. Als Faustregel in der Wissensarbeit kann gelten: sobald andere Teammitglieder nicht mehr direkt ansprechbar sind sondern angerufen, angemailt oder angechattet werden müssen kann von Präsenzarbeit nicht mehr die Rede sein.


An dieser Stelle wird das Problem vieler grosser Organisationen offensichtlich. In den einen werden Mitarbeiter zu Projektteams zusammengefasst, die weiterhin bei ihren entsendenden Einheiten sitzen. In anderen wurden feste Arbeitsplätze abgeschafft, so dass man sich täglich einen neuen suchen muss - mit der Folge dass es für Teams schwer wird genug nebeneinanderliegende freie Plätze zu finden. Beides hat eine Verteilung der Teams über verschiedene Räume, Stockwerke oder Gebäude-Flügel zur Folge.


Selbst innerhalb eines Gebäudekomplexes führt diese geografische Verteilung dazu, dass mit den Kollegen auf dem gleichen Weg kommuniziert wird wie mit denen in anderen Standorten oder Ländern, also über Calls, Chats oder Mails. Der Vorteil des gemeinsamen Standorts schrumpft darauf zusammen, dass man einfacher Präsenzmeetings organisieren kann - was aber gemeinsame Präsenzarbeit nur zum Teil ersetzt und ausserdem oft an zu wenigen verfügbaren Meetingräumen scheitert.


Soweit zum ersten Teil der These: was für Präsenzarbeit gehalten wird ist in vielen Fällen nichts anderes als Remote-(Zusammen-)Arbeit mit Kollegen die irgendwo verstreut im Gebäudekomplex sizen. Aber es kommt noch ein zweiter Teil dazu, einer dessen Auswirkungen weitgehend unterschätzt werden - es ist nicht nur Remote-Arbeit sondern Remote-Arbeit unter schlechten Bedingungen, was deutliche Auswirkungen auf Effektivität und Ergebnisqualität hat.


Anders als zu Hause, wo man zwar einsam aber ungestört ist, führt das in Grossraum- und Gruppen-Büros stattfindende Zusammensitzen mit den Mitgliedern anderer Teams dazu, dass deren Telefonate und Video Calls mit ihren ebenfalls verstreut sitzende Teammitgliedern einen ständigen Hintergrundlärm erzeugen, gegen den nur noch Schallschutz-Kopfhörer helfen. Da es dadurch unmöglich gemacht wird ansprechbar zu sein verschwindet die direkte Kommunikation fast völlig. Dazu kommt der Stress.


Letztendlich ist es eine Loose-Loose-Situation: um rechtzeitig im Büro sein zu können fallen mit früh Aufstehen und langen Fahrtzeiten die negativen Effekte der Präsenzarbeit an, gleichzeitig bleiben nicht nur deren mögliche Vorteile aus, sondern die zwangsweise auch vor Ort stattfindende de facto-Remote-Arbeit ist sogar stressiger und unkomfortabler als sie es von zu Hause aus wäre. Wer kann es den Menschen verdenken wenn sie nicht zurück ins Büro wollen?


Heisst das also, dass es bei dauerhaftem Arbeiten von zu Hause aus bleiben soll? Auch nicht wirklich, denn hier entstehen andere Probleme. Besser wäre es in der Präsenzarbeit für Bedingungen zu sorgen die dazu führen, dass sie ihren Namen wirklich verdient hat. Und dafür müsste man nicht einmal besonders innovativ sein, man müsste nur das beherzigen was schon vor einem Vierteljahrhundert als gut erkannt wurde. Es wäre höchste Zeit die Büros entsprechend umzubauen, dann kommen die Mitarbeiter auch wieder gerne dorthin.

Montag, 7. Juni 2021

Air Sandwich

Bild: Wikimedia Commons / Matthias Süßen - CC BY-SA 4.0

Zu den Tätigkeiten die ein Agile Coach ausüben kann gehört eine die man als "Auditierung" agil arbeitender Projekte oder Unternehmen bezeichnen könnte. In den meisten derartigen Fällen ist die dahinterstehende Motivation die, dass die Umstellung des Arbeitsmodus nicht zu den Verbesserungen geführt hat die erhofft waren, und dass das Unternehmen herausfinden möchte ob es bei der Umstellung etwas falsch gemacht hat. Und zu den häufigsten Fehlern die dabei gefunden werden gehört das so genannte "Air Sandwich".


Erstmals geprägt von der amerikanischen Strategieberaterin Nilofer Merchant in ihrem 2009 erschienenen Buch The New How: Creating Business Solutions Through Collaborative Strategy beschreibt dieser Begriff einen der klassischen Gründe dafür, dass grosse Veränderungsvorhaben wirkungslos bleiben - das fehlende Herunterbrechen des grossen Plans auf ein Detail- und Abstraktions-Niveau das auf der Ausführungsebene umsetzbar ist. Mit ihren Worten:


An Air Sandwich is a strategy that has clear vision and future direction on the top layer, day-to-day action on the bottom, and virtually nothing in the middle.


Am Beispiel einer nicht gut verlaufenden Umstellung auf agiles Arbeiten würde das so aussehen: in der obersten Unternehmensebene ist grundsätzlich verstanden, dass schnelle Liefer- und Reaktions-Zyklen wichtig sind, und deren Implementierung wird angeordnet. Im Idealfall würde jetzt in der Mitte die Operationalisierung beginnen, zum Beispiel in Form eines Rückbaus von Silos und Hierarchien, so dass auf der unteren Ebene selbstorganisierte, crossfunktionale Produktteams entstehen können.


In der Realität ist es dagegen häufig so, dass die Anordnung schneller und flexibler zu werden in der Mitte auf die dort vorhandene Luftschicht (das Air Sandwich) trifft, ungebremst durch diese hindurchfällt und weiter unten auf der Umsetzungsebene einschlägt. Da in diesem Szenario die Hierarchien und starken Aufgabenteilungen aber nicht verändert worden sind (das hätte in der Mitte passieren müssen) kommt es dort nur zu symbolischen Veränderungen, wie z.B. Scrum in Komponententeams.


Eine populäre Deutung für das Air Sandwich ist, dass die in der Mitte liegenden Management-Schichten kein Interesse haben sich selbst ändern zu müssen, weshalb sie derartige Anweisungen einfach nach unten durchreichen. Sie sagt aber meistens mehr über das Menschenbild des so Urteilenden aus als über die Realität. Eine wahrscheinlichere Erklärung ist aber, dass das Gesamtsystem so konstruiert wurde, dass es durch die Umsetzung organisatorischer Veränderungen an seine Grenzen gebracht wird.


Zur Erklärung: in den meisten klassischen Organisationen ist es eben nicht die Aufgabe der mittleren Schichten Organisationsveränderungen durchzuführen, stattdessen haben sie vor allem eine Kommunikationsfunktion: auf dem Weg von oben nach unten werden Ziele und Anweisungen immer weiter ausdetailliert und auf die verschiedenen Empfänger aufgeteilt, auf dem Weg nach oben werden Rückmeldungen und Ergebnis-Berichte immer weiter zusammengefasst und vereinheitlicht.


Um zu verhindern dass eine Umstellung auf agiles Arbeiten durch ein Air Sandwich wirkungslos wird sind demnach zwei Dinge elementar: zum einen muss allen Beteiligten klar werden, dass in der Mittelschicht nicht nur die Veränderungs-Vision nach unten durchkommuniziert werden muss, sondern dass in diesem Rahmen auch organisatorische Veränderungen geplant und durchgeführt werden müssen. Zum anderen muss klar sein, dass viele klassische Mittelschichten darin weder Expertise noch Erfahrung haben1.


Natürlich sind derartige Überlegungen und Erkenntnisse zunächst einmal frustrierend, da durch sie klar wird, dass Veränderungsbemühungen schwieriger sind als gedacht und meistens eine Unterstützung durch externe Experten benötigen. Auf der anderen Seite bewahren sie aber auch davor, dass als einziges Ergebnis das entsteht was in Air Sandwiches in beliebiger Menge erzeugt werden kann: heisse Luft.


1Es gibt zwar Change Management-Einheiten, aber das ist nochmal ein eigenes Thema.

Freitag, 4. Juni 2021

Lots of systems all over the place

Wer häufiger in der agilen Filterblase unterwegs ist kennt Woody Zuill vor allem als Pionier des Mob Programming und der NoEstimates-Bewegung, in diesem Talk redet er aber über das Management. Genauer gesagt darüber, welche Fehlannahmen, Fehlwahrnehmungen und unhinterfragten Handlungsmuster dazu führen, dass viele Management-Entscheidungen trotz guter Intention keine Verbesserungen zur Folge haben, sondern eher das Gegenteil.



Angesichts des Themas ist es übrigen um so bemerkenswerter welche Art von Präsentation er benutzt, die ist nämlich weit, weit weg von dem was Manager üblich zu sehen bekommen. Aber wer weiss, vielleicht ist gerade das gar nicht so schlecht.

Montag, 31. Mai 2021

Kommentierte Links (LXXV)

Grafik: Pixabay / The Digital Artist - CC0 1.0

Kai Pukall: Kann man Businesswert messen?

Das Thema Business Value, bzw. dessen Bestimmung und Messung ist einer der grossen Klassiker für agile (und nicht-agile) Teams, Produktmanager und Unternehmen. Was Kai Pukall hier zurecht anmerkt ist, dass es sich dabei grösstenteils um Business-Theater handelt. Die Zukunft vorauszusagen (und mit ihr die Gewinne oder Einsparungen die sich mit einem Produkt oder Feature erzielen lassen) ist nicht möglich, aber ganz umsonst ist die Beschäftigung mit dem Thema nicht - es lassen sich so Indikatoren, Wahrscheinlichkeiten und Risiken identifizieren. Aus meiner persönlichen Erfahrung würde ich noch einen weiteren oft unterschätzten Mehrwert von Business Value-Diskussionen einwerfen: sie helfen dabei Anforderungen aus den Backlogs und Roadmaps herauszunehmen die fast keinen Wert haben, aber trotzdem irgendwann eingeplant wurden. Das ist oft schmerzhaft, bringt aber sehr viel.

Neil Rahilly, Casey Winters, Fareed Mosavat, Keya Patel: The art of removing features and products

Apropos herausnehmen. Was hier ein "Autorenkollektiv" aus den Firmen Reforge und Mixpanel zusammengetragen hat ist die umfangreichste Auseinandersetzung mit dem Thema des Ausbauens von Produkt-Features die ich bisher gelesen habe. Angefangen bei den Gründen dafür (Spoiler: es gibt auch gute Gründe für das Entfernen von Features deren Einführung Sinn gemacht hat), über die technischen, menschlichen und wirtschaftlichen Probleme die dabei auftreten können bis hin zu den Erfolgsfaktoren und notwendigen oder hilfreichen organisatorischen Rahmenbedingungen. Ein Text der jedem Product Owner und Produktmanager wärmstens zu empfehlen ist.

Steve Denning: How To Lead Change From Anywhere

Vor allem in grossen Organisationen ist eines der grössten Hindernisse für positive Veränderungen die weit verbreitete Meinung, selbst nicht der Lage zu sein dazu beitragen zu können (→ Untertanenkultur). Dass das nicht so ist wird zwar von Change Managern und Agile Coaches immer wieder betont, wie es vor sich gehen kann wird aber häufig nicht gesagt. Steve Denning stösst in diese Lücke und gibt eine gute Anleitung zum Verändern einer Organisation "von unten". Wie immer muss zwar auch hier klar sein, dass es sich um eine Inspiration handelt und nicht um eine Blaupause, es ist aber auf jeden Fall vieles dabei was sich in fast jedem Kontext anwenden lässt.

Jason Yip: Making the rules explicit becomes more critical shifting from co-located to remote

Das Explizit machen von Regeln ist einer der grossen Klassiker im Rahmen agiler Transitionen und führt immer wieder zu wertvollen Erkenntnissen. Das gilt bereits dann wenn Teams in Co-Location zusammensitzen, es gilt aber nochmal verstärkt im Fall von Remote-Arbeit. Was Jason Yip völlig zu Recht anmerkt ist, dass in diesem Fall die implizite Kommunikation wegfällt, sowohl in Bezug auf das weniger sichtbar werdende Verhalten der anderen Teammitglieder als auch in Bezug auf die abnehmbare Sichtbarkeit der Aktionen von Experten und erfahrenen Kollegen, an denen andere (bewusst oder unbewusst) ihre Handlungen ausgerichtet haben. Yip geht soweit, dass er nicht nur das Explizit Machen von Arbeits- und Entscheidungsprozessen sondern auch von Informationsströmen empfiehlt, um so in Summe alles abzubilden was für die Produktentwicklung relevant ist.

Gojko Adzic: Nijute - how to solve impossible problems

Ich gebe zu, auch ich neige vermutlich manchmal dazu, im Kanban-Umfeld (zu) viele japanische Lehnwörter zu benutzen. Aus diesem Grund fühlte ich mich leicht ertappt als Gojko Adzic mit seinem japanisch klingenden (?) Begriff "Nijute" ein bisschen die Agile-Community trollte, bei dem es sich in Wirklichkeit um die Abkürzung für "Not Impossible, Just Too Expensive" handelt. Unanhängig von diesem Hintergrund kann man ihm nur zustimmen, dass "möglich, aber zu teuer" bei Machbarkeitsdiskussionen ein besseres Argument ist als das häufig benutzte "das geht nicht". Weshalb das so ist und warum hinter dieser Aussage mehr steckt als im ersten Moment zu vermuten kann man schön herausgearbeitet bei ihm nachlesen.

Freitag, 28. Mai 2021

2001 Agile vs 2021 Agile

Grafik: Pixabay / Bytrangle - CC0 1.0

Während der letzten Monate ist Jeff Patton, einer der bekannten Vordenker der agilen Bewegung, in zwei Podcasts zu Gast gewesen die ich zufällig kurz nacheinander gehört habe (nachzuhören hier und hier). Unter seinen vielen anregenden Denkanstössen stach in beiden Auftritten einer heraus: in Pattons Wahrnehmung haben wir heute ein anderes Verständnis von Agilität als die Verfasser des Manifests für agile Softwareentwicklung vor 20 Jahren, denen wir den Begriff immerhin verdanken.


Das ist insofern bemerkenswert, da das agile Manifest eigentlich als zeitlos gültiges Dokument konzipiert wurde und von seinen Verfassern und dem überwiegenden Teil der "agilen Bewegung" auch bis heute noch so gesehen wird. Patton vertritt hier also eine Minderheits-Meinung, wenn auch eine die er gut begründen kann. Und angesichts seiner anerkannten Verdienste und Expertise ist diese Meinung eine nähere Betrachtung wert.


Ein zentraler Unterschied zwischen den Verständnissen von 2001 und von 2021 den er sieht ist die unterschiedliche Bedeutung von Product Discovery, Outcome-Orientierung und Erfolgsmessung. Seiner Auffassung nach spielten diese schon im New New Product Development Game vorhandenen Konzepte auf der legendären "Leightweight Methods Conference" in Snowbird/Utah keine Rolle, während sie heute aus agiler Produktentwicklung nicht mehr wegzudenken sind.


Was er dagegen im agilen Manifest noch sehr stark wahrnimmt ist eine Betonung des Delivery-Aspekts, die er an den Formulierungen "deliver working software frequently" und "working software is the primary measure of progress" festmacht. Die Ursache dafür sieht er in den Berufen der Verfasser des agilen Manifests, bei denen es sich grossteils um externe Berater und Entwickler handelte, deren Beruf weniger aus Produktinnovation und mehr aus der Umsetzung von Kundenaufträgen bestand.


Ein dritter Unterschied liegt für ihn im technischen Fortschritt begründet - 2001 wurde Software noch auf CDs und DVDs verschickt und war nach dem Absenden für die Entwickler nicht mehr erreichbar, diese mussten also möglichst perfektionistisch arbeiten. Abweichend davon machen die heute durchführbaren Updates über das Internet es möglich auch frühe und noch unperfekte Versionen auszuliefern und sie im laufenden Betrieb kontinuierlich zu optimieren und zu erweitern.


Soviel zu Pattons zentralen Punkten, jetzt zur eigentlich interessanten Frage - hat er recht? Die nicht ganz befriedigende Antwort: in gewisser Weise schon, je nach Sichtweise aber auch nicht. Er hat recht damit, dass Product Discovery, Outcome-Orientierung, Erfolgsmessung und Continuous Delivery im Manifest für agile Softwareentwicklung nicht explizit genannt werden. Aber - wenn man es möchte lassen sie sich implizit aus den anderen Punkten ableiten, z.B. Continuous Delivery aus dem "Constant Pace".


Vielleicht ist aber auch gerade das eine Besonderheit dieses Dokuments: obwohl sich die Nutzergewohnheiten, Produktlebenszyklen und technischen Rahmenbedingungen über die letzten 20 Jahre deutlich verändert haben lässt es sich für jeden Zeitpunkt dieser Spanne so interpretieren, dass eine für diesen Moment passende Interpretation von Agilität entsteht. Damit wäre es also doch zeitlos (was Pattons Denkanstösse übrigens nicht weniger wertvoll macht).


Nachtrag:

Zum Thema Agile 2001 vs Agile 2021 passt auch diese Äusserung von Ron Jeffries, einem der Unterzeichner des Manifests:

Dienstag, 25. Mai 2021

Begriffs-Entfrachtung

Bild: Wikimedia Commons / Rohit Choudhary Raj - CC BY-SA 3.0

Zu den grossen Problemen nahezu aller agilen Transformationsvorhaben (und auch vieler Firmen die ihre Arbeitsweisen bereits umgestellt haben) gehört die Unklarheit des Begriffs "Agil". An keiner Stelle (auch nicht im Manifest für agile Software-Entwicklung) wird definiert was genau darunter zu verstehen ist, man kann lediglich versuchen es sich aus dem Kontext herzuleiten - in irgendeiner Form läuft es auf beweglich, schnell und reaktionsfähig heraus, völlig klar wird es aber nicht.


Diese Unklarheit hat mit der Zeit dazu geführt, dass der Begriff mitunter sehr weit ausgelegt und manchmal sogar erweitert wird. Immer wieder werden verschiedene ähnliche, verwandte oder nicht im Widerspruch stehende Konzepte zu (halb)offiziellen Elementen der Agilität erklärt. Das ist in verschiedener Hinsicht problematisch: zum einen wird die Umsetzung unnötig eingeengt, zum anderen liefert es all jenen Munition die nach Gründen suchen um das Konzept ablehnen zu können.


Um die Diskussion und die Umsetzung wieder zurück zu Klarheit, Offenheit und Realismus zu führen kann es nötig sein den Begriff zu "entfrachten" ihn also von allem zu befreien was ihm nachträglich aufgeladen wurde. Das macht sowohl zu Beginn agiler Transitionen Sinn als auch bei Firmen und Teams die schon länger so arbeiten, bei denen sich aber (ggf. unbemerkt) derartige Überfrachtungen eingeschlichen haben.


Vermutlich das häufigste Überfrachtungselement ist die Überzeugung, dass agiles Arbeiten erfordert, "dass jeder alles kann". Abgeleitet von dem Wunsch Crossfunktionalität zu haben und Flaschenhälse zu vermeiden ist die Grundidee Wissen zu verteilen zwar richtig, in diesem Extrem führt sie aber entweder dazu, dass die Betroffenen sich überfordert fühlen oder dazu, dass sie unverhältnismässig viel Zeit für Lernen und Ausprobieren einfordern.


Ein weiteres Element mit dem agile Arbeitsweisen überfrachtet werden ist Basisdemokratie. Vermutlich ausgehend von den hohen Mitbestimmungsrechten der agilen Teams stösst man in vielen Organisationen auf Menschen die der Meinung sind, dass in einem "wirklich agilen" Unternehmen auch über Entscheidungen zu Produktstrategie oder Stellenbesetzungen abgestimmt werden müsste. Aber bei aller Liebe zur Demokratie - um schnell liefer- und reaktionsfähig zu sein braucht man sie nur bedingt.


Oft mit der Forderung nach Demokratie einhergehend kommt als drittes Überfrachtungselement der Konsens-Zwang. Ohne dass klar ist wie diese Idee entstanden ist herrscht in vielen Teams die Überzeugung vor alle Entscheidungen einstimmig treffen zu müssen, mitunter wird auch gefordert das auf grössere Organisationseinheiten zu übertragen. Hier droht sogar das Gegenteil von Agilität - lähmende Dauer-Debatten bis endlich alle zustimmen.


Ebenfalls immer wieder anzutreffen ist die Überzeugung, dass konsequent agil arbeitende Firmen ihren Kunden jeden denkbaren Wunsch erfüllen müssten. So naheliegend das angesichts des hohen Wertes der Kundenorientierung auch klingt, stimmen tut es nicht. Spätestens bei dem (menschlich verständlichen) Kundenwunsch immer die höchste Qualität zum niedrigsten Preis haben zu wollen muss sich die Frage nach der Wirtschaftlichkeit stellen.


Und auch das kann in Extremfällen auftreten: die Überzeugung, dass agile Unternehmen eher gemeinwohl- als gewinnorientiert arbeiten müssten. Man kann die Ursache dafür vermutlich bei den amerikanischen XP- und Scrum-Teams der 90er Jahre finden, die sich ihre Handlungsfreiheit noch gegen das Shareholder Value-getriebene Management erkämpfen mussten, eine daraus abgeleitete grundlegende Ablehnung von Gewinnorientierung ist aber eher anarchistisch als agil.


Die Liste liesse sich noch weiterführen, die Grundproblematik ist aber klar: sobald sich die Überfrachtung des Begriffs "Agil" mit einem oder mehreren der hier genannten Aspekte in den Köpfen festgesetzt hat wird der Versuch so zu arbeiten eher zu Frustration und Unwillen führen als zu Erfolgen. Da dieses Antipattern in vielen Fällen aber unbewusst herbeigeführt wird oder schleichend und unbemerkt entsteht kann man es kaum verhindern. Also was tun?


Ein Lösungsansatz ist es, möglichst früh eine intern geltende "offizielle Definition" des Begriffs zu verfassen, idealerweise eine die sich auf die Kernaspekte der Liefer- und Reaktionsfähigkeit beschränkt und breit kommuniziert wird. Die kann dann regelmässig genutzt werden um sich zu fragen ob sich mittlerweile alte oder neue Überfrachtungselemente eingeschlichen haben, die dann wieder entfernt werden sollten.


Und bevor es zu Missverständnissen kommt: das heisst nicht, dass man diese Ideen nicht nutzen könnte. Wenn eine Organisation z.B. alles im Konsens entscheiden will, nur zu. Sie sollte das nur nicht deshalb tun weil es angeblich zur Agilität gehört.

Samstag, 22. Mai 2021

Customer-Vendor Antipattern (II)

Bild: Pixabay / Suju-Foto - CC0 1.0

Würde man die populärsten Missverständnisse über Scrum sammeln gäbe es eines das ganz sicher weit oben in der "Beliebtheitsskala" auftauchen würde: das, dass sich der Inhalt eines Sprints nicht mehr ändern darf sobald er gestartet wurde. Gerade weil es so verbreitet ist lohnt sich ein näherer Blick. Worum geht es in diesem Missverständnis, wie konnte es zu ihm kommen und überhaupt - was ist eigentlich falsch daran?


Zunächst zur Erläuterung. Im Rahmen eines Sprints, also eines Zeitraumes von ein bis vier Wochen, liefert ein Scrum Team eine bestimmte Menge an Mehrwert ab, z.B. in Form neu programmierter Software-Features. Diese zu liefernden Features werden vor dem Sprint in Anforderungen beschrieben (häufig in Form von User Stories) und in das so genannte Sprint Backlog übernommen, das im Sprint abgearbeitet wird. An dieser Stelle steht dann häufig das Missverständnis: viele Menschen glauben, dass während des Abarbeitens keine Änderungen an diesen Anforderungen mehr stattfinden dürfen.


Wann dieser populäre Irrtum entstanden ist lässt sich zwar nicht mehr genau rekonstruieren, die mit ihm regelmässig mitgelieferten Begründungen lassen aber erahnen wie das geschehen sein dürfte. Von Product Owner-Seite heisst es meistens, dass die Entwickler sich durch Änderungen am Sprint-Inhalt aus den gemachten Zusagen herauswinden könnten, von Entwickler-Seite, das ihnen der Product Owner auf diese Weise zusätzliche Arbeit unterschieben könnte. Beides lässt tief blicken.


Was aus diesen Aussagen erkennbar wird ist, dass sich hier alle Beteiligten im Customer-Vendor Antipattern verfangen haben. Beide betrachten den Sprintumfang als das Ergebnis einer Verhandlung in der sie versucht haben der jeweils anderen das Maximum an Zugeständnissen abzuringen. Der Product Owner hat möglichst viele Anforderungen in den Sprint drücken wollen, die Entwickler dagegen haben deren Menge möglichst gering halten wollen um ohne Zeitdruck arbeiten zu können.


Auch eine ähnliche Variante kommt häufig vor: in ihr ist es nicht der Product Owner der den Entwicklern möglichst hohe Zusagen abringen will sondern es sind ausserhalb des Teams stehende Stakeholder. Der Product Owner befindet sich in dieser Konstellation entweder gemeinsam mit den Entwicklern in einer Abwehrhaltung oder eher befindet sich in einer Zwischenposition in der er es keiner der beiden Seiten recht machen kann.


Die Auswirkungen des Customer-Vendor Antipatterns können weit über das Team hinaus verheerend sein. Latentes Misstrauen im Refinement, erbittertes Feilschen im Planning, ein Gefühl des übervorteilt worden Seins im Review und gegenseitige Vorwürfe in der Retrospektive sind häufig auftretende Folgen dieser gegeneinander gerichteten Positionierung der Teammitglieder, die den Ruf der Beteiligten, der angewandten Methodik aber auch der diese Konflikte zulassenden Firma schwer beschädigen können.


Um es dazu nicht kommen zu lassen ist es dringend anzuraten bereits auf erste Zeichen dieses Antipatterns zu achten und ihnen von Anfang an entgegenzutreten. Das kann innerhalb des Teams durch Retrospektiven geschehen oder ausserhalb dadurch, dass übergriffige Stakeholder in ihre Schranken gewiesen und die Autorität des Product Owners ihnen gegenüber gestärkt wird, es kann aber auch durch Arbeit an den Rahmenbedingungen geschehen.


Die einfachste Art das zu tun führt dabei wieder zurück zum Beginn dieses Textes, denn sie besteht aus der Beseitigung des Missverständnisses, dass der Inhalt eines Sprints sich nicht mehr ändern darf sobald er gestartet wurde. Richtig ist in Scrum nämlich, dass der Sprintinhalt sehr wohl geändert werden kann (siehe hier), lediglich das Sprint-Ziel nicht. Mehr noch: der Sprint-Inhalt muss sogar geändert werden sobald das Sprint-Ziel gefährdet ist, um es zumindest in einer abgespeckten Version erreichen zu können. Und umgekehrt: wenn es früher als gedacht erreicht wird kann Arbeit nachgezogen werden.


Hat ein Scrum Team diese Vorgaben einmal verinnerlicht wird das Customer-Vendor Antipattern von sich aus nach und nach verschwinden, alleine deshalb weil alle mühsam erfeilschten zu grossen oder zu geringen Zusagen wieder ausgeglichen werden sobald klar wird, dass sie an der Realität vorbeigehen. Die Möglichkeit und damit auch der Anreiz den anderen zu übervorteilen entfallen einfach, und als Folge dessen gehen auch die schädlichen Verhaltensweisen zurück.

Montag, 17. Mai 2021

Sprintfähigkeit (wieder)herstellen

Bild: Pexels / Jonathan Borba - CC0 1.0

Auf den ersten Blick sieht Scrum wie eine Arbeitsweise aus auf die man sich einfach umstellen kann, der Scrum Guide scheint schliesslich lediglich den Sprint, die drei Rollen, die vier Meetings und die drei Artefakte vorzugeben. Das scheint sich schnell einführen zu lassen. Auf den zweiten Blick wird es allerdings deutlich schwieriger, denn das dritte der drei Artefakte hat es in sich: das Increment ist eine neue, benutzbare Produktversion, und davon muss es mindestens eine pro Sprint geben.


Wer schon einmal in einem komplexen Produktentwicklungs-Umfeld gearbeitet hat wird erkennen welche Herausforderung das bedeuten kann: die initialen Anforderungen müssen so geklärt sein, dass die Arbeit an ihnen sofort beginnen kann, das Team muss crossfunktional genug sein um nicht auf Zulieferungen warten zu müssen und Tests und Deployments müssen automatisiert sein um möglichst schnell stattfinden zu können.


Die wenigsten Teams die bisher in einem eher klassischen Umfeld mit bürokratischem Anforderungs-Management, starker Arbeitsteilung und vielen manuellen Arbeitsschritten gearbeitet haben werden aus dem Stand dazu in der Lage sein, mit dem Effekt, dass aus einem sofort gestarteten Sprint kein auslieferbares Increment entstehen kann (und aus den nächsten vermutlich auch nicht). Frustration und Enttäuschung wären die Folge.


Um es dazu nicht kommen zu lassen ist es wichtig, dass vor dem ersten Sprint die Grundlagen dafür geschaffen werden ihn überhaupt durchführen zu können. Es wird häufig versucht das in einen so genannten Sprint 0 zu packen, was aber nicht immer funktioniert. Gerade in grösseren Organisationen können Wochen und Monate dafür nötig sein, was den Begriff des Sprints völlig konterkarieren und unbrauchbar machen würde.


Zielführender ist es in solchen Fällen überhaupt erstmal die Sprintfähigkeit herzustellen bevor man mit Scrum beginnt. Das kann ein letztes mal in Form eines klassischen Projekts entstehen, es kann aber auch nach einem anderen mehr oder weniger agilen Vorgehen durchgeführt werden. Wichtig ist in jedem Szenario aber ein klares Zielbild: nur wenn nachvollziehbar definiert ist welche Kriterien für eine Sprintfähigkeit zu erfüllen sind ist klar wann diese Vor-Phase vorbei ist.


Ein Sonderfall dieser Situation tritt ein wenn ein bereits nach Scrum arbeitendes Team seine Sprintfähigkeit verliert, zum Beispiel durch Personalabgänge oder ausfallende Infrastruktur. Der Scrum-Begründer Ken Schwaber empfiehlt in diesem Fall (zumindest bei grösseren Vorhaben) so genannte Scrumble-Phasen, in denen die Sprints ausgesetzt werden und stattdessen an der Wiederherstellung der Sprintfähigkeit gearbeitet wird.


Elementar in beiden Varianten ist, dass in ihnen ein möglichst ausschliesslicher Focus darauf liegt an den Voraussetzungen für Scrum zu arbeiten. Wird parallel dazu bereits mit der Arbeit am Produkt begonnen, werden diese fehlenden Voraussetzungen dazu führen, dass sich nicht integrierte Arbeit anstaut oder Vorarbeiten durchgeführt werden die sich später ggf. nicht abschliessen lassen. Beides würde wieder zu den Problemen führen für deren Beseitigung Scrum eigentlich erfunden wurde, es wäre also nicht im Sinne der Idee.