Agile Methoden im öffentlichen Dienst

 

Seit einigen Jahren unterliegt die Welt der Softwareentwicklung einem Wandel: Weg von klassischen Vorgehensweisen, bei denen strikte Planverfolgung und starre Verträge im Vordergrund standen, hin zu agilen Verfahrensweisen, die das Softwareprodukt und die Zufriedenheit des Kunden in den Vordergrund stellen. Die Basis für diese Veränderungen stellt das Agile Manifest (http://agilemanifesto.org/) sowie in zunehmendem Maße die sogenannte Software-Craftsmanship-Bewegung (http://manifesto.softwarecraftsmanship.org/) dar.

 

Insbesondere wenn Behörden agile Methoden einzusetzen möchten, stellt sich die Frage, welche Vorgehensweisen sich leicht etablieren und sinnvoll in das bestehende Umfeld integrieren lassen. Eine solche Veränderung lässt sich natürlich nicht auf einen Schlag einführen, schließlich müssen sich Behörden an das Vorgehensmodell V-Modell XT (http://www.v-modell-xt.de/) halten. Aber was spricht überhaupt für den Einsatz agiler Methoden, und lassen  sich diese im Behördenumfeld überhaupt einsetzen?

Im Behördenumfeld sind mitunter einschneidende Veränderungen zu beobachten, die schon für den Einsatz von agilen Methoden im Bereich der Softwareentwicklung in sprechen:

Zum einen werden Behörden durch Ausschreibungen und die externe Vergabe von Projekten immer häufiger mit Partnern konfrontiert, die ihrerseits bereits den klassischen Weg verlassen haben und verstärkt agile Methoden einsetzen. Durch den Einsatz dieser Methoden sind diese Firmen ihren Mitbewerbern in zunehmendem Maße überlegen und gelangen über das Ausschreibungsverfahren immer mehr in Projekte der öffentlichen Hand.

Auf der anderen Seite haben sich auch die Anforderungen an die Projektdurchführung innerhalb der Behörden geändert: Immer mehr Anforderungen müssen in immer kürzerer Zeit umgesetzt werden. Zudem steigt die Gesamtanzahl der Projekte, die umgesetzt und häufiger ausgeliefert werden müssen.

Beide Einflussfaktoren bewegen Behörden heute dazu, sich mit agilen Methoden zu befassen und das eigene Vorgehen bei der Projektabwicklung entsprechend anzupassen.

Eine der sichtbarsten Veränderungen, die durch den Einsatz agiler Methoden bewirkt werden, zeigt sich darin, dass Produkte bzw. Produktinkremente immer häufiger und immer schneller ausgeliefert werden können. Der Grund hierfür ist die Fokussierung der agilen Methoden auf die Verkürzung der Feedback-Schleife zwischen der Anforderung an ein Produkt und der Funktionalität, die der Nutzer erlebt. Diese Fokussierung hat Auswirkungen auf die klassische Aufteilung des Projektteams, die bislang an den Phasen der Softwareentwicklung orientiert wird. (Anforderung, Entwicklung, Test, Deploy): Das Team muss nun den Mehraufwand, der durch die Übergaben zwischen den einzelnen Gruppen entsteht, reduzieren. Das erfordert eine engere Zusammenarbeit der Teammitglieder und folglich ein Aufbrechen der starren Strukturen zugunsten eines interaktiven, funktionsübergreifenden und hochvernetzten Teams.

Agile Methoden bewirken letztendlich eine engere Zusammenarbeit der Projektbeteiligten. Die engere Kooperation gepaart mit einem größere Handlungsfreiraum, für das gesamte Team verstärkt das persönliche Verantwortungsgefühl der Mitarbeiter gegenüber dem Projekt und erhöht somit die Motivation zur Erreichung der Projektziele.

Neben der schnellen Lieferung von Produkten wird sich eine weitere Verbesserung besonders bemerkbar machen: die Qualität der Software. Diese qualitative Veränderung liegt in der besonderen Vorgehensweise bei der Durchführung von agilen Projekten begründet. Einen wichtigen Anteil an dieser Veränderung hat die testgetriebene Entwicklung (Test Driven Development, TDD). Beim TDD werden Tests geschrieben, um auf der Basis der Ergebnisse das Design der Anwendung zu entwickeln. Kombiniert wird dieses Vorgehen mit Pair-Programming (http://c2.com/xp/PairProgramming.html) und Continuous Integration (http://martinfowler.com/articles/continuousIntegration.html), was dazu dient, mögliche Fehler bei der Entwicklung früh zu erkennen und sofort beseitigen zu können.

Diese Verfahren tragen dazu bei, dass Anwendungen evolutionär entwickelt und Designentscheidungen so spät wie möglich getroffen werden können. Doch inwieweit profitiert die Softwareentwicklung von diesem Umstand? Nun, Entscheidungen zu treffen ist eine der kritischsten Aufgaben in der Softwareentwicklung. Meist halten die Auswirkungen lange an und lassen sich zu einem späteren Zeitpunkt nur schwer wieder ändern. Zum Zeitpunkt der Entscheidungen sind oftmals noch nicht alle notwendigen Informationen verfügbar, sodass, ein großes Maß an Unsicherheit in den Entscheidungsprozess mit einfließt. Und genau aus diesem Grund werden bei agilen Vorgehensweisen Entscheidungen erst so spät wie möglich getroffen. Bis dahin können viel mehr Informationen gesammelt und sowohl das Projekt als auch die Anwendung können flexibler gestaltet werden als es mit den klassischen Methoden möglich wäre.

Um Mitarbeiter für eine Arbeitsstelle zu begeistern, reicht es häufig nicht mehr aus, ihnen Sicherheit und Herausforderung zu bieten. Immer wichtiger werden die Mitgestaltungsmöglichkeiten jedes Einzelnen im Projekt und in der Organisation. Maßgeblich bei der Entscheidung für oder gegen einen Arbeitsplatz sind für qualifizierte Fachkräfte heute zunehmend die Rahmenbedingungen der Projekte, die bei einem potentiellen Arbeitgeber durchgeführt werden. Die agilen Vorgehensweisen bieten ein Umfeld, das Mitarbeiter nicht nur zur aktiven Mitgestaltung motiviert, sondern diese auch explizit so vorsieht. 

Im Rahmen des vom Gesetzgeber vorgegebenen Vorgehens nach V-Modell XT lassen sich nicht alle Änderungen, die für einen vollständigen Übergang zu einer agilen Organisation notwendig sind, durchführen. Es ist aber möglich, agile Vorgehensweisen innerhalb des V-Modell-Prozesses anzuwenden und somit die Vorteile der agilen Softwareentwicklung zu nutzen.

Am einfachsten ist es, Veränderungen auf Teamebene durchzusetzen, da diese nicht den Prozess sondern lediglich die Zusammenarbeit der Projektgruppe betreffen. Hier können zum Beispiel Verfahren wie Pair-Programming oder TDD eingesetzt werden, um die Zusammenarbeit des Teams zu verbessern und die Geschwindigkeit und Qualität der Software zu erhöhen.

In weiteren Schritten sollte damit begonnen werden, die Arbeit des Teams zu reorganisieren. Dazu zählt der Übergang von schwergewichtigen, langfristig geplanten Aufgaben, die einzelnen Teammitgliedern zugewiesen werden, hin zu Anforderungen, die in kleineren Einheiten erstellt werden. Die Lösungen liefern einen (kleinen) Geschäftswert und werden nicht mehr von außen zugewiesen sondern vom Team selbst angezogen und dann zu einem bestimmten Termin fertiggestellt. Als Vorlagen können hier die Verwendung von „User Story“ (http://c2.com/cgi/wiki?UserStory) oder „Minimum Marketable Feature“ (http://www.netobjectives.com/glossary/#term142) dienen.

 

Christian Dähn, Senior Consultant bei Opitz Consulting