AGILITY.X – Thesen zur agilen Softwareentwicklung

Die msg life blickt als Softwarehersteller für die Versicherungsbranche auf eine mehr als 40-jährige Historie des Kommens und Gehens verschiedener Ansätze der Softwareentwicklung (SWE) zurück. In dieser Zeit wurden viele Steinchen umgedreht. Da die traditionellen, an das Wasserfall- oder V-Modell angelehnten Ansätze an Grenzen gestoßen sind, wurden bereits früh agile Zwischentöne angeschlagen. Dieser Paradigmenwechsel durchzieht nicht nur die Softwarebranche, sondern die gesamte Versicherungswelt. In jedem Vorhaben stellt sich die gleiche Frage: Welches Vorgehen führt uns zum Erfolg – klassisch oder agil? 

Die Blog-Reihe AGILITY.X vereint Beiträge, die verschiedene Facetten von Agilität beleuchten. Methoden und Praktiken agiler Softwareentwicklung werden ebenso betrachtet wie Herausforderungen der agilen Transformation. Neben überblicksartigen Beiträgen stehen Blogs, die Einblicke in Change-Prozesse bei msg life geben oder Spannungsfelder wie das Schätzen und Planen in der agilen Welt thematisieren. Die Autor*innen begleiten in unterschiedlichen Rollen agile Transformationsprozesse bei msg life.

Die Geburtsstunde(n) der Agilität

In der Softwarebranche zeigten sich bereits Mitte der 1960er-Jahre erstmals krisenhafte Entwicklungen: Die Kosten der Software im Vergleich zur Hardware stiegen immer weiter an. Zugleich übten Softwarerentwickler*innen massive Kritik an den traditionellen Vorgehensmodellen, die ihnen wenig Freiraum für eigenverantwortliches Arbeiten und kreative Lösungen gaben. Spätestens seit den 1990er Jahren schärften neue Programmiersprachen und Methoden wie Objektorientierung, Extreme Programming und Feature Driven Development das Bewusstsein für geeignetere Vorgehensweisen. Dabei setzte sich die Einsicht durch, dass Softwareentwicklung (und andere Formen der Wissensarbeit) flexiblere Methoden braucht.

Parallel wurde in den USA ein Absinken der Wettbewerbsfähigkeit der klassischen Güterindustrie beobachtet, insbesondere im Vergleich zur „exzellenten“ japanischen Industrie. Als Ursachen wurden vor allem verkrustete hierarchische Strukturen, schwache Kundenorientierung und lange Produktentwicklungszeiten ausgemacht. Auch in diesem Bereich suchte man nach neuen Formen der Organisation von Produktentwicklungsarbeit. Die Organisationsforscher Ikujirō Nonaka und Hirotaka Takeuchi beflügelten mit ihren vergleichenden Analysen erfolgreicher Produktinnovationen maßgeblich die Erfolgsgeschichte der Agilität.

Thesen zur agilen Softwareentwicklung

Spätestens seit der Veröffentlichung des Manifesto for Agile Software Development im Jahr 2001 erfreut sich Agilität einer immer größeren Beliebtheit. Das Konzept prägt wissenschaftliche Diskurse über neue Formen der Organisation von Arbeit. In der Praxis bietet es sich leicht als Blaupause an, Projekte in time, budget und quality durchzuführen. Nebenwirkungen: Eine stärkere Identifikation mit der Arbeit, interdisziplinäre Arbeitsprozesse und ein intensiverer Kundenkontakt.

Neben all dem Spaß müssen auch die Zahlen stimmen! Aktuell ist die agile Vorgehensweise die effizienteste und bringt dem Auftraggeber den größten Nutzen. Allerdings ist sie – und dies ist der  Wermutstropfen – friktionsreicher als die Beratungsindustrie es Glauben macht. Die folgenden Thesen werfen Licht auf Brüche und Widersprüche, die sich in der Praxis zeigen. Sie sollen zum Weiterdenken anregen und ein Spektrum möglicher Diskussionsthemen aufzeigen.

These  1 – Agilität bedeutet keinesfalls einen Abschied, sondern eine neue Form von Hierarchie nach dem Muster von Schachteln-in-Schachteln!

Das Bild der chinesischen Schachteln oder russischen Matrjoschka-Puppen verwendet der Managementtheoretiker Dirk Baecker, um zu beschreiben, dass die neue Hierarchie nicht mehr zwischen oben und unten wirkt, sondern zwischen innen und außen. Die Pointe ist: Nicht allein das Management formuliert Anforderungen an Qualität, Kosten und Zeit, sondern auch das Team im Zusammenspiel mit Kunden und anderen Stakeholdern. Die Definition und Moderation dessen, was unter einem Außen verstanden wird, ist die elementare Aufgabe der agilen Teams. Ihre Herausforderung ist es, Beschleunigung (Sprint) und Innehalten (Inspektion), Innenorientierung (SWE-Prozess) und Außenorientierung (Kundenwünsche) immer wieder in ein sinnvolles Verhältnis zu bringen. Es muss laufend neu ausgehandelt werden, wer oder was unter welchen  Gesichtspunkten  und  für  welche  Zeitspannen prioritär zu berücksichtigen ist und was daraus folgt. In diesem Setting tun Manager*innen gut daran, ihre Führungsansprüche zurückzunehmen und das fünfte agile Prinzip zu beherzigen: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.“

These 2 – Agilität bedeutet Selbstorganisation bei gleichzeitig enger Taktung und Verzahnung der Arbeit mit Erwartungen und Ansprüchen des Kunden

Mehr Durchorganisiertheit war nie und dennoch wird Agilität als Befreiung erlebt! Ein Beispiel: In agilen Frameworks wie Scrum wird Entwicklungsarbeit im Modus einer prozessualen und rhythmisch getakteten Bindung an externe Erwartungen selbständig gemanagt. Durch die Einbeziehung der Kundenperspektive und die cross-funktionale Wissensverbreiterung in agilen Teams (Silowissen ade!) verbessert sich das Verständnis der eigenen Arbeit und dies führt zu einer höheren Motivation. Agilität firmiert daher zurecht als mitarbeiterzentrierter Ansatz, der die Freude an der Arbeit steigert. Genau hier liegt die Hebelwirkung, um Qualität und Effizienz des SWE-Prozesses nachhaltig zu steigern. Erfolgreiche Softwareentwicklung erfordert aber nicht nur hochmotivierte Teams, die selbstorganisiert Entscheidungen treffen und lösungsorientiert denken. Es kommt auch darauf an, die Teams in ein adäquates organisationales Umfeld einzubetten. Nur dann wird Agilität den Nutzen bringen, den man sich verspricht.

These 3 – Agilität bedeutet unbekanntes Terrain – für den Kunden und die/den Softwareentwickler*in.

Das Credo lautet: Flexibilität, Transparenz und Kommunikation! Beide Seiten sind gleichermaßen gefordert. Der Kunde verzichtet auf das detaillierte Pflichtenheft, vorgegebene Planungsabläufe und kleinteilige Projektphasen. Er gibt (vermeintlich) einen Teil der Kontrolle ab und bekommt im Gegenzug einen nach außen geöffneten SWE-Prozess, den er mitgestalten kann. Genau hier liegt das Erfolgsgeheimnis: Früh und kontinuierlich – und nicht erst am Ende einer monatelangen Entwicklungsphase – wird dem Kunden funktionsfähige Software gezeigt und immer wieder gibt es Inspektionspunkte, um Erwartungen abzugleichen. An die Stelle detaillierter Pflichtenhefte tritt die Verantwortung der Softwareentwickler*innen, einen offenen Prozess mit dem Kunden zu steuern. Worauf sich alle Beteiligten also einlassen müssen: Flexibilität (Änderungen sind jederzeit, auch spät in der Entwicklung willkommen), Transparenz (Entwicklung wird zu einem offenen Prozess) und Kommunikation (verschiedene Stakeholder arbeiten eng zusammen).

Und wie geht es weiter?

Agilität avancierte bis heute zurecht zu einem der populärsten Konzepte, um mit hoher Dynamik, Unsicherheit und Komplexität umzugehen – nicht nur in der Softwarebranche. Es erhöht den Kundennutzen und die Qualität. Agile Frameworks sind in den meisten Unternehmen aber nicht in Reinform anzutreffen, drei Pfade zeichnen sich ab:

1. Die Gestaltung offener, agiler Entwicklungsprozesse steht häufig orthogonal zu hierarchischen Strukturen und planungsgetriebenen Aktivitäten. In diesem Spannungsfeld suchen und finden Unternehmen ihren eigenen agilen Weg.
2. Agilität ist nicht das einzige Modell. Viele Organisationen setzen Entwicklungsthemen mit unterschiedlichen Komplexitäts- und Unbekanntheitsgraden um. Dies führt zu einer friedlichen Koexistenz verschiedener Vorgehensmodelle. Neben agilen Frameworks werden dann häufig Spiralmodelle oder Hybride eingesetzt.
3. Wie bei jedem Ansatz wird sich auch Agilität weiterentwickeln. Einerseits durch Spezialisierung, aber auch durch Verallgemeinerung entstehen neue Ausprägungen agiler Modelle.

Dogmatiker sind hier fehl am Platze! Dort, wo die Rahmenbedingungen passen und Agilität das Framework der Wahl ist, ist es wichtig und richtig, dies in der unternehmensinternen Diskussion mit Nachdruck zu vertreten und durchzusetzen.  Gleichzeitig müssen wir aber für notwendige Weiterentwicklungen, Kombinationsmöglichkeiten und hybride Vorgehensweisen offen bleiben. Die Reise geht weiter – auch für die msg life.