Agile Teams als ultimative Problemlösung?
Aktuell finden sich am Markt zahlreiche Beispiele, in denen sich Versicherer mit der Frage beschäftigen, wie sie ihre Organisation kundenorientierter und anpassungsfähiger – sprich agiler – aufstellen können. Als Lösungsansatz wird in Medienberichten und Diskussionen häufig die Etablierung interdisziplinärer Teams aus Fachbereichen und IT – oft nach dem „Spotify-Modell“ – genannt, die durch agile Prozesse in die Lage versetzt werden sollen, Anforderungen schneller und zielgerichteter als bisher umzusetzen. Auch wenn es sich bei solchen Umstrukturierungen um große kulturelle Veränderungsprozesse handelt, sind interdisziplinäre Teams und agile Methoden nur ein Teil der Lösung und für sich genommen nicht der Weisheit letzter Schluss. Vielmehr müssen sich Versicherer auch mit angrenzenden Fragen zu Prozessen und Technologien auseinandersetzen, um einen nachhaltigen Mehrwert aus einer agilen Organisationsstruktur zu ziehen. Andernfalls besteht die Gefahr, die gesteckten Ziele zu verfehlen und Frustration und Resignation in der Organisation zu erzeugen. Um die Zusammenhänge besser zu verstehen, lohnt sich daher ein kurzer Blick in die Geschichte.
Ein kurzer Blick zurück
Blickt man in die Geschichte zurück, so hat Agilität ihren Ursprung bereits in den 1970er Jahren, als das evolutionäre Projektmanagement und die adaptive Softwareentwicklung aufkamen. Der große Durchbruch gelang jedoch erst in den 1990er Jahren mit dem Aufkommen von Scrum [1] und Extreme Programming [2]. Aus den Erkenntnissen der Systemtheorie heraus ist Scrum für die Bedürfnisse der Softwareentwicklung entstanden und 2001 in Form des agilen Manifests festgeschrieben. In seinen Ursprüngen ist Scrum relativ offen gehalten und definiert lediglich vier zentrale Werte und zwölf abgeleitete Prinzipien für „better ways to develop software“ [3]. Die individuelle Interpretation und Ausgestaltung dieser Werte und Prinzipien oblag und obliegt(!) jedoch den anwendenden Teams – insbesondere in der Anfangszeit von Scrum wurden jedoch über regelmäßige Anwendertreffen Best Practices ausgetauscht und anschließend veröffentlicht [4]. Einen Großteil dieser Best Practices werdend dabei auch heute noch intensiv genutzt.
Betrachtet man verschiedene Fallstudien aus den Anfängen der Scrum-Bewegung, so zeigt sich, dass die konsequente Anwendung agiler Methoden gerade zu Beginn die Anwender vor große Herausforderungen stellte [5]. So sahen sich die Anwender – wie heute die Versicherer – häufig mit monolithischen Architekturen konfrontiert, die die Umsetzung autonomer und selbstorganisierter Teams (Agiles Manifest, Prinzip 11) erschwerten, da selbst kleine Anpassungen mit hohem Abstimmungsaufwand zwischen den Teams verbunden waren. Zudem waren die Werkzeuge im Rahmen des Softwareentwicklungsprozesses häufig noch stark durch manuelle Tätigkeiten und viele Übergaben zwischen verschiedenen Teams geprägt, was die Auslieferung lauffähiger Software in Zyklen von wenigen Wochen erheblich erschwerte (Agiles Manifest, Prinzip 3). Die Unternehmen im Silicon Valley hatten also bis mindestens Mitte der 2000er Jahre ähnliche Probleme, wie wir sie heute in der Versicherungsbranche beobachten können.
Die Herausforderungen erkennend, kam es jedoch Mitte bis Ende der 2000er Jahre zu einem regelrechten Boom in der Entwicklung verwandter Methoden und Werkzeuge der Softwareentwicklung (siehe Abb. 1). Dies betrifft zum einen die Weiterentwicklung von Continuous Integration (1994) zu Continuous Delivery (2006) [6] sowie das Aufkommen von Infrastructure as Code (2009) [7]. Diese Entwicklungen hatten auch einen wesentlichen Einfluss auf die Entstehung sowie die hohe Popularität von DevOps (2009) [8]. Denn auch wenn die Konzepte Scrum und DevOps prinzipiell eigenständig eingesetzt werden können, trägt ihre Kombination wesentlich dazu bei, dem Prinzip der Auslieferung kleiner, lauffähiger Software-Inkremente in wöchentlichen Zyklen gerecht zu werden. Ohne hohe Automatisierungsgrade sind die mit Deployments verbundenen Einmalkosten (wie z.B. übergreifende Tests) schlichtweg zu hoch und rechtfertigen damit kürzere Zyklen wirtschaftlich nicht.
Abbildung 1: Zeitliche Entwicklung
Parallel zu den beschriebenen Entwicklungen haben sich in den 2000er Jahren auch die Systemarchitekturen deutlich verändert. Die vorherrschenden monolithischen Architekturen wurden zunehmend durch modulare Architekturen abgelöst. Dazu trug auch die technologische Entwicklung im Web bei, denn mit der Verbreitung von SOAP (1999) [9] begannen die Unternehmen, sich mehr und mehr in Richtung serviceorientiertere Architekturen zu bewegen. Anfang der 2010er Jahre hat dieses Architekturprinzip unter dem Begriff Microservices (2012) [10] nochmals deutlich an Popularität gewonnen und sich in vielen amerikanischen Technologieunternehmen als dominierendes Architekturprinzip etabliert. Durch diese Entwicklungen – weg von großen komplexen Systemen hin zu Dutzenden einfachen Services – konnte die technologische Komplexität in den Unternehmen deutlich reduziert werden. Ein Aspekt, mit dem sich derzeit auch viele Versicherer beschäftigen. Dieser serviceorientierte Schnitt ermöglicht es einem Scrum-Team, die volle Verantwortung für genau einen gekapselten Service zu übernehmen und diesen eigenständig weiterzuentwickeln. Dem Prinzip der selbstorganisierenden Teams sowie dem Prinzip der Einfachheit konnte somit ebenfalls deutlich besser entsprochen werden.
Agilität als ganzheitliches Betriebsmodell verstehen!
Der Blick zurück macht deutlich: Spätestens mit dem Aufkommen von Scrum haben sich seit den 2000er Jahren viele Unternehmen mit dem Einsatz agiler Entwicklungsmethoden beschäftigt. Dabei haben sie jedoch schnell erkannt, dass sich der volle Wert der Methoden nur dann entfalten kann, wenn das gesamte (IT-)Betriebsmodell auf den agilen Softwareentwicklungsprozess ausgerichtet wird. (IT-)Betriebsmodell bedeutet in diesem Zusammenhang nicht nur die Anpassung des grundsätzlichen Vorgehensmodells und die Strukturierung der Mitarbeitenden in interdisziplinäre Teams, sondern insbesondere auch die Einführung neuer Werkzeuge wie Continuous Deployment und die zunehmende Entkopplung der IT-Architektur. Damit rückt der Softwareentwicklungsprozess zunehmend in den Mittelpunkt der Aktivitäten der Unternehmen, die sich nicht zuletzt durch diese starke Fokussierung zu agilen Technologieunternehmen weiterentwickelt haben.
Viele Unternehmen, die sich frühzeitig mit agilen Methoden auseinandergesetzt haben, haben im Laufe der Zeit ihr ganz individuelles (IT-)Betriebsmodell entwickelt und entlang von Best Practices weiterentwickelt. Viele dieser Best Practices erfreuen sich auch am Markt großer Beliebtheit und wurden von anderen Unternehmen adaptiert und teilweise wiederum weiterentwickelt. So ist in den letzten Jahren ein großer Werkzeugkasten entstanden, aus dem sich Unternehmen bedienen können, um ihre Organisation – nicht zuletzt durch den Einsatz von neuen Technologien – insgesamt flexibler und anpassungsfähiger zu gestalten. Dies ist auch ein wesentlicher Grund, warum es nicht „das“ agile Vorgehen gibt. Die ursprünglichen – teilweise auch sehr unkonkreten Ideen – wurden zwischenzeitlich vielfach weiterentwickelt und an den individuellen Kontext der Unternehmen angepasst.
Zur Orientierung haben sich in den letzten Jahren allerdings Frameworks entwickelt, die viele der notwendigen Elemente aufgreifen und in einem integrierten Ansatz zusammenführen. Als Beispiel sei hier das Scaled Agile Framework (SAFe) genannt, das seit 2011 kontinuierlich weiterentwickelt wird und mittlerweile in vielen globalen Unternehmen zur Skalierung agiler Aktivitäten zum Einsatz kommt [11]. SAFe definiert dabei nicht nur die Zusammenarbeit und Koordination innerhalb einzelner Teams, sondern umfasst auch Methoden und Vorgehensweisen, um übergreifende Steuerungsmechanismen (z.B. Anforderungsmanagement, Portfoliomanagement, Architekturmanagement) zu implementieren. Auch wenn diese Steuerungsmechanismen in einer perfekten Welt (autonome, selbstorganisierte Teams, die sich um gekapselte Services kümmern) nicht notwendig wären, sieht die Realität – in der Versicherungswirtschaft, aber auch in vielen anderen Branchen – oft (noch) anders aus und erfordert daher die Steuerung genau dieser Abhängigkeiten.
Einem einfachen Überstülpen von Frameworks ist allerdings mit Skepsis zu begegnen – so auch bei SAFe. Einerseits enthalten die Frameworks teilweise Lücken, welche durch die Unternehmen geschlossen werden müssen. So geht SAFe aktuell u.a. nicht auf die disziplinarische Führung von Mitarbeitenden und deren Weiterentwicklung ein. Andererseits bleiben oft unternehmensspezifische Besonderheiten unberücksichtigt. Dennoch bietet SAFe verschiedene Ansätze, die an den eigenen Unternehmenskontext angepasst werden können. Wichtig ist jedoch auch hier, jeweils die ganzheitliche Perspektive über die verschiedenen Ebenen Organisation, Mitarbeitende, Prozesse und Technologie sicherzustellen und bereit zu sein, dem Softwareentwicklungsprozess – dem eigentlichen Auslöser der agilen Überlegungen – einen entsprechend hohen Stellenwert im Unternehmen einzuräumen. Überspitzt gesagt: Bestehende Projekte einfach in Agile Release Train umzubenennen und ein vierteljährliches Abstimmungsmeeting PI Planning zu nennen, bringt ein Unternehmen einer agilen Organisationsaufstellung nicht wirklich näher. In solchen Fällen handelt es sich eher um etwas Lametta, dass den wahren Zustand der IT-Arbeit kaschieren soll – in der Regel erfolglos.
Versicherer auf dem Weg zum Technologieunternehmen?
Was bedeutet dies nun für die Versicherungsbranche? Versicherer sollten sich im ersten Schritt fragen, warum sie ihre Arbeitsweise überhaupt in Richtung agiler Vorgehensweisen anpassen wollen. Denn je nach konkreter Zielsetzung können unterschiedliche Formen agiler Strukturen sinnvoll sein. Von einzelnen, spezifischen agilen Projekten bis hin zu einer agilen Organisationsstruktur. Dabei ist jedoch zu beachten, dass in den meisten Fällen insbesondere die am Softwareentwicklungsprozess beteiligten Einheiten im Fokus stehen und in Solutions (oder ähnlichen Konstrukten) gebündelt werden. Außendienst, Operations und Competence Center wie z.B. Recht oder Finanzen können zwar als Product Owner oder Experten in agile Organisationsstrukturen eingebunden werden, erledigen ihre Regeltätigkeiten aber weiterhin eher in klassischen Strukturen (siehe Abb. 2). Aber auch in diesen Bereichen gibt es interessante Entwicklungen für die Weiterentwicklung der jeweiligen Organisation, die hier jedoch nicht im Mittelpunkt stehen sollen.
Abbildung 2: Relevante Organisationseinheiten
Unabhängig von der konkreten Ausgestaltung gilt jedoch auch für Versicherer, das Thema Agilität ganzheitlich zu betrachten – von agilen Teams über automatisierte Entwicklungsprozesse bis hin zu gekapselten IT-Architekturen. Dabei ist es unerheblich, ob Versicherer auf Basis der am Markt verfügbaren Tools ein eigenes Framework bzw. (IT-)Betriebsmodell definieren oder auf etablierte Frameworks wie SAFe, LeSS oder Nexus zurückgreifen und diese unternehmensspezifisch anpassen [12]. Ein Blick auf die aktuellen Top-Themen der Versicherungsbranche zeigt, dass diese Notwendigkeit auch grundsätzlich erkannt wurde [13]. Insbesondere das Thema Agilität, dass auf der Prioritätenliste sehr weit oben steht wird, wie eingangs erwähnt, breit diskutiert und in Teilen bereits eingeführt bzw. aktiv praktiziert. Auch die Umsetzung von DevOps sowie die Standardisierung und Weiterentwicklung der IT-Architektur in Richtung Microservices werden von den Versicherern als wesentliche Digitalisierungsthemen genannt [14]. Die Erfahrung zeigt jedoch, dass die Themen (noch) zu häufig isoliert und an unterschiedlichen Stellen und Ebenen im Unternehmen betrachtet werden. Dies führt dann in der Regel zu einzelnen (Teil-)Zielbildern, die Lücken und Inkompatibilitäten zueinander aufweisen. Organisatorische und technische Fragestellungen müssen daher unbedingt ganzheitlich betrachtet werden. Es bedarf also einer engen Zusammenarbeit der verschiedenen Unternehmensbereiche, um ein gemeinsames, kohärentes Zielbild für die Zukunft zu entwickeln.
Wie und wo starten?
Viele Versicherer befinden sich bereits in der Umsetzung agiler Organisationsformen. Dabei sind derzeit unterschiedliche Vorgehensweisen im Markt zu beobachten. Die einen starten bottom-up mit der Definition einzelner agiler Piloten. Auf diese Weise können sich die Mitarbeitenden mit agilen Arbeitsweisen vertraut machen und sich sukzessive einer für sie passenden Ausgestaltung annähern. Sind diese Grundlagen gelegt, erfolgt die Ausweitung auf weitere Teams und die Skalierung über verschiedene Ebenen mit übergreifender Steuerung [15]. Andere Unternehmen gehen die Transformation top-down an und erarbeiten zu Beginn ein ganzheitliches Zielbild, entlang dessen dann die Umsetzung der Transformation erfolgt. Aber auch in diesem Fall sind in der Regel Piloten vorgesehen, um das Zielbild iterativ zu schärfen. Beide Ansätze haben sich bisher in der Praxis bewährt und sind mit spezifischen Vor- und Nachteilen verbunden – letztlich muss jedes Unternehmen individuell abwägen, welcher Ansatz für die eigene Organisation am besten geeignet ist.
Ob bottom-up oder top-down: Die Erarbeitung eines Zielbildes ist oft sehr anspruchsvoll, da das Zielbild weitreichende Auswirkungen auf die gesamte Organisation hat und – wie bereits mehrfach erwähnt – sowohl organisatorische, prozessuale als auch technische Aspekte abdecken muss. Aus diesem Grund ist es notwendig, verschiedene Expertinnen und Experten mit unterschiedlichen Kompetenzen in die Entwicklung einzubeziehen. Diese Expertinnen und Experten sollten zudem schon viel außerhalb der eigenen Organisation gesehen haben, um neue Impulse für das Zielbild zu geben und zu verhindern, dass zu sehr am Bestehenden festgehalten („Das haben wir doch schon immer so gemacht!“) und damit die Transformation gefährdet wird. Um eine breite Akzeptanz in der Organisation zu erreichen, müssen zudem „Fans“ in den Erarbeitungsprozess eingebunden werden, damit sie im Rahmen der Umsetzung als Multiplikatoren fungieren können. Denn letztlich bleibt die Entwicklung hin zu einer agilen Organisationsaufstellung – trotz aller oben genannten technischen Komponenten – eine große organisatorische und kulturelle Transformation, die den Mitarbeitenden neue Werte und Arbeitsweisen abverlangt. Es braucht daher auch das viel zitierte Commitment des Top-Managements, um alle Mitarbeitenden hinter dem Zielbild zu versammeln. Dies ist die wesentliche Grundvoraussetzung für das Gelingen des Veränderungsprozesses.
Ist das Zielbild formuliert, beginnt die eigentliche Arbeit. Das Zielbild muss Schritt für Schritt im Unternehmen etabliert und von den Mitarbeitenden im Arbeitsalltag gelebt werden. Dabei handelt es sich um einen langfristigen Kulturwandel in der Organisation, der sukzessive und behutsam erfolgen muss. Auch die notwendigen prozessualen und technischen Veränderungen sind in der Regel keine Quick Wins und werden entsprechend Zeit in Anspruch nehmen. Gerade in dieser Phase hilft jedoch das Zielbild weiter, auf dessen Basis ein schrittweiser Transformationspfad abgeleitet und mit weiteren Vorhaben synchronisiert werden kann. So ist es beispielsweise häufig ein erfolgreiches Muster, agile Teamstrukturen und moderne Softwareentwicklungspraktiken im Rahmen großer Erneuerungsprojekte aufzubauen und nach Projektabschluss in die Linienorganisation zu überführen. Auch wenn dadurch die Komplexität der Projekte weiter zunimmt, gelingt es auf diese Weise häufig, die notwendige Dynamik zu erzeugen. Umgekehrt besteht jedoch die Gefahr, dass ein Scheitern des Projektes unmittelbar auf die neue Organisationsstruktur und Arbeitsweise zurückfällt.
Abschließend lässt sich festhalten, dass es nicht „das“ agile Vorgehen gibt. Vielmehr sind aus den ursprünglichen Ideen mittlerweile eine Vielzahl an unterschiedlichen Ausprägungen entstanden. Die erfolgreichen Umsetzungen in Unternehmen eint jedoch eins: Sie gehen weit über die Zusammenstellung interdisziplinärer Teams und integrierter Arbeitsweisen hinaus. Vielmehr bedarf es einer ganzheitlichen Betrachtung entlang des Softwareentwicklungsprozesses, um durch neue Arbeitsweisen, die Befähigung der Mitarbeitenden sowie automatisierte Prozesse und Tools tatsächlich kundenorientierter und flexibler agieren zu können. Nachdem auch in der Versicherungsbranche gelegentlich damit kokettiert wurde, dass sich die Häuser zu modernen Technologieunternehmen à la Silicon Valley entwickeln müssen, wird sich im Rahmen der Transformation die Spreu vom Weizen trennen: Einerseits in Unternehmen, die im Rahmen ihrer Transformation eher an der Oberfläche kratzen und andererseits in Unternehmen, die stattdessen die Transformation als ganzheitliche Chance (und Herausforderung) wahrnehmen und neben den kulturellen auch die prozessualen und technischen Aspekte umfassend einbeziehen. Ich bin davon überzeugt, dass der zweite Weg für die Unternehmen zwar deutlich(!) anspruchsvoller ist, sich aber langfristig auszahlen wird.
Anmerkungen
[1] K. Schwaber (1995): SCRUM Development Process präsentiert auf OOPSLA Konferenz; in dem Beitrag ist dabei von beispielsweise Product Owner, Scrum Master, Retrospective oder Definition of Done noch keine Rede. Diese Begriffe sind alle erst im Zeitverlauf entstanden und dazugekommen.
[2] Extreme Programming wurde von K. Beck, W. Cunningham und R. Jeffries während ihrer gemeinsamen Arbeit am C3-Projekt bei Chrysler entwickelt; Veröffentlichung der Ergebnisse K. Beck (1999): Extreme Programming Explained.
[3] Einleitende Worte des agilen Manifests: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”
[4] K. Schwaber (2002): Agile Software Development with Scrum; K. Schwaber (2004): Agile Project Management with Scrum;K. Schwaber (2007): The Enterprise and Scrum.
[5] Beispielsweise J. Sutherland (2005): Future of Scrum: Parallel Pipelining of Sprints in Complex Projects; O. Salo; P. Abrahamsson (2005): Integrating Agile Software Development and Software Process Improvement: A Longitudinal Case Study.
[6] Erste Nennung von Continuous Integration durch G. Booch (1994): Object-Oriented Analysis and Design with Applications; Vorstellung von Continuous Delivery durch J. Humble & D. Farley (2006): The deployment production line auf der AGILE 2006.
[7] A. Shafer (2009): Agile Infrastructure präsentiert auf Velocity Konferenz; Etablierung des Begriffs Infrastructure as Code durch L. Kanies & A. Jacob (2010): Infrastructure as code: Automation is essential to DevOps auf DevOps Day.
[8] J. Allspaw & P. Hammond (2009): 10 Deploys per Day: Dev and Ops Cooperation at Flickr auf Velocity-Konferenz.
[9] D. Winer und Microsoft entwickelten 1998 die Spezifikation für XML-RPC; als Weiterentwicklung daraus entstand SOAP, das 1999 veröffentlicht wurde.
[10] J. Lewis (2012): Micro Services – Java the Unix way präsentiert auf 33rd Degree in Kraków.
[11] Initiale Veröffentlichung durch D. Leffingwell in 2012; erste Vorstellung auf AGILE Konferenz 2012.
[12] Während LeSS und Nexus relativ schlank gehalten sind und den (ursprünglichen) Prinzipien von Scrum sicherlich am nächsten kommen, stoßen diese Frameworks bei größeren Organisationen schnell an ihre Grenzen. Nexus ist in seiner Basiskonfiguration auf bis zu neun Teams ausgelegt, während LeSS für bis zu acht Teams effektiv funktioniert. SAFe wiederum kann nach Praxisberichten mit bis zu etlichen hundert Mitarbeitenden umgehen, benötigt dafür aber auch weitreichendere Steuerungsmechanismen und kommt daher etwas mächtiger daher.
[13] Ergebnisse der GDV IT-Erhebung 2022, Schwerpunkte der Digitalisierung 2022.
[14] Viele Versicherer sind aktuell dabei ihre IT-Systeme zu erneuern und zunehmend auf Standardsoftware zu setzen. Dabei sind viele Lösungen – insbesondere die der großen Anbieter – jedoch im Moment architekturell nur bedingt (micro-)servicefähig. Es ist jedoch davon auszugehen, dass die Anbieter ihre Lösungen perspektivisch in Richtung einer höheren Servicefähigkeit weiterentwickeln werden.
[15] Aktuell gibt es diverse Diskussionen, welche auf die Nachteile von agilen Organisationsformen und insbesondere Skalierungs-Frameworks eingehen (allen voran SAFe). Dabei wird immer wieder darauf verwiesen, dass durch die Steuerung von Abhängigkeiten zusätzliche Abstimmungsmechanismen geschaffen werden, welche den agilen Grundsätzen widersprechen. Diesen Kritiken ist auch grundsätzlich wenig entgegenzusetzen, da sie berechtigte Punkte adressieren (die beste Skalierung ist, nicht zu skalieren). Oft vernachlässigen sie jedoch, mit welchen signifikanten finanziellen und zeitlichen Aufwänden die Entflechtung von gewachsenen IT-Strukturen verbunden ist. Daher sollten Skalierungsansätze eher als ergänzend angesehen werden: Die agile Skalierung zu nutzen, technische Abhängigkeiten in einem neuen Arbeitsmodus Stück für Stück zu reduzieren und damit einhergehend auch die Abstimmungsmechanismen Stück für Stück zurückzuschrauben.