Als agile Organisation mit nicht-agilen Organisationen zusammenarbeiten – nicht immer einfach, gerade wenn es ums Controlling geht. Dr. Stefan Barth gibt nach sechs Jahren ein Update, wie jetzt in seiner Firma Agile Controlling umgesetzt wird.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Als agile Organisation mit nicht-agilen Organisationen zusammenarbeiten – nicht immer einfach, gerade wenn es ums Controlling geht. Dr. Stefan Barth gibt nach sechs Jahren ein Update, wie jetzt in seiner Firma Agile Controlling umgesetzt wird.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Vor sechs Jahren schrieb ich für das projektmagazin einen Artikel mit dem Titel "Agile Controlling - aussagekräftiges Berichtswesen für agile Organisationen" (Ausgabe 05/2015) aus der Sicht der tarent solutions GmbH, einem Dienstleister für Design und Entwicklung sicherer und skalierbarer Cloud-Plattformen für Medien, Logistik, Retail und Telekommunikation mit rund 300 Mitarbeitern. Der Anlass war damals der Folgende: Ausgehend von den drei Bewertungsparametern für erfolgreiche Software-Entwicklungsprojekte
kam die amerikanische Forschungs- und Beratungsfirma Standish Group in ihrem Chaos Report 2015 zu dem Ergebnis, dass Software-Entwicklungsprojekte mehrheitlich an einem dieser drei Parameter scheitern.
Software-Entwicklungsorganisationen reagierten auf diesen Missstand zunehmend mit dem Einsatz agiler Entwicklungsmethoden – was heute als Standard betrachtet werden kann – während die Auftraggeberseite verstärkte Controlling-Bedürfnisse entwickelte, die klassischen Prinzipien folgten. Diesen kulturellen und methodischen Bruch versuchte ich damals mit einem "schützenden Kokon" um die agile Entwicklungsorganisation zu entschärfen: Es wurde eine Übersetzungsschicht zwischen agilem Vorgehen und klassischer Projektsicht geschaffen (Bild 1).
Der Chaos Report 2020 der Standish Group zeigt, dass sich die Situation hinsichtlich des Erfolgs von Software-Entwicklungsprojekten in den letzten sechs Jahren wenig verändert hat. Dementsprechend bleiben uns auch bis heute die Unsicherheiten der Auftraggeber-Seite erhalten, die zu einem erhöhten Controlling-Bedürfnis führen.
Was die Statistik jedoch verbirgt: Aus unserer Sicht als Dienstleister treffen wir auf neue Herausforderungen in den Projektumsetzungen. Während in der Vergangenheit der kulturelle Bruch zwischen einer klassischen Projektsicht und dem agilen Entwicklungsvorgehen an der Schnittstelle zwischen Dienstleister:in und Anforderer:in verlief, hat sich der kulturelle Bruch mittlerweile tief in die Organisation des Auftraggebenden verschoben. Ursächlich hierfür ist ein stetig zunehmendes Verständnis agiler Arbeitsweisen, das über die Kernorganisation der IT (des Auftraggebenden) hinaus abstrahlt. Dies macht es tatsächlich sogar noch schwieriger als in der Vergangenheit, eine konsistente Strategie für den Umgang mit dem kulturellen Bruch zu finden, da der Verlauf der "Frontlinie" unklar ist.
Uns ist darüber hinaus deutlich geworden, dass ein "Kokon", der die agile Entwicklungsorganisation vor einem klassischen Umfeld schützt, maßgeblich kommunikativ zum Projekterfolg beiträgt, jedoch kaum inhaltlich. Der Denkfehler im System ist der gebrochene Anforderungsprozess: Wenn der:die Product Owner:in auf der Dienstleister-Seite agil arbeitet und die gleichnamige Rolle auf der Auftraggeber-Seite konsequent klassischen Prinzipien folgt, geht das verloren, was man gemeinhin als den maßgeblichen Vorteil agilen Anforderungsmanagements betrachtet: iterativ und visionsorientiert zu arbeiten, statt zu versuchen, bereits am Anfang des IT-Projekts das exakte Ergebnis zu kennen.
Handelt die "Demand-Seite" jedoch agil (was ja wünschenswert ist), wird der kulturelle Bruch von der Schnittstelle zwischen Demand und Supply in die Demand-Organisation verlagert – mit der Folge, dass die Sphärentrennung zwischen Demand und Supply unsinnig wird. Das Modell von 2015 zur Bewältigung der Herausforderungen im Controlling verliert damit seine Grundlage.
Die Antwort darauf, wie sich unter diesen Voraussetzungen agiles Projektcontrolling umsetzen lässt, ist so nicht mehr durch eine einfache, modellartige Blaupause zu beantworten: Das Umfeld, in dem Controlling etabliert werden muss, ist komplex. Erfolgreich sind nur individuelle Lösungsansätze.
Dieses Szenario ist für uns im Hinblick auf die Ausgangsherausforderung am einfachsten: der Auftraggebende ist vertraut mit agiler Softwareentwicklung.
Das Szenario zeichnet sich durch folgende Eigenschaften aus:
Unsere Teams betten sich in das bestehende Controlling-System ein und leisten den geforderten Beitrag. Dieser kann darin bestehen, Burn Down Charts beizubringen oder aktiv an der Programminkrement-Planung mitzuwirken in skalierenden, agilen Organisationen. Hier bewegen sich unsere Mitarbeitenden inklusive der projektorganisierenden Rollen (Scrum Master und Product Owner) in einem Ökosystem, was unserem internen nicht unähnlich ist (siehe Abschnitt "Organisation"). Die Abrechnung erfolgt über Zeit und Aufwand.
Gefahr Selbstoptimierung – Misstrauen in einer DienstleisterbeziehungDie Grundlage agilen Arbeitens ist die Bereitschaft, sich gegenseitig zu vertrauen – insbeson-dere im Auftraggeber-Dienstleisterverhältnis. Nicht umsonst lautet das dritte Prinzip des agi-len Manifests "Customer collaboration over contract negotiation". Ist das Vertrauen gestört, beginnen beide Seiten sich vor möglicher Unredlichkeit zu schützen, indem sie ihre eigene, wirtschaftliche Position im Projekt optimieren. Der:die Auftraggeber:in hinterfragt permanent Kostenprognosen für die Weiterentwicklung mit dem Gefühl, dass ihm Informationen vorent-halten werden. Der:die Dienstleister:in versucht, unbezahlte Aufwände durch Kleinlichkeit bei Change Requests zu begegnen. Dies ist ein Teufelskreis. |
Wir begegnen einem solchen Umfeld in der Regel als mitwirkende oder gestaltende Dienstleister in großen Plattformentwicklungen. Die Grenzen des Projektcontrollings sind dort erreicht, wo die Führungskraft ein Gantt-Chart mit zeitlichen Meilensteinen bis zum Projektende sehen möchte und womöglich regelmäßig Fortschritts- und Risikoberichte erwartet.
In der beschriebenen Konstellation ist die Führungskraft oft weit von den Details der fachlichen Umsetzung entfernt. Ich begegne ihrer Anforderung nach konkreter Projektplanung dann mit einer Darstellung der größeren Feature-Bausteine für einen Zeithorizont von bis zu einem Jahr. Dies ist auch mit agilen Controlling-Methoden ohne weiteres möglich.
Die Herausforderung, die bleibt, ist der "5-Jahresplan", den sich das Top Management wünscht. Intern stellen wir bei Tarent Solutions uns nicht die Frage nach einem 5-Jahresplan. Gegenüber unseren Auftraggeber:innen begründen wir, warum wir hierzu keine seriöse Prognose geben können: Markt- und Kundenbedürfnisse sind bei diesem Zeithorizont zu wenig vorhersehbar, sodass das zu erstellende Endprodukt kaum klar zu umreißen wäre. Damit suggeriert eine langfristige Fertigstellungplanung eine Sicherheit, die nicht existiert. Da die Argumente tatsächlich augenscheinlich sind (und typischerweise dieselben, warum der:die Auftraggeber:in sich seinerseits agil aufgestellt hat), ist der Überzeugungsversuch häufig erfolgreich.
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
