Agilität für IT-Governance, Prüfung & Revision E-Book

Urs Andelfinger

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 466

Beschreibung

IT-Governance, Prüfung & Revision mal agil gedacht!

• Herausforderungen und Notwendigkeit eines Perspektivwechsels für IT-Governance, Prüfung & Revision
• viele Fallbeispiele zeigen die praktische Umsetzbarkeit auf

Agilität und der Einsatz agiler Methoden sind heute nicht mehr nur auf IT-Projekte begrenzt, sondern prägen zunehmend ganze Organisationen. Dieses Buch zeigt auf, wie sich IT-Governance, Prüfung & Revision erfolgreich dem durch Agilität ausgelösten Wandel stellen können und wie sich der Umgang mit den Kernthemen Risiko & Unsicherheit verändert. Zum einen werden Ansätze für eine agile IT-Governance und eine agile Prüfung & Revision beschrieben, indem sie sich agile Werte und Vorgehensweisen zu eigen machen. Zum anderen werden IT-Governance, Prüfung & Revision befähigt, agile Projekte angemessen steuern und wirksam prüfen zu können.

Leseprobe

Prof. Dr. Urs Andelfinger ist seit 2004 Professor an der Hochschule Darmstadt und unterrichtet Wirtschaftsinformatik und Softwaretechnik. Zuvor war er einige Jahre in der Automotive- und in der Finanzindustrie sowie in einer großen Unternehmensberatung tätig. Er ist langjähriger CMMI-Experte, zertifizierter Scrum Master und SAFe-Agilist und beschäftigt sich seit vielen Jahren mit wirksamer IT-Governance auf der Basis von COBIT. Dabei entwickelt er in enger Verzahnung mit der Praxis interdisziplinäre Ansätze für eine bessere Verbindung von IT-Projektmanagement, IT-Governance und Organisationsentwicklung. Er ist regelmäßig Gastdozent an der TU Clausthal und an der Frankfurt School of Finance & Management. Er ist außerdem Mitglied in verschiedenen wissenschaftlichen und branchenspezifischen Organisationen (GI, ACM, FIfF, ISACA).

Dr. Petra Haferkorn1 ist Regierungsdirektorin bei der Bundesanstalt für Finanzdienstleistungsaufsicht und leitet internationale Vor-Ort-Prüfungen der Governance und des Risikomanagements von Kreditinstituten, Versicherungen und anderen Finanzdienstleistern. Seit vier Jahren ist sie Prüfungsleiterin von IT-Prüfungen mit den Schwerpunkten IT-Governance und Informationssicherheitsmanagement. Sie ist als Gastdozentin an der Frankfurt School of Finance & Management in der Executive Education tätig. In ihrer Dissertation entwarf sie eine Systemtheoretische Prüfungstheorie, die es ermöglicht, Prüfungsansätze nach ihrer Sinnhaftigkeit zu beurteilen. Seit 2016 ist der Schwerpunkt ihrer Publikationen das Thema »Risikokommunikation« und wie diese trotz unterschiedlicher Risikoeinschätzungen der Kommunikationspartner gelingen kann.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Urs Andelfinger · Petra Haferkorn

Agilitätfür IT-Governance,Prüfung & Revision

Grundlagen und Umsetzung in die Praxis

Edition ISACA Germany Chapter

Urs Andelfinger

[email protected]

Petra Haferkorn

[email protected]

Lektorat: Christa Preisendanz

Lektoratsassistenz: Anja Weimer

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Frank Heidt

Herstellung: Stefanie Weidner

Illustrationen: Manuel Dorn, www.prognosegmbh.de

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition ISACA Germany Chapter: Vorstand ISACA Germany Chapter – Vizepräsident für Publikationen

Prof. Dr. Matthias Goeken · [email protected]

ISBN:

Print

978-3-86490-861-3

PDF

978-3-96910-563-4

ePub

978-3-96910-564-1

mobi

978-3-96910-565-8

1. Auflage

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Geleitwort

Ziehen sich Gegensätze tatsächlich an? In der Informatik und der Unternehmens-IT, insbesondere in der Systementwicklung, stehen sich seit geraumer Zeit leichtgewichtige und schwergewichtige Modelle und Methoden gegenüber. Scrum, eXtreme Programming (XP) und andere gelten als Vertreter der ersten Gruppe. Sie und weitere agile Vorgehensmodelle, Projektmanagementmethoden etc. sind inzwischen weitestgehend etabliert. Auch gilt »Agilität« über die Systementwicklung hinaus als »Megatrend«: Prozesse, Manager und Organisationen sollen agil sein, um einer dynamischer werdenden Unternehmensumwelt und einem veränderten Alltag im Unternehmen entgegenzutreten.

Davon relativ unbeeindruckt wirken Rahmenwerke und Modelle der IT-Governance und des IT-Managements wie COBIT und ITIL. Sie kommen eher schwergewichtig daher und ihre Entwickler scheinen davon auszugehen, dass auf eine dynamische Unternehmensumwelt und einen veränderten Unternehmensalltag mit Stabilität, Solidität und mittel- bis langfristiger Orientierung zu reagieren ist. Hier und auch an anderen Stellen in vielen Organisationen kann man eine damit einhergehende und sich zum Teil intensivierende Plan- und Kontrollorientierung beobachten.

Wie passen nun aber dies und der Megatrend »Agilität« zusammen? Man kann sie sicherlich als unverbunden und nebeneinander herlaufend wahrnehmen – Agilität in Verbindung mit Selbstorganisation, Flexibilität, Lern- und Innovationsorientierung, also Offenheit für Veränderungen sowie den Versuch, Neues zu integrieren, auf der einen Seite und Stabilität gepaart mit Fremdorganisation, Hierarchie, Beständigkeit, Planorientierung und Kontrolle auf der anderen.

Man kann sie aber auch als These und Antithese begreifen und eine Synthese erhoffen, erwarten oder erarbeiten. Dann sind agile Ansätze und die eher stabilitätsorientierten Frameworks und Modelle keine unverbundenen Gegensätze.

In der Softwareentwicklung haben sich mit der Zeit aus dem Konkurrenzverhältnis spannende konzeptionelle und methodische Diskussionen ergeben. Darüber hinaus wurden und werden – konzeptionell/methodisch und in der praktischen Anwendung sowieso – Elemente der schwer- und leichtgewichtigen Ansätze zu hybriden Ansätzen kombiniert. Diese Synthesen werden in vielen Studien als Fortschritt erkannt.

Vor diesem Hintergrund ist es ein großes Glück, dass an der Verbindung von IT-Governance, Prüfung & Revision mit Agilität geforscht und gearbeitet wird. Ich könnte mir vorstellen, dass auch hier eine Synthese Fortschritt bedeuten kann und wird.

Ich freue mich besonders, dass Prof. Dr. Urs Andelfinger und Dr. Petra Haferkorn sich diesem Thema widmen und sich entschieden haben, ihr Werk in der ISACA-Reihe zu veröffentlichen. Beide sind seit Jahren sowohl in Forschung und Lehre als auch in praktischen Vorhaben aktiv und als Experten bekannt – insbesondere zu den hier betrachteten Themenfeldern agile Methoden, IT-Governance, Prüfung und Revision sowie Projektmanagement und Systemtheorie.

Entsprechend legen sie in ihrem Werk sehr kenntnisreich die theoretischen Grundlagen und können – hierauf aufsetzend – ganz konkrete Ansatzpunkte aufzeigen, wie ein Zusammenspiel von Agilität mit Governance, Prüfung & Revision gestaltet werden kann. So münden die Ausführungen vielfach in praktische Hinweise für die Umsetzung.

Die Auseinandersetzung hat eine beeindruckende Tiefe, die neben der Ebene der Methoden und Systeme u.a. auch kommunikative, organisatorische und kulturelle Aspekte einbezieht und damit die so oft vernachlässigten »weichen Faktoren« integriert. An vielen Stellen sind die Ausführungen durchaus anspruchsvoll – und gerade deshalb mit Gewinn zu lesen!

Ich wünsche dem Buch eine breite Leserschaft und gute Resonanz in der Community. Den Autoren danke ich für die sehr gute Zusammenarbeit – wie auch dem dpunkt.verlag bei der professionellen Unterstützung und Durchführung des Buchprojekts!

Ihnen als Leserinnen und Leser wünsche ich gute Erkenntnisse und dass die Lektüre für Sie ebenfalls ein Gewinn wird und Sie die Frage, inwieweit sich Gegensätze anziehen, für sich besser beantworten können.

Prof. Dr. Matthias GoekenHochschule der Deutschen BundesbankVizepräsident Publikationen im ISACA Germany Chapter

Vorwort

Die UP-Bank ist in den Schlagzeilen: Sie hat über die letzten drei Jahre in der Kundenzufriedenheitsumfrage des Branchenmagazins Innovative Finanzwirtschaft stets den Spitzenplatz mit den meisten kundenorientierten Innovationen belegt. Inzwischen ist sie auch im Benchmarking des wissenschaftlich begleiteten Kostenmonitors des Modern-Banking-Instituts e.V. klar an die Spitze all ihrer Mitbewerber gerückt. Die interne Kostenquote ist auf ein Niveau gesenkt worden, das selbst die nächsten Konkurrenten blass aussehen lässt.

Noch vor fünf Jahren hätte dabei niemand der UP-Bank diesen Turnaround zugetraut. Sie war mehrere Jahre lang sogar als Übernahmekandidat gehandelt worden. Nach einem Vorstandswechsel und einer konsequenten Neuausrichtung der IT-Strategie auf agile Softwareentwicklung für die durchgängig selbst entwickelte neue Kernbankplattform war der Erfolg alles andere als sicher. Als letzten Innovationsschritt hat sie letztes Jahr begonnen, alle ihre Anwendungen auf Cloudbasierten Betrieb bei einem bankexternen Hostingunternehmen umzustellen.

Die Entwicklung sowohl der Technologie als auch des Markterfolgs scheinen den Weichenstellungen seit dem Turnaround recht zu geben. Wären da nicht die allmählich durchsickernden Zweifel, die seit wenigen Wochen die Schlagzeilen wichtiger Branchenagenturen beherrschen: Ausgelöst durch eine eigentlich routinemäßige Überprüfung des internen Kontrollsystems in der Kreditabteilung ist wohl eine interne Diskussion entstanden, inwieweit der Ansatz der UP-Bank für das externe Hosting wirklich sinnvoll ist und welche Regelungen dabei zu beachten sind. Durch das Scheitern von »EU-US Privacy Shield« hat sich nämlich die Rechtsgrundlage für die eigentlich erfolgte Auswahl des Cloud-Providers schon wieder geändert.

Der Aufsichtsrat hat deshalb inzwischen ein Expertengutachten bis Ende dieses Monats beauftragt, bis zu dessen Fertigstellung keine weiteren Funktionalitäten der noch intern betriebenen Anwendungen auf den externen Dienstleister ausgelagert werden dürfen.

Wie verlautet, ist es jedoch unwahrscheinlich, dass angesichts der Komplexität und Neuartigkeit der Thematik bereits eine finale Beurteilung bis Monatsende möglich sein wird.

Es soll auch unklar sein, ob es bei der agilen Entwicklung der neuen Kernbankplattform ein klassisches Pflichtenheft als verbindliche Vertragsgrundlage gab. In das gleiche Horn stößt wohl auch die Interne Revision, die bislang vergeblich einen dokumentierten Change-Control-Prozess einforderte. In dem fraglichen Projekt scheinen nämlich Änderungen fast wie auf Zuruf erfolgt zu sein.

Zwar ist man sich auf Vorstandsebene der UP-Bank durchaus der strategischen und möglicherweise auch juristischen Tragweite dieser Fragestellungen bewusst. Man möchte jedoch das laut Branchenmonitor erreichte Image des Innovationsführers der Branche weiterhin pflegen. Daher ist jetzt eine gewisse Ratlosigkeit auf Vorstandsebene nicht zu verleugnen.

Ist dieses Szenario übertrieben? Ist es Ihnen – vielleicht in Teilen oder auch insgesamt – schon einmal begegnet? Wie ist ein solches Szenario im Sinne einer Governance (noch) zu steuern und zu führen? Wie können Sie im Rahmen eines solchen Szenarios (noch) wirksam prüfen? Wie müssen sich Governance, Prüfung & Revision gegebenenfalls weiterentwickeln, um mit der Veränderungsgeschwindigkeit von Technologien und der Wirtschaft Schritt zu halten? Ist wirklich alles agil in diesem Szenario? Wo tragen vielleicht Mythen rund um Agilität zur Verwirrung bei? Schließen sich Agilität und Governance & Prüfung bei näherer und kompetenter Betrachtung vielleicht gar nicht aus?

Was ist Agilität eigentlich und was unterscheidet sie im Kern von klassischen plan- und Compliance-orientierten Ansätzen? Und wo anfangen? Was sind wichtige Eckpunkte, die beachtet werden sollten? Wo lauern Fallstricke? Was hat es mit dem Zusammenspiel von agilen Methoden und den oft zitierten agilen Werten auf sich? Wie kann ich Agilität schließlich konkret im Rahmen von IT-Governance, Prüfung & Revision umsetzen? Wo liegen vielleicht auch Grenzen?

Aus unserer Sicht sind sowohl das Szenario als auch die sich daraus ergebenden Fragestellungen durchaus realistisch. Ähnliche Situationen sind uns und vielleicht auch Ihnen in vielfältigen Varianten schon begegnet. Zum einen mischt sich die Dynamik einer zunehmend digitalisierten Wirtschaft mit dem legitimen Bestreben, nicht vollständig der Eigendynamik und dem Lauf der Dinge ausgeliefert zu sein. Zum anderen mischen sich Zutreffendes und Mythen, was Agilität ausmacht und wie sie sich zu Governance, Prüfung, Revision und Compliance verhält.

Mit unserem Buch möchten wir Ihnen eine Orientierungshilfe für diese Fragestellungen an die Hand geben. Das Buch vereint eine fokussierte Darstellung der Grundideen von Agilität mit praktischen Umsetzungshilfen für die Themengebiete von IT-Governance, (IT-)Prüfung & Revision. Klassische Ansätze der IT-Governance, Prüfung & Revision sollen dabei nicht komplett ersetzt werden. Die Übergänge werden in der Praxis ohnehin oft fließend sein. Wir möchten Sie vielmehr anregen, Agilität als hilfreiche ergänzende Perspektive für die eigene Arbeit zu verstehen und kompetent nutzen zu können, insbesondere wenn das Arbeitsumfeld durch komplexe Sachverhalte, Dynamik und eine geringe Vorhersagbarkeit geprägt ist.

Wer sich darauf einlässt, kann im Buch viel Nützliches finden. Deshalb möchten wir Sie auch ermutigen, mit den hier vorgestellten Inhalten wie mit Bausteinen zu experimentieren und auch eigene Kombinationen klassischer und agiler Elemente zu erproben. Wir wünschen Ihnen nun viel Spaß beim Ausprobieren und Kombinieren.1 Dabei sind wir auch auf Ihre Erfahrungen neugierig und freuen uns über jedes Feedback und jeden Erfahrungsbericht, ob kritisch, zustimmend oder auch alternative Wege ausprobierend.

Urs Andelfinger, Petra HaferkornDarmstadt und Bonn, November 2021

Danksagung

Dieses Buch verdankt sein Entstehen nicht einem einzelnen Ereignis und auch nicht dem isolierten Können oder Wissen des Autorenteams. Vielmehr ist das Buch über längere Zeit angeregt worden durch eine Vielzahl glücklicher Umstände, persönlicher Begegnungen, beruflicher Projekte und fachwissenschaftlicher Diskussionen. Irgendwann haben diese Facetten sich immer mehr verdichtet zur Idee, einen roten Faden in Form eines Buches durch das Thema der Agilität für die IT-Governance, Prüfung & Revision zu legen. Doch das alleine macht noch kein Buch. Daher möchten wir stellvertretend für viele weitere namentlich ungenannt bleibende Beitragende Dr. Martin Fröhlich danken für seine Anregung, aus unseren einzelnen Gedanken ein konsistentes Buch zu machen. Dr. Wolfgang Johannsen (†) gab entscheidende Anregungen zu den Zusammenhängen zwischen IT-Governance und Entwicklungsprozessen. Armin Nilles danken wir, dass er uns in Austausch gebracht hat, den Zusammenhängen zwischen Agilität und systemischen Ansätzen auf den Grund zu gehen. Prof. Dr. Matthias Goeken danken wir nicht nur für die Bereitschaft, die Aufnahme des Buches in die Edition ISACA Germany Chapter beim dpunkt.verlag zu empfehlen, sondern auch für sein unermüdliches Engagement, das Buchmanuskript im Detail zu prüfen und vom Konzept her zu begleiten. Manuel Dorn hat mit viel inhaltlichem Einfühlungsvermögen und grafischer Professionalität die Illustrationen gestaltet. Dem dpunkt.verlag und insbesondere unserer Lektorin Christa Preisendanz danken wir für die immer herzliche sowie persönlich-engagierte Betreuung beim Wachsen des Buches.

Unseren Familien danken wir für die Geduld und große Nachsicht, mit der sie uns den Rücken freigehalten haben, dass wir an so vielen Wochenenden und zu Urlaubszeiten an diesem Buch arbeiten konnten. Alle verbliebenen Unklarheiten, Fehler und Unzulänglichkeiten gehen alleine zulasten der Autoren.

Inhaltsübersicht

1Einführung

Teil I – Agilität: Grundlagen und Grundmuster zur Umsetzung

2Agilität im Überblick

3Agilität: Was ist (wirklich) anders?

4Agile Prozesse in der IT-Governance, Prüfung & Revision

Teil II – Agile IT-Governance

5Was ist (agile) IT-Governance?

6Kontexteignung bewerten (Readiness-Check)

7Umsetzungsorientierter Zyklus

8Reflexionsorientierter Zyklus

9Zusammenfassung: Agile IT-Governance kompakt

Teil III – Agile Prüfung & Revision

10Was ist eigentlich eine (agile) Prüfung?

11Agile Prüfung & Revision im Überblick

12Spannungsfelder und Kontexteignung bewerten (Readiness-Check)

13Prüfungsvorbereitung

14Agile Prüfung vor Ort

15Konsolidierung der Prüfungsergebnisse

16Retrospektiven und reflektierendes Lernen

17Zusammenfassung: Agile Prüfung & Revision kompakt

Teil IV – Prüfung agiler Projekte

18Prüfung agiler Einzelprojekte

19Prüfung skalierter agiler Projektorganisationen

Anhang

Literatur

Index

Inhalt

1Einführung

1.1Worum es uns geht

1.2Für wen ist dieses Buch?

1.3Warum noch ein Buch zur Agilität?

1.4Inhalt und Struktur

Teil I – Agilität: Grundlagen und Grundmuster zur Umsetzung

2Agilität im Überblick

2.1Ursprünge der Agilität

2.2Agilität in der IT

2.3Agile Methoden für IT-Projekte: Beispiel Scrum

3Agilität: Was ist (wirklich) anders?

3.1Grundhaltung: Neues als Störung oder als Chance?

3.1.1Grundhaltung Kontrollorientierung

3.1.2Grundhaltung Möglichkeitsorientierung

3.1.3Die strukturelle Dynamik zwischen den Grundhaltungen

3.2Lernorientierung: Darf es auch etwas anderes sein?

3.2.1Umsetzungsorientiertes Lernen

3.2.2Reflektierendes Lernen

3.2.3Agilität verbindet umsetzungsorientiertes und reflektierendes Lernen

3.3Risiko: Begriff und seine Funktionen

3.3.1Gefahr versus Risiko

3.3.2Risiko als instrumentelle Kategorie

3.3.3Risiko als soziale Konstruktion

3.3.4Umgang mit Risiko in der Agilität

3.4Wirklichkeit ist immer die Wirklichkeit eines Beobachters

3.4.1Die Rolle des Beobachters bei der Erzeugung von Wirklichkeit

3.4.2Agilität: Wirklichkeitskonstruktion durch Aushandlungsprozesse

3.5Probleme und Rationalitäten: weniger eindeutig als gedacht

3.5.1Von zahmen und bösen Problemen

3.5.2Über die Zweckrationalität hinaus

3.6Widersprüche und Paradoxien sind normal

3.6.1Eindeutigkeit hat es schwer in der Organisationsrealität

3.6.2Agilität: Ambiguitätstoleranz ist hilfreich

3.7Sinn entsteht im Laufe der Zeit

3.7.1Sensemaking nach Weick

3.7.2Emerging Strategies nach Mintzberg

3.8Agiles Vorgehen: Wirkung kleiner Schritte ausprobieren

3.8.1Kompliziert und komplex sind verschiedene Qualitäten

3.8.2Nicht triviale Systeme haben Eigensinn

3.8.3Explorieren statt planbasierter Steuerung

4Agile Prozesse in der IT-Governance, Prüfung & Revision

4.1Anforderungen an agile Prozesse

4.2Das generische Grundmuster

4.2.1Herleitung des generischen Grundmusters

4.2.2Schrittweise gemeinsame Exploration und Wirklichkeitskonstruktion

4.2.3Handeln und Lernen auf zwei Ebenen

4.3Entscheidungsprämissen begrenzen den Handlungsspielraum

4.4Anschlussfähigkeit macht das Grundmuster wirksam

Teil II – Agile IT-Governance

5Was ist (agile) IT-Governance?

5.1Entwicklungsgeschichte der IT-Governance

5.2Begriff und Zielsetzung agiler IT-Governance

5.3Der Perspektivwechsel der agilen IT-Governance

5.4Prozessmodell für eine agile IT-Governance

5.4.1Das generische Grundmuster

5.4.2Das konkrete Prozessmodell

6Kontexteignung bewerten (Readiness-Check)

6.1Bewertungskriterien

6.1.1Eignung der Aufgabenstellung

6.1.2Emergente Sinnfindung und Risikoorientierung

6.1.3Anschlussfähigkeit(en) und Elastizitätsbereiche

6.1.4Ambiguitätstoleranz und Good-enough-Governance

6.1.5Nichtlinearitäten und Systeme mit Eigendynamik

6.2Selbstbewertung der Kriterien

7Umsetzungsorientierter Zyklus

7.1Vorbereitung – startklar machen

7.1.1Inhaltliche Klärung: vom Möglichkeitsraum zum risikobewussten Erkundungsraum

7.1.2Anforderungen an Anschlussfähigkeiten ermitteln

7.1.3Kompetenzen prüfen und Team bilden

7.1.4Rollen, Verantwortlichkeiten und Stakeholder klären

7.1.5Prozesse und Kommunikationsstrukturen vorbereiten

7.1.6Geschützte Räume etablieren

7.1.7Ressourcenausstattung klären

7.2Auf das Agilitätsdilemma vorbereiten

7.2.1Was ist das Agilitätsdilemma?

7.2.2Typische Bruchstellen

7.3Exploration und umsetzungsorientiertes Lernen

7.3.1Exploration

7.3.2Umsetzungsorientiertes Lernen und Validierung der (Risiko-)Erwartungen

8Reflexionsorientierter Zyklus

8.1Verankerung

8.1.1Erzählungen und Heldenreisen

8.1.2Mentale und sprachliche Bilder

8.1.3Parallelorganisation(en)

8.1.4Vernetzung fördern

8.2Mit dem Agilitätsdilemma umgehen

8.2.1Innovationsrisikopoker

8.2.2Denkanstöße und Aktivitäten

8.3Reflektierendes Lernen und risikoorientierte Justierung der IT-Governance

9Zusammenfassung: Agile IT-Governance kompakt

Teil III – Agile Prüfung & Revision

10Was ist eigentlich eine (agile) Prüfung?

10.1Sisyphos und Unsichtbarkeit der Prüfung

10.2Kernpunkte einer agilen Prüfung

11Agile Prüfung & Revision im Überblick

11.1Der Perspektivwechsel der agilen Prüfung & Revision

11.1.1Inkrementelle Exploration und Lernen

11.1.2Kontinuierliche Risikokommunikation

11.2Prozessmodell für agile Prüfung & Revision

11.2.1Das generische Grundmuster als Vorbild

11.2.2Das konkrete Prozessmodell

12Spannungsfelder und Kontexteignung bewerten (Readiness-Check)

12.1Strukturelle Spannungsfelder

12.1.1Objektivität und Perspektivität

12.1.2Unabhängigkeit und Abhängigkeit

12.1.3Unabhängigkeit und Objektivität

12.2Spannungsfelder zum Prüfungsergebnis

12.2.1Zurückschauende Kontrolle und vorausschauende Prüfung

12.2.2Bestätigungshoffnung und Veränderungsauftrag

12.2.3Final dokumentierte und kontinuierliche mündliche Berichterstattung

12.2.4Denken in Ambiguitäten

12.2.5Selbstbewertung der Spannungsfelder

12.3Spannungsfelder zum Prüfungsprozess

12.3.1Prüfungszeit, Prüfungsressourcen und Prüfungsqualität

12.3.2Additives versus vernetztes Zusammenfügen der einzelnen Ergebnisse

12.3.3Steuerung und Unsteuerbarkeit der Prüfung

12.3.4Selbstbewertung der Spannungsfelder

13Prüfungsvorbereitung

13.1Inhaltliche Vorbereitung

13.1.1Vom Prüfungsauftrag zum Audit-Board

13.1.2Vom Audit-Board zum Sprint-Board

13.2Das Prüferteam

14Agile Prüfung vor Ort

14.1Bearbeitung des Sprint-Boards

14.2Regelmäßige Reflexion des Fortschritts

14.3Nützliche Prüfungstechniken

14.3.1Trichterförmige Befragung

14.3.2Verkettete Gespräche

14.3.3Störungen aufdecken und Ebenenwechsel nutzen

15Konsolidierung der Prüfungsergebnisse

15.1Wichtige Aktivitäten

15.1.1Integration der Beobachtungen zu einem sinnhaften (statt: wahren) Gesamtbild

15.1.2Anschlussfähigkeit des Prüfungsergebnisses

16Retrospektiven und reflektierendes Lernen

16.1Wichtige Aktivitäten

16.1.1Grundform für Retrospektiven

16.1.2Retrospektiven auf die Inhalte

16.1.3Retrospektiven auf die Arbeitsweisen

16.2Hilfreiche Techniken zur Unterstützung von Retrospektiven

16.2.1Hypothetische Fragen

16.2.2Gewaltfreie Kommunikation

16.2.3Reflexionspoker

17Zusammenfassung: Agile Prüfung & Revision kompakt

Teil IV – Prüfung agiler Projekte

18Prüfung agiler Einzelprojekte

18.1Prüfung der agilen Methodik

18.2Prüfung der gelebten Agilität

18.3Gesetzliche Anforderungen in agilen Projekten

18.4Mythen rund um die Prüfung agiler Projekte

19Prüfung skalierter agiler Projektorganisationen

19.1Von agilen Einzelteams zu skalierten agilen Projektorganisationen

19.2Denkanstöße zur Prüfung

19.2.1Produktarchitektur und Organisationsstrukturen

19.2.2Nutzung von Metriken und KPIs auf Gesamtproduktebene

19.2.3Weitere Denkanstöße

Anhang

Literatur

Index

1Einführung

Ein Buch zur Agilität für IT-Governance, Prüfung & Revision muss sich mit Widersprüchlichkeiten, Paradoxien und Spannungsfeldern beschäftigen:

Agilität steht oft als Metapher und Schlagwort für situative Flexibilität, Veränderlichkeit und rasche Reaktionsfähigkeit, notfalls auch anders als ursprünglich geplant. IT-Governance hingegen möchte den Einsatz der IT in Organisationen in einem magischen Dreieck zwischen Wirtschaftlichkeit, Wertbeitrag und Risikobetrachtungen geordnet führen und (planmäßig) kontrolliert weiterentwickeln. Prüfung & Revision beschäftigen sich mit der Ordnungsmäßigkeit von Geschäftsaktivitäten und benötigen dazu mehr oder weniger stabile Bezugspunkte.

Dieses Buch handelt also im Kern von Widersprüchen, z.B. zwischen Stabilität und Veränderung sowie zwischen vorausschauender Planung und Ergebnisoffenheit. Diese Spannungsfelder stellen sich zunehmend auch für die Gebiete der IT-Governance, Prüfung & Revision, beispielsweise: Wie kann IT-Governance ergebnisoffener und somit agiler werden, ohne dass daraus Beliebigkeit entsteht?

Die Antwort des Buches ist nicht, diese Widersprüche und Spannungsfelder durch einen harmonischen Ansatz zu beseitigen, der bestehende Widersprüche einfach ignoriert oder zudeckt. Stattdessen werden Wege aufgezeigt, wie Organisationen konstruktiv mit diesen Spannungsfeldern umgehen und sie in einer angemessenen Balance halten können. Das ist der Kern von Agilität für IT-Governance, Prüfung & Revision.1

Dieses Kapitel beginnt mit einem Überblick, um welche grundlegenden Widersprüche es hauptsächlich im Buch gehen wird, und wir gehen darauf ein, für wen das Buch besonders geeignet ist. Außerdem geht es der Frage nach, warum es noch ein Buch zur Agilität braucht, wo es doch schon so viele Veröffentlichungen dazu gibt. Zum Abschluss des Kapitels werden Aufbau und zentrale Inhalte des Buches skizziert.

1.1Worum es uns geht

Agilität und der Einsatz agiler Methoden sind heute nicht mehr nur auf IT-Projekte begrenzt, sondern prägen zunehmend ganze Organisationen. Man erwartet von Agilität beispielsweise verbesserte Reaktionsfähigkeiten auf eine zunehmende Marktdynamik und eine stärkere Kundenorientierung. Agilität ist dabei weniger eine einzelne konkrete Methode, sondern eine eigenständige Denk- und Sichtweise, die verspricht, Stabilität und Flexibilität einer Organisation wirksam zu verbinden.

Oft wird die Flexibilität und Dynamik, die man mit Agilität in einer Organisation erreichen möchte, jedoch als besondere Herausforderung für die IT-Governance sowie für die Prüfung & Revision gesehen, die eher auf Stabilität, Kontinuität und Gewissheit ausgerichtet sind. Dabei wird leicht das Verbindende zwischen diesen Disziplinen und der Agilität übersehen, nämlich ein bewusster Umgang mit Risiko und Unsicherheit:

IT-Governance (beispielsweise auf Basis von COBIT (Control Objectives for Information and Related Technology)) ist ein von der Geschäftsstrategie her getriebener Führungsansatz für die Entwicklung und den Einsatz von IT in der Organisation, der durch planbasierte, aber prozesshaft auszugestaltende Vorgehensweisen prospektiv Risiken und Unsicherheit abmildern möchte. Pläne und quantitative Zielvorgaben haben einen hohen normativen Stellenwert, Abweichungen von den Plänen und zugehörigen Kenn- und Erfolgsgrößen zeigen Risiken an, die behandelt werden müssen.

(IT-)Prüfung & Revision möchten mithilfe systematisch aus historischer Erfahrung gewonnenen Prüfkriterien vorhandene Risiken aufdecken und (oft rückblickende) Prüfungsurteile über die Ordnungsmäßigkeit der abgeschlossenen Geschäftsvorfälle liefern. Erfahrungsbasierte Prüfungsstandards und Checklisten werden als normative Grundlage herangezogen, Abweichungen davon zeigen Risiken an, die behandelt werden müssen.

Agilität möchte in kleinen, aber eng aufeinanderfolgenden Explorationsschritten möglichst rasch konkrete Arbeitsfortschritte und Erkenntnisse in einem Themengebiet erreichen, das typischerweise noch nicht ganz verstanden ist. Agilität arbeitet bewusst mit überschaubaren Zielsetzungen und hält die inhaltlichen Details, so lange es geht, offen. Falls Risiken und Schäden eintreten – so die Annahme –, sind sie eher klein, verkraftbar und eine rechtzeitige Reaktion ist möglich. In der Agilität kann man deshalb als Leitmotiv formulieren: »Do fast – fail fast – learn fast.« An die Stelle eines normativen Ansatzes mit klaren Vorgaben als SOLL-Bezugspunkt tritt eine situativ und laufend fortgeschriebene Bewertung, ob bzw. inwieweit eine Abweichung ein Risiko oder eine neue Erkenntnis darstellt. Abweichungen von den ursprünglichen Vorgaben, Zielsetzungen oder Erwartungen werden als Gelegenheiten zum Lernen verstanden. Pläne, Prüfungsstandards und standardisierte Risikoklassifikationen sind zwar als Orientierungshilfe auch in der Agilität nützlich, jedoch ist ihr Stellenwert nicht so zentral wie in klassischen Ansätzen der IT-Governance, Prüfung & Revision.

Einig sind sich also Agilität, (klassische) IT-Governance und (normative) Prüfung & Revision in ihrem Fokus auf einen bewussten Umgang mit dem Risiko und dessen Begrenzung. Der Weg ist jedoch unterschiedlich und das hat Konsequenzen, wie das Beispiel der UP-Bank aus dem Vorwort zeigt. Klassische IT-Governance und normative Prüfung & Revision stoßen nämlich immer öfter auf hartnäckige Fragestellungen, beispielsweise:

Wie soll man aufgrund der vielfältigen neuen Technologien, für deren Zusammenwirken es noch keine hinreichenden Erfahrungswerte gibt, längerfristig valide Planungen und IT-Strategien erstellen?

Wie wäre es stattdessen, rasch ein überschaubares, aber funktionsfähiges Projektergebnis zu erhalten, mit dem man schon mal erste Erfahrungswerte bekommt?

Wie soll man die sich im Zusammenspiel mit den neuen Technologien herausbildenden neuen Organisations- und Arbeitsprozesse valide auf Basis von vergangenheitsbasierten Checklisten und Risikoeinschätzungen prüfen?

Wie gehen wir mit dem Problem um, dass bei der Veränderungsdynamik der Organisation und der langen Erstellungsdauer von Prüfungsberichten der Bericht zum Zeitpunkt seiner finalen Veröffentlichung bereits wieder veraltet sein dürfte?

Wie wäre es stattdessen, rasch ein überschaubares, aber funktionsfähiges Projektergebnis zu erhalten, mit dem wir ganz konkret die offenen Fragen beantworten könnten, statt noch ein Jahr bis zum kompletten IT-Produkt zu warten, das dann vielleicht nicht freigegeben wird?

Um die Beantwortung von solchen Fragen, wie hier exemplarisch formuliert, geht es in diesem Buch. Das Buch versucht, die bewährte Risikoorientierung von (klassischer) IT-Governance und (normativer) Prüfung & Revision mit dem Ansatz der Agilität zu verbinden. Dabei wird insbesondere einer Vorgehensweise in kleinen Schritten und der Kontinuität und Qualität der Kommunikationsprozesse eine größere Bedeutung zukommen als in stärker plangetriebenen Ansätzen von IT-Governance und Prüfung & Revision.

1.2Für wen ist dieses Buch?

Das Buch richtet sich an erfahrene Führungskräfte, Praktiker und anwendungsorientierte Wissenschaftler aus dem gesamten Berufsspektrum der IT-Governance, Prüfung & Revision. Während wir das Buch geschrieben haben, hatten wir verschiedene Zielgruppen besonders im Blick:

Leserinnen und Leser im gesamten Spektrum von IT-Governance, Prüfung & Revision, die eine fundierte und kompakte Orientierungshilfe suchen zu Grundkonzepten der Agilität und/oder konkrete Perspektiven und Entscheidungshilfen zur Umsetzung in ihren Berufsfeldern benötigen. Sie können sich an aktuellen Diskussionen kompetent beteiligen und Entscheidungen in diesem Themenfeld informiert treffen.

IT-Governance-Verantwortliche, Prüfer und Revisoren, die zwar von Agilität gehört haben, aber noch nicht praktisch damit vertraut sind, können lernen, was mit Agilität im Kern gemeint ist und wie sich ihre Aufgabengebiete dadurch verändern werden. Sie können dann besser entscheiden, ob und wo sie Agilität nutzbringend einsetzen können.

IT-Governance-Verantwortliche, Prüfer und Revisoren, die bereits erste Umsetzungsversuche der Agilität in ihren Aufgabengebieten unternommen haben, können lernen, worauf für eine erfolgreiche Umsetzung besonders zu achten ist. Sie erhalten vielfältige Hinweise zu den Grundkonzepten, die hinter der methodischen Ebene der Agilität »versteckt« sind, die aber oft den kleinen Unterschied für eine erfolgreiche Umsetzung ausmachen.

IT-Governance-Verantwortliche, Prüfer und Revisoren, für die IT-Steuerung und eine Prüfung mehr sind als die rational-zweckorientierte Überprüfung der Einhaltung von Prüfstandards und die formale Einhaltung von Plänen. Sie erhalten vielfältige Hinweise, welche Aspekte für Wirksamkeit von Prüfungen und IT-Governance-Vorhaben noch hilfreich sind.

Prüfer und Revisoren, Mitarbeiterinnen und Mitarbeiter, die checklistenmüde sind oder nicht mehr an einfache Rezepte und Methoden glauben oder die auch enttäuscht sind von der geringen Wirksamkeit normativer Prüfungen. Sie alle werden angeregt, neu über ihre Tätigkeit nachzudenken, und erhalten vielfältige Anregungen, ihr Handlungsrepertoire für die IT-Steuerung und für die IT-Prüfung zu erweitern.

Prüfer und Revisoren, die das Energieniveau und das Dynamik-Moment aus den Erkenntnissen einer Prüfung aufrechterhalten möchten. Sie erhalten vielfältig anwendbare Umsetzungshinweise.

Die ISACA und weitere Berufsverbände können aus dem Buch Anregungen für die Weiterentwicklung der IT-Governance und der Prüfung & Revision

unter Bedingungen der Agilität

ableiten. Die Weiterentwicklung umfasst dabei sowohl Inhalte der einschlägigen Methoden, Standards und Referenzmodelle wie auch die Weiterentwicklung der entsprechenden Berufsbilder.

1.3Warum noch ein Buch zur Agilität?

Agilität ist in den letzten Jahren zu einem vielgebrauchten Schlagwort geworden. Weit über den ursprünglichen Fokus auf Softwareprojekte hinaus hat sich inzwischen eine große Vielfalt von agilen Methoden entwickelt. Das Methodenspektrum reicht von Scrum für die Teamebene bis zu Skalierungsansätzen der Agilität für ganze Organisationen wie z.B. SAFe oder LeSS.

Auch uns als Autorenteam begleitet Agilität schon seit vielen Jahren, sei es im Unterricht an Hochschulen und in der Weiterbildung oder in der Praxis der IT-Governance, der (IT-)Prüfung & Revision und der Organisationsberatung. Die Vielzahl von Führungsratgebern, methodischen Büchern, Erfahrungsberichten und einschlägigen, oft sehr gut gemachten Blogs rund um die Agilität zeugt schließlich davon, dass Agilität irgendwie »angekommen« sein muss. Warum schreiben wir also noch ein Buch dazu?

Nun, die Antwort darauf ist eigentlich ganz einfach: Wenn wir in unserer Berufspraxis, sei es an der Hochschule, bei Prüfungen oder in der Beratung, nach den Zusammenhängen von Agilität, IT-Governance, Prüfung & Revision gefragt werden, gibt es kaum systematische Literatur dazu, die diese Themen kompakt und umsetzungsorientiert zusammenbringt. Zwar gibt es verschiedene erste Ansätze und Initiativen dazu, wie z.B. die GAAN-Initiative [GAAN 2021] und einen DIIR-Prüfungsstandard [DIIR 2019] mit einem Exkurs zur Prüfung agiler Projekte, aber nach unserem Eindruck gibt es hier eine Lücke, die wir mit unserem Buch füllen möchten.

Diese Lücke ist übrigens umso erstaunlicher, weil es nämlich immer öfter vorkommt, dass sich Informationstechnologien und IT-gestützte Produkte schneller weiterentwickeln als in den strategischen IT-Planungen der IT-Governance vorgesehen. Und langjährig bewährte Prüfungsvorgehensweisen und klassische IT-Sicherheitsbetrachtungen sind nicht mehr ohne Weiteres anwendbar auf neuartige Prüfungsthemen und neue Risikokonstellationen. Insbesondere die Berufsgruppen der ISACA, d.h. insbesondere IT-Revisoren, Informationssicherheitsmanager und IT-Governance-Experten, spüren die damit einhergehende Veränderungsdynamik besonders stark. Um hier nicht vollkommen dem Lauf der Dinge ausgesetzt zu sein, könnten Ideen und methodische Elemente der Agilität helfen. Daher möchten wir die Frage, warum noch ein Buch zur Agilität, wie folgt thesenartig beantworten:

Weil es einfach fachlich an der Zeit ist und es noch kaum systematische Veröffentlichungen zur Agilität für die IT-Governance, Prüfung & Revision gibt.

Weil es viele Mythen über Agilität insbesondere im Bereich der IT-Governance, Prüfung & Revision gibt, die unzutreffend sind.

Weil es oft falsche Erwartungen an und viele gescheiterte Umsetzungen von Agilität gibt, die nicht sein müssten.

Weil die erfolgreiche Umsetzung vielfältige Herausforderungen bei der Umsetzung mit sich bringt, die über die methodische Ebene hinausreichen.

Da es bereits schon sehr viele gute Veröffentlichungen zur Agilität (im Allgemeinen und zu agilen Methoden) gibt, wollen wir in unserem Buch übrigens nichts wiederholen, was an anderer Stelle bereits und oft auch sehr zutreffend und schön dargestellt wurde. Daher verweisen wir an geeigneten Stellen auf einschlägige Literatur und fokussieren uns in diesem Buch stringent auf eine Darstellung der Agilität für die Bereiche der IT-Governance, Prüfung & Revision.

1.4Inhalt und Struktur

Wie oben bereits erläutert, streben IT-Governance, Prüfung & Revision nach Verlässlichkeit und Risikobegrenzung, indem sie sich bewusst mit Risiko und Unsicherheit auseinandersetzen. Beides wird vor allem durch die Einhaltung von Vorgaben, also insbesondere von Plänen und Prüfkriterien, hergestellt. Im Kern sind eine planbasierte Vorgehensweise in der IT-Governance und eine normative und an feststehenden Kriterien ausgerichtete Prüfung & Revision vor allem in stabilen Unternehmensumwelten durchaus sinnvoll und gut anwendbar.

Auch Agilität strebt nach Verlässlichkeit und Risikobegrenzung im Handeln, geht jedoch vom Ansatz her von neuartigen Themenstellungen bzw. von einer Veränderlichkeit der Umwelt aus. Wenn sich der Wissensstand oder Umweltfaktoren ändern, können auch Entscheidungen und Beurteilungen anders ausfallen als ursprünglich geplant. Zielvorgaben und Prüfkriterien werden daher in der Agilität anfänglich eher grob gehalten und sukzessive angepasst und präzisiert, je näher sie zeitlich oder sachlich liegen. Aus Sicht der Agilität wird dadurch der zunehmenden Komplexität und Veränderungsdynamik der Unternehmensumwelt besser Rechnung getragen und letztlich Verlässlichkeit und Risikobegrenzung besser und rascher gewährleistet als durch eine verbindlich beschlossene und eher langfristige Planung oder durch letztlich aus der Vergangenheit abgeleitete Prüfkriterien und Risikolisten.

Damit die größere inhaltliche Veränderlichkeit und längerfristige Unbestimmtheit der Planung nun aber nicht zu Beliebigkeit führen, gehört zur Agilität auch die Verpflichtung, kontinuierlich und in sehr überschaubaren Zeitabständen immer sehr konkrete Arbeitsresultate zu liefern. Das wirkt nach unserer Erfahrung sehr disziplinierend und unterstützt wirksam den Lernprozess der Beteiligten.

Zusammenfassend stellt die zunehmende Komplexität und Dynamik der Unternehmensumwelt also eine große Herausforderung dar für eine eher langfristig orientierte IT-Governance und für eine eher normativ arbeitende Prüfung & Revision, und zwar auf zwei Ebenen:

Auf der

methodischen

Ebene äußert sich die Herausforderung darin, dass sich Technologien und IT-gestützte Produkte typischerweise schneller weiterentwickeln, als der Zyklus der strategischen IT-Planungen vorsieht. Auch Einsatzszenarien und Risiken entwickeln sich oft schneller, als von den Prüfungsstandards erfasst.

Auf der dahinterstehenden Ebene der

Denkweise und Haltung

äußert sich die Herausforderung darin, dass sowohl IT-Governance als auch Prüfung & Revision zwar durchaus intuitiv merken, dass komplexe Themenstellungen, begrenzte längerfristige Planbarkeit und neuartige Risikokonstellationen eher die Regel als die Ausnahme sind. Oft ist es aber schwierig, den Mut aufzubringen, in einem Umfeld, das an längerfristige Planungen gewohnt, normativ geprägt und auf Compliance bedacht ist, die Konsequenz zu ziehen, zukünftig explorierend und in kleinen Schritten vorzugehen. Lieber geht man deshalb aufgrund der Erwartungen des Umfelds für sich selbst kein Risiko ein und bewertet beispielsweise eine Abweichung gegenüber der ursprünglichen Projektplanung oder gegenüber den allgemein anerkannten Prüfkriterien als Non-Compliance. Agilität würde darin eher eine Gelegenheit zum Lernen sehen, bei der auch die Projektplanung, die Projektzielsetzung und die Prüfkriterien selbst zur Diskussion und Überprüfung stehen. Dass aus einer klassischen plan- und Compliance-orientierten Denkweise und Haltung leicht ein Risiko eigener Art entstehen kann, sei abschließend nur am Rande bemerkt: das Risiko von irrelevanten Projektergebnissen und Prüfungsergebnissen, die in der Folge nie verwendet werden. (Immerhin hat man sich dabei an die geltenden Erwartungen des Umfelds gehalten.)

Unser Buch setzt an diesen zwei Ebenen an und gibt Antworten auf folgende Leitfragen: Was sind die besonderen Denkweisen und Haltungen der Agilität und was unterscheidet sie genau von plan- und Compliance-orientierten Ansätzen? Welche Ansätze gibt es für die Umsetzung von Agilität in der IT-Governance, Prüfung & Revision? Das Buch ist zu diesem Zweck (nach dieser Einführung) in folgende Teile gegliedert:

Teil I

Agilität: Grundlagen und Grundmuster zur Umsetzung

beschreibt nach einer Einführung in die Ursprünge der Agilität wesentliche Unterschiede von plan- und Compliance-orientierten Ansätzen zu agilen Ansätzen. Die zentralen Unterschiede werden in Form von Facetten des agilen Perspektivwechsels konkret beschrieben und prägnant zusammengefasst. Hieraus wird abschließend ein

generisches Grundmuster für agile Prozesse

abgeleitet und überblicksartig beschrieben.

Teil I

möchte Leserinnen und Leser aus dem gesamten Themenspektrum der IT-Governance, Prüfung & Revision von der Denkweise her befähigen, Agilität als hilfreiche ergänzende Perspektive für die eigene Arbeit zu verstehen, insbesondere wenn das Arbeitsumfeld durch Komplexität, Dynamik und eine abnehmende Vorhersagbarkeit geprägt ist.

Teil I

ist aber auch lesenswert, wenn Sie eine kompakte Einführung in das Themengebiet der Agilität suchen und verstehen möchten, worin die wesentlichen Unterschiede zu plan- und Compliance-orientierten Vorgehensweisen bestehen.

Teil II

Agile IT-Governance

entwickelt aus dem in

Teil I

vorgestellten generischen Grundmuster einen durchgängigen Methodenrahmen für eine agile IT-Governance und gibt konkrete Umsetzungshinweise. Es wird zu Beginn auch darauf eingegangen, dass agile IT-Governance durchaus als Fortsetzung einer IT-Governance im Sinne von COBIT für unbekannte oder sich dynamisch entwickelnde Umgebungen verstanden werden kann. Agile IT-Governance ist damit komplementär zu klassischen Ansätzen der IT-Governance und eignet sich vor allem zur Exploration neuer Zusammenhänge. Daher berührt agile IT-Governance auch an einigen Stellen Themenbereiche, die im Innovationsund Veränderungsmanagement verankert sind. Agile IT-Governance eignet sich deshalb auch, Organisationen in Richtung Ambidextrie und bimodaler IT weiterzuentwickeln. Ein besonderes Augenmerk wird hier auf den Übergang von der Explorationsphase hin zur dauerhaften Verankerung von IT-Governance-Vorhaben gelegt. Dieser Übergang ist für viele Organisationen eine kritische Schwelle, an der innovative Vorhaben und der Transformationsprozess zu mehr Ambidextrie oft stecken bleiben.

Teil III

Agile Prüfung & Revision

entwickelt aus dem in

Teil I

vorgestellten generischen Grundmuster einen durchgängigen Methodenrahmen für eine agile Prüfung & Revision und gibt konkrete Umsetzungshinweise. Eine agile Prüfung & Revision plant den Prüfungsprozess nicht von vorne bis hinten detailliert durch, sondern nutzt das Grundmuster zur sukzessiven Exploration des Prüfungsgebiets. Um die Komplexität der zu prüfenden Sachverhalte in all ihrer Widersprüchlichkeit und Vieldeutigkeit erfassen zu können, ist eine gewisse Zusammenarbeit mit der geprüften Organisation unerlässlich. Dies gilt umso mehr, wenn Mängel der Organisation nachhaltig beseitigt werden sollen: Ohne die Erfahrungen und Kenntnisse der Mitarbeiter der Organisation und ohne ihre Motivation, den neu eingeschlagenen Kurs dauerhaft beizubehalten, können Prüfer keine tiefgreifenden Organisationsentwicklungsprozesse anstoßen. Agile Prüfung & Revision legt deshalb großen Wert auf die stringente Organisation eines

gemeinsamen

Lern- und Entscheidungsprozesses von Prüferteam und geprüftem Organisationsbereich während der Prüfung. Um dabei eine angemessene Objektivität und Unabhängigkeit des Prüferteams zu wahren, werden dem Prüferteam für die Durchführung der agilen Prüfung & Revision verschiedene Hilfestellungen zu einer Standortbestimmung an die Hand gegeben. Als weitere Leitplanken für einen explorativen Prüfungsprozess zeigen wir auf, wie Risiken identifiziert und bewertet werden können, zudem werden relevante Gesprächstechniken präsentiert und beschrieben, wie schließlich eine gemeinsame Konsolidierung der Prüfungsergebnisse mit dem geprüften Bereich erreicht werden kann. Zum Abschluss des Kapitels werden Perspektiven für eine veränderte Rolle von Prüferinnen generell vorgestellt und diskutiert.

Teil IV Prüfung agiler Projekte

ist etwas anders strukturiert als die

Teile II

und

III

und im Verhältnis zu den anderen Teilen kürzer. Ausgehend vom generischen Grundmuster für agile Prozesse werden zunächst konkrete Anregungen gegeben, wie die Prüfung der methodischen Aspekte in einem agilen (Einzel-) Projekt erfolgen kann. Dabei werden auch vertiefende Hinweise auf die Prüfung von Projekten nach Scrum gegeben. Danach wird dargelegt, wie eine Einschätzung der gelebten Agilität erfolgen kann, also inwieweit die Grundideen und Werte der Agilität umgesetzt sind. Für diese Prüfung sind die in

Teil I

beschriebenen Facetten des agilen Perspektivwechsels besonders hilfreich. Hierauf aufbauend wird dann auf die Prüfung der beiden Ebenen (Methodik und dahinterstehende agile Grundhaltung) für eine skalierte agile Projektorganisation eingegangen. Auf der Grundlage von

Teil IV

können leicht eigene Ansätze entwickelt werden zur Prüfung konkreter agiler Einzelprojekte und skalierter agiler Projektorganisationen. Dabei sollte neben der Prüfung der methodischen Elemente immer auch eine Einschätzung der agilen Grundhaltung erfolgen.

Auch wenn wir in den Teilen II – IVmethodische Ansätze und Vorgehensweisen beschreiben, möchten wir Sie ganz im Sinne der Agilität ermutigen, diese angepasst an Ihre jeweilige Situation anzuwenden und nach Bedarf auch zu variieren oder mit anderen Vorgehensweisen zu kombinieren. Und wenn Sie bereits über ein Grundverständnis zur Agilität verfügen, können Sie auch gerne direkt mit Inhalten aus den Teilen II – IV beginnen und je nachdem später zu Teil I zurückkehren.

Teil I

Agilität: Grundlagen und Grundmuster zur Umsetzung

Ja, mach nur einen Plan

sei nur ein großes Licht

und mach dann noch ’nen zweiten Plan

gehn tun sie beide nicht.

Bertolt Brecht, Dreigroschenoper

Agilität bedeutet einen auf schrittweises Lernen und adaptive Risikobewältigung zielenden Denk- und Methodenansatz. Im Projektmanagement und bei der Softwareentwicklung hat sich Agilität bereits seit vielen Jahren bewährt und ist durch Methoden wie beispielsweise Scrum fest etabliert. Insbesondere wenn es um die Entwicklung von Software auf Basis neuer Technologien und für neue Anwendungsfelder geht, für die nicht von vornherein schon bewährte Lösungen existieren, bieten sich agile Ansätze an, die in kleineren, rasch aufeinanderfolgenden Schritten statt längerfristig durchgeplant vorgehen.

Auch in der IT-Governance, Prüfung & Revision geht es zunehmend um Fragestellungen, Prüfungszusammenhänge und IT-Einsatzszenarien, die nicht mehr alleine mit den bisherigen Erfahrungen, Prüfungskriterien und Risikokategorien bearbeitet und beurteilt werden können. Agilität gewinnt darum auch für IT-Governance, Prüfung & Revision zunehmend an Bedeutung. Statt einer längerfristig im Detail und mit klaren Ergebnissen durchgeplanten IT-Governance und statt der Verwendung im Vorhinein weitgehend feststehender detaillierter Prüfkriterien und Risikobetrachtungen rückt Agilität auch in der IT-Governance, Prüfung & Revision das gemeinsame Erkunden von unbekannten Zusammenhängen, das Experimentieren, die dynamische Risikoidentifikation und -bewertung und das daraus resultierende Lernen und das situative Sicheinlassen auf neue Erkenntnisse in den Mittelpunkt.

Agilität bedeutet somit einen klaren Perspektivwechsel für die IT-Governance, Prüfung & Revision, eine ohnehin stets ungewisse Zukunft nicht mehr langfristig im Detail planmäßig vorwegzunehmen oder das Neue vorrangig an Maßstäben der Vergangenheit zu messen und zu bewerten.

Agilität lässt sich jedoch auch nicht einfach treiben oder wartet die Entwicklung ab. Sie trifft durchaus vorausschauend organisatorische und in Strukturen sowie Prozessen verankerte Vorkehrungen, um auf verschiedene Entwicklungspfade der Zukunft kompetent und risikoorientiert reagieren zu können. Allerdings werden detaillierte inhaltliche Festlegungen immer nur für einen kürzeren Zeithorizont vorgenommen, um die Reaktionsfähigkeit für unterschiedliche Entwicklungen offen zu halten. Die jeweils konkret eintretende Entwicklung wird – nach Maßgabe der generellen Zielrichtung des Projekts oder der Prüfung – in einem laufenden Lern- und Entscheidungsprozess systematisch und strukturiert so bearbeitet, dass über die jeweils nächsten Schritte immer auch im Lichte der neuen Bedingungen, Risikoeinschätzungen und Erkenntnisse entschieden wird.

Zwei wesentliche Kernfähigkeiten dabei sind die vorausschauende Vorwegnahme möglicher zukünftiger Entwicklungen (Antizipationsfähigkeit) und der Aufbau von Anpassungsfähigkeiten an veränderte Kontexte, insbesondere falls unerwartete Entwicklungen eintreten (Resilienz).

Agilität eignet sich vor allem für den Umgang mit noch nicht klar umrissenen oder noch nicht (ganz) verstandenen Themenfeldern und kann dazu beitragen, eine dynamische Balance zwischen Stabilität und Lernen zu erreichen. Richtig umgesetzt ist Agilität deshalb ein guter Ansatz, die Handlungsmöglichkeiten von IT-Governance, Prüfung & Revision in Richtung einer zusätzlichen Fähigkeit zur Ambidextrie zu erweitern, bei der situativ erfolgreiches (statt: primär normativ korrektes) Handeln im Mittelpunkt steht. Je nach Kontextbedingungen kann dann stärker der Effizienzgesichtspunkt (Exploitation mithilfe klassischer Ansätze) oder der Lerngesichtspunkt (Exploration mithilfe agiler Ansätze) zum Tragen kommen. Klassische Ansätze der IT-Governance, Prüfung & Revision sollen jedoch nicht komplett ersetzt werden, die Übergänge werden in der Praxis vielmehr fließend sein.

Teil I setzt die hier begonnene Einstimmung und Einführung in die Agilität als komplementäre Denkweise zu klassischen plan- und Compliance-orientierten Ansätzen der IT-Governance, Prüfung & Revision fort. Das Ziel ist, IT-Governance, Prüfung & Revision von der Denkweise her zu befähigen, Agilität als hilfreiche ergänzende Perspektive für die eigene Arbeit zu verstehen, insbesondere wenn das Arbeitsumfeld durch Komplexität, Dynamik und eine abnehmende Vorhersagbarkeit geprägt ist. Er ist wie folgt aufgebaut:

Kapitel 2 (Agilität im Überblick) führt in die Ursprünge der Agilität als Denkhaltung und Methode ein und beschreibt typische Missverständnisse und Mythen, denen sich Agilität in der Praxis oft gegenübersieht. Dabei wird auch das Phänomen des agilen Theaters beschrieben, das häufig entsteht, wenn agile Methoden in einem nicht agilen Kontext angewendet werden.

Kapitel 3 (Agilität: Was ist (wirklich) anders?) beschreibt anhand konkreter Facetten den bereits angesprochenen Perspektivwechsel der Agilität und arbeitet die Unterschiede und die Komplementarität im Vergleich zu plan- und Compliancegetriebenen Ansätzen detailliert heraus.

Kapitel 4 (Agile Prozesse in der IT-Governance, Prüfung & Revision) entwickelt aus den einzelnen Facetten des agilen Perspektivwechsels das generische Grundmuster für agile Prozesse. Das generische Grundmuster bildet das Bindeglied zu den Teilen II – IV, in denen konkrete Ansätze und Umsetzungshilfen für eine agile IT-Governance (Teil II), für eine agile Prüfung & Revision (Teil III) und für die Prüfung agiler Projekte (Teil IV) vorgestellt werden.

2Agilität im Überblick

Agilität ist in den letzten Jahren zu einem breit verwendeten und zunehmend mehrdeutigen Sammelbegriff geworden für moderne Arbeitsorganisation und Arbeitsweisen im weitesten Sinne. Die Erwartungen an Agilität sind dementsprechend vielfältig. Man verspricht sich von Agilität eine stärkere Kundenorientierung und verbesserte Reaktionsfähigkeiten auf eine zunehmende Marktdynamik genauso wie intern eine effektivere Kommunikation und effizientere Arbeitsprozesse.

Die Vielfalt der Begriffsverständnisse und die vorrangige Fokussierung der Diskussion in vielen Organisationen auf methodische Aspekte verstellen jedoch gerne den Blick darauf, was Agilität im Kern ausmacht. Ihr Ursprung ist einfach die Berufs- und Lebenserfahrung, dass trotz aller Planung und Risikovorsorgemaßnahmen immer wieder mit unerwarteten Ereignissen und einem sich verändernden Erkenntnisstand in der Zukunft zu rechnen ist. Als Konsequenz nimmt Agilität einen Perspektivwechsel vor und geht von der prinzipiellen Offenheit (jedoch nicht: Beliebigkeit) zukünftiger Entwicklungen aus, mit der wir trotz aller Planungs- und Kontrollanstrengungen zurechtkommen müssen.

Agilität baut für diese prinzipielle Unsicherheit vorausschauend Handlungskompetenzen, Organisationsstrukturen und (Kommunikations-)Prozesse auf, um schnell und situationsgerecht, also agil mit dem jeweils Neuen zielorientiert zurechtzukommen, was immer es sein möge.1 Eine detaillierte und verbindliche Planung findet in der Agilität deshalb immer nur für kurze Zeitabschnitte statt. Eine gute Analogie zur Veranschaulichung von Agilität sind Rettungsdienste:

Eine Gesellschaft leistet sich Rettungsdienste, weil ein Überfall, ein Unfall oder ein Brand jederzeit passieren können. Es ist zwar nicht vorhersehbar, an welcher Stelle, zu welcher Zeit und in welcher genauen Art solche Ereignisse konkret eintreten werden. Aber es ist vorhersehbar, dass sie eintreten werden. Statt also einen konkreten Einsatz an einem konkreten Ort detailliert zu planen, werden generelle Handlungskompetenzen, Organisationsstrukturen und (Kommunikations-)-Prozesse aufgebaut und bereitgehalten, um im Falle eines Falles zielgerichtet zu retten. Und damit das auch im Ernstfall klappt, werden mögliche Ausgestaltungen der Zukunft oft in Form von Szenarien und Manövern geprobt und exploriert. Wenn dabei etwas (noch) nicht so funktioniert, wie es soll, ist das Risiko nicht so groß, wie es ein Ernstfall gewesen wäre. Agilität hat also viel von einer kurzfristig verfügbaren Reaktions- und dennoch zielorientierten und risikobewussten Gestaltungsfähigkeit, ohne dass man bereits alle Details der situativ erforderlichen Handlungsweisen zu kennen braucht.

Dieses Kapitel gibt einen Überblick über das Gesamtkonzept der Agilität und möchte der oft zu beobachtenden Verengung der Diskussion auf die methodischen Aspekte von Agilität entgegenwirken. Wichtig ist uns, Agilität als ein Gesamtkonzept von Grundhaltung (agil SEIN) und darauf beruhenden Methoden (agil TUN) zu vermitteln.

2.1Ursprünge der Agilität

Viele Kernideen der Agilität wurden – ohne dass es damals bereits »Agilität« genannt wurde – maßgeblich von zwei japanisch-amerikanischen Wirtschaftswissenschaftlern, Hirotaka Takeuchi und Ikujiro Nonaka, in den 1980er-Jahren auf der Grundlage empirischer Beobachtungen herausgearbeitet. Sie beschäftigten sich damals mit der Frage, wie hierarchisch-tayloristisch organisierte Technologiefirmen angesichts von tiefgreifenden Markt- und Technologieumbrüchen bahnbrechende Innovationen in kurzer Zeit marktreif bekommen. Die 1980er-Jahre waren gekennzeichnet u.a. durch die Mikrochiprevolution, die Entwicklung des PCs sowie durch den Eintritt der asiatischen Automobilindustrie in den weltweiten Automobilmarkt. Takeuchi und Nonaka haben deshalb innovative Produktentwicklungen im Automobil-, IT- und Fotografiesektor untersucht. Ihre Erkenntnisse haben sie unter dem Titel The New New Product Development Game beschrieben [Takeuchi & Nonaka 1986]. Sie erkannten als systematisches Muster, dass das neue Neue-Produkte-Spiel methodische Aspekte hat und eine spezifische Arbeits- und Führungskultur aufweist:

Von der

methodischen

Seite her entdeckten sie, dass sequenzielle Vorgehensweisen der Arbeitsorganisation (ähnlich zu einem Staffellauf) konsequent ersetzt wurden durch das komplette Abarbeiten von kleineren Einzelaufträgen in kleineren Teams, die erst später an Synchronisationspunkten integriert wurden. Die einzelnen Arbeitsgruppen arbeiten dabei ziemlich selbstständig und erproben ihre Teilergebnisse immer auch praktisch, bevor sie weitergereicht oder integriert werden.

Von der

Arbeits- und Führungskultur

her entdeckten sie, dass sich das Miteinander der Beteiligten deutlich von arbeitsteiligen und hierarchisch geprägten Organisationsformen unterscheidet. Sie beobachteten in den untersuchten Innovationsprojekten fachlich talentierte und selbstverantwortliche Mitarbeiter, die mitdenken, kreativ auf neue Herausforderungen reagieren und daraus lernen. Aufseiten der Führungskräfte beobachteten sie, dass diese typischerweise eher für gute Rahmenbedingungen sorgten, als sich selbst im Detail operativ zu beteiligen. Zusammenfassend haben sie diese neue Arbeitsweise in ihrem Artikel als

subtle control

(vermittelt durch grobe Zielsetzung, Selbstorganisation und Verzicht auf Mikromanagement) bezeichnet.

Schon hier taucht also die Grundidee von Agilität als Gesamtkonzept von Grundhaltung, Führungsstil und methodischer Umsetzung, auf ohne dass es bereits Agilität genannt wurde. Tabelle 2–1 stellt einige der methodischen Neuerungen und wichtige Aspekte dieses neuen Führungsstils (subtle control) dar.

Methodische Kernpunkte

Führungsstil der subtle control

»Built-in instability«: kein Mikromanagement und keine komplette Planung, sondern nur grobe Zielsetzung

Selbstorganisierende Projektteams

Überlappende, getaktete Entwicklungsphasen

»Multilearning«: multilevel, multifunktional Organisationsweiter Transfer des Gelernten

Auswahl der richtigen Teammitglieder

Schaffen einer offenen Arbeitsumgebung

Ermutigung, in direkten Austausch mit den Endkunden zu treten

Bewertung und Belohnung nach Gruppenleistung

Synchronisierung unterschiedlicher Taktzahlen Fehlertoleranz und Rechnen mit Fehlern

Tab. 2–1Methodische Neuerungen und neue Managementkultur im New New Product Development Game nach [Takeuchi & Nonaka 1986]

Der Artikel von Takeuchi & Nonaka ist aber auch noch in einer anderen Hinsicht folgenreich geworden, da er vermutlich die Wahl des Begriffs Scrum mitbeeinflusst hat. Die Autoren fassen nämlich ihre Erkenntnisse wie folgt zusammen: Der neue Ansatz sei wie ein rugby approach, bei dem das Team versucht, die Distanz auf dem Spielfeld als Team zurückzulegen, und dabei den Ball dynamisch vor- und zurückspielt. In dieser Formulierung taucht erstmalig die Analogie der Strategie hinter dem neuen Führungsstil zum Rugby auf, was später zur Begriffsbildung von Scrum als Methode geführt hat: Scrum bezeichnet einfach das Gedränge bei Rugby-Spielen. Auch die Idee des Vor- und Zurückspielens des Balls taucht übrigens später in den agilen Grundideen auf, wenn es beispielsweise heißt, dass Reagieren auf Veränderungen höher zu werten ist als das Befolgen eines Plans.

2.2Agilität in der IT

Während Takeuchi und Nonaka ihre Arbeiten bereits in den 1980er-Jahren veröffentlichten, verfolgte man in der IT für die Planung und Durchführung von IT-Projekten noch längere Zeit die Idee, dass typische Probleme in IT-Projekten wie Zeit- und Kostenüberschreitungen sowie Qualitätsprobleme normativ mithilfe immer umfangreicherer Vorgehensmodelle, Planungen und Dokumentationen bewältigt werden sollten. Als Beispiel sei hier nur kurz der klassische Ansatz mit aufwendig erstellten Lasten- und Pflichtenheften genannt, die oft viele Seiten umfassen und dann häufig doch ganz anders umgesetzt werden als ursprünglich geplant – weil sich der Kontext und die Kundenanforderungen über die Zeit geändert haben. In den1990er-Jahren mehrten sich jedoch die Zweifel daran, auf diesem Wege die immer wiederkehrenden Probleme von IT-Projekten wie insbesondere unpassende Funktionalitäten und die langen Projektlaufzeiten in den Griff zu bekommen.

Diese Zweifel führten 2001 schließlich zu einer Zusammenkunft einer Gruppe von erfahrenen Informatikern, die ein Grundsatzpapier unter dem Titel Manifesto for Agile Software Development für einen besseren Weg zur Durchführung von IT-Projekten veröffentlichten [Beck et al. 2001]. Auch wenn das Agile Manifesto nicht direkt Bezug auf die Vorarbeiten von Takeuchi und Nonaka nimmt, kann es aus heutiger Sicht als mehr oder weniger direkte Fortsetzung dieser Überlegungen für IT-Projekte angesehen werden. Es ist thesenartig formuliert und ist keine direkt umsetzbare Methodik (vgl. Tab. 2–2).

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen

mehr als

Prozesse und Werkzeuge

Funktionierende Software

mehr als

umfassende Dokumentation

Zusammenarbeit mit dem Kunden

mehr als

Vertragsverhandlung

Reagieren auf Veränderung

mehr als

das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Tab. 2–2Das Manifest für Agile Softwareentwicklung (»Agiles Manifest«) [Beck et al. 2001]

Für ein angemessenes Verständnis der Tragweite des Perspektivwechsels, der im Agilen Manifest steckt, ist es wichtig zu verstehen, dass es im Kern um eine konsequente Kundenorientierung geht. Und da Kunden ihre Wünsche und Anforderungen laufend weiterentwickeln, muss auch Agilität alle Aktivitäten und Planungen in den IT-Projekten immer wieder im Hinblick auf ihren jeweils aktuellen Wertbeitrag und die Kundenorientierung hinterfragen.

Hier schließt sich nun der Kreis auch zum oben bereits mehrfach erwähnten bewussten Umgang von Agilität mit Risiko, und zwar gleich in doppelter Hinsicht, nämlich mit einem direkten produktbezogenen Risiko und mittelbar mit einem unternehmerischen Risiko: Agilität möchte das unmittelbare Risiko vermeiden, durch unpassende IT-Produkte den Kundenwunsch zu verfehlen. Außerdem möchte Agilität das mittelbare Risiko vermeiden, durch nicht kundengerechte Produkte den Umsatz oder die Nachfrage zu reduzieren und schließlich in wirtschaftliche Probleme zu geraten. Deshalb wiederum ist es für Agilität wichtiger, auf Veränderung zu reagieren, als das Befolgen eines einmal früher gemachten Plans.

Anders als in manchen Implementierungsversuchen im Gefolge des Agilen Manifests geht es der Agilität jedoch nicht um eine radikale Abkehr von allen Hilfstechniken und Methoden klassischer Vorgehensmodelle, wie z.B. Modellierung, Dokumentation und Planung. Es geht der Agilität vielmehr um die Wiederherstellung einer angemessenen Balance, die angesichts ausufernder bürokratischer IT-Vorgehensmodelle zunehmend verloren zu gehen drohte. Beispielsweise ist es durchaus im Sinne der Agilität, zu planen, aber durch eine Planung, die in zunehmend dynamischen Kontexten zwar die nächsten Schritte plant, jedoch auf eine zu langfristige Planung verzichtet.

Das Versprechen von Agilität in der IT ist also, ähnlich wie beim New New product development game, die Kundenorientierung und Innovationskraft von (IT-)Projekten systematisch zu verbessern. Und zwar sowohl auf der methodischen Ebene wie auch von der Grundhaltung her.

Methodisch ist Agilität konsequent kunden- und wertschöpfungsorientiert. In der Grundhaltung ist Agilität von Respekt gegenüber der Eigenverantwortung, Selbstständigkeit und Selbstorganisationsfähigkeit aller Beteiligten sowie von einer kontinuierlichen Lernhaltung geprägt. Agilität selbst bietet jedoch keine direkt umsetzbare Methodik an, sondern lediglich konzeptionelle Orientierungshilfen und Grundideen, an denen sich jede agile Methode zu orientieren hat.

2.3Agile Methoden für IT-Projekte: Beispiel Scrum

Wie im vorigen Abschnitt erläutert, ist Agilität eine an Selbstorganisation, Selbstverantwortung und kontinuierlichem Lernen ausgerichtete und kundenorientierte Grundhaltung, ohne schon selbst eine direkt umsetzbare Vorgehensweise zu sein. Diese Lücke füllen agile Methoden. Alleine im Bereich von IT-Projekten gibt es eine Vielzahl von agilen Methoden und Techniken, wie z.B. Scrum, SAFe für skalierte agile Projekte und stärker programmierbezogene agile Techniken wie XP (Extreme Programming). Stellvertretend für diese Vielzahl wird in diesem Abschnitt die agile Methode Scrum aufgrund ihrer aktuell weiten Verbreitung im Überblick dargestellt.2

Der Scrum Guide von Schwaber und Sutherland definiert Scrum als »Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren« [Schwaber & Sutherland 2020, S. 3].

Noch bevor dann im weiteren Verlauf des Scrum Guide die methodischen Elemente beschrieben werden, verweisen Schwaber und Sutherland darauf, dass Scrum auf der Theorie empirischer Prozesssteuerung beruht, die durch die drei Säulen

Transparenz über den Arbeitsstand,

systematische empirische Überprüfung der Ergebnisse sowie

laufende (situative) Anpassung des Prozesses (WIE) und der Inhalte (WAS)

charakterisiert ist [Schwaber & Sutherland 2020, S. 4]. Diese drei Säulen können als konkrete Umsetzung des oben von [Takeuchi & Nonaka 1986] beschriebenen Rugby Approach von back and forth als zentraler Spielstrategie angesehen werden. Für das Miteinander in Scrum-Projekten werden hieraus die sogenannten Scrum-Werte abgeleitet, nämlich

Commitment,

Fokus,

Offenheit,

Respekt und

Mut.

Auch das sind konkrete Formen der bereits von [Takeuchi & Nonaka 1986] herausgearbeiteten Aspekte des neuen Arbeits- und Führungsstils der subtle control. Die Verbindung der drei Säulen der empirischen Prozesssteuerung mit diesen fünf Werten führt dann insgesamt dazu, dass alle Beteiligten als Team gerade in komplexen, sich dynamisch entwickelnden und innovativen Situationen konkrete und werthaltige Ergebnisse erarbeiten können. Erst durch die Verbindung der empirischen Prozesssteuerung mit diesen Werten können dann auch die zentralen Scrum-Elemente

Verantwortlichkeiten

(Scrum-Team, bestehend aus Entwicklerinnen, Scrum Master und Product Owner),

Artefakte

(Product Backlog, Sprint Backlog und Produktinkrement) und

Ereignisse

(Sprint-Planung, Daily Scrum, Sprint-Review und Sprint-Retrospektive)

ihre volle Wirksamkeit entfalten. Zusammengehalten werden diese Elemente durch den Scrum-Flow, wie er in Abbildung 2–1 dargestellt wird.3

Abb. 2–1Der Scrum-Flow im Überblick

Der Scrum-Flow ist ein iterativer und immer gleich langer Ablauf, ein einzelner Durchlauf wird als Sprint bezeichnet und dauert typischerweise zwischen zwei und vier Wochen. Jede Verantwortlichkeit hat dabei genau beschriebene Zuständigkeiten, es sind immer die benannten Artefakte zu erstellen und weiterzuentwickeln und die Kommunikation geschieht im Rahmen der benannten Ereignisse. Scrum geht also in kleinen Entwicklungsschritten vor und unterstützt rasches produkt- sowie prozessbezogenes Lernen.

Sprint-Reviews unterstützen das produktbezogene Lernen. Im Sprint-Review wird regelmäßig geprüft, ob das im aktuellen Sprint entwickelte (Produkt-)Inkrement (immer) noch den Kundenerwartungen entspricht. Gegebenenfalls kann dann schon sehr frühzeitig gegengesteuert werden. Dadurch werden nicht wertschöpfende Fehlentwicklungen frühzeitig erkannt und Verschwendung (z.B. durch Entwicklung von Funktionalitäten, die der Kunde gar nicht möchte) wird vermieden. Aus Sicht des Risikomanagements sind das ebenfalls gewichtige Vorteile.

Sprint-Retrospektiven unterstützen das prozessbezogene Lernen. In der Sprint-Retrospektive reflektiert das Scrum-Team regelmäßig seine Arbeitsprozesse und die Qualität der Zusammenarbeit. Aus jeder Retrospektive resultieren einige wenige konkrete Maßnahmen, die dann im jeweils nächsten Sprint erprobt werden.

Die Wirksamkeit des Scrum-Flows und insbesondere die raschen Lerneffekte, die mit dem Scrum-Flow möglich sind, erfordern jedoch von der Grundhaltung her Mut und Ehrlichkeit sowie gegenseitiges Vertrauen und eine hohe Fehlertoleranz (ohne Schwarze-Peter-Mentalität) bei allen Beteiligten. Wenn nach Scrum gearbeitet wird, sollten daher ergänzend immer das Fundament von empirischer Prozesssteuerung und die Scrum-Werte mitgedacht und respektiert werden.

Die Einführung agiler Methoden, wie z.B. die Umsetzung des Scrum-Flows, ist noch kein Garant dafür, dass die Organisation wirklich agil wird, d.h. eine risikoorientierte und situativ anpassbare Handlungsfähigkeit für komplexe oder dynamische Situationen erreicht. Auch wenn der Scrum-Flow aus Abbildung 2–1 in vielen Organisationen als mehr oder weniger wörtlicher Blueprint für die Einführung agiler Methoden dient, so verdeckt die verbreitete Fixierung auf die Methodik doch das Wesentliche dabei: die agile Grundhaltung und die Kultur, mit der die methodischen Elemente tatsächlich genutzt werden sollen – oder kurz: die agilen Werte, auf denen die agilen Methoden beruhen.

Während sich Organisationen also nach unserer Erfahrung eher leichttun, die methodischen (d.h. die sichtbaren) Elemente von Scrum gemäß Abbildung 2–1 für ihre (IT-)Projekte einzurichten und in Prozessleitfäden zu beschreiben, tun sich viele Organisationen eher schwer damit, das Wesentliche, d.h. die Scrum-Werte, die damit eigentlich einhergehen, umzusetzen.

So führen die Scrum-Methoden zwar auf operativer Ebene rasch zu einer (agil daherkommenden) Umorganisation und machen eine agile Organisationskultur wahrscheinlicher, jedoch ändern sich die Erwartungshaltung und die Handlungsmuster der Organisation, insbesondere die der Führungskräfte, oft nicht ausreichend:

Zwar wird in kleinen Iterationen (Sprints) gearbeitet, jedoch sind die Führungskräfte und die Vertreter des Kunden oft nicht darauf vorbereitet, dass sie sich bei jedem Sprint-Review auch konkret mit einem funktionierenden Softwareprodukt beschäftigen sollten. Sie sind oft auch nicht vorbereitet, die jeweils zusätzlich verfügbare Funktionalität in Produktion zu übernehmen und können so gar nicht den ganzen Nutzen aus der agilen Vorgehensweise ziehen.

Zwar finden ein Sprint-Review (produktbezogen) und eine Sprint-Retrospektive (prozessbezogen) statt. Jedoch wird das Offenlegen von Fehlern (direkt oder indirekt) missbilligt bzw. ist sogar mit Angst besetzt und es kann keine Verbesserung des agilen Prozesses angestoßen werden.

Zwar gibt es ein agiles Entwicklungsteam statt des früheren Projektleiters, aber jetzt trifft der Scrum Master letztendlich die Entscheidung über die als Nächstes aus dem Sprint Backlog umzusetzenden User Stories und damit, welche Funktionalität als Nächstes fertiggestellt werden muss. Damit wird die Selbstorganisation des Teams unterlaufen.

Wie die Beispiele zeigen, greift eine gelebte agile Softwareentwicklung tief in die soziale Ordnung und in lange eingeübte Grundüberzeugungen einer Organisation ein, insbesondere wenn diese eher klassisch arbeitsteilig und hierarchisch geprägt ist.