Wie „skalierst“ du Agilität? Ein Interview mit Malte Foegen.

Wie entscheidest du, welche agilen Ansätze du aus dem agilen Werkzeugkoffer nimmst, wenn es darum geht, eine agile Organisation zu gestalten?

Ich gucke mir jedes Team und jede Ebene für sich an. Nur so kann man herausfinden, welcher agiler Ansatz für welches Team und für welche Ebene sinnvoll ist.

Und man kann nicht einfach so ein „Scaled Agile“ Framework nehmen?

In der Praxis muss man schon genau hinsehen, was ein Team braucht. Eine agile Organisation setzt unterschiedliche Frameworks an unterschiedlichen Stellen ein, weil sich ja die Arbeit der Teams unterscheidet. Größere Frameworks sind auch schon lange keine Frameworks im Sinne von „mach es genau so“ mehr. Sie sind ein Set von Frameworks, die wie Puzzleteile spezifisch für eine Organisation zusammengesetzt werden müssen. „Tailoring“ nennt man das.

Ist dann Agilität nicht beliebig, also ein „Agil-But“?

Nein, die Puzzlestücke – ich würde eher von Mustern sprechen – sollte man schon so machen, wie sie beschrieben sind. So ein Puzzlestück ist z.B. Scrum oder Kanban. Hier sollte ich nicht rumfummeln. Aber das Aussuchen der richtigen Puzzlestücke, und das Zusammenstellen dieser zu einer agilen Organisation, das ist nur fallspezifisch zu lösen.

Und wo beginnst du?

Ich beginne bei den Teams, weil sie die Basisbausteine jeder Organisation sind. Ohne agile Teams bekommt man keine agile Organisation.

Und was für Fragen stellst du auf der Teamebene?

Auf der Teamebene sehe ich grundsätzlich zwei Muster: entweder habe ich ein Team, das größere Aufgaben erledigt, die auch etwas Zeit brauchen. Ein Beispiel wäre z.B. ein Team, das ein Produkt entwickelt. Die andere Möglichkeit ist ein Team, das einen Service liefert und eher kleine Anfragen statt längerfristiger, größerer Aufgaben hat. Im ersteren Fall ist vermutlich Scrum ein Ansatz, im letzteren eher Kanban.

Und wenn ein Team beides macht, also etwas entwickelt und auch Serviceanfragen behandelt?

Dann kann ich beides kombinieren. Das ist Scrumban. Das heißt aber auch, dass man alle Regeln von Scrum und Kanban hat. Nicht etwa ein bisschen von beidem.

Und bei Scrum, was mache ich, wenn das Team mehrere Produkte hat?

Auch Scrum. Dann stehen halt Anforderungen für mehrere Produkte im Produkt Backlog.

Müssen alle Teams das gleiche Framework nutzen, wenn sie zusammenarbeiten?

Nein, die agilen Frameworks sind alle miteinander kompatibel. Das eine Team kann Scrum machen, das andere Kanban, und trotzdem können sie am gleichen Produkt arbeiten.

Jetzt zur Zusammenarbeit von Teams. Wie beginnst du, wenn du eine „Konfiguration“ suchst?

Meine erste Frage geht zum Artefakt „Produkt“. Da frage ich, ob das Team ein gemeinsames Produkt erstellt oder nicht. Ist die Antwort „Ja“ können wir schon mal notieren: es gibt ein gemeinsames Ziel, eine gemeinsame (Qualitäts-)Definition von Fertig, ein gemeinsames Product Backlog, ein gemeinsames Product Backlog Refinement, und einen Product Owner. Die Fragen sind bei einem Service ähnlich, da heißt das oft nur anders. Das Produkt ist der Service, die Qualitätsdefinition ist das Service Level Agreement, und der Produkt Owner heißt häufig „Service Request Manager“. Ggf. haben wir auch ein Service Development Backlog, falls wir den Service weiter entwickeln müssen. 

Und wenn die Antwort nein ist?

Dann können die Teams unabhängig voneinander arbeiten. Das ist eigentlich der beste Fall. Um abzustimmen, an welchen Themen die Teams grundsätzlich arbeiten und wie viel Kapazität bzw. Budget sie haben, kann man ein Portfolio Kanban nutzen. Mehr sollte man dann aber auch nicht tun. Unabhängige Teams sind am schnellsten.

Und wenn es ein gemeinsames Produkt gibt, wie geht es dann weiter?

Die nächste Frage geht dann zu dem Artefakt „Inkrement“. Ich frage, ob die Teams nur zusammen liefern können, oder ob jedes Team unabhängig vom anderen Team liefern kann. Wenn sie nur zusammen liefern können („deploy“ heißt das in der Software), dann notiere ich: gemeinsames Inkrement, gemeinsames Sprint Review und gemeinsame Planung. Wenn die Teams unabhängig liefern können, dann brauche ich das alles nicht als gemeinsames Ereignis. Allerdings wäre es natürlich einfacher, wenn wir auf das gemeinsame Inkrement verzichten können und jedes Team unabhängig von anderen ausliefern kann. Das braucht dann ggf. Architekturarbeit und shared code ownership.

Und wenn es kein gemeinsames Inkrement gibt?

Das ist eigentlich toll, weil die Teams dann unabhängiger sind. Aber auch ohne gemeinsames Deployment kann es immer noch sein, dass die Teams während des Sprints zusammenarbeiten müssen. Dann frage ich, ob die Teams „einfach aufeinander zugehen und reden“ oder ob sie ein „Scrum of Scrums“ nutzen wollen. Je nachdem was sie entscheiden notiere ich das dann. Ggf. kann eine gemeinsame Planung auch helfen, oder eine gelegentliche gemeinsame Retrospektive. Wenn die Teams das wollen notiere ich auch das auf meiner Konfigurationsliste. Diese Synchronisation ist übrigens ganz typisch für Service-Teams, die haben häufig ein „Morgenmeeting“ (aka Daily Scrum) oder ein gemeinsames „Queue Replenishment“ (aka Planung).

Und was ist mit der zeitlichen Synchronisation?

Da frage ich nicht nach. Wenn es gemeinsame Ereignisse gibt, dann notiere ich mir immer „gemeinsamer Takt“. Sonst komme ich ja bei der Organisation der Ereignisse in Teufels Küche.

Wie viel gemeinsamer Takt muss denn sein?

Das hängt vom Koordinationsbedarf und der Änderungshäufigkeit der Anforderungen ab. Wenn ich sehr große Anforderungen habe, an denen ein Team mehr als 2 Wochen arbeitet, dann können sich die Teams diese Einträge alle 3-6 Sprints ziehen. So eine Synchronisation alle 3-6 Sprints nennen wir Etappe. Wenn ich nur kleine Anforderungen habe, und die sich häufig ändern, dann brauche ich jeden Sprint eine gemeinsame Planung.

Muss alles im gemeinsamen Product Backlog stehen?

Nein, es kann sein, dass ein Team sich z.B. 50% der Kapazität für direkte Anfragen reserviert, und die anderen 50% auf ein gemeinsames Product Backlog zurückgehen.

Braucht jedes Team einen Product Owner, oder gibt es einen PO für alle?

Das geht beides. Das Product Backlog Refinement ist eine gemeinsame Aufgabe vom Team und Product Owner. Ein PO und Teams, ein Chief PO und Team-PO, ein PO und Teamvertreter – das hängt vom Können und von der Zeit ab, die PO und die Teams haben. Aber alle Optionen können funktionieren. Wichtig ist, dass es als Zusammenarbeit verstanden wird, und nicht als Team versus PO.

Und die ganzen anderen Fragen, wie z.B. verteilte Teams, oder Teammitglieder in zwei Teams?

Das sind alles gute Fragen. Das sind für mich aber Impediments, egal welchen Ansatz ich wähle. Diese Impediments muss ich so oder so lösen, sie bestimmen daher nicht die Konfiguration meiner agilen Organisation.

Und das Management?

Das ist auch ein Team. Team hat für mich etwas mit Zusammenarbeit und an-einem-Strang-ziehen zu tun, Teams gibt es auf allen Ebenen.

Und was ist mit größeren Organisationen bzw. den nächsten Ebenen?

Die nächste Ebene geht genauso wie die erste. Ich denke mir die Bereiche einfach als Teams, und stelle mir die Fragen zur Zusammenarbeit der Teams einfach noch mal – rekursiv sozusagen.

Und das ist alles? Das ist die ganze Wahrheit?

Nö, das ist nicht die ganze Wahrheit, die findet man erst mit vielen Jahren und „Finetuning“ heraus. Aber es ist ein guter Anfang. Und es ist besser als daherzukommen mit „Alles ist Scrum“ oder „Wir machen SAFe“, oder „SAFe ist doof, wir machen LeSS“. Oder „Wir machen Spotify Modell“. Ach, ihr versteht mich. Das mit dem Hammer ist nicht so gut, und auch nicht das mit den S, M, L Hämmern. Leider braucht es einen ganzen Werkzeugkoffer, Nachfragen was das Team braucht und Fingerspitzengefühl.

Und wenn ich jetzt selbst etwas lesen will?

Dann würde ich bewusst zwei Frameworks angucken, die erst einmal scheinbar sehr unterschiedlich sind – und dann doch ganz viel Übereinstimmung haben.

Und natürlich empfehle ich auch unser Buch „Organisation in einer digitalen Zeit“, das genau diese Themen bespricht.

Diesen Blogbeitrag gibt es übrigens auch auf Englisch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Deine E-Mail-Adresse wird nicht veröffentlicht, an Dritte weitergeleitet oder anderweitig genutzt.