Agile Produktentwicklung in echt

Agilität und Softwareentwicklung

Lexware, eine Marke der Haufe Group, bietet Software zur Buchführung, Gehaltsabrechnung und Warenwirtschaft für kleine und mittelständische Unternehmen. Eine Million Kunden nutzen diese Anwendungen. Sie erwarten neben einer hohen Anwenderfreundlichkeit, dass ihre Software immer den aktuellen technischen und gesetzlichen Vorgaben entspricht. Mehr als 200 Mitarbeiter unterschiedlicher Disziplinen arbeiten laufend an der Aktualität der Desktopsoftware, die über fünf bis sieben Releases pro Jahr sichergestellt wird.

Agilität ist kein Selbstzweck: Entscheidend für ein Gelingen sind ein überzeugendes Why und ein motivierendes Zielbild.

Warum agile Transformation?

Innerhalb der Portfolio-Strategie von Lexware leisten diese Produkte einen maßgeblichen Beitrag zur Profitabilität und damit zur Finanzierung von cloudbasierten Innovationen. Ziel ist es, unter Beibehaltung der Stabilität und Qualität der Software die Entwicklungskosten sukzessive zu reduzieren. Dies führt zu einer Reihe von Konsequenzen, die letztlich den Anstoß für eine Transformation gaben:

• Multitasking: Viele Mitarbeiter waren in mehreren Projektteams eingesetzt und konnten sich so nicht auf ein einzelnes Produkt fokussieren.
• Zunahme von Kopfmonopolen: Insbesondere für die komplexen Berechnungsregeln und -kerne kam es zu Konstellationen, in denen nur noch einzelne Entwickler in der Lage waren, den Code zu aktualisieren.
• Zunahme der technischen Schulden: mit der Fokussierung auf die Umsetzung von gesetzlichen Vorgaben gerieten stellenweise Wartungen am Bestandscode ins Hintertreffen.
• Demotivation und Fluktuation: Viele Mitarbeiter waren frustriert, weil sie ihren Anspruch an innovative Arbeit nicht umsetzen konnten.

Fünf Leitfragen der Transformation

Um diese Problemfelder anzugehen, haben wir einen Transformationsprozess angestoßen, der sich an fünf zentralen Leitlinien orientierte, die sich über die letzten zwei Jahre herauskristallisiert haben:

Das „Why“ und die Vision

Eine agile Transformation ist kein Selbstzweck, sondern Mittel zum Zweck –  Motivation und Treiber für die Transformation müssen klar beschrieben und einsichtig sein. Bei Lexware waren es die oben beschriebenen Problemfelder, die aktiv angegangen werden sollten. Ebenso wichtig war uns die Formulierung eines attraktiven, glaubwürdigen und erreichbaren Zielbilds, das uns Orientierung gab und dabei half, uns auf eine gemeinsame Richtung zu verständigen.

Schon der Prozess hin zur agilen Organisation war agil.

Weg und Ziel müssen konsistent sein

Die Transformation einer klassischen, auf „command & control“ basierenden Organisation in ein agiles, selbstorganisiertes Cluster kann nicht Top-Down erfolgen. Dies wäre ein Verrat an den Idealen, Werten und der Motivation, die hinter der Transformation stehen. Für Lexware bedeutete das, dass auch der Prozess hin zu einer agilen Organisation bereits agil war – konkret bestand er aus vierwöchigen Iterationen, innerhalb derer Experimente durchgeführt wurden. Diese wurden dann in Overall-Retros vorgestellt und in Entscheidungen überführt.

„Führen“ zur „Selbstverantwortung“ – Umgang mit dem Paradoxon

Ziel einer agilen Transformation ist ein Zustand, in dem Teams autonom und selbstorganisiert zusammenarbeiten. Dies setzt voraus, dass die Mitarbeiter dieser Teams dies gelernt haben – und das wiederum erfordert eine hohe Sensibilität und Aufmerksamkeit bei der Frage, wie viel Selbstorganisation man wann zulässt und wie viel an Einmischung, Gestaltung oder Impulsen zielführend sind. Wir haben bei unserer Transformation in beiden Extremen (zu viel Freiheitsgrade und zu starke Eingriffe) Erfahrungen gesammelt – und hatten einen Durchbruch, als wir gemeinsam eine „Geschäftsordnung“ erarbeitet haben, die regelt, wie Experimente aufgesetzt und wie Entscheidungen getroffen werden.

Zwischen Euphorie und Widerstand – wie umgehen damit?

In einer Gruppe von 200 Mitarbeitern ist das gesamte Spektrum an Zustimmung und Ablehnung vertreten – auf der einen Seite diejenigen, denen es nicht schnell und radikal genug geht, auf der andren Seite die Blockierer und die Low Performer, die nicht wollen oder nicht können. Uns war es wichtig, auf alle bestmöglich einzugehen, aber auch vor unbequemen Konsequenzen nicht zurückzuschrecken. Die Gruppe der Treiber haben wir bestmöglich einbezogen und sie aktiven Gestaltern der Transformation gemacht. Ein besseres Verständnis der Motive von Blockierern – Angst vor Bedeutungsverlust oder einer Sonderrolle – hat uns geholfen, sie abzuholen und zu integrieren. Uns war wichtig, einen Teil der Entscheidungskompetenz für den Umgang mit Low Performern auf die Teams zu übertragen und hier auch Prozesse zu moderieren, die zu klaren Entscheidungen pro oder contra Verbleib im Team geführt haben.

Entscheidend für den Erfolg: Keine Gräben zwischen "dem Management" und "den Mitarbeitern".

Die Rolle des Managements

Entscheidend für den Erfolg der Transformation war, dass die Manager der beteiligten Bereiche ein gemeinsames Verständnis dafür hatten und auch bereit waren, dies gegenüber der Geschäftsführung gemeinsam zu vertreten. In der konkreten Arbeit war uns wichtig, dass es keine Gräben zwischen „dem Management“ und „den Mitarbeitern“ gab, sondern dass wir uns auf Augenhöhe begegneten und Argumente zählte - nicht, von wem sie vorgebracht wurden. Bei anstehenden Entscheidungen hatten Führungskräfte das gleiche Stimmrecht wie jeder einzelne Mitarbeiter.

Scrum als Framework für alle

Viele Dinge wurden im Rahmen der Transformation verändert. Die tiefgreifendste Änderung war sicherlich die konsequente Einführung von Scrum als Framework für alle Teams und die damit verbundenen Strukturanpassungen: Weg von einer projektorientierten Matrixorganisation hin zu einem Cluster, wo für die einzelnen Areas jeweils ein Product Owner eingesetzt wurde, der von zwei und fünf DEV-Teams unterstützt wird – und den entsprechenden Scrum Mastern.

Mehr Effizienz und Perspektiven für die Mitarbeiter

Die angestrebten Ziele – Steigerung der Effizienz der Softwareentwicklung und Schaffen einer Perspektive für die betroffenen Mitarbeiter – konnten erreicht werden. Dies ging einher mit einer Steigerung der Qualität, die zu einer höheren Kundenzufriedenheit führte und dies wiederum zu einem Umsatz- und Ergebniswachstum. Erfreulich dabei ist, dass diese Effekte sich gegenseitig verstärkt haben, so dass damit eine gute Grundlage für die nächsten Schritte gelegt werden konnte.

Besonders ermutigend ist aus unserer Sicht, dass die Autonomie des Clusters und der einzelnen Teams stark gestiegen ist, sodass Management-Eingriffe, beispielsweise zur Priorisierung oder bei Notfällen, nicht mehr erforderlich sind.

Transformation ist nie zu Ende

Von Anfang an war uns klar, dass eine agile Transformation nicht ein Prozess vom Zustand A in den Zustand B sein kann, sondern dass ein solcher Transformationsprozess – ganz im Sinne des „Inspect & Adapt“ auf lange Sicht angelegt ist. Die nächsten Schritte haben die Reduzierung der technischen Abhängigkeiten zwischen den Produkten zum Ziel sowie die Möglichkeiten, auch im Desktop-Umfeld die Integration und Auslieferung von Software häufiger durchzuführen.

Autonomie der Cluster und der einzelnen Teams macht Eingriffe des Managements unnötig.

Wir sehen diese Transformation im Kontext des „Lernenden Unternehmens“, das bezüglich Struktur, Vorgehen, Haltung nicht auf einem Punkt stehenbleibt, sondern sich kontinuierlich weiterentwickelt. Zum Schluss drei Punkte zum Mitnehmen:

• Agilität ist kein Selbstzweck: Entscheidend für ein Gelingen sind ein überzeugendes Why und ein motivierendes Zielbild.
• Weg und Ziel müssen konsistent sein – ansonsten fehlen Glaubwürdigkeit und Lernfelder
• Eine Transformation braucht Zeit – diese sollte man sich nehmen und lassen, um möglichst viele der betroffenen Mitarbeiter auf diesem Weg auch mitnehmen zu können.