Agile Governance

Bild: Wikimedia Commons/CTBTO - CC BY 2.0

Gerade ist mir beim Blättern in IT-Zeitschriften dieser Artikel hier in die Hände gefallen: Agile Governance auch in regulierten Märkten und für Konzerne. Verkürzt gesagt geht es hier darum, wie agile Projekte und Abteilungen den Governance-Erfordernissen großer Konzerne gerecht werden können. Ein wichtiges Thema, schließlich habe ich die Erfahrung gemacht, dass Unklarheiten in diesem Bereich regelmässig dazu führen, dass agile Methoden (absichtlich oder versehentlich) in Richtung Wasserfall um-, bzw. zurückzugestaltet werden.

Der aus meiner Sicht zentrale Satz des Artikels ist folgender: "Es reicht [...] in bestehenden Strukturen neu zu denken." Anders oft fälschlicherweise angenommen ist es nämlich meistens nicht so, dass die Vorschriften nur eine einzige Vorgehensweise zulassen, und zwar die "schon immer" benutzte, die sich oft durch Hierarchie, Bürokratie, latenten Dokumentations-Overhead und schlimmstenfalls Tendenz zum Blaming/Fingerpointing auszeichnet. Dort wo das trotzdem behauptet wird sind es häufig Konzern-Trolle, die das Ziel haben den Diskussionsschwerpunkt zu verlagern: lässt man sich darauf ein geht es plötzlich nicht mehr darum den Governance-Anforderungen mit möglichst geringem Aufwand gerecht zu werden, sondern darum diese zu ändern - ein vor allen in frühen Phasen einer Transition hochgradig anspruchsvolles Unterfangen. Die erste und wichtigste Maßnahme sollte also sein, diesem Derailing auszuweichen und im direkten Kontakt mit der Revisionsstelle/-abteilung das "minimum viable Requirement" festzustellen mit dem diese sich zufrieden gibt.

Erstaunlich oft wird man dabei feststellen, dass diese Damen und Herren sehr verständnisvoll und entgegenkommend sind. Bemerkenswert gute Ergebnisse können zum Beispiel alleine dadurch entstehen, dass man mit ihnen gemeinsam den jeweiligen Prozess (z.B. Scrum) durchgeht und nachfragt welche ihrer Anforderungen durch ihn bereits abgedeckt sind. Es kann passieren, dass die angeblich völlig unverzichtbare Feinspezifikation plötzlich unnötig wird, da ja bereits in den User Stories klar dokumentiert ist was die Fach- von der Entwicklungsabteilung will. Auch ist es keineswegs so, dass das häufig vorgegebene Vier Augen-Prinzip gesonderte Test-Abteilungen oder -phasen erfordert - wenn eine Story zuerst im Team getestet und danach vom PO abgenommen wird kann das völlig ausreichen. Derartige Beispiele ließen sich viele finden, denn fast überall ist es so, dass viele der angeblich von oben vorgegebenen Vorschriften in Wirklichkeit von den oben genannten Konzern-Trollen erfunden oder übermässig dramatisiert worden sind.

An dieser Stelle ein kurzer Exkurs zu diesen Trollen - in vielen Fällen sollen Angestellte eines Unternehmens ihren Kollegen durch das Erfinden immer weiterer Governance- (oder Compliance- oder sonstiger) Vorschriften Klötze an die Beine hängen und damit Effizienz, Agilität und Kreativität hemmen oder verhindern? Man fragt sich an dieser Stelle - warum sollten die so etwas machen? Wer Konzernerfahrung hat wird es erraten können: oft um die eigene Existenz zu rechtfertigen. Selbst in größeren Unternehmen gibt es für viele derartige Stellen bei näherer Betrachtung erschütternd wenig anderes zu tun. Um das nicht offensichtlich werden zu lassen (die Folge wäre nämlich meistens der Abbau dieser Stellen) werden Vorschriften zu rigide ausgelegt und schlimmstenfalls sogar erweitert. Für diese kann dann nämlich eine umfangreiche Planungs-, Steuerungs- und Überwachungsbürokratie aufgebaut werden, aus der sich ausreichend Tätigkeiten (und damit Legitimation) ableiten lassen.

Aus diesem Grund werden Teile dieser Organisationseinheiten (die natürlich auch viele gute Leute enthalten, das der Vollständigkeit halber gesagt) auch mit großer Wahrscheinlichkeit gegen jede Form agiler Governance Sturm laufen solange nicht klar ist wie ihre zukünftige Rolle sein wird (und ob es sie noch geben wird). Sich mit dieser Frage zu beschäftigen ist dann die anstrengende aber verdienstvolle Arbeit nicht nur des Managements sondern auch der Agile Coaches, Scrum Master, Product Owner und aller denen schnelle Liefer- und Reaktionsfähigkeit am Herzen liegt.