Agile Governance (II)

Zum Thema Agile Governance habe ich bereits vor einigen Jahren etwas geschrieben, aber Dan North geht mit einem weitaus grösseren Detailgrad darauf ein. Vieles davon ist "agiler common sense", aber es ist immer wieder interessant alles im Kontext zu sehen. Und die Automatisierungs-Beispiele am Ende können sogar als Vorbild genutzt werden.

Stalemate-Machine

Bild: Wikimedia Commons / US Army - CC0 1.0

Sucht man nach beispielhaften fehlgeschlagenen Grossvorhaben ist eines zwar nicht auf den ersten Blick naheliegend, in vieler Hinsicht aber gut geeignet: der verlorene Krieg der USA in Vietnam. Was nötig gewesen wäre um ihn zu gewinnen wird zwar für immer Spekulation bleiben, viele Faktoren die dazu beigetragen haben, dass er verloren wurde, kennt man aber. Um einen davon soll es hier gehen, die so genannte "Stalemate-Machine", sinngemäss übersetzt den "Stillstands-Generator".

Der Hintergrund dieses Phänomens war der steigende Unwille in der amerikanischen Bevölkerung und Regierung in diesen Krieg zu investieren. Aus Sorge um ihre Wiederwahl wollten die Regierungen der 60er und 70er Jahre nicht mit immer höheren Kosten an Leben und Geld in Verbindung gebracht werden. Ihr Ziel war es also diese Kosten möglichst gering zu halten. Die Kriegsführung wurde entsprechend angepasst.

So lange es irgendwie möglich war wurde die Beteiligung amerikanischer Einheiten gering gehalten, Auseinandersetzungen sollten in erster Linie von einheimischen Truppen ausgetragen werden. Erst wenn diese am Rand der Niederlage standen erfolgte ein Eingreifen der Amerikaner. Sobald die Situation dadurch wieder unter Kontrolle war zogen sie sich zurück, was ihren Gegnern die Neugruppierung ermöglichte.

Der Militär-Analyst und Whistleblower Daniel Ellsberg hat für diese Strategie den Begriff der Stalemate-Machine geprägt. Wegen der Möglichkeit bei drohenden Niederlagen einzugreifen konnte der Krieg nicht verloren werden, wegen der fehlenden Bereitschaft ohne drohende Niederlage grössere Operationen durchzuführen war er aber auch nicht zu gewinnen. Die Folge war ein "stillstehender Krieg" ohne Gewinner.

Die Parallelen zur Wirtschaft sind in vielen Unternehmen offensichtlich. Auch hier wird häufig der Punkt erreicht an dem ein Projekt oder Vorhaben so viel gekostet hat, dass weitere Ausgaben in Management-Runden nur schwer zu vermitteln sind. Es bekommt von da an nur noch überschaubare Beträge genehmigt, damit es aus den Bilanzen weniger heraussticht. Bedingt dadurch gerät es weiter in Verzug, was nur noch bei wichtigen Deadlines zu kurzfristigen Hau-Ruck aktionen führt, die schnell wieder vorbei sind.

Der grosse Vorteil im Vergleich zum Militär ist an dieser Stelle: man könnte ohne ethische Bedenken diesen Krisenmodus verlassen und eine angemessen moderate, dafür aber permanente Finanzierung sichern. Man müsste nur wollen. Noch besser wäre es, es gar nicht so weit kommen zu lassen und von Beginn an massvoll aber stetig zu investieren. Damit würde es gar nicht erst zum Stalemate kommen.

Backlog Konmari

Bild: Pixabay / 123nurik123 - CC0 1.0

Wegen irgendeiner Fernsehsendung hört man gerade viel von einer Japanerin mit dem (Künstler?)Namen Marie Kondo. Bekannt geworden ist sie durch die von ihr entwickelte Konmari-Methode zum Aufräumen von Wohnungen und Garderoben, die mittlerweile aber auch für Büros, Werkstätten, Schreibtische, etc. angewandt wird. Das Ganze lässt sich aber noch weiter treiben - warum sollte man Konmari nicht auch für Product Backlogs anwenden? Auch die sind ja oft hoffnungslos überladen und zugemüllt.

Als ersten Schritt definiert Kono das Commitment. Dieses geht bei ihr über die engere Bedeutung des sich verpflichtet Fühlens hinaus und enthält auch einen Zeitplan. Es sollte ein Zieldatum geben bis zu dem die Aufräumarbeiten abgeschlossen sein müssen, es sollte Zwischenziele geben und es sollte einen oder mehrere Zeiträume geben die für diese Arbeit reserviert sind, z.B. jeden Werktag von 10 bis 11 bis zum Ende des Monats.

Als nächstes sollte Klarheit über das angestrebte Zielbild herrschen. Dazu sollte dieses in seinem Idealzustand beschrieben werden. Für ein Backlog bedeutet das: geordnet (z.B. nach Business Value, MVPs, Sprintzielen, oder Roadmap) und mit einer absteigend geringer werdenden Granularität. Basierend darauf lassen sich die Einträge später neuordnen, teilen oder zusammenlegen.

Das eigentliche Aufräumen beginnt dann mit dem Ausmisten. Orientiert am vorher verfassten Zielbild kann alles weg was nicht dazu passt. Für viele Teams dürfte das der schwerste Teil dieser Übung sein, gleichzeitig ist es auch der wichtigste. Ist die Gesamtmenge übersichtlicher geworden fällt das Sortieren leichter und geht schneller voran. Eine weitere Hilfe besteht darin, sich um Nostalgie und Emotionen weckende Anforderungen als letztes zu kümmern, um nicht abgelenkt zu werden.

Auch bei der Aufteilung der Arbeitsschritte empfiehlt Konmari ein anderes Vorgehen als das meistens anzutreffende. Statt sich von einem Ort zum nächsten vorzuarbeiten entsprechen die Arbeitsphasen verschiedenen Kategorien. Bezogen auf das Produktmanagement bedeutet das, dass nicht zuerst Jira, dann Salesforce und dann  HP-ALM abgearbeitet werden sondern z.B. erst toolübergreifend alle Innovationsvorhaben, dann die Servicetasks und dann die Bug-Tickets.

Während des Aufräumens sollte Ordnung unmittelbar entstehen. Statt neue Haufen zu bilden, die dann (hoffentlich) später sortiert werden sollte alles sofort an den (nach aktuellem Kenntnisstand) finalen Ort wandern. Um Agile-Buzzwords zu benutzen: jedes Aufräum-Incement sollte eine Definition of Done erfüllen und unmittelbaren Mehrwert stiften.

Über dem gesamten Prozess sollte im klassischen Konmari das Leitmotiv des Erzeugens von "Sparking Joy" stehen, also des Verstrahlens von Freude. Als Gegenstück im Produktmanagement würde sich das weit verbreitete "Delighting Customers" anbieten. Im Hinterkopf sollte demnach während des ganzen Aufräumvorganges stehen, dass das Endergebnis den höchstmöglichen Kundennutzen zum Ziel haben sollte.

In diesem Sinne - ab zum Aufräumen.

Keine Entschuldigungen im Review

Bild: Pixabay / Geralt - CC0 1.0

Egal ob im Sprint Review, in einem Stakeholder-Meeting oder bei einer wie auch immer gearteten Ergebnispräsentation - jedes agil arbeitende Team sollte in regelmässigen Abständen seinen Kunden, Sponsoren und Auftraggebern Ergebnisse zeigen. Bestenfalls sollten in diesem oder in einem anderen Rahmen auch Zieldaten und Forecasts kommuniziert werden, um Umsatzplanungen, Kommunikationsstrategien und ähnliches möglich zu machen. Und da der Mensch als solcher nun mal fehlbar und die Realität nicht vorhersehbar ist werden nicht immer alle Ergebnisse zum angedachten Zeitpunkt fertig sein. Was jetzt?

Ein häufiges Verhalten vieler Teams ist es, in solchen Situationen umfangreiche Erklärungen und Begründungen abzugeben. Mitunter in erstaunlichem Detaillierungsgrad wird dargelegt warum man sich in den Aufwandsschätzungen vertan hat, wie es dazu kommen konnte, dass die Planungen zu optimistisch waren oder welche Faktoren dazu geführt haben, dass das ursprünglich realistische Ziel wider Erwarten doch nicht erreicht werden konnte.

Verbunden damit ist in der Regel guter Willen. Transparenz ist bekanntlich einer der Grundprinzipien agilen Arbeitens, es ist also scheinbar nur folgerichtig sie auch in diesem Fall anzuwenden und für jeden nachvollziehbar zu machen warum alles so gekommen ist wie es ist. Zielführend ist dieses Vorgehen allerdings nur selten. Häufiger führt es zu Befremdung und Skepsis bei den Zuhörern, also zum Gegenteil des eigentlich erhofften Ergebnisses.

Zunächst wirken Erklärungen und Begründungen schnell wie Ausreden und Fingerpointing, und zwar auch dann wenn sie explizit nicht so gemeint sind. "Wir wollten ja, aber ..." hinterlässt selten einen guten Eindruck, erst recht nicht wenn es mehrfach geschieht. Und dass es immer wieder geschehen wird ist unvermeidbar, siehe menschliche Fehlbarkeit und Unvorhersehbarkeit der Realität. Besser sind Aussagen wie "Wir sind nicht ganz fertig geworden, arbeiten aber weiter daran." oder "Dieser Lösungs-Ansatz war leider der falsche, basierend auf dem was wir daraus gelernt haben arbeiten wir jetzt an einem besseren."

Des Weiteren sind derartige Themen für die meisten Kunden, Sponsoren und Auftraggeber schlicht uninteressant. Negative (und übrigens auch positive) Implementierungsdetails sind nicht der Grund dafür, dass man sich mit einem Umsetzungsteam trifft. Normalerweise kommen die Teilnehmer solcher Veranstaltungen weil sie Ergebnisse sehen, ausprobieren und Feedback geben wollen und nicht um zu hören wo es Probleme gab die sie weder beurteilen noch beheben können.

Zuletzt fressen Erklärungen und Begründungen Zeit weg die deutlich besser und gewinnbringender genutzt werden könnte. Jede Nacherzählung unerwarteter Hindernisse könnte ersetzt werden durch Hands on-Demonstrationen, Zufriedenheitsmessungen, Verbesserungsvorschläge oder die Vorstellung und Abstimmung von nächsten Schritten. Gerade vor dem Hintergrund, dass in agilen Teams Meetings meistens timeboxed sind ein nicht zu unterschätzender Faktor.

Das Alles heisst übrigens nicht, dass Fragen nach den nicht gelieferten Ergebnissen nicht beantwortet werden sollen. Das sollten sie auf jeden Fall. Aber nur dann wenn sie gestellt werden und ohne zu viele Details. Die will niemand hören.

Process, Tribe and Comfort Zone

Ich bin nicht sicher ob Emily Phillips hier wirklich über Agile Leadership spricht oder nicht doch eher darüber wie sie mit den Unwägbarkeiten des eigenen Lebens umgeht. Interessant ist es aber so oder so.

Investitionsstaus

Bild: Wikimedia Commons / Caliva - CC BY-SA 4.0

Es war eine der letzten Meldungen des Jahres: im Jahr 2018 wurden Investitionsmittel von insgesamt 25 Milliarden Euro nicht abgerufen. Wohlgemerkt, es handelte sich dabei um bereits freigegebene Summen, es gab nichts mehr zu beantragen und genehmigen, man hätte direkt mit dem Ausgeben anfangen können. Dass das nicht geschehen ist ist keine Besonderheit der staatlichen Verwaltung, auch in vielen grossen Firmen gibt es dieses Phänomen - und es hat Gründe.

Am Anfang steht wie so oft das Dilemma, dass die Zukunft nicht vorhersehbar ist und die Realität sich anders entwickelt als geplant. Im besten Fall führt das dazu, dass Vorhaben schneller (und damit billiger) umgesetzt werden können als vorgesehen. Das gibt es, es ist aber selten. Häufiger ist das absolute Gegenteil: weil die Planung an der Realität vorbeiging muss neu geplant werden, die Umsetzung beginnt dann deutlich später oder muss sogar ins nächste Jahr verschoben werden.¹

Beide Fälle führen dazu, dass in den jeweiligen Organisationen Stillstand einkehrt. Denn um neue Vorhaben zu beginnen müssten diese eine genehmigte Finanzierung für das laufende Jahr haben, was aber bei grösseren Summen einen monatelangen bürokratischen Prozess erfordern kann. Bis dieser abgeschlossen ist kann mit der Arbeit nicht begonnen werden, und wenn er bis Jahresende nicht beendet wurde bleibt das Geld ungenutzt. Stattdessen das bereits freigegebene Budget derjenigen Vorhaben zu nehmen die nicht starten konnten geht auch nicht - derartige Mittel sind in der Regel zweckgebunden.

Letztendlich können derartige Zustände mehrfach schädlich sein. Zum Einen sorgen sie dafür, dass sich Arbeiten unnötig verzögern (→ Cost of Delay), des Weiteren wurden ggf. bereits Lizenzen oder Geräte gekauft, können aber nicht benutzt werden, wodurch sie zwar Geld kosten aber keines erwirtschaften (→ Totes Kapital), schlimmstenfalls führt der Versuch das vorhandene Geld irgendwie doch einzusetzen zu unnötigen Erweiterungen bereits fertiger Ergebnisse, wodurch diese unübersichtlicher, instabiler und wartungsintensiver werden (→ Bloatware/Feature Creep).

Alles das ist für alle Beteiligten relativ klar zu erkennen sobald es einmal eingetreten ist, es wird also versucht Gegenmassnahmen zu ergreifen. Der in vielen Fällen eingeschlagene Lösungsweg macht aber alles nur noch schlimmer: er besteht daraus, strukturell mehr Vorhaben zu beantragen und genehmigen zu lassen als durchgeführt werden können. Stellt sich jetzt eines als nicht durchführbar heraus kann man einfach das nächste beginnen, man ist also in jedem Fall ausgelastet. Problem gelöst?

Auch hier tritt wieder das Problem der nicht vorhersehbaren Zukunft auf: wenn wider Erwarten alle Vorhaben wie geplant begonnen und durchgeführt werden können, dann ist es nicht mehr möglich diejenigen umzusetzen die "auf Vorrat" beantragt worden sind. Für sie wird also eine fehlende Machbarkeit gemeldet, wodurch ihr Budget wieder zur allgemeinen Verfügung steht. Abgerufen werden kann es wegen der genannten bürokratischer Prozesse dann nicht mehr rechtzeitig. Siehe oben.

Das Bemerkenswerte ist, dass es auch andere Lösungen gäbe, durch die Inverstitionsstaus vermieden werden könnten: man könnte Genehmigungsprozesse beschleunigen, die Zweckbindung von Finanzierungen aufheben oder die Organisation vom Push- auf das Pull-Prinzip umstellen. Jede dieser Optionen würde aber tiefgreifende Änderungen der Organisations- und Genehmigungsstrukturen erfordern, wovor dann doch zurückgeschreckt wird. Und dann bleibt es dabei, dass immer wieder Geld nicht abgerufen wird.

Nachtrag:
Um auf Feedback zu reagieren: ja, in diesem Beitrag geht es hautptsächlich darum was falsch läuft und nur wenig darum wie es besser gehen würde. Das hat seinen Grund darin, dass das besser Machen aus einer Umstellung, bzw. einem Rückbau bestehender Organisationsformen bestehen muss. Da die aber von Fall zu Fall unterschiedlich sind ist es kaum möglich eine generelle Handlungsempfehlung abzugeben. Wie so oft: es kommt darauf an.

Nachtrag II:
Passend zum Thema geht es in einer der ersten Meldungen des Jahres weiter: Investitionsstau in Städten und Kommunen erreicht Rekordniveau.


¹Natürlich gibt es auch die Fälle in denen die Umsetzung zum geplanten Zeitpunkt beginnt und endet oder in denen sie
zum geplanten Zeitpunkt beginnt und verspätet endet, aber die sind in diesem Zusammenhang nicht von Bedeutung

Kommentierte Links (XXXXIV)

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

• Garry Ridge: The Four Pillars of the Fearless Tribe

  Wenn man diesem Text glauben darf ist WD-40 eine mehr als bemerkenswerte Firma. Alleine die in diesem Text zitierten Ergebnisse einer internen Mitarbeiterbefragung sind beeindruckend:
  
  • 97 % der Mitarbeiter kennen die Firmenziele
  • 93 % sehen der Zukunft der Firma mit Vorfreude entgegen
  • 92 % fühlen sich ermutigt an der eigenen Weiterentwicklung zu arbeiten
  • 97 % verstehen wie ihre Tätigkeit auf die Firmenziele einzahlt
  • 97 % wissen welche Ergebnisse die Firma von ihnen erwartet
  • 98 % glauben, dass ihre Überzeugungen und Werte zu Firmenkultur passen
  • 99% erzählen Freunden gerne von ihrer Arbeit
  Der CEO Garry Ridge gibt in diesem Text einen detaillierten Überblick über die Firmenkultur die diese Ergebnisse hervorgebracht hat und über die Grundlagen und Prinzipien auf denen sie beruht. Unbedingt lesens- und nachahmenswert.
  

• Corporate Rebels: The Fundamental Things People Get Wrong About Self-Management

Eher ein Erklär-Artikel, allerdings ein wichtiger und nötiger. Denn während nahezu jeder der in einem agilen Kontext arbeitet von Selbstorganisation spricht, kann kaum jemand definieren was genau das ist und auch nicht was es nicht ist (Spoiler: es ist nicht "jeder macht was er will"). Infolgedessen ist der Begriff häufig mit unrealistischen Erwartungen und Befürchtungen verbunden, die schnell in Enttäuschung und Widerstand umschlagen. Die hier beschriebenen negativen Definitionen (dessen was Selbstorganisation nicht ist) können dabei helfen die Erwartungen auf ein realistisches Mass herunterzuschrauben - oder empozuheben

• Willem-Jan Ageling: #NoEstimates – The 6 Alternatives for Estimating

  Noch ein Erklär-Artikel. Während Selbstorganisation für viele Menschen etwas ist was sie zwar nicht im Detail, aber zumindest auf einer sehr abstrakten Ebene beschreiben können, sind die meisten beim Thema "No Estimates" völlig verloren. Nach dem über-vereinfachenden Erklärungsversuch, dass Aufwände einfach nicht geschätzt werden, kommt nichts Brauchbares mehr. Dass es dann nicht nur einen sondern gleich mehrere No Estimates-Ansätze gibt hat für Viele einen fast schon esoterischen Touch. Und doch - es gibt sie, aufgelistet und erklärt in diesem Blog-Eintrag. [Nachklapp: das Ganze mag auch mit dem leicht missverständlichen Begriff zu tun haben, aber der hat sich nun mal so etabliert.]

• Gary Hamel: Busting Bureaucracy

  Ein sehr guter und lesenswerter Text, aber auch einer den man sehr zwiespältig sehen kann. Dass Bürokratie Abläufe verlangsamt, die Beteiligten frustriert, Kreativität behindert, unnötige (und häufig versteckte) Kosten verursacht und wegen dieser und weiterer Gründe schnellstmöglich beseitigt werden sollte wird kaum auf Widerspruch stossen, damit hat Gary Hamel absolut recht. Auch dass es eine Gruppe von "Bürokraten" gibt, die von der Bürokratie profitiert (in Form von Macht, Anerkennung, Arbeitsverträgen, etc.) dürfte ein unstrittig anerkannter Teil des Problems sein. Schwierig wird es aber wenn "die da oben" dämonisiert werden. Das ermöglicht zwar eine mitreissende Revolutions-Rhetorik, baut aber auch Fronten auf und reisst Gräben auf. Veränderung wird dadurch schwerer.

• Greg Satell: The Demise of Blockbuster, and Other Failure Fairy Tales

  Der Untertitel sagt eigentlich bereits alles aus: "When big companies collapse, the story is never simple". Tatsächlich ist in den letzten Jahren der Mythos entstanden, dass im Fall von Firmen wie Blockbuster, Kodak und Xerox der Niedergang, bzw. das Verpassen neuer Märkte vermeidbar gewesen wäre, wenn deren Management nur ein "agileres Mindset" gehabt hätte. In Wirklichkeit ist es natürlich komplexer. Die Herausforderungen wurden zwar erkannt und es wurden Pläne zu ihrer Bewältigung entwickelt, letztendlich wurde sich aber gegen große (und riskante) Inverstitionen entschieden, deren Erfolg damals nicht absehbar war. Was der Autor nicht sagt: mit agilem Vorgehen (MVPs, incrementelle Lieferung, etc.) hätte man die Investitionsrisiken stark reduzieren können.

• Edward Niedermeyer: Elon Musk Is the Henry Ford of His Age. That's Bad.

  Ein gutes Beispiel für den Unterschied zwischen Agil und Lean und dafür wo welcher Ansatz Sinn macht. Das hier beschriebene Vorgehen von Tesla kommt klar aus dem Lean Startup (trotz seines Namens ein agiles Framework). Das Wichtigste ist es dort, schnell mit validierbaren Ergebnissen am Markt, bzw. beim Kunden zu sein und Geld zu verdienen. Das Ausliefern von leicht fehlerhaften Produkten wird bewusst in Kauf genommen und später durch Updates gefixt. Das Problem: Updates einer Automobil-Hardware müssen von Reparaturteams durchgeführt werden und erfordern unverhältnismässig viel Zeit und Aufwand. An der Stelle wäre vermutlich ein Lean-Ansatz besser gewesen, bei dem die Fertigungsstrasse so optimiert wird, dass es gar nicht zu fehlerhaften Auslieferungen kommt.

• Bob Tarne: Agile Road Trip, Lessons From a Coach at Toyota

  Passend zum letzten Thema. Bei vielen Agile Coaches hat Toyota bis heute einen nahezu mythischen Ruf, da diese Firma federführend an der Entwicklung des Lean Management beteiligt war. Dass die Softwareentwicklung dort bis vor wenigen Jahren noch nach Wasserfall strukturiert war (siehe hier) wird dabei häufig ignoriert. Um so interessanter ist es zu erfahren, in wiefern der "Toyota Way" in die mittlerweile stattfindende agile Transition einfliesst. In der nordamerikanischen Tochtergesellschaft scheint das nur in geringem Ausmass so zu sein, zumindest legt dieser Artikel von Bob Tarne das nah. Bei der international tätigen Tochtergesellschaft Toyota Connected scheint das besser zu funktionieren (siehe hier). Wie das bei der Muttergesellschaft stattfindet ist zur Zeit aus den öffentlichen Dokumenten nicht zu erkennen. Man kann auf die ersten nicht-japanischenVeröffentlichungen gespannt sein.

• Falk Kühnel: Agile scaling is plain wrong!

  Eine unterhaltsam geschriebene Abrechnung mit dem Buzzword "Scaled Agile" oder "agile Scaling". Tatsächlich ist es so, dass je nach Kontext völlig unterschiedliche Bedeutungen mit diesem Begriff verbunden werden. Eine extrem verbreitete fehlt aber bei Falk: Agile Scaling als Synonym für ein mit agilen Teams durchgeführtes Chinesenprinzip, also dafür, dass mehr Teams mit der selben Aufgabe beauftragt werden, in der Hoffnung schneller fertigzuwerden. Das wäre nochmal ein Thema für sich.

Was man alleine im Büro machen kann

Bild: Pixabay / tookapic - CC0 1.0

Immer wieder gibt es Phasen in denen der Grossteil der Kollegen im Urlaub ist und nur einige wenige zurückbleiben um bei Bedarf den Betrieb am Laufen zu halten. Die Zeit zwischen Weihnachten und Neujahr gehört dazu, aber auch andere Ferienzeiten. An den normalen Aufgaben des eigenen Teams weiterzuarbeiten ist in solchen Situationen oft nicht möglich (oder sinnvoll), so dass sich die Frage stellt: was soll man als (letzter) Teil eines agilen Teams in dieser Zeit tun? Hier einige Ideen.

Zunächst sollte klar sein, dass es auch in dieser Situation nicht zielführend wäre nicht gebrauchsfähige Teilergebnisse zu liefern. Ein Frontend ohne Backend wird z.B. dadurch nicht besser, dass es während der Winterpause erstellt wurde. Der nachgelagerte Erklär-, Integrations- und Anpassungsaufwand ist in der Regel so gross, dass man durch Implementierungs-Vorarbeiten nicht viel gewinnen kann.

Was hingegen häufig Sinn machen kann ist eine andere Art von Vorarbeit - ein Grooming, bzw. Refinement. Es kann zwar ohne den Input der anderen an der Umsetzung Beteiligten nicht final sein, trotzdem können bereits viele Frage- und Problemstellungen identifiziert werden die noch geklärt werden müssen bevor die Implementierung beginnen kann.

Auch bestimmte Spikes, bzw. Forschungsaufgaben können alleine durchgeführt werden. Wenn beispielsweise ein in nächster Zeit neu anzuschliessendes System in der Lage sein soll mit verschiedenen Datentypen umzugehen, kann bereits im Voraus jeder davon darin eingegeben und seine Verarbeitung überprüft werden, um herauszufinden wo Probleme auftreten und wo Anpassungsbedarf besteht.

Es können Minimum Viable Products, Riskiest Assumption Tests, Proofs of Concept oder Prototypen gebaut werden, durch die belegt (oder auch widerlegt) werden kann, dass bestimmte Vorhaben überhaupt möglich sind. Da die genannten Elemente nur der Beweisführung dienen und danach weggeworfen werden ist es hinnehmbar wenn an ihnen noch nicht alle mitarbeiten.

Nicht beliebt aber immer wieder notwendig sind Nacharbeiten an Testautomatisierung oder Dokumentation. Eine höhere Testabdeckung oder eine verständlichere Strukturierung von Anleitungen oder Handbüchern können dafür sorgen, dass die Arbeit in späteren Phasen leichter oder weniger wird.

Zuletzt kann die Zeit auch für die eigene Weiterentwicklung genutzt werden. Egal ob technisch, methodisch oder fachlich, wenn auf diese Weise mehr Wissen in ein Team kommt kann es als Ganzes nur davon profitieren. Dass es später auf mehrere Köpfe verteilt werden sollte dürfte klar sein, aber das kann auch im Rahmen von Pairing oder Reviews passieren wenn alle anderen wieder da sind.