Zwischen Selbstorganisation und Leitprinzipien

Um sich dem Begriff der Agilität zu nähern, lohnt ein Blick ins Wörterbuch. Hier begegnen einem Synonyme wie „Wendigkeit“ oder „Beweglichkeit“. Diese Verwendung des Begriffs hat auch zunehmend Einzug in die Arbeitswelt gefunden, wo Agilität gerne gleichbedeutend für Veränderungsbereitschaft, Flexibilität und Eigenverantwortung verwendet wird. Ganz ursprünglich kommt der Begriff jedoch aus der Systemtheorie und wurde dort schon in den 1950er Jahren geprägt. Mit dem sogenannten AGIL-Schema beschreibt der amerikanische Soziologe Talcott Parsons die Grundfunktionen, die zur Erhaltung eines jeden Systems notwendig sind: adaptation (Anpassung), goal attainment (Zielverfolgung), integration (Eingliederung) und latent pattern maintenance (Aufrechterhaltung). Die Anfangsbuchstaben der Grundfunktionen ergeben hierbei das Akronym AGIL.

In vielen Quellen wird dieses Konzept als Ursprung des Themas Agilität gesehen. Der Transfer dieser Begriffe auf eine Organisation fällt nicht schwer. Unter einer wendigen oder beweglichen Organisation kann man sich durchaus etwas vorstellen. Trotzdem gilt es zu differenzieren: Agilität ist nicht mit Chaos gleichzusetzen und bedeutet nicht, dass alle Beteiligten tun können, was sie wollen und wann sie es wollen. Es bedeutet auch nicht, dass die selbstorganisierten Teams ihre Arbeit ohne Führung und Planung durchführen oder auf Veränderung immer sofort reagieren, nur weil es möglich ist. Auch agile Organisationen, agiles Vorgehen und agile Methoden brauchen Rollen, Rituale und Regeln. Agilität wird in Bezug auf Organisationen als die Fähigkeit angesehen, in sich verändernden Umgebungen und komplexen Zusammenhängen schnell agieren und darauf reagieren zu können und gerade deswegen erfolgreich zu sein. Wie lassen sich daraus nun Handlungsempfehlungen und Methodiken für Vorhaben in der Verwaltung – konkret bei der Umsetzung von IT-Vorhaben – ableiten? Dazu lohnt sich ein Blick auf die Softwareentwicklung, eine der Keimzellen für agile Vorgehensmodelle.

Von der linearen zur iterativen Entwicklung

Schon die frühe Softwareentwicklung setzte phasengetriebene Projektmethoden ein, um Softwareentwicklungsprojekte umzusetzen, zum Beispiel das Wasserfallmodell oder das V-Modell mit jeweils aufeinanderfolgenden und in sich abgeschlossenen Phasen.

Änderungen im Projektverlauf haben hier den Effekt, dass die Phasen teilweise erneut durchlaufen werden müssen, was einen enormen Aufwand zur Folge haben kann. Zudem liegen der Einführungstermin oder geplante Releases meist in ferner Zukunft, sodass die Planung mitunter auch nur grob oder ungenau erfolgen kann, und Kunden erst sehr spät ihr Produkt kennenlernen und Anpassungen anregen können. Als Antwort auf diese Probleme haben sich ab den 1990er Jahren entsprechende Ansätze herausgebildet, um Softwareentwicklung leichtgewichtiger umzusetzen, indem schrittweise (inkrementell) und sich dabei wiederholend (iterativ) vorgegangen wird.

Mehr als nur Methodik

Um ein gemeinsames Verständnis dafür zu schaffen, was Agilität in der Softwareentwicklung bedeutet, hat eine Gruppe von 17 Softwareentwicklern 2001 ein Manifest für die agile Softwareentwicklung veröffentlicht (Manifesto for Agile Software Development). Es besteht aus vier grundlegenden Leitsätzen. Diese lauten:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als umfassende Dokumentationen.
3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Daraus leiten sich zwölf Prinzipien ab, die die Leitsätze konkretisieren und die Vorgehensweise genauer definieren. Sie räumen beispielsweise der Auslieferung von funktionierender sowie einwandfreier Software höchste Priorität ein, betonen die Veränderungsbereitschaft als Wettbewerbsvorteil, legen ein Hauptaugenmerk auf die (persönliche) Zusammenarbeit und den regelmäßigen Austausch in selbstorganisierten Teams oder empfehlen eine regelmäßige Reflexion des bisher Erreichten, um ggf. Anpassungen vorzunehmen. Agilität ist vielmehr als „Mindset“ zu verstehen, als Einstellung bzw. Haltung, in deren Fokus die Menschen und ihre Interaktion genauso wie das zu liefernde Produkt und die Kundenzufriedenheit stehen.

Von Rollen und Werkzeugen: agile Methoden

Aus diesen Leitsätzen und Prinzipien lässt sich eine Menge agiler Methoden ableiten. Anfang der 2000-er Jahre haben sich in der agilen Softwareentwicklung vor allem Scrum, Rapid Application Development oder Extreme Programming etabliert. Jede dieser agilen Methoden baut auf die vier Leitsätze, legt sie aber mitunter unterschiedlich aus. Zu den gängigen agilen Praktiken gehören dabei besondere

• Meeting-Formate
• selbstorganisierte Teams
• wertschätzender Umgang ohne Hierarchien im Team
• regelmäßige Feedbackschleifen
• inkrementeller, iterativer Entwicklungsfortschritt
• ein ständig aktuelles, auslieferbares Produkt (Continuous Integration / Continuous Delivery)
• enge Einbeziehung des Kunden
• frühe und regelmäßige Lieferungen an den Kunden

Die aktuell verbreitetste agile Projektvorgehensmethode ist Scrum. Diese gibt einen definierten Rahmen für die agile Durchführung von Projekten vor, indem bestimmte Rollen, Meetings und Werkzeuge festgelegt werden – basierend auf agilen Prinzipien. Das Scrum-Framework ist dabei nicht verbindlich, sondern bietet lediglich Orientierungspunkte für die Zusammenarbeit. Es fordert also viel Disziplin, Ehrlichkeit, Offenheit, Selbstkritik und Eigenverantwortung ein. Die eigentliche Arbeit erfolgt dabei in Sprints: Durch sich wiederholende Abfolgen von Sprints (Iteration) wird sich dem finalen Produkt schrittweise und aufeinander aufbauend genähert (Inkrement). Gerade in den ersten Sprints kann es hilfreich sein, angeleitet zu werden, sich an die Rollen, Rituale und Regeln zu halten, die natürlich anpassbar sind. Besonders zu Beginn agiler Entwicklungs- aber auch Transformationsprozesse kann ein erfahrener Agile Coach mit einer neutralen Sicht unterstützen, um die Arbeitsweise und Kultur der Organisation zu verändern. Ein entscheidendes Tool aller agilen Methoden ist die Retrospektive. Damit können Personen, Teams und Stakeholder ehrlich beurteilen, ob der agile Prozess erfolgreich abläuft oder was verbessert werden kann. Jede Meinung ist wichtig, keine falsch. Fehler sollten nicht verschwiegen werden, denn dies ist Teil des agilen Lernprozesses, und nur dadurch kann die gewollte Verbesserung erreicht werden.

Agilität in der HZD

Auch in der HZD – und hier an vorderster Stelle in der Softwareentwicklung – finden agile und hybride Methoden seit Jahren Anwendung. Prominente Beispiele dafür sind die Entwicklung des Spielersperrsystems OASIS, des Betriebsportals KONSENS oder auch die Entwicklung des Produktes e2P (elektronisches Postein- und Postausgangsmanagement) bei der Umsetzung des elektronischen Rechtsverkehrs. Auch die Entwicklung eines Prototyps für den neuen ITSM-Arbeitsplatz im Incident Management hat die HZD mit Unterstützung eines Agile Coaches umgesetzt. Neben der Software- und Produktentwicklung eignen sich agile Vorgehensweisen aber auch für komplexe Infrastrukturprojekte, weshalb sich die HZD beispielsweise bei der Migration des Rechenzentrums von 2014 bis 2019 an agilen Vorgehensweisen orientiert und das Test Center Hessen mithilfe dieser Methodik aufgebaut hat.

Die Erfahrungen aus diesen Projekten fließen aktuell in das derzeit strategisch wichtigste Programm der HZD zur Cloud-Transformation ein, das agil umgesetzt und – erstmals in der HZD – nach dem anerkannten Steuerungsmodell SAFe® geführt wird. Der Durchführung von Projekten nach agilen Methoden sind im Umfeld der öffentlichen Verwaltung jedoch Grenzen gesetzt, denn üblicherweise wollen die Auftraggebenden im Vorfeld bereits möglichst genau wissen, welche Kosten sie zu erwarten haben und zu welchem Termin das Produkt fertiggestellt sein wird. Oftmals ist der Fertigstellungszeitpunkt sogar fest vorgegeben. Dies führt zu einer umfassenden Projektplanung weit in die Zukunft hinein, obwohl dies nicht im Sinne einer agilen Vorgehensweise ist. Nicht selten sind Auftraggebende in der Linienaufgabe ihrer Fachbereiche so eingespannt, dass sie die Rolle des Product Owners – eine zentrale Vollzeit-Rolle – nicht oder zumindest nicht in vollem Umfang wahrnehmen können. Um dennoch von agilen Methoden zu profitieren, wird in den meisten Fällen eine hybride Vorgehensweise gewählt. In den meisten Fällen werden hierbei vor allem in der Umsetzungsphase ein inkrementell-iteratives Vorgehen und einige agile Prinzipien genutzt.

Transformation von Organisationen und Zusammenarbeit

Agile Ansätze lassen sich ebenso gut auf Transformationsprozesse übertragen, wie sie die HZD in den nächsten Jahren mit der Entwicklung hin zum Cloud-Service-Provider des Landes durchleben wird. Die Klammer bildet das Programm Cloud-Transformation, welches Agilität zu seinem Handlungsprinzip macht. Derart umfangreiche Wandlungsprozesse verändern auch das Verständnis von Organisationen selbst und betreffen ebenso die Zusammenarbeit in Teams im Allgemeinen wie auch das Führen von Mitarbeitenden im Besonderen. Bei einem IT-Partner wie der HZD, der Produkte und Verfahren für und mit seinen Kunden in agilen Prozessen entwickelt, hat das aber auch Auswirkungen über die Grenzen der eigenen Organisation hinaus: Ganz nach dem Leitsatz „Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen“ wird die Mitarbeit der Kunden in jedem agilen IT-Projekt für die gesamte Projektlaufzeit benötigt. Die reine Auftragsvergabe reicht nicht aus. Die gewählte Methodik muss gemeinsam besprochen werden und ein regelmäßiger Austausch mit zentralen Instanzen wie Product Owner und Scrum Master gewährleistet sein, um möglichst schnelle Teilergebnisse im Sprint zu erarbeiten, die wiederum getestet werden müssen.

Autoren des Beitrags

Matthias Guckler
Bereichsleiter Anwendungsentwicklung bei der HZD

Adam Miosga
Abteilungsarchitekt für Verfahren der Justiz bei der HZD