Als ich mich kürzlich auf einer Konferenz mit anderen agilen Coaches ausgetauscht habe, stellten wir uns die Frage nach unserer Haltung zu SAFe. Kurz zur Erläuterung: Das ist ein Framework, das mehrere agile Teams koordinieren soll, damit sie gut auf einer Ebene arbeiten können. Mich interessierte die Erfahrung aus der Praxis derer, die schon damit gearbeitet haben und nicht nur die Theorie aus Büchern.
Agile im Team-, Programm- und Portfoliomanagement
Welche Ansätze, welche Prinzipien, welches Framework können dabei helfen, um die Arbeitsorganisation in großen Projekten mit mehr als fünf Teams sicherzustellen? Damit sie dabei unterstützt werden, neue Produkte und Lösungen in kürzester Zeit nachhaltig auf dem Mark zu etablieren.
Eines davon ist eben SAFe, das Scaled Agile Framework, eines der verbreitetsten Rahmenwerke, um agiles Handeln zu skalieren. Ein System, das Verantwortlichkeiten und Aktivitäten auf Team-, Programm- und Portfolio-Ebene koordiniert. Für eine schlanke und effektive Produktentwicklung, die gleichzeitig die Produktivität und Flexibilität aller Beteiligten fördert.
Es gibt vor, ein „Team of teams“ zu etablieren, also ein Zusammenschluss mehrerer agiler Teams. Dieses hält einen Dependency Board ab, um die Prioritäten und Abhängigkeiten der einzelnen Teams darzulegen und miteinander zu besprechen. Danach soll sich dies durch das komplette Projekt ziehen, um die wichtigsten Ziele zu definieren und zu realisieren. Soweit die Theorie, mich interessierte nun die Praxis:
Fazit meines Austauschs mit den erfahrenen Kollegen: Skalierung soll vermieden werden, wo es nur geht. Ich war nicht wirklich überrascht, jedoch überrascht von der Vehemenz dieser Aussage. Die weitere Empfehlung lautete: Lieber auch zehn Teams parallel laufen lassen und die Product Owner tauschen sich aus, als ein extra Framework einzusetzen.
Zwei Erkenntnisse waren elementar: Als erstes wurde die Gefahr genannt, dass das Management der alten Schule sich zu sehr einmischt und kontrollieren möchte. SaFe gibt dieser Personengruppe zu viele Möglichkeiten. Dies geht sogar so weit, dass niemand mehr von einem Dependency Board sprechen möchte, sondern von „Big Room Planning“. Außerdem wird der Overhead schnell zu groß gegenüber seinem Nutzen.
Mehr Raum für gute Kommunikation statt SAFe
Statt auf Prozesse zu setzen, lieber mehr Raum für gute Kommunikation stiften. Es ist also wichtig Kommunikationsräume zu schaffen, in denen sich Teams und Teammitglieder austauschen können. Dazu kann man über die verschiedenen Ebenen etablieren. Auch bietet es sich an Chapters einzuführen, sprich Teammitglieder verschiedener Teams mit gleichen fachlichen Themen zu verbinden, damit diese sich gegenseitig Dailies und Sprints geben können.
Für sehr große Organisationen hingegen macht SAFe durchaus Sinn, um Teams, Programme und Strukturen in ihren Vorhaben transparenter und effektiver zu gestalten. Aber nicht starr nach Plan eingesetzt, sondern nach eigenen Regeln gestaltet, die für das Projekt sinnvoll sind.
Viele Projekte haben von den gängigen Frameworks wie SAFe, LeSS, Nexus, Scrum of Scrum und weiteren die besten Methoden für ihre Ziele adaptiert und zu eigen gemacht. Dies funktioniert wunderbar. Mein Fazit: Praktischer Austausch kann sehr wertvoll sein und zeigt eine andere Realität, als in Büchern häufig versprochen.
Opmerkingen