Freitag, 11. September 2015

Agile Governance

FS
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 das mittlere Management eben diese Erfordernisse regelmässig als Hebel einzusetzen versucht um agile Methoden in Richtung Wasserfall um-, bzw. rückzugestalten.

Der aus meiner Sicht zentrale Satz des Artikels ist folgender: "Es reicht [...] in bestehenden Strukturen neu zu denken." Anders als von dem erwähnten mittleren Management oft behauptet ist es nämlich meistens nicht so, dass die Vorschriften nur eine einzige Vorgehensweise zulassen, und zwar die "schon immer" benutzte, die sich in der Regel durch Hierarchie, Bürokratie, Dokumentations-Overhead und Tendenz zum Blaming/Fingerpointing auszeichnet. Dass das trotzdem behauptet wird ist in der Regel Bestandteil einer Derailing-Strategie, die das Ziel hat 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 allem bei großen Mittelständlern und Großkonzernen nahezu aussichtsloses 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 Scrum-Prozess 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 dem nun zum dritten mal erwähnten mittleren Management erfunden worden sind.

Diese Aussage wirkt zunächst schwer nachvollziehbar - in vielen Fällen soll diese Management-Ebene durch das Erfinden immer weiterer unnötiger Governance- (oder Compliance- oder sonstiger) Vorschriften ihren Mitarbeitern 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: in der Regel um die eigene Existenz zu rechtfertigen. Gerade in größeren Unternehmen ist das mittlere Management bei näherer Betrachtung nämlich oft erschütternd überflüssig. Um das nicht offensichtlich werden zu lassen (die Folge wäre nämlich der Abbau dieser Stellen) werden die genannten Pseudo-Vorschriften erfunden. 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 wird das Mittelmanagement auch mit großer Wahrscheinlichkeit gegen jede Form agiler Governance Sturm laufen. Sich diesem entgegenzustemmen ist dann die anstrengende aber verdienstvolle Arbeit des Scrum Masters (und ggf. des PO).
Powered by Blogger.