Donnerstag, 26. März 2020
Backlogs
 |
| Bild: Pixabay / Pandapotter - Lizenz |
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.
Montag, 23. März 2020
Sense of Urgency
 |
| Bild: Pixabay / Slonpics - Lizenz |
Dass sich das in so kurzer Zeit derartig radikal geändert hat, hat mit einem Phänomen zu tun, das im Change Management Sense of Urgency (übersetzt Gefühl der Dringlichkeit) genannt wird. Dabei handelt es sich um nicht weniger als um den heiligen Gral aller Veränderungsvorhaben - wenn der Sense of Urgency gegeben ist werden auch weitreichende Veränderungen von den Beteiligten und Betroffenen nicht nur hingenommen sondern sogar unterstützt, was im Change Management der anzustrebende Idealzustand ist.
Damit dieses Gefühl entsteht müssen in der Regel zwei Voraussetzungen gegeben sein: zum einen muss wirklich eine Dringlichkeit vorliegen, zum anderen müssen bei Nichtstun ernsthafte Konsequenzen drohen. Das scheint naheliegend, ist es in der Realität meistens aber nicht. In grossen Organisationen wird oft schon von einem Sense of Urgency gesprochen wenn in zwei Jahren eine Verrentungswelle ansteht, nach der Stellen extern (und damit teurer) besetzt werden müssen. Wie unsinnig eine solche Begriffsverwendung ist zeigt sich beim Vergleich mit echter Dringlichkeit: Börsencrashs, Produktionsausfällen, Security Breaches oder (wie im aktuellen Fall) Seuchenausbrüchen.
Der Vorteil eines bei Beteiligten und Betroffenen gegebenen Sense of Urgency ist, dass Reaktionsgeschwindigkeit und Handlungsspielraum schnell und massiv erweitert werden können. Das kann wie im aktuellen Fall bedeuten, dass mit Notstandsverordnungen regiert werden kann, auf die Wirtschaft übertragen aber z.B auch, dass die betriebliche Mitbestimmung oder regulierende Vorschriften tatsächlich oder de facto ausgesetzt werden. Es entsteht dadurch der sprichwörtliche "grosse Hebel", mit dem schnell reagiert und "durchregiert" werden kann.
Auf der anderen Seite stehen aber auch grosse Risiken die beachtet werden müssen. Im schlimmsten Fall kann sich der Sense of Urgency zu einer Massenpanik auswachsen, in deren Rahmen auch unverhältnismässige oder populistische aber wirkungslose Massnahmen durchgepeitscht werden. Zudem ist er zwar ein guter Ausgangspunkt für Hau Ruck-Veränderungen, flacht aber auch schnell wieder ab, weshalb er selten langfristige und nachhaltige Verbesserungsprozesse auslösen kann (einmal mehr sei an dieser Stelle Alan Deutschmanns Buch Change or Die empfohlen).
Zusammengefasst: der Sense of Urgency kann eine mächtige Veränderungskraft sein, der man sich aber mit Vorsicht anvertrauen sollte. Man kann mit ihm in kurzer Zeit viel erreichen aber auch viel beschädigen. Und wenn das Risiko besteht, dass diese Schäden an so fundamental wichtigen Stellen wie den Grundrechten oder der betrieblichen Mitbestimmung auftreten, dann sollte man sich sehr sicher sein, dass man sich nicht gerade von seiner Dynamik zu weit treiben lässt.
Donnerstag, 19. März 2020
Warum Meetings von verteilten Teams länger dauern
 |
| Bild: Pexels / Andrea Piacquadio - Lizenz |
Um dieses Verständnis zu bekommen bietet es sich an das Ganze von der anderen Seite aus zu betrachten - warum sprengen zusammensitzende Teams1 deutlich seltener die Timebox ihrer Meetings? Die vereinfachte Antwort: weil ihre Kommunikation grösstenteils ausserhalb dieser Termine stattfindet, so dass in ihnen ein ganz anderer Focus möglich ist. Und auch die Art dieses Informationsaustausches ausserhalb der Meetings kann man differenzieren, in beiläufige Kommunikation und implizite Kommunikation.
Das einfacher zu verstehende der beiden Konzepte ist die beiläufige Kommunikation. Darunter fällt jeder Austausch zu beruflichen Themen der ohne formellen Anlass stattfindet, meistens dann wenn die Beteiligten sich mehr oder weniger zufällig begegnen. In der Mittagspause, an der Kaffeemaschine, auf dem Weg vom Parkhaus zum Büro, etc. Gegebenenfalls kann sie auch spontan im Büro entstehen, z.B. mit der über den Tisch gerufenen Aufforderung "So, ich bin fertig. Willst Du es Dir ansehen?"
Implizite Kommunikation ist dagegen ein eher unsichtbarer und oft sogar unbeabsichtigter Austausch von Informationen. Dazu gehören Gestik und Mimik, durch die z.B. Begeisterung, Ablehnung oder Ratlosigkeit sehr effektiv übermittelt werden können, es gehören aber auch Informationsübermittlungen dazu für die man nicht einmal gleichzeitig in einem Raum anwesend sein muss. Der aus dem Besprechungszimmer herausschallende emotionale Ausbruch wäre ein Beispiel, oder die Spuren eines nicht zu Hause sondern spät im Büro eingenommenen Abendessens.
Diese beiden Kommunikationsformen fallen weg wenn die Teammitglieder nicht mehr zusammensitzen. Da die auf diese Art vermittelten Informationen (oder der sich aus ihrem Fehlen ergebende Klärungsbedarf) aber wichtig sind wird meistens versucht sie in dem einzigen gemeinsamen Forum auszutauschen das verblieben ist - den Meetings. Diese werden dadurch mit einer viel grösseren Anzahl von Themen überladen als vorher und dauern dementsprechend auch deutlich länger.
Sich über diese Mechanismen bewusst zu sein ist auch der erste Schritt auf dem Weg zur Lösung des Problems. Wenn sie den Beteiligten bewusst sind kann darauf aufbauend versucht werden sie zu kompensieren. Eine Möglichkeit ist z.B. eine gemeinsame "virtuelle Kaffeepause" am Nachmittag, also eine kurze Videokonferenz mit keinem anderen Zweck als einem schnellen Austausch ohne vorgegebene Agenda (z.B. als Lean Coffee), eine andere wäre eine digitale Instant Implementation Hour, in der kleinere Anliegen gebündelt werden können. Je nach Kontext gibt es aber noch viele weitere.
Mit ein bisschen Übung kann ein derartiges Vorgehen das Phänomen der ausufernden Remote-Meetings nicht nur abschwächen sondern sogar weitgehend kompensieren. An einer Stelle muss die Erwartungshaltung aber realistisch bleiben: so effektiv wie bei zusammensitzenden Teams wird die Kommunikation von Remote-Teams nie werden. Man kann aber versuchen dem so nahe zu kommen wie möglich.
1Die Rede ist hier von Teams die schon eine gewisse Erfahrung in agilem Arbeiten haben. Bei Teams in Umbruchphasen ist die Lage nochmal anders.
Montag, 16. März 2020
Von schwarzen und grauen Schwänen
 |
| Bild: Wikimedia Commons / Squacco - CC BY-SA 2.0 |
Definiert durch John Stuart Mill und Nassim Taleb basiert sie auf der bis ins 18. Jahrhundert üblichen Redensart "so wahrscheinlich wie ein schwarzer Schwan", mit der ausgedrückt werden sollte, dass etwas völlig unmöglich ist. Der Hintergrund war, dass alle damals bekannten Schwanen-Arten weiss waren. Dieses Sprichwort wurde gegen 1700 widerlegt, als in Australien schwarze Schwäne entdeckt wurden. Das scheinbar Unmögliche war Realität geworden.
In Anlehnung an diese historische Kuriosität verwandten Mill und Taleb den Begriff des schwarzen Schwans als Beschreibung für ein extrem unwahrscheinliches Ereignis, das dann plötzlich doch eintritt. Und während Mill es dabei beliess definierte Taleb (auf dessen gleich benanntes Buch die heutige Verwendung zurückgeht) den Begriff weiter aus. Für ihn gehören (neben anderen, die eher für die rückblickende Betrachtung relevant sind) folgende Charakteristika dazu:
- völlige Unvorhersehbarkeit und Unvorstellbarkeit
- plötzliches Auftreten ohne Vorwarnung
- schwere Konsequenzen1
Angewandt auf die gegenwärtige Situation fällt auf, dass diese Kritierien hier nicht alle gegeben sind. Selbst wenn es in der jüngeren Vergangenheit keine derartigen Pandemien in der westlichen Welt gegeben hat, in anderen Weltgegenden und etwas weiter in der Vergangenheit auch in Europa gab es sie durchaus. Russische Grippe, Spanische Grippe, Asiatische Grippe, Ebola-Fieber, SARS, Schweinegrippe und MERS sind bekannte Fälle der letzten 150 Jahre, SARS und MERS sind dabei sogar mit den aktuell umgehenden Coronaviren verwandt.
Der Begriff des Schwarzen Schwans dürfte damit sowohl nach der Definition von Mill als auch nach der von Taleb eher unpassend sein, denn selbst wenn das Ausmass ohne historischen Vergleich sein mag, das Auftreten einer globalen Krankheit ist es nicht. Passender für die Beschreibung dürfte die ebenfalls von Taleb geprägte abgeschwächte Variante sein, der "Graue Schwan". Dieser ist definiert als ein zwar sehr seltenes aber bekanntes Phänomen, das in ungeahnter Stärke und Plötzlichkeit auftritt. Auf die Coronavirus-Pandemie trifft das zu.
Soweit die Begriffsabgrenzung, jetzt zur finalen Frage: hat diese Differenzierung noch einen Mehrwert über geisteswissenschaftliche Wortklauberei hinaus? Ja, hat sie, denn die Erwägung der vorbeugenden Massnahmen die in den beiden Fällen ergriffen werden können sind jeweils andere. Im Fall des Grauen Schwans kann kontrafaktisches Denken helfen, also die Überlegung wie eine bereits bewältigte Krise noch schlimmer hätte enden können.2 Im Fall des Schwarzen Schwans hilft es nur alle Abläufe und Strukturen so zu optimieren, dass schnelle Entscheidungen möglich sind sobald eine solche Situation eintritt.
1Letzteres natürlich nicht von den australischen Schwänen abgeleitet sondern dazudefiniert
2Dieses Vorgehen führte z.B. zu den erstaunlichen Erfolgen bei der Corona-Bekämpfung in Taiwan
Donnerstag, 12. März 2020
The unexpected benefit of celebrating failure
Zugegeben, alleine der Name von Astro Teller ist irgendwie cool, das was er zu sagen hat aber auch: es geht darum wie in Firmen wie Google das Scheitern von Projekten als etwas Positives gesehen und genutzt wird. Und ein gutes Zitat ist auch dabei: "Skeptizismus und Optimismus sind keine Gegensätze."Montag, 9. März 2020
(Kein) Powerpoint
Eine Beobachtung die man bei vielen Scrum Mastern und Agile Coaches machen kann ist die, dass sie selten bis nie Powerpoint oder vergleichbare Programme benutzen. Stattdessen wird auf Flipcharts, Whiteboards und Tafeln gemalt und geschrieben, Post Its werden an die Wand geklebt und Karten hochgehalten. Das ist eine derartig zentrale Abweichung von den üblichen Gepflogenheiten des Büroalltags, dass sich ein näherer Blick auf die Ursachen lohnt.
Als wichtige historische Rahmenbedingung ist zunächst die Herkunft der heutigen agilen Frameworks aus der IT zu nennen. Viele Scrum Master haben früher in ihrer Karriere Code geschrieben und sind daher daran gewöhnt, dass Arbeitsergebnisse auch nüchtern, schlicht und schmucklos sein können. Vor allem das für Präsentationen typische "Aufhübschen" ist in diesem Berufsverständnis irrelevant. Entweder etwas macht Sinn oder eben nicht, Ästhetik ist da eher sekundär.
Die zweite "historische Wurzel" ist die starke Abgrenzung der aus den Umsetzungs-Einheiten entstandenen agilen Bewegung zu den sich eher an das Management richtenden klassischen Unternehmensberatungen. Selbst bei den mittlerweile existierenden agilen Beratern wird dieser Unterschied weiterhin kultiviert und äussert sich neben der Ablehnung von beratertypischem Kleidungsstil und Fachjargon auch in der Meidung von Powerpoint als dem klassischen Beraterwerkzeug.
Neben diesen historisch-ideologischen Gründen gibt es aber auch ganz praktische wegen denen digitale Folienschlachten abgelehnt werden. Der offensichtlichste: das meistens groteske Missverhältnis zwischen Erstellungsaufwand und Nutzungsdauer. In grossen Organisationen fliessen oft Stunden oder sogar Tage in übertrieben perfektionistische Präsentationen, die dann nur für Minuten an die Wand geworfen werden. Wer die Steigerung von Effektivität und Effizienz zu seinem Beruf gemacht hat wird das instinktiv verabscheuen.
Ebenfalls ein Ärgernis ist das Verhalten von Meeting-Teilnehmern, das durch Powerpoint getriggert wird. Präsentationen mit vielen Informationen, mit gutem Design oder mit Animationen und eingebetteten Medien (und irgendetwas davon ist fast immer vorhanden) ziehen automatisch die Aufmerksamkeit weg vom Vortragenden und hin zum Bildschirm oder Beamer. Die Folge ist ein Fehlen von Focus und Verständnis, wodurch Termine nachhaltig entwertet werden.
Zuletzt zwingt ein vorbereiteter Foliensatz einem Meeting, bzw. einem Referenten eine starre Agenda auf. Wenn im Rahmen der Durchführung Gesprächsbedarf zu neuen Themen entsteht wird der häufig nicht bedient, da ja keine Folien dafür vorliegen. Und selbst wenn Themenblöcke nur untereinander vertauscht werden wird das Vor- und Zurückspringen (samt des kurzen Auftauchens der dazwischenliegenden Folien) den Ablauf für den Vortragenden hektisch und für die Zuhörer verwirrend machen.
Mit während des Meetings beschrifteten Flipcharts und Whiteboards treten all diese Probleme nicht mehr auf, weshalb sie mit der Zeit zu den bevorzugten Präsentationsmitteln von Scrum Mastern und Agile Coaches geworden sind. Es erfordert zwar gewisse Fertigkeiten in den Bereichen Tafelschrift und Visualisierung, die sind aber erlernbar. Und als unbeabsichtigter Nebeneffekt wirkt das gleichzeitige Miteinander von Vortrag und Visualisierung häufig so beeindruckend, dass es zur Soft Power of Scrum beiträgt.
Freitag, 6. März 2020
Das Scrum-Schisma
 |
| Bild: Pixabay / Schach 100 - Lizenz |
Um zu verstehen wie diese Trennung entstanden ist hilft ein Blick in die Vergangenheit. In seiner ersten schriftlichen Form ist das heutige Scrum noch als teambasiert zu erkennen. Das OOPSLA-Paper von 1995 spricht eindeutig vom "Scrum Project Team" mit Subteams für Produktmanagement und Entwicklung. Es wird zwar betont, dass zum Entwicklungsteam auch Vertreter von Marketing, Vertrieb und anderen Funktionen gehören müssen, die Zusammenarbeit mit der umgebenden Organisation ist aber noch kein Thema.
Der seitdem entwickelte "offizielle Weg", vertreten von den Gründern Schwaber und Sutherland und den Verbänden Scrum Alliance und Scrum.org, ist (zugespitzt) der, dass sich das restliche Unternehmen nach dem Scrum Team zu richten hat. Laut Scrum Guide muss die gesamte Organisation die Entscheidungen des Product Owners respektieren, das Entwicklungsteam ermächtigen seine Arbeit selbst zu managen und wird in ihrer Umstellung auf Scrum von den Scrum Mastern geführt.
Dass das eher unbekannt ist liegt wesentlich an der Abneigung von Schwaber und Sutherland gegen zu spzifische Prozessbeschreibungen, die dann im Einzelfall nicht mehr passen würden. Die Art der Umsetzung ist daher bewusst offengelassen, die quasi-offiziellen Skalierungsframeworks LeSS und Nexus stimmen aber darin überein, dass die Verantwortung des Product Owners für alle an diesem Produkt arbeitenden Teams ein wesentliches Element ist.
Wesentlich häufiger als der "offizielle Weg" ist in Unternehmen die Situation vorzufinden, dass Scrum (und ähnliche Ansätze) auf die Teamebene beschränkt werden, und auch dort häufig nur auf die Umsetzung, während Planung, Architekturentscheidungen und Kunden-/Auftraggeberkontakt an andere Gruppen ausgelagert werden. Bekannt ist in diesem Zusammenhang SAFe mit seinen zahlreichen Rollen, aber auch PMI und Prince2 haben (eingeschränktes) Scrum bei sich integriert.
Diese Formalisierung ist aber letztendlich nichts anderes als das offiziell Machen der bereits in vielen Unternehmen schon länger gelebten Praxis. Ohne Kenntnis des übergreifenden Anspruchs (oder ohne Bereitschaft ihn zu akzeptieren) ist Scrum an vielen Stellen schon seit längerem ein reiner Team-Ansatz, der damit zwar die reine Lehre nicht erfüllt, meistens aber besser funktioniert als das vorher genutzte Mikromanagement.
Zu einem Zusammenprall der beiden unterschiedlichen Scrum-Auslegungen kommt es vor allem dann wenn Angestellte oder Berater mit einem Hintergrund der einen Scrum-Variante in ein Unternehmen kommen in dem die andere gelebt wird. Ein Konflikt ist dann unvermeidbar, der aber je nach Kenntnisstand unterschiedlich ausgetragen werden kann. Da wo den Beteiligten das "Scrum-Schisma" bewusst ist kann versucht werden zu einer Lösung zu kommen, da wo davon ausgegangen wird, dass das jeweils "eigene" Scrum auch das einzige ist reden sie aneinander vorbei.
Dienstag, 3. März 2020
The agile Bookshelf: Change or die
 |
| Bild: Pixabay / sbtlneet - Lizenz |
In seinem Buch Change or die, das auf einem Artikel mit dem gleichen Namen basiert, versucht der Journalist Alan Deutschmann die Ursache für die häufig fehlende Veränderungsbereitschaft zu ergründen, und das gleich zu Beginn an einem drastischen Beispiel: obwohl sie sich bewusst sind, dass sie damit den eigenen Tod in Kauf nehmen, ändern viele Menschen mit Herzerkrankungen ihren Lebenswandel nicht. Auch an anderen Beispielen aus Wirtschaft und Gesellschaft zeigt Deutschmann auf, dass selbst harte drohende Konsequenzen oft kein ausreichender Grund für Änderungen sind.
Die Ursache dafür sieht er in der klassischen Art wie Veränderungsbedarfe kommuniziert werden. Er selber benutzt dafür die Begriffe Facts, Fear und Force (Fakten, Furcht und Zwang), und zeigt auf, dass diese auf Schockmomenten basierenden Konzepte gar nicht langfristig erfolgreich sein können. Kein Mensch kann sich dauerhaft im Zustand der Alarmiertheit, Erregung und Verängstigung befinden, früher oder später setzen Gewöhnung und Abstumpfung ein. Die Veränderungsbereitschaft verschwindet dann so schnell wieder wie sie aufgetreten ist.
Als bessere Konzepte führt Deutschmann Relate, Repeat und Reframe ein (den Bezug zu sich selbst erkennen, Neuerungen nach und nach Verinnerlichen, eine neue Welt- bz. Systemsicht entwickeln). Im genauen Gegensatz zu den Schockeffekten von Facts, Fear und Force handelt es sich dabei um langwierige, dafür aber auch nachhaltige Prozesse, mit denen auch umfangreiche und drastische Veränderungen möglich sind. Auch hierfür führt er zahlreiche Beispiele aus Wirtschaft und Gesellschaft an.
Obwohl Artikel und Buch nicht neu sind (verfasst 2005, bzw. 2007) sind sie noch nicht im Mainstream angekommen, noch immer wird die Sinnhaftigkeit von Veränderungsvorhaben auf die klassische Weise kommuniziert (statt Facts, Fear und Force spricht man heute aber eher vom Sense of Urgency). Sie sind daher weiterhin als Leseempfehlung nutzbar und haben nichts von ihrer Aktualität eingebüsst.
