Lösungsansätze zur Prüfung agiler Organisationen
Agilität ist seit Jahren in vielen Unternehmen auf dem Vormarsch. Und nachdem die Agilität ursprünglich Anwendung in kleinen Teams fand, werden aktuell zunehmend diese agilen Teams in größeren (skalierten) Einheiten zusammengefasst. Großprojekte mit einigen hundert Mitarbeitern werden inzwischen agil organisiert und auch ganze Unternehmen transformieren sich und schaffen agile Organisationsformen. Doch was bedeutet dies für interne Revisionen? Nach Ansicht der Autoren werden neue Denk- und Arbeitsweisen notwendig, für die die Revision ein Verständnis erlangen muss, um in diesem Umfeld zum Unternehmenserfolg beitragen zu können. Der Artikel behandelt zwar vorrangig die Prüfung skalierter agiler Systeme, bietet aber auch einen Ausblick auf die Rolle der Revision im agilen Unternehmensumfeld.
Disclaimer: Dieser Artikel ist ziemlich lang. Wenn Du diesen lieber als PDF lesen oder ausdrucken möchtest, dann klicke hier:
1. Herausforderungen für die Revision
Im agilen Projektmanagement gibt es inzwischen verschiedene bewährte Ansätze der Skalierung einzelner agiler Teams zu größeren zusammenhängenden agilen Einheiten. Hierdurch entstehen agile Organisationen, die sowohl Großprojekte aber auch Linienorganisationsformen bis hin zu ganzen Unternehmen sein können.
Diese agilen Organisationen stellen die Revision vor neue Herausforderungen, weil Rollen und Verantwortlichkeiten anders verteilt sind und Planungen sowie Dokumente dynamisch entstehen. Gewohnte Herangehensweisen in der Prüfung passen nicht mehr. Neue Prüfungsansätze sind erforderlich. Statische Prüfungsverfahren wird es in dem dynamischen Prüfungsbereich sehr wahrscheinlich nicht mehr geben, weil die zur Anwendung kommenden agilen Frameworks in der Praxis regelmäßig Anpassungen erfahren. Zumal bei der Einführung agiler Arbeitsformen häufig unternehmensindividuelle und auch Interimslösungen im Rahmen des Transformationsprozesses hin zu einer agilen Organisation implementiert werden. Dies wiederum stellt auch die interne Revision vor die Herausforderungen, individuelle Lösungen zu finden. Hierzu werden im Folgenden vier Ansätze vorgestellt, die helfen können, auf diese Herausforderung zu reagieren:
- Flughöhen (Flightlevel) nach Leopold – Blick über die Teamgrenzen & Abhängigkeiten sichtbar machen (Kapitel 3.1)
- Der Projektwürfel – agile Organisationen nach DIIR-Standard Nr. 4 prüfen (Kapitel 3.2)
- SAFe-Metriken und Self-Assessments – Beispiele für interne Kontrollen (Kapitel 3.3)
- Prinzipien – Agile Prinzipien als Hilfsmittel in der Prüfung (Kapitel 3.4)
Diese vier Ansätze werden anschließend durch drei Vertiefungsthemen hinsichtlich besonders risikobehafteter Fragestellungen ergänzt. Zuvor wird jedoch zum gemeinsamen Verständnis einleitend ein kurzer Überblick zu bekannten Rahmenwerken zu agilen Organisationen dargestellt.
Ein Verständnis dieser Rahmenwerke setzt auch ein Grundverständnis agiler Arbeitsweisen voraus. Für interessierte Revisoren mit weiterem Informationsbedarf empfehlen wir den Artikel „Revision agiler Projekte“ (Andelfinger et al. (2016)), der als Vorgänger zu diesem Artikel Prüfern einen Überblick zu agilen Denk- und Arbeitsweisen gibt.
2. Rahmenwerke zu agilen Organisationen
Zwei bekannte Rahmenwerke für agile Organisationen sind Large Scale Scrum (LeSS) und das Scaled Agile Framework (SAFe).
2.1 Was ist LeSS
Large Scale Scrum (LeSS) bietet eine konsequente agile Lösung basierend auf Scrum, um mit mehreren Scrum Teams zusammen an einem gemeinsamen Produkt zu arbeiten – insbesondere bei Großprojekten bzw. komplexen Produkten (für mehr zu LeSS vgl. Larman/Vodde (2016)). Der Lösungsansatz von LeSS ist es, den Sprint-Zyklus von Scrum zu belassen, aber bestimmte Scrum-Events gemeinsam durchzuführen. Bei LeSS werden die Sprint Planung Eins und das Sprint Review gemeinsam durchgeführt. Jedes Team hat seine eigene Retrospektive und darüber hinaus gibt es eine gemeinsame Retrospektive mit Vertretern aller Teams. Zur horizontalen Koordination gibt es gemeinsame Product Backlog Refinements und eine Inter-Team-Koordination (z. B. Scrum of Scrums).
Die Prüfung von LeSS-Großprojekten basiert auf dem Vorgehen zu Scrum-Projekten. Die Ergänzungen bzw. Erweiterungen zu Scrum-Projekten sind bei der Prüfungsplanung entsprechend zu berücksichtigen. Dieses Prüfungsvorgehen bei agilen Projekten wurde bereits in Andelfinger et al. (2016) umfassend beschrieben.
2.2 Was ist SAFe?
Das Scaled Agile Framework (SAFe) ist – neben LeSS – eines der verbreitetsten Rahmenwerke, um agile Produktentwicklung mit vielen Teams zu skalieren (für mehr zu SAFe vgl. Knaster/Leffingwell (2020)). SAFe baut auf Lean Management auf und bietet ein agiles Framework für die Ebene der Teams, der Programme und der gesamten Organisation (Portfolio-Ebene).
Gründe für die Popularität von SAFe sind:
- Große Projektorganisationen können in einer agilen Organisation zusammengefasst werden.
- Die Programm- und Portfolio-Ebene sind darin integriert.
- Standardisierte Techniken, Rollen, Meetings und Artefakte werden zur Verfügung gestellt.
Kern des Frameworks sind die sogenannten Agile Release Trains (ART). So arbeiten mehrere Teams in einem ART zusammen und bearbeiten ein gemeinsames Produkt. Ein großes Unternehmen budgetiert typischerweise mehrere solcher Produkte in einem Portfolio, um den Mitteleinsatz bei der Entwicklung vieler komplexer Produkte über alles zu optimieren. Die Definitionen und Unterschiede von Portfolios, Programmen und Projekten sind u. a. im DIIR Standard Nr. 4 beschrieben.
Zur Skalierung agiler Teams zu einer ganzen agilen Organisation verlängert sich der Planungshorizont auf den höheren Ebenen von zwei bis vier Wochen (agiler Teams) auf mehrere Monate oder gar bis in den Bereich von Jahren.
Auf ART (Einheitenebene) werden dann Etappen von zwei bis drei Monaten geplant. Eine weitere Ebene darüber umfasst mehrere agile Einheiten, die in einem Portfolio Backlog mit einer Organisation von mehreren Einheiten gesteuert werden und strategisch auf ein bis zwei Jahre ausgerichtet sind. Damit wird bei der Skalierung agiler Projekte über die grundlegenden agilen Planungseinheiten – User Story und Tasks – um Features und Epics ergänzt.
Beim Framework SAFe wird die Zusammenarbeit von vielen Entwicklungsteams entsprechend in den Planungsebenen Essential (Einheiten bzw. ART), Large Solution (Lösungsentwicklung bestehend aus mehreren Einheiten bzw. ARTs) und Portfolio umgesetzt.
Die verschiedenen Elemente von SAFe werden in dem Big Picture der SAFe-Organisation dargestellt:
SAFe wird stetig weiterentwickelt und bietet aktuell mit SAFe 5.0 wohl das umfassendste Framework zu agilen Organisationen. Eine große Organisation mit vielen agilen Teams stellt in seiner Komplexität prüferisch eine besondere Herausforderung dar.
