Auf die Plätze, fertig, los – Agile Skalierung

Zu Anfang eines Rennens heißt es meistens „Auf die Plätze, fertig, los”. Auf Teamebene bedeutet „Ready to Develop” – also „fertig für die Entwicklung” – dass eine User Story bereit dafür ist, an das Team weitergegeben und in den nächsten Sprint aufgenommen zu werden. Ready to Develop wird oft als Stütze für die Definition of Done angesehen. Nur zum Vergleich: Die Definition of Done ist sowohl im Bezug auf ein einzelnes Team als auch dann sinnvoll, wenn mehrere Teams ein gemeinsames Ziel verfolgen. Tatsächlich kann man „ready” nicht so einfach auf ein größeres Projekt übertragen wie „done”. Bei größeren agilen Projekten erfordert „Ready” häufig zwei unterschiedliche Kriterien: „Ready to Develop” und „Ready to Go”.

Fünf einfache Kriterien für die agile Skalierung

Die gängigsten Ready-Kriterien sind in „Ready to Develop“ eingebettet. Ready to Develop wird auf Teamebene verwendet. Die Kriterien sind:

• Die Story ist gut gestaltet.
• Die Story erfüllt die INVEST Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable)
• Eine Story braucht Akzeptanzkriterien.
• Für jede Story sollte man einen externen Experten (nicht im Team) für das jeweilige Thema zur Hand haben.
• Es gibt keine externen Abhängigkeiten, die die Story davon abhalten, fertiggestellt zu werden.

Anhand dieser fünf Kriterien lässt sich gut herausfinden, ob man im nächsten Sprint direkt mit der Arbeit an einer bestimmten User Story anfangen kann oder ob noch mehr Grooming benötigt wird. Teams haben natürlich lieber Arbeiten, die sie sofort angehen können, statt solcher, die schlecht definiert sind

Team of Teams und die nächste Ebene

Die gleiche Vorliebe hat das sogenannte „Team of Teams” (Beispiel dafür ist ein Agile Release Train in SAFe). Um definieren zu können, ob sie bereit sind, mit der Arbeit zu beginnen, benötigt ein Team of Teams jedoch Kriterien auf einem höheren Level. Die „Ready to Go”-Kriterien, die ich am häufigsten benutze, sind diese:

1.) Die Teams haben ihren Entwicklungsrhythmus aneinander angepasst. Den Rhythmus der Teams anzugleichen und einen gemeinsamen Rhythmus zu finden, ist eine sehr gute Maßnahme, um Kommunikation und Integration zu gewährleisten.

2.) Es gibt einen ausreichend gepflegten Backlog. Man sollte genug Arbeit identifizieren und vorbereiten, um mit der Arbeit beginnen und die Teams unterstützen zu können – nicht mehr. Der Backlog muss nicht vollständig sein (oder voll und ganz ausgearbeitet), bevor die Arbeit beginnt.

3.) Architektur und Standards wurden ausreichend definiert. Bei SAFe wird z. B. nur so viel Design und Architektur entwickelt, dass die Teams gerade rechtzeitig die Hilfe und Beratung erhalten, die sie benötigen.

4.) Erkennbare Einschränkungen wurden identifiziert. Einschränkungen beziehen sich meist auf Dinge wie Fristen, begrenzte Budgets und verfügbare Kapazitäten aber manchmal auch auf physische oder technische Einschränkungen. In jedem Team muss jeder Einzelne über die Einschränkungen Bescheid wissen, in deren Grenzen man sich bewegt.

5.) Die benötigte Infrastruktur wurde realisiert. Die Infrastruktur besteht aus den grundlegenden Strukturen, Instrumenten und Services, die benötigt werden, um einen bestimmten Wert zu liefern. Wenn Sie Software liefern wollen, kann die benötigte Infrastruktur etwas so Simples wie ein Sitzplatz und ein Stromanschluss sein oder aber etwas so Komplexes wie Server, Router, Netzwerke und Entwicklungstools.

6.) Teams und Rollen wurden eingeteilt. Stellen Sie sicher, dass Sie die Scrum Teams mit allen notwendigen Rollen besetzt und organisiert haben (vorausgesetzt, Sie arbeiten nicht mit bereits existierenden Teams). Außerdem sollten alle zusätzlichen Rollen identifiziert und geklärt worden sein. Wenn man sich nämlich nicht richtig auf das Organisieren und Besetzen der Teams konzentriert, kann das schnell schief gehen.

Legt los mit der agilen Skalierung!

Ready to Go und Ready to Develop haben unterschiedliche Ziele und somit auch unterschiedliche Kriterien. Wenn es also an der Startlinie heißt „…fertig”, gehen Sie im Kopf noch einmal alle „Ready to Go”-Kriterien durch, um herauszufinden, ob sie wirklich schon bereit sind, mit einem großen Projekt anzufangen. Sobald Sie diese Hürde genommen haben, können Sie die zweite Reihe von Kriterien angehen – die „Ready to Develop”-Kriterien. Wenn Sie diese beiden Faktoren einbeziehen, werden Sie viel besser lossprinten können, wenn der Startschuss fällt.

Dieser Text stammt aus dem Blog von SPaMCAST und wurde von uns ins Deutsche übersetzt.