Nun zur pragmatischen Kapazitätsschätzung. Am einfachsten ist diese, wenn die Agile Release Trains (ART) für jedes Portfolio Epic, zu dem sie Wert beitragen, eine Schätzung in T-Shirt Size abgeben, wie intensiv sie daran beteiligt sind: XL, L, M, S, XS. Die einfachste Art ist es, dass jeder ART eine Bubble an das Portfolio Epic hängt, zu dem er etwas beiträgt. Die Farbe definiert den ART, die Grösse der Bubbles entspricht der Intensität. Das sieht dann zum Beispiel wie folgt aus:
Nun kann man ganz einfach die ARTs fragen: „Schafft ihr das, was das Bild wiedergibt – und zwar ohne Wartezeiten aufgrund zu hoher Parallelität?“. Der Hinweis auf das Vermeiden von Wartezeiten ist relevant. Es ist das Ziel der Flow-Optimierung, dass jedes einzelne Portfolio Epic in der kürzesten möglichen Zeit durch das Portfolio Kanban läuft. Das ist mit dem Anspruch verbunden, Wartezeiten zu vermeiden aufgrund Überlast in einem Team oder ART. Teams und ARTs sind hier in der Verantwortung, entsprechendes Feedback zu geben. Solution Manager, Product Manager und Business Owner sind in der Verantwortung, das Feedback ernst zu nehmen und die Entscheidungen in der Priorisierung entsprechend zu fällen.
Wenn nun ein ART die Hand hebt und mit „NEIN“ auf die obige Frage antwortet, so bedeutet dies, dass mindestens eines der Portfolio Epics mit Beteiligung des ART nach unten geschoben werden muss. Das sind die wichtigsten Entscheidungen in der Priorisierung, die im Portfolio zu fällen sind. Schiebt man kein Portfolio Epic aufgrund des Feedbacks nach unten, dann dauern alle Portfolio Epics mit Beteiligung des Teams eben länger, da Wartezeiten entstehen. Der Flow wird schlechter und die Wertgenerierung für das Unternehmen sinkt.
Auf diese Weise lässt sich sehr pragmatisch herausfinden, ob das Wunschbild der Wertgenerierung auch von den ARTs als realistisch erreichbar eingeschätzt wird. Zusammen ist es nun möglich, Wertbeitrag der ARTs und Abhängigkeiten zwischen den ARTs zu diskutieren und auf der Basis zu entscheiden, wie viele und welche Portfolio Epics mit hoher Wahrscheinlichkeit (Confidence Vote) im nächsten Zeitabschnitt der Portfoliomap abgeschlossen werden können – und welche eben NICHT und somit auf später verschoben werden MÜSSEN.
Unangenehme aber wichtige Entscheidungen, um Flow zu optimieren
Zugegeben, diese Entscheidungen sind nicht einfach. Sie bedeuten, zu entscheiden «Was machen wir NICHT» (so dass die Dinge, die wir machen, schneller Wert erzeugen). Das sind genau die Entscheidungen, die jeder versucht, zu vermeiden. Diesen Entscheidungen müssen wir uns jedoch stellen, wenn wir Geschwindigkeit und Wertgenerierung steigern wollen. Das Vermeiden von Parallelität im System ist der Hebel. Die Transparenz der Portfoliomap über das gesamte Portfolio ist zwingend. Gärtchendenken war dann (hoffentlich) gestern.
In der Portfoliomap und der damit verbundenen Transparenz sind noch viele weitere sehr hilfreiche Ansätze verbunden, die helfen, den Flow zu optimieren. So zum Beispiel:
- Warum läuft die Zeit in der Portfoliomap von oben nach unten und nicht von links nach rechts wie im SAFe Portfolio?
- Warum wird kein Balken gezogen, wie lange ein Portfolio Epic im Portfolio ist, sondern nur ein Post-it in den Zeithorizont geklebt, in dem wir uns wünschen oder (most likely) erwarten, dass der Wert des Portfolio Epic eingelöst wird?
Das zu diskutieren würde jedoch diese Blogserie sprengen. Neugierig? Dann nehmen Sie Kontakt mit uns auf.
Dieser Blogbeitrag war dem operativen Kapazitätsmanagement gewidmet, also dem Abgleich von Demand und vorhandener Kapazität der Teams für die Portfolio Epics, die gerade in der Umsetzung sind oder demnächst umgesetzt werden sollen.
Der nächste Blogbeitrag beschäftigt sich mit dem taktischen Kapazitätsmanagement, also dem Umgang mit der mittelfristigen Veränderung des Demands und kontextgebundener Kapazität. Oder, mit einem Beispiel ausgedrückt: Augenblicklich sind viele Teams damit beschäftigt, mit Java kundenorientierte Online-Systeme zu implementieren. Wir wissen jedoch jetzt schon, dass wir im nächsten Jahr eine SAP R3 – Hana Ablösung durchführen müssen, wir also wenig Kapazität am Frontend und viel Kapazität in SAP benötigen werden.
