Core Elemente Timeboxed

Timeboxed

Das Umfeld 

Nahezu alle Projekte bewegen sich heute in einer Welt sehr schnellen Wandels (Volatility) und damit einer erschwerten Vorhersagbarkeit und Planung (Uncertainity). Gleichzeitig steigt die Komplexität der Projekte u.a. vor allem durch neue Technologien exponentiell (Complexity). Aus diesen Gründen funktionieren Best Practice-Ansätze immer weniger (Ambiguity).

Bezogen auf diese Gründe spricht man vermehrt davon, dass wir uns in einer VUCA-Welt bewegen.

VUCA bezieht sich aber auch auf eine Vielzahl von modernen Umgebungen, vor allem in der Digitalisierung, wenn es darum geht, sich in dieser sich stark verändernden Welt zu bewegen.

Dieses Umfeld bietet in Folge nicht mehr die Möglichkeit, mit klassischen Methoden über längere Zeiträume zu planen (Wasserfallmethode). Auch ist der Einbau von Pufferzeiten, um die Unwägbarkeiten abzumildern, keine Lösung. Zu vielfältig und dynamisch ist das Umfeld und damit die Dynamik der Anforderungen geworden, und die zeitliche Dynamik lässt großzügige „Pufferzeiten“ eigentlich nicht mehr zu.

Was ist in diesem Umfeld stabil?


Was ist verlässlich?


Auf was kann man aufbauen?

Zeit ist der Maßstab 

  • Die Zeit ist unabhängig von jeglicher Veränderung.

  • Eine Sekunde ist immer eine Sekunde, und eine Woche ist immer eine Woche.

  • Auf die Zeit ist Verlass.

Zeit als Steuerungsgröße 

  • Alle agilen Verfahren arbeiten timeboxed.

  • Eine Aufgabe bestimmt nicht mehr die Dauer, sondern die Timebox definiert den Scope der Aufgabe.

Daraus folgt

  • Schneide zu große Aufgaben kleiner, sodass sie in die Timebox passen.
  • Fülle die Timebox mit (größeren und kleineren) Aufgaben, sodass sie optimal gefüllt ist.
  • Wende die Timebox auf alle weiteren Elemente an, wie Ressourcen, Budgets etc.

So weit, so gut.
Wie aber anwenden? 

 

Unterschiedliche Tätigkeiten müssen in eine zeitliche Abfolge gebracht werden, damit ein Projektziel (Objective) erreicht wird. Dies erfolgt üblicherweise durch viel Projektplanung und viel Koordination während der Umsetzung.

Einführung einer Sprint Timebox als Takt (Standard in Scrum) 

 

Durch eingezogene Grenzen einer Timebox als Takt werden verlässliche (Zeit-)Räume geschaffen, auf die alle bauen können.

Wie aber werden Objectives (Projektziele) und zugehörige Tätigkeiten in diese Grenzen eingeordnet, damit dieser Takt nicht dazu verkommt, lediglich eine Art „Statusmeeting“ ohne Relevanz für das eigentliche Arbeiten zu werden?

Einzug von Sprint Timeboxen ohne Anpassung der Objektives und Tätigkeiten

Dies geschieht durch die Anpassung der Objectives und der zugehörigen Tätigkeiten an die zugehörige Timebox. Die Objectives und Tätigkeiten werden neu „geschnitten“ damit diese in einer Timebox erledigt werden können. Auf diese Weise entsteht eine neue Form von Arbeiten mit dem Fokus, „Dinge“ in der Timebox zu erledigen.

Soweit nichts Besonderes. Denn diese Arbeitsweise zeichnet alle agilen Methoden aus. Jedoch fokussiert sich dieser Ansatz immer auf EIN Team, welches möglichst autark seine Tätigkeiten erledigen kann. Was aber, wenn die Vorhaben größer werden und mehrere Teams gleichzeitig arbeiten müssen?

Sprint Timeboxen mit neu geordneten Objectives und Tätigkeiten

Was ist in FAST nun anders?

Anwendung der Timebox auf weitere Elemente  

In FAST greift das Prinzip Timebox grundsätzlich nicht nur für inhaltliche Arbeiten wie Objectives und die zugehörigen Tätigkeiten, sondern auch auf Releases und für Ressourcen & Budgets

All diese Elemente und Aktivitäten finden so in einer zugehörigen Timebox statt.

Auf diese Weise wird in FAST erstmals ein ganzheitlicher Blick auf die Gesamtsituation aus zu erreichenden Objectives und zu liefernden Releases, zugehörigen zur Verfügung stehenden Ressourcen und bereitgestellten Budgets geschaffen, gegen die synchron auch ein entsprechendes Controlling aufgebaut werden kann.

Auf diese Weise wird in FAST erstmals auch eine Möglichkeit geschaffen, dass eines der häufigsten Gegenargumente, warum Agilität im Unternehmen nicht funktionieren soll, ausgehebelt wird. Nämlich die Kontrolle über das Budget und die eingesetzten Ressourcen.
Insbesondere der Einordnung von Releases in das Konstrukt Timebox kommt im späteren Verlauf noch besondere Bedeutung zu, wenn FAST über mehrere Teams skalliert wird (siehe auch Planungsstruktur).

Unterschiedliche Timeboxen – unterschiedliche Scopes 

 

In FAST wenden wir das Prinzip der Timebox auf mehr Ebenen an, als nur auf der Sprint-Ebene und darunter (Day). So ist insbesondere die nächsthöhere Ebene der Season eine weitere Timebox von besonderer Bedeutung in FAST. In dieser Timebox werden größere Ziele bzw. Objectives platziert, die nicht innerhalb eines Sprints erledigt werden können.

Kritiker mit agilem Hintergrund werden nun sofort sagen: Das ist jetzt aber nicht mehr agil!”

Dies stimmt insoweit, als dass die reine Lehre in agilen Verfahren, wie beispielsweise Scrum, möglichst viele kleine Lernzyklen ermöglichen möchte. Und Feedbackschleifen nicht zu lang (mehrere Wochen) sein sollen.

Aber viele Organisationen sind mit diesem schnellen” Takt zum Einstieg maximal überfordert und brechen nach wenigen Zyklen (Wochen) die agile Arbeitsweise ab und fallen auf klassische Methoden (Wasserfall) zurück. Oder sie starten die Einführung von agilen Methoden erst gar nicht, da sie oder das Management befürchten, dass durch die schnelle Abfolge von Sprints die Kontrolle über die Ziele oder das Budget verloren geht.

FAST – die Season 

Hier setzt FAST mit der Einführung der Season als nächste übergeordnete Timebox eine weitere Timebox ein, die es den Teams und der Führung ermöglicht, in einem größeren Zeitrahmen von mehreren Sprints zu planen (häufig zu Beginn der Arbeit mit FAST kleine Wasserfälle) und sich damit erst einmal grundsätzlich an das Prinzip Timebox zu gewöhnen.

Die Erfahrung zeigt, dass sich im Verlauf von mehreren Seasons die Dynamik immer weiter auf Sprint-Ebene verlagert und die Season Plannings weniger einer „Wasserfall-Planung“ dienen, sondern vermehrt der Fokus auf die Klärung von Abhängigkeiten zwischen den Teams gelegt wird, um während einer Season ständige Umplanungen aufgrund von nicht geklärten Abhängigkeiten zu anderen internen oder externen Teams zu reduzieren.

Ein weiteres wesentliches Ziel von FAST ist es, als Framework auch auf höheren Unternehmensebenen zu wirken. Mit der Einführung von Timeboxen auf Season-Ebene gelingt es, durch das zugehörige Season Planning die nächste Management-Ebene in das Framework zu integrieren. Einerseits, weil ein Season-Rhythmus ein eher managementtauglicher Zeitraum ist, zum anderen, weil die Zusammenkunft aller Value Stream-Mitglieder bei einem Season Planning ein Event darstellt, das die Aufmerksamkeit ALLER in den Mittelpunkt stellt.

Für eine Season liefert die Management-Ebene somit die notwendigen Ziele (Objectives) als Input (Was möchte ich als Management in der nächsten Season Timebox umgesetzt haben?) und als Ergebnis zum Ende des Season Planning hin bzw. aus den Teams die Rückmeldung vor Start der Season: „Das können wir liefern!“ Mit einer gemeinsamen finalen Abstimmung und ggf. Nachjustierung wird erreicht, dass beide Ebenen (Management und Teams) ein Commitment für die Planung zum Start der Season vereinbaren können (Confidence Vote).

Auf diese Weise entsteht auf Season-Ebene ein weiterer Learning Cycle auf Basis einer Timebox.

Die Regeln eines zugehörigen Planning, des Reviews der erreichten Ergebnisse bzw. einer Retrospektive auf das „Wie die Ziele erreicht wurden“, die auf Spint-Ebene in allen agilen Methoden bewährte Praxis ist, können in FAST auf allen anderen Ebenen analog angewendet werden. Sie benötigen lediglich andere „Zeitrahmen“ (Timeboxen). So findet ein Season Planning in der Regel in einer Timebox von 2 Tagen statt.

Erfahrungen mit Timeboxen auf Season- und Sprint-Ebenen 

Durch die Ebene Season entstehen diverse Kombinationsmöglichkeiten von Season Timeboxen und Sprint Timeboxen. Nicht alle sind zielführend.


In Kombination haben sich daher folgende Timebox-Kombinationen bewährt:

  1. Season mit 3 Monaten Länge + zweiwöchige Sprints
    FAST Standard Season mit 6 Sprints

  2. Season mit 4 Monaten Länge + zweiwöchige Sprints
    Verlängerte Season mit 8 Sprints
    Insbesondere bei eher geringen Abhängigkeiten zwischen den Teams einsetzbar.

  3. Season mit 4 Monaten Länge + dreiwöchige Sprints
    Verlängerte Season mit 5 Sprints
    Insbesondere sinnvoll für unerfahrene Teams.

 

Warum ergeben dreiwöchige Sprints als Timebox Sinn? 

Längere Sprints bieten

  • den Teammitgliedern Raum, sich an die Sprint-Methodik zu gewöhnen und den Fokus innerhalb des jeweiligen Sprints zu justieren. (Insbesondere bei Teammitgliedern sinnvoll, die nicht Vollzeit im Sprint arbeiten, sondern auch noch BAU [Business as usual] haben).

  • Raum für zusätzlichen Abstimmungsaufwand zwischen Product Owner, Scrum Mastern und den Teams, wenn mehrere Value Streams eng verzahnt werden müssen.

  • mehr Raum für stetige Tätigkeiten in einem verlässlichen Team.

Weitere Erfahrungen und Praxistipps

  • Zweiwöchige Sprints kommen bei kleinen Programmorganisationen oder neuen, unerfahrenen Teams zum Einsatz (schnelle Lernzyklen).

  • Bei großen Organisationen mit vielen Teams empfiehlt sich manchmal ein dreiwöchiger Rhythmus, um Overheadkosten zu reduzieren.

  • Bei erfahrenen und gut funktionierenden Teams kann ebenfalls ein dreiwöchiger Rhythmus genutzt werden

  • 4 Seasons zu 3 Monaten ist der Standard. Sind pro Release viele Quality Gates zu durchlaufen (Reviews, Testing, Dokumentation, Releasemanagement etc.), kann es sinnvoll sein, auf 3 Seasons zu 4 Monaten zu wechseln.

Weitere Timeboxen in FAST – Year, Epoche, Decade 

Konsequent weiterverfolgt, entstehen auf diese Weise weitere Timeboxen nach oben, die es ermöglichen, im FAST Framework auch das Jahr als Timebox zu betrachten oder sogar theoretisch eine Epoche (3 Jahre) oder eine Decade (10 Jahre).

Auch die zugehörigen Events wie das Planning finden dann beispielsweise als Year Planning statt, inklusive des zugehörigen Reviews und der zugehörigen Retrospektive.

Der Umgang mit den Timeboxen auf den verschiedenen Ebenen 

 

Auf diese Weise entsteht ein System aus ineinandergreifenden Timeboxen, die Objectives auf der strategischen Ebene (Decade, Epoche) in immer feinere Objectives (Year, Season) herunterbrechen. Wichtig ist, hierbei nicht in den Ansatz einer Durchplanung zu verfallen, die man auf Basis der Wasserfallmethodik gewöhnt ist.

Auf der Year Ebene beispielsweise sollte der Fokus auf das nächste Jahr und maximal grob auf das zweite bzw. dritte Jahr danach gelegt werden. Somit bleiben Jahr zwei und drei aus der Timebox Epoche mit zunehmender Entfernung zum aktuellen Zeitpunkt immer unspezifischer, da man diesen Horizont sowieso nicht exakt planen kann und hier ja das Prinzip der Agilität greifen soll.

Gleiches Prinzip wird auf der Season Ebene angewendet. Die nächste Season ist sehr konkret. Season zwei und drei usw. bleiben unspezifischer. Hier liegt der Fokus eher auf der Klarheit, warum in der aktuellen Season bestimmte Objectives oder Ziele nicht geplant sind. Weil sie nämlich in Season zwei oder drei an der Reihe sind. 

Auf diese Weise entsteht ein auf Timeboxen basiertes aufeinander aufbauendes System von Objectives mit dem Fokus immer auf den nächsten Zeitraum, je nachdem, auf welcher Ebene ich mich bewege. Gleichzeitig aber passen alle Timeboxen aller Teams immer wieder zusammen, da alle Teams die gleichen Boxgrößen” verwenden.
Im nächsten Schritt ist nun lediglich notwendig, die unterschiedlichen Taktungen in einen gemeinsamen Rhythmus zu integrieren (siehe Rhythmus).