Guidelines / Kapazitäten einschätzen und Defokussierung verhindern

Kapazitäten einschätzen und Defokussierung verhindern

Freie Kapazität – was ist das eigentlich?

In agilen Umgebungen wird sehr häufig viel über das Thema Aufwand für ein Thema, Objective oder eine User Story gesprochen. Die Diskussionen hier sind ähnlich kontrovers wie die, bei denen es um die Kapazität geht.

Häufig wird eingewendet: „ich weiß doch nicht, was ich nächste Woche an Zeit zur Verfügung habe!“ Oder: „Die Welt dreht sich so schnell. Nächste Woche sieht sie schon wieder anders aus, und deshalb ergibt es überhaupt keinen Sinn, mich damit zu beschäftigen, wie viel Kapazität ich in der nächsten Timebox (einem Sprint, einer Season) zur Verfügung habe.“

Ohne eine Beschäftigung mit der Kapazität passiert aber genau das, was wir in so vielen agilen Umgebungen immer wieder erleben: Die Timebox ist hoffnungslos überplant. Frust kommt auf allen Seiten auf, da keine Verlässlichkeit entsteht. Und diese Verlässlichkeit entsteht eben nur, wenn ich mir im Vorfeld überlege, was ich in einem definierten nächsten Zeitrahmen wirklich schaffen kann. Und dazu gehört nun mal, sich zu überlegen, wie viel Aufwand es bedeutet, ein Thema zu bearbeiten. Und auf der anderen Seite, wie viel Zeit (Kapazität) mir dazu zur Verfügung steht.

Einfach gerechnet, wären dies für einen 2-Wochen-Sprint die Arbeitszeit bei einer 5-Tage-Woche à 8 Stunden also 10 Arbeitstage = 80 Stunden.

Ist doch ganz einfach!

Nein, ist es leider nicht, denn wenn wir etwas genauer hinschauen, wird schnell klar, dass diese 80 Stunden für ein Thema gar nicht vollumfänglich zur Verfügung stehen.

Es lohnt sich also, noch ein paar weitere Punkte zu betrachten, um zu der Kapazität zu gelangen, die wahrscheinlich wirklich zur Verfügung steht.

Werden die oben genannten 3 wesentlichen Punkte beachtet und von der gesamten Arbeitszeit abgezogen, so erhält man die „freie“” Kapazität, die real für die Bearbeitung von Themen zur Verfügung steht. Und am Ende bleiben in der Regel oft nur 40 bis 50 % der ursprünglichen Arbeitszeit übrig.

Warum ist diese Betrachtung in FAST so wichtig, und warum wird sie im allgemeinen agilen Kontext kaum beachtet? 

 

Ist ein Team zu 100 % in eine agile Umgebung eingebettet, wie beispielsweise ein Entwicklerteam, so reduziert sich der Einfluss von außen immer mehr und wird in den Takt von Sprint Plannings und Daylies integriert. In diesen Umgebungen verringert sich die Auswirkung von oben genannten Faktoren immer mehr, da durch die Routinen diese immer verlässlicher werden.

Hier überspringt man häufig die Kapazitätsplanung eines nächsten Sprints und misst eher die Veränderung, wie viel man in einem Sprint schafft und inwieweit sich diese Kennzahl verbessert, verschlechtert oder gleich bleibt. Die sogenannte Velocity ist eine gute Kennzahl, um dem Team mit Feedback die Möglichkeit zu geben, den Erfolg von durchgeführten Veränderungen zu sehen, oder bei Verschlechterung der Kennzahl ein Signal zu senden, in einer Sprint Retro auf die Suche nach möglichen Ursachen zu gehen.
Alles im Sinne von Lernzyklen.

Das Umfeld in einem Unternehmen ist größtenteils aber nicht so zu gestalten, wie es die agilen Grundgedanken im agilen Manifest beschreiben. Die Unternehmen sind heterogenen Umgebungen ausgesetzt. Und so ist FAST bewusst für eine solche Umgebung konzipiert.

Dies bedeutet, um für den agilen Rhythmus eines Sprints den Rahmen zu schaffen, dass hier, wie oben beschrieben, Verlässlichkeit entsteht, an den Themen, die geplant sind, auch wirklich arbeiten zu können, ist es unerlässlich, die sehr schwankenden äußeren Rahmenbedingungen der „nicht zur Verfügung stehenden Zeit“ vor einem Sprint Planning aus der Rechnung abzuziehen.

Auf diese Weise schaffen wir in FAST eine „agile Zeitblase“, die es ermöglicht, im Zusammenspiel mit dem geschätzten Aufwand für die Themen, in Einklang gebracht zu werden.

Dies ist dann die Basis dafür, dass

  • die Themen, die geplant sind, auch bearbeitet werden.

  • die Themen, die geplant wurden, auch in der Timebox geliefert werden.

Und auf diese Weise kommt es aufgrund der fehlenden Überplanung auch zu keinen Entscheidungsprozessen aus dem überplanten Themenbacklog „Prioritäten setzen“, oder dazu, im Sprint zu viele Themen anzufangen und nicht abschließen zu können.

Auf diese Art und Weise wird eine wesentliche Ursache für die Defokussierung von Teams verhindert.

Und sollte es aufgrund der vielleicht zu vorsichtigen Planung von Kapazität und Aufwand dazu kommen, dass freie Kapazität zur Verfügung steht, spricht nichts dagegen, aus dem Baglog des nächsten Sprints ein Thema nach vorne zu ziehen.