Effiziente Verwaltung – Agile vs. klassische Methoden
Wie führt man öffentliche Projekte zum Erfolg? Mit den beiden Cassini Beratern Theodoros Moutsokapas und Florian Theißing trifft ein Befürworter der Agilität auf einen Anwalt klassischer Methoden. Doch beide sehen Übergänge. Ein Zwiegespräch.
Können Verwaltungen überhaupt agil?
Moutsokapas: Diese Frage soll ein Klischee bedienen: Natürlich können Verwaltungen agil. Das erlebe ich täglich in meinen Projekten.
Theißing: In welchen Projekten? Nehmen wir ein großes Bund-Länder-Projekt in der Softwareentwicklung. Daran sind etliche Stakeholder beteiligt. Für die geht es um Berechenbarkeit und Nachvollziehbarkeit. Sie wollen das fertige Produkt vorab genau beschrieben wissen. Das ist nicht zuletzt für die Vergabe unerlässlich. In solchen Fällen: Klares Plädoyer für strukturierte Methoden.
Moutsokapas: Wer sagt, es geht um Agilität auf Gedeih und Verderb? Da bin ich Realist. Die Initiierungsphase eines Projektes kann ja durchaus wasserfallartig sein, um Größe und Stakeholder zu bestimmen. Bei Detailfragen wie z. B. welche Technologie eingesetzt wird, kann man aber den agilen Weg gehen. Die Kunst ist, die Teilbereiche mit agilem Potenzial zu identifizieren. Sind die Rollen erst mal definiert, können auch größere Projekte iterativ erstellt werden.
Theißing: OK, ich gebe aber zu bedenken, dass es in der öffentlichen Verwaltung eine starke Absicherungskultur gibt, die sich mit Agilität oft nur schwer vereinbaren lässt.
Moutsokapas: Auch die kann man agil lösen. Beispiel: In einem Projekt haben Dienstleister und Kunden eine Probephase vereinbart. In mehreren Sprints wurden verschiedene Lösungen ausprobiert. Nach drei Wochen lagen die Ergebnisse vor, von denen eins ausgewählt wurde. Die Folge: Keine Fehler, keine Schuldigen, kein Verzug.
Theißing: Ich räume ja ein: Im Verlauf eines Wasserfallprojektes kann es zu berechtigten Fragen kommen. Brauchen die Entwickler Gestaltungsspielraum? Verändern sich Anforderungen? Dokumentiert man sich tot anstatt miteinander zu sprechen? Dann machen agile Elemente durchaus Sinn.
Moutsokapas: Agilität ist auch eine Frage des Zeitpunkts. Am Anfang steht oft das detaillierte Lastenheft. Je länger aber ein Projekt dauert, desto eher ändern sich die Anforderungen. Vor allem sind das der Prozesswandel in der Aufgabenerledigung, die Veränderungen in den Umsystemen und die stetige Technologieentwicklung. Agilität bietet hier eine Lösung. Ich habe ja nichts dagegen, wenn bestimmte Aufgaben per Wasserfall erledigt werden – wie die Migration gegen Ende, einfach weil es feste Termine gibt.
Welche Aufgabe haben Berater von Cassini, wenn die eine oder andere Methode im Projekt an ihre Grenzen stößt?
Theißing: Zum einen klar zu sagen: Agile ist kein Dogma. Erfolg hat der Berater, der in der Lage ist, das Repertoire an agilen Methoden mit den Anforderungen der öffentlichen Verwaltung zusammenzubringen.
Moutsokapas: Wasserfall aber auch nicht. Entscheidend sind die Rahmenbedingungen: Wann geht was? Agile eignet sich dann, wenn das Budget offen ausgestaltet ist, man die Teamgröße definieren kann, das Ziel grob vor Augen hat und sich alles Andere im Prozess nach und nach entwickelt darf. Wasserfall bleibt aber aktuell, wenn man weiß, was man haben möchte, Prozesse und Teilbereiche klar abgesteckt sind oder Aufgabentypen agil nicht zulassen – oft außerhalb der Softwareentwicklung, im Zusammenhang von Gesetzgebungsverfahren, bei Organisationsveränderungen oder Strategieprojekten. Da spricht vieles für Wasserfall. Und das muss ein Berater erkennen.
Theißing: Womit wir wieder am Anfang sind: Über welche Projekte sprechen wir? Agile Projekte brauchen einen eindeutigen Kunden und Entscheidungsprozesse, die nicht in die politische Sphäre hineinreichen. Nochmal: Wer entscheidet in einem Projekt, das durch Länder, Bund und EU finanziert wird? Eindeutige Beschlüsse und gesetzliche Vorgaben determinieren den Projektverlauf so stark, dass Agile als Dogma nicht funktionieren kann.
Moutsokapas: Ich gebe Dir ja recht: Berechenbarkeit ist wichtig. In einem unserer agilen Projekte definierten wir deshalb einen Ansprechpartner, der als Gesamt-Product Owner klare Ansagen zu den Ergebnissen machen konnte. Das bringt Nachvollziehbarkeit. Je mehr Stakeholder, desto anspruchsvoller wird es natürlich, die Anforderungen zu sammeln und desto disziplinierter muss man sein. Auch das haben wir geschafft, mit fünf Product Ownern und einem Gesamt-Product Owner.
Theißing: Ein Lösungsansatz, der funktioniert: Wir machen nicht das ganze Projekt agil, sondern schauen, wie man in dem großen Konglomerat die Teilbereiche so kapseln kann, dass das Potenzial der Agilität für das Projekt ausgeschöpft wird. Dabei muss das Bedürfnis der öffentlichen Verwaltung nach Stabilität berücksichtigt werden.
