Unternehmen, die sich dazu entschließen, agile Software-Entwicklung zu skalieren, stehen vor der Herausforderung, sich für ein skaliertes agiles Framework zu entscheiden, dies anzupassen oder gar ein eigenes zu entwickeln. Da sich die Grundideen und Strukturen zwischen den skalierten agilen Frameworks zum Teil grundlegend unterscheiden, sollte die Entscheidung sorgsam getroffen werden. Deshalb möchte ich eine Empfehlung geben, wie man die Entscheidungsfindung ausgestalten sollte.
Dazu möchte ich zunächst auf die Herausforderungen eingehen und damit meine Sichtweise auf die Entscheidungsfindung als auch das Vorgehen begründen.
Über die Voraussetzungen zur agilen Skalierung und weshalb man jene anpassen sollte, habe ich bereits erklärt
Welche Herausforderungen entstehen, wenn man skalierte agiles Arbeiten einführt?
Zunächst möchte ich auf die relevanten Herausforderungen der skalierten agilen Software-Entwicklung eingehen.
Kommunikation! Die Kommunikation ist als Wertschöpfung anzuerkennen, deshalb sind die Informationsflüsse zu koordinieren. Reibungsverluste und Missverständnisse können durch Kommunikation vermieden bzw. reduziert werden. Zudem sind die Kollaboration und die Kommunikation permanent zu erhalten.
Die Interteamkoordination ist eine zentrale Herausforderung. Die Synchronisierung und Koordination zwischen den Teams und Aufgaben soll Abhängigkeiten verringern, um so eine konsistente Leistung aufrechtzuerhalten.
Der Wissensaustausch und die Wissensverteilung sind eine konstante Herausforderung, da sich sowohl das Produkt als auch die Technologie weiterentwickeln und so neues Wissen generieren, das wiederum verteilt werden muss. Der fehlerhafte Umgang mit Wissen kann zu Abhängigkeiten, einem Wettlauf um Ressourcen, bis hin zu Blockaden führen.
Da das Produkt fortlaufend entwickelt wird und sich die Anforderungen an die zu entwickelnde Software im Zeitverlauf verändern können, sind die Architektur und die Infrastruktur fortlaufend anzupassen und weiterzuentwickeln. Und je mehr Teams involviert sind, desto herausfordernder gestaltet sich dieser Prozess.
Je nach skaliertem agilen Framework werden neue Rollen eingeführt. Sowohl die Aufgabenverteilung als auch die mögliche Veränderung von Verantwortlichkeiten können aufgrund von inadäquater Rollenklärung zu Unklarheiten führen.
Die Autonomie ist im skalierten Umfeld eine Herausforderung. Ein ausgewogenes Verhältnis zwischen der Autonomie und der Kontrolle (Vorgaben, Übersicht) wirkt sich positiv auf das Engagement und die Motivation aus. Den Teams ermöglicht die Selbstorganisation, die Verantwortung für den Entwicklungsprozess zu übernehmen und ihn freiwillig zu verbessern. Zugleich wird die Transparenz zwischen den Beteiligten häufig geringer, je mehr Teams involviert sind, was zu einem Verlangen nach einer stärkeren Kontrolle führen kann (auf Kosten der Autonomie).
Ich bin mir sicher, diese Liste kannst Du locker mit Deinen eigenen Erfahrungen ergänzen!
Das skalierte agile Framework finden ist ein komplexes Entscheidungsproblem
Diese skizzierten Herausforderungen in ihren jeweiligen Ausprägungen können nicht vollständig vorhergesehen werden. Zudem können diese erst im Zeitverlauf der Skalierung auftreten oder an Bedeutung gewinnen.
Die Festlegung der Bearbeitung der (bekannten) Herausforderungen ist abhängig von der Dringlichkeit und deren Abhängigkeiten (personell, sachlich, soziotechnisches System) – hierzu kann keine pauschale Empfehlung gegeben werden. Eine starke Interdependenz der Herausforderungen kann zudem angenommen werden. Summa summarum kann man von einem komplexen Entscheidungsproblem sprechen.
Ein Plädoyer für eine Gruppenentscheidung
Da Unternehmen an verschiedenen Punkten des Einführungsprozesses mit unterschiedlichen Herausforderungen konfrontiert sind, ist eine kollaborative Entscheidungsfindung ein relevanter Baustein für Akzeptanz und Erfolg. Die Einführung eines skalierten agilen Frameworks wird von der operativen Ebene getragen und sollte in Einklang mit der strategischen Ausrichtung erfolgen, also dem Management. Dabei sollte ein klares Gleichgewicht zwischen der Top-down- und der Bottom-up-Betrachtungsweise berücksichtigt werden, sodass eine kontinuierliche beiderseitige Unterstützung und Reflexion ermöglicht wird.
Eine Gruppenentscheidung wird deshalb bevorzugt. Dies ist aus zwei Gründen erforderlich. Das Wissen ist verteilt: Die Einbeziehung der operativ tätigen Mitarbeitenden ist zwingend erforderlich, da möglichst zahlreiche Informationen eingeholt und betrachtet werden müssen. Zudem ist ein Abgleich zu den strategischen Überlegungen zu treffen. Weiterhin sind die agilen Werte und Prinzipien beizubehalten.
Das agile Arbeiten erfordert einen hohen Grad an selbstständigem Arbeiten und somit Autonomie und Verantwortungsbereitschaft. Vorgeplante Top-down-Entscheidungen beschneiden diese Arbeitsweise und die agile Unternehmenskultur und würden die Autonomie und die Fähigkeit zur weiteren Selbsttransformation einschränken. Insbesondere vor dem Hintergrund, das agile Arbeiten auszuweiten, ist es relevant, Kollaboration, Kommunikation und Transparenz in den Mittelpunkt zu stellen.
Um die Akzeptanz für die Transformation zu erreichen, ist es bedeutend, die Mitarbeitenden auf breiter Ebene einzubeziehen. Zudem sollten die Mitarbeitenden so früh wie möglich involviert werden. Dies erfordert sowohl eine kollaborative Haltung als auch die Zusammenarbeit des Managements mit den operativ tätigen Mitarbeitenden. Dies fördert die Qualität, die Akzeptanz und die Unterstützung für die Entscheidung.
Das führt uns nun geradewegs zur Gruppenzusammensetzung für die Entscheidung.
Wie sollte die Gruppe zusammen gesetzt sein?
Die Gruppe sollte auf keinen Fall ausschließlich aus Führungskräften des Managements besteht, die die operativen Herausforderungen nicht aus eigener Erfahrung kennen, denn das führt unweigerlich ins Anti-Pattern des Groupthinks.
Deshalb sollte die Gruppe aus gleichberechtigten Mitarbeitenden aus dem Bereich ,Umsetzung‘ (Development Team, Architekten, UX Experten), der ,Geschäftsseite‘ (Product Owner, Product Manager und Management) sowie aus Agile Coaches und/oder Scrum Mastern bestehen. Es können entweder alle Mitarbeitenden involviert oder Repräsentanten gesendet werden.
Bei der Auswahl dieser Entscheidergruppe ist es entscheidend, dass ein Mix aus informierten Personen eine fundierte strategische oder operative Sichtweise bieten kann, sodass ein 360°-Blick auf die Entscheidungssituation gewährleistet ist. Das ermöglicht den Abbau von Informationsasymmetrien, sodass Transparenz und ein gegenseitiges als auch gemeinsames Verständnis hergestellt wird. Dabei können mögliche Herausforderungen identifiziert werden und für die Auswahl und Ausgestaltung eines künftigen skalierten agilen Frameworks im Blick behalten werden.
Zudem ist eine gleichbleibende Zusammensetzung der Entscheidergruppe erforderlich. Die Verantwortung für die Entscheidung wird in der Entscheidergruppe geteilt. Zusätzliche Konsultationen können im Rahmen der Informationsbeschaffung eingeholt werden. Konsultationen sind je nach Auswirkung der Entscheidung notwendig, wenn diese Kunden und Lieferanten oder angrenzende Abteilungen betreffen.
Zusammenfassend lässt sich festhalten: strategisch- und operativ-tätige Mitarbeitende, die innerhalb des skalierten agilen Frameworks arbeiten, sind Entscheider. Alle anderen sind keine Entscheider, können jedoch als Stakeholder einbezogen werden.
Die Entscheidung, ob skaliert wird, obliegt dem Management, weil es sich dabei um eine strategische und ressourcenorientierte Entscheidung handelt. Es kann jedoch nicht allein vom Management antizipiert und entschieden werden, welche Eigenentwicklung oder welches skalierte agile Framework samt möglicher Anpassungen sinnvoll ist.
Wie nun Vorgehen bei der Entscheidungsfindung?
Für den komplexen Problembereich schlägt Cynefin als Lösungsstrategie einen ,Probiere-Erkenne-Reagiere-Ansatz‘ vor. Der komplexe Problembereich wird daher auch „Domain of Emergence“ genannt. Meiner Meinung nach lässt sich dieses Entscheidungsproblem also nicht mittels ,einmaliger Entscheidung auf dem Reißbrett‘ klären, sondern bedarf einer schrittweisen Implementierung und Überprüfung.
Um emergente Praktiken zu finden, sollte also ein Umfeld geschaffen werden, in dem das Beobachten ermöglicht wird. Denn wenn der gewünschte Endzustand nur schematisch beschrieben werden kann und kein offensichtlicher Weg dorthin besteht, ist ein iterativer Ansatz notwendig. Das minimiert das Risiko von Fehlentscheidungen und lässt zudem Handlungsspielräume offen.
Dieses situative Vorgehen ermöglicht es, mit neuen Informationen, Erfahrungen und der Dynamik des Umfelds umzugehen. In diesem Zusammenhang ist das Lernen als Vor- und Nachteil zugleich anzuführen: Das Lernen erfordert ein hohes Maß an Zeit, Kollaboration, Aufmerksamkeit und Selbstreflektion. Es ermöglicht jedoch die situationsgerechte Ausgestaltung des skalierten agilen Frameworks.
Mein Tipp: Startet am besten mit einer gemeinsam verabschiedeten Minimalausprägung (Minimum Scaled Agile Framework) und bewegt Euch dann in regelmäßigen Reviewzyklen (bspw. als Retro zum Gesamtsystem) gemeinsam nach vorn. Dabei kann ein Framework als möglicher Zielzustand (aber nicht als zu erreichender Endzustand) verstanden werden.
Verbesserungsvorschläge und Klärungsbedarf kann auch in großen Gruppen mittels Open-Space-Formaten oder World Cafes oder auch Appreciative Inquiries adressiert werden. An diesem Punkt möchte ich auf das Konzept von Argyris & Schön des „organisationalen Lernens“ verweisen.
Quellen
- Edison, H. u. a., Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review, 2021
- Conboy, K., Carroll, N., Implementing Large-Scale Agile Frameworks: Challenges and Recommendations, 2019
- Dikert, K. u. a., Challenges and success factors for large-scale agile transformations: A systematic literature review, 2016
Schreibe einen Kommentar