Wenn es auf Geschwindigkeit und Flexibilität ankommt Produkte, Projekte, Portfolios, Experimente – die agile Transformation der Haufe Group

Beim Software- und Medienanbieter Haufe Group gärte es: Multitasking, wachsender Overhead und Abhängigkeiten demotivierten viele Mitarbeiter. Der Ruf nach Veränderung wurde immer lauter, eine Initiative für eine agile Transition gründete sich – und hatte Erfolg: Aus ihr entstand das agile "Lexware-Cluster". Steffen Jakob und Michael Baur beschreiben ihr Vorgehen, die Erfolge aber auch die Probleme, vor die Sie die Disruption stellte.

Materialien
video

Management Summary

  • Wachsende Herausforderungen durch sich immer schneller verändernde Märkte, Kunden-Bedürfnisse und Rahmenbedingungen führten beim Software- und Medienanbieter Haufe Group zu dem Entschluss, die gewachsene Produktentwicklungslandschaft in eine agile Organisation zu überführen. Angestoßen und vorangetrieben wurde diese Veränderung von Mitarbeitern sämtlicher Hierarchieebenen.
  • Agile Selbstverantwortung kann nicht von oben vorgegeben werden, die Betroffenen müssen diese selbst wollen und mitgestalten. Es gilt also, eine Veränderung anzustoßen, dabei aber die Mitarbeiter mitzunehmen. Die gegründete Initiative löste diese Herausforderung, indem sie Impulse setze: Sie hob Denkverbote und andere Hemmnisse auf und ermutigte auch die anderen Mitarbeiter dazu.
  • Von Anfang an sammelten die Mitglieder der Initiative Erfahrungen im agilen Arbeiten, erstellten u.a. ein Backlog und führten Sprints durch, um die agile Transition vorzubereiten. Zur Orientierung erarbeiteten sie zudem frühzeitig ein Zielbild und eine Vision. Um alle betroffenen Mitarbeiter einzubeziehen, öffneten sie die Initiative nach fünf Monaten für alle über 200 Mitarbeiter.
  • Die Öffnung war die Geburt des "Lexware-Clusters" und der Startschuss für die Transition. Das Cluster entwickelt das Unternehmen seitdem weiter, u.a. indem es Herausforderungen über selbstorganisiert durchgeführte Experimente löst.
  • Der Transitionsprozess ist auf Dauer angelegt: Kontinuierliches, durch Experimente validiertes Lernen; kleine, aber durchgehende Veränderungen, die die Betroffenen selbst initiieren. Als mögliches Ziel-Szenario dient das Scrum-Skalierungsmodell "LeSS" bzw. "LeSS huge"; ein fest definierter Endzustand wird jedoch bewusst nicht angestrebt.

Wenn es auf Geschwindigkeit und Flexibilität ankommt Produkte, Projekte, Portfolios, Experimente – die agile Transformation der Haufe Group

Beim Software- und Medienanbieter Haufe Group gärte es: Multitasking, wachsender Overhead und Abhängigkeiten demotivierten viele Mitarbeiter. Der Ruf nach Veränderung wurde immer lauter, eine Initiative für eine agile Transition gründete sich – und hatte Erfolg: Aus ihr entstand das agile "Lexware-Cluster". Steffen Jakob und Michael Baur beschreiben ihr Vorgehen, die Erfolge aber auch die Probleme, vor die Sie die Disruption stellte.

Materialien
video

Management Summary

  • Wachsende Herausforderungen durch sich immer schneller verändernde Märkte, Kunden-Bedürfnisse und Rahmenbedingungen führten beim Software- und Medienanbieter Haufe Group zu dem Entschluss, die gewachsene Produktentwicklungslandschaft in eine agile Organisation zu überführen. Angestoßen und vorangetrieben wurde diese Veränderung von Mitarbeitern sämtlicher Hierarchieebenen.
  • Agile Selbstverantwortung kann nicht von oben vorgegeben werden, die Betroffenen müssen diese selbst wollen und mitgestalten. Es gilt also, eine Veränderung anzustoßen, dabei aber die Mitarbeiter mitzunehmen. Die gegründete Initiative löste diese Herausforderung, indem sie Impulse setze: Sie hob Denkverbote und andere Hemmnisse auf und ermutigte auch die anderen Mitarbeiter dazu.
  • Von Anfang an sammelten die Mitglieder der Initiative Erfahrungen im agilen Arbeiten, erstellten u.a. ein Backlog und führten Sprints durch, um die agile Transition vorzubereiten. Zur Orientierung erarbeiteten sie zudem frühzeitig ein Zielbild und eine Vision. Um alle betroffenen Mitarbeiter einzubeziehen, öffneten sie die Initiative nach fünf Monaten für alle über 200 Mitarbeiter.
  • Die Öffnung war die Geburt des "Lexware-Clusters" und der Startschuss für die Transition. Das Cluster entwickelt das Unternehmen seitdem weiter, u.a. indem es Herausforderungen über selbstorganisiert durchgeführte Experimente löst.
  • Der Transitionsprozess ist auf Dauer angelegt: Kontinuierliches, durch Experimente validiertes Lernen; kleine, aber durchgehende Veränderungen, die die Betroffenen selbst initiieren. Als mögliches Ziel-Szenario dient das Scrum-Skalierungsmodell "LeSS" bzw. "LeSS huge"; ein fest definierter Endzustand wird jedoch bewusst nicht angestrebt.

Seit der Einführung einer projektorientierten Organisation vor etwa fünf Jahren wenden wir in der Haufe Group in immer mehr Projekten agile Prinzipien an. Vor allem in der Entwicklung von Softwareprodukten setzen sich agile Arbeitsweisen inzwischen durch. Dies gilt insbesondere für Neuentwicklungen. Mittlerweile erfordern die sich immer schneller verändernden Märkte, Kunden-Bedürfnisse und Rahmenbedingungen jedoch auch bei dem Weiterentwickeln von Bestandsprodukten ein Umdenken, um flexibler auf die Veränderungen reagieren zu können. So können wir z.B. dank moderner Endgeräte und neuer Entwicklungstechnologien noch intuitiver bedienbare und intelligentere Konzepte zur Benutzerführung realisieren. Diese wiederum entwickeln sich rasch weiter und befeuern dadurch auch die Erwartungshaltung unserer Kunden. Zusätzlich verstärken der Gesetzgeber und die Behörden den Druck zur Veränderung, indem sie in immer kürzeren Zyklen zunehmend komplizierte Änderungen vornehmen, die wir in unseren Produkten umsetzen müssen.

Wir brauchen kurze Zyklen zur Produktentwicklung!

Immer häufiger machen wir die Erfahrung, dass komplexe Projekte, in deren Verlauf sich schnell und häufig Anforderungen ändern (z.B. aufgrund modifizierter Geschäftsmodelle, aktueller Rechtsprechungen, geänderter Schnittstellenspezifikationen usw.), im Wasserfallprinzip nicht mehr zielführend abgewickelt werden können. Die sequentielle Abarbeitung in hierarchisch organisierten, bereichsspezifischen Spezialisten-Teams, funktioniert in einfachen sowie in komplizierten und gut abschätzbaren Projekten nach wie vor gut, ist jedoch in einem komplexen und sehr dynamischen Umfeld nicht mehr ausreichend. Was fehlt ist vor allem die Möglichkeit, in kurzen Zyklen (von zwei bis vier Wochen) funktionsfähige und auslieferbare Teil-Ergebnisse zu erzielen, Feedback vom Kunden einzuholen, daraus zu lernen und schnell im Projekt zu adaptieren. Agile Arbeitsweisen fördern und fordern genau das.

Umfassender Kulturwandel als Voraussetzung

Die Transformation einer gewachsenen Produktentwicklungslandschaft in eine agile Organisation ist eine Herausforderung für alle Beteiligten, weil nicht nur Arbeitsprozesse und -strukturen, sondern vor allem Denkweisen, Werte und Haltungen sich ändern müssen. Dies gilt sowohl für alle Teammitglieder, als auch für die Manager und die Mitglieder der Geschäftsleitung. Diesen Weg beschreitet die Haufe Group derzeit auch im Bereich der Desktop-Software-Lösungen der Marke Lexware. Er wird nur dann erfolgreich sein, wenn alle Beteiligten im Unternehmen mithelfen und bereit sind, Gewohntes loszulassen, Neues zu wagen und Veränderungen zuzulassen. Dies betrifft die Art der Zusammenarbeit, die Wahrnehmung von Verantwortung, das Treffen von Entscheidungen, die Führung, die Unternehmenskultur und Vieles mehr.

Loslassen – Erfolgsfaktor und zugleich Stolperstein

Wir haben auf unserem bisherigen Weg gelernt, dass ein Erfolgsfaktor einer gelungenen Transition in ein agiles Cluster darin besteht, dass Manager und Geschäftsleitung "wohldosiert loslassen" und gemeinsam mit den Betroffenen an neuen Strukturen und Rahmenbedingungen arbeiten (dazu später mehr). Zudem braucht es mutige Mitstreiter aus der Belegschaft, die sich zutrauen Verantwortung zu übernehmen, Entscheidungen zu treffen und dabei auch Fehler zu machen.

Als ein wesentlicher Stolperstein hat sich bei uns vor allem der Umgang mit Fehlern erwiesen. Dies stellt einen von vielen Handlungsfeldern dar, wo wir als Projektmanager mit gutem Beispiel vorangehen und dazu beitragen können, dass die Transformation ein Erfolg wird. In unserer Rolle als Projektverantwortliche haben wir hierbei die Möglichkeit, das Team entscheiden zu lassen und ihm somit Vertrauen zu schenken. Bei einem Fehler dürfen wir dann keinesfalls nach den Schuldigen suchen und z.B. die Art der Korrektur vorgeben oder gar selbst vornehmen. Stattdessen sollten wir das Team dabei unterstützen, aus dem Fehler zu lernen und selbst eine Lösung zu entwickeln. Im bisherigen Verlauf unserer Transition kamen wir immer wieder an den Punkt, wo wir als Projektmanager sehr weiterhelfen können, ohne selbst steuernd einzugreifen (siehe dazu auch die Artikelserie "Was zeichnet eine positive Fehlerkultur aus?", ab Projekt Magazin 21/2015).

Die Haufe Group und die Lexware-Produkte

Die Haufe Group mit Hauptsitz in Freiburg im Breisgau hat weltweit insgesamt rund 1.800 Beschäftigte. Sie bietet ihren Kunden integrierte Arbeitsplatz- und Gesamtlösungen zur erfolgreichen Gestaltung ihrer steuerlichen, wirtschaftlichen und rechtlichen Aufgaben an. Sie ist in Deutschland eines der führenden Medien- und Softwarehäuser für Fachinformationen und -portale, (Cloud Computing-)Applikationen, eProcurement, Online-Communitys sowie Personal- und Organisationsentwicklung.

Zu den Hauptzielgruppen der Haufe Group gehören große und mittelständische Unternehmen, Kleinbetriebe und Selbstständige, Steuerberater und Anwälte, der Öffentliche Dienst sowie Immobilienunternehmen und Vereine. Bei ihnen nimmt die Haufe Group mit den Marken Haufe, Haufe Akademie und Lexware eine führende Marktstellung ein. Die Marke Lexware ist führend bei KMU im Bereich kaufmännischer Standard-Software-Lösungen (wie z.B. Lexware financial office), sowie bei privaten Nutzern mit Finanz- sowie Steuersoftware der Produktreihen "TAXMAN" und "Lexware Finanzmanager".
Weitere Informationen unter: www.haufegroup.com

Sehen Sie sich den Vortrag zum Artikel als Video an!

Warum eine agile Transformation?

Die Strukturen und Prozesse in der Desktop-Software-Entwicklung bzgl. der Lexware Standard-Software-Lösungen waren viele Jahre lang stabil und wurden von uns in dieser Zeit nicht grundsätzlich in Frage gestellt. Auf die veränderten Marktanforderungen im Software-Umfeld reagieren wir mit dem verstärkten Ausbau unserer Cloud-Angebote. Wir müssen also die Herausforderung meistern, gleichzeitig neue, qualitativ hochwertige Cloud-Lösungen zu schaffen und gleichzeitig unsere Marktposition sowie die Stärken der Bestandprodukte sicher zu stellen.

Als Familienunternehmen setzen wir dabei auf eine nachhaltige und wirtschaftlich ausgewogene Finanz- und Investitionspolitik. Unsere Portfolio- und Produktstrategie spiegelt dies wider, indem wir bei den Bestandsprodukten auf gesetzliche sowie technische Aktualität und gute Qualität setzen. Bei den neuen Cloud-Produkten investieren wir zudem in die Funktionserweiterung. In beiden Fällen stehen die Kundenbedürfnisse im Vordergrund.

Agile Vorgehensweise für Cloud-Lösungen

Die neuen Cloud-Lösungen entwickeln wir nach agilen Prinzipien: Kleine, funktionsübergreifende und sich selbstorganisierende Teams entwickeln iterativ in kurzen, meist zweiwöchigen Sprints auslieferbare Produktinkremente. In den allermeisten Fällen sind wir dabei in der Lage, kontinuierlich Neuerungen an unsere Cloud-Kunden auszuliefern. Auf diese Art lernen wir direkt von den Nutzern und lassen das Gelernte in die nächste Iteration einfließen.

Was dabei als nächstes gemacht wird, ist im Produkt-Backlog ersichtlich, welches der Product Owner verantwortet. Die Teams arbeiten fast alle nach Scrum, unterstützt von einem Scrum Master. In diesem Projektumfeld benötigten wir keinen "klassischen" Projektmanager mehr. Die meisten seiner Aufgaben wie Steuern, Entscheidungen herbeiführten und den Projektfortschritt reporten, übernehmen Team, Product Owner und Scrum Master. Einige Projektmanager-Aufgaben fallen im agilen Kontext auch weg, wie z.B. das Erstellen eines dedizierten Ablaufplans mit festen Terminen und von Statusreports (siehe dazu den Tipp: "So etablieren Sie Demos als Ersatz für Statusmeetings", Projekt Magazin 03/2018).

Wasserfallprinzip

In unserem Desktop-Bestandsgeschäft arbeiteten wir viele Jahre mit hierarchisch und nach Disziplinbereichen aufgestellten Teilteams. Die Produktpflege und die Projekte in diesem Umfeld führten wir vor Beginn der Transition sequentiell nach dem Wasserfallprinzip durch: Es wurden spezifische Aufträge formuliert und ein Projektmanager mit der Organisation und Durchführung beauftragt. Die Weiterentwicklung dieser Produkte erfolgte bei uns, seit Einführung einer projektorientierten Matrixorganisation (siehe Glossareintrag "Starke Matrixorganisation"), in produktspezifischen Teams: Wir als Projektmanager arbeiteten innerhalb dieser Projektteams mit vier Teilteams:

  1. Konzeptionsteam, bestehend aus Business-Analysten
  2. Entwicklungsteam aus Entwicklern und einem Development-Manager
  3. Qualitätssicherungs-Team aus Testern und einem Test-Manager
  4. Support-Team aus Support-Spezialisten und einem Support-Manager

Project Governance

Als Projektmanager verantworten wir die termingerechte Lieferung der neuen Releases mit den erforderlichen neuen Features, sowie gesetzlichen und technischen Anpassungen (je nach Produkt bis zu 50 pro Jahr) in hoher Qualität. Die Mitarbeiter der Projektteams gehören je nach fachlicher Ausrichtung zu unterschiedlichen Geschäftsbereichen und Abteilungen, sodass sich hieraus eine Matrixstruktur ergibt.

Ein zentraler Punkt der Project Governance ist, dass Produktmanager, Projektmanager und das Team gemeinsam den kommerziellen Erfolg der Produkte (Umsatz, Ertrag, Kundenzufriedenheit) verantworten. Dies spiegeln auch die persönlichen Zielvereinbarungen der Projektbeteiligten wider.

Bild 1: Projektorientierte Matrix-Organisation

Bild 1: Projektorientierte Matrix-Organisation
Bild vergrößern

Neue Funktionen und Änderungen hatten wir zunächst meist vollständig konzipiert, dann entwickelt, danach getestet und erst nach einer Stabilisierungsphase an die Kunden ausgeliefert. Unser Support-Team hat dann die Kunden bei der Anwendung der neuen Funktionen und Änderungen unterstützt.

Die Hauptaufgaben für uns Projektmanager bestanden darin, das Ganze zu steuern, zu koordinieren, zu überwachen und den jeweiligen Projektfortschritt an die internen Auftraggeber zu berichten. Auftraggeber im Desktop-Bestands-Produkt-Umfeld sind bei Haufe-Lexware unsere Produktmanager aus dem zuständigen Zielgruppenbereich, hier "Small-Business".

Auslöser für die agile Transition im Bestandsgeschäft

Ausgehend von unserer Unternehmensstrategie (Investition in Cloud, Margensteigerung im Desktop-Umfeld) kürzten wir im ersten Schritt Budgets und verminderten die funktionale Erweiterung der Bestandsprodukte im Desktop. Aufgrund der vielen gesetzlich und technisch erforderlichen Änderungen, Anpassungen und teils umfangreichen Erweiterungen (vor allem im Bereich der Entgeltabrechnung), erhöhte sich der Druck auf die Desktopteams.

Disruptiver Ansatz als Ausweg

Die gestiegenen Anforderungen an die Teams sollten sich in keinem Fall auf die Produktqualität auswirken. So reifte in der Organisation die Erkenntnis, dass nur ein disruptiver Ansatz, der eine radikale Veränderung der Prozessregeln, der Strukturen und der Arbeitsweisen beinhaltet, einen Ausweg ermöglicht.

Herausforderungen und Handlungsbedarf

Die Kunden schätzen unsere Lexware-Desktop-Produkte vor allem aufgrund der einfachen Bedienbarkeit und für das gute Preis-Leistungsverhältnis. Motivation für den Kauf der Updates oder den Abschluss eines Abonnements, stellen einerseits vor allem die gesetzlichen Änderungen (u.a. neuer Steuertarif, neue Datensätze, neue Bescheinigungen) und andererseits die technischen Änderungen (u.a. Kompatibilität mit den aktuellsten Windows-, Browser- und Office-Versionen) dar. Aus diesem Grund investieren wir vor allem in diesen beiden Bereichen. Zur Reduzierung der Kosten passen wir die Entwicklungsbudgets jährlich nur so weit an, dass wir die technische Nachhaltigkeit und die Stabilität der Produkte nicht gefährden. Solche Veränderungen können verschiedene Konsequenzen für Projektteams nach sich ziehen (siehe auch Bild 2):

  • Multitasking und Abhängigkeiten: Mitarbeiter mit speziellem Wissen müssen in mehreren Projekten gleichzeitig eingesetzt werden – dies erhöht die Rüstzeiten und senkt deutlich die Effizienz.
  • Kopfmonopole nehmen zu: Das Wissen über fachliche und technische Zusammenhänge in den Produkten verteilt sich auf weniger Mitarbeiter – die Abhängigkeit von einzelnen Personen nimmt zu.
  • Technical Debt: Die Investitionen in die Code-Qualität der Desktop-Produkte sind zu Gunsten neuer Produkte rückläufig. Dies birgt bei den Produkten, die stetig umfangreicheren Anforderungen von Seiten des Gesetzgebers erfüllen müssen, die Gefahr steigender technischer Schulden.
  • Overheadanteil steigt: Durch die Reduzierung der "operativen" Ressourcen in den Projekten verschlechtert sich das Verhältnis von Steuerungsrollen zu operativen Rollen.
  • Demotivation und Fluktuation: Viele Mitarbeiter wollen ihre Arbeitsweisen und ihre Produkte weiterentwickeln und am technologischen Puls der Zeit arbeiten. Verringerter Innovationsspielraum kann zu Demotivation führen.
Bild 2: Unsere Produkt-Strategie stellte uns vor eine Reihe von Herausforderungen

Bild 2: Unsere Produkt-Strategie stellte uns vor eine Reihe von Herausforderungen

Der Ruf nach Veränderung kam aus vielen Richtungen

Der Bedarf und der Wunsch eine Veränderung anzustoßen, wurde in vielen Bereichen und Teams immer lauter. Um diesen Entwicklungen zu begegnen, starteten wir zunächst eine bereichsübergreifende Initiative. Diese setzte es sich zum Ziel, die projektbasierten Strukturen durch ein agiles Cluster zu ersetzen. Sie bildete sich aus Mitgliedern der an der Produktentwicklung beteiligten Bereiche und hatte rund ein Dutzend Mitglieder.

Das Management gab uns das Go

Das Startsignal für die Initiative gaben letztendlich die Geschäftsbereichsleiter für Projektmanagement und Entwicklung. Hierbei führten wir bewusst auch Vertreter unterschiedlicher Hierarchieebenen zusammen. Ergänzt wurde das Team um die bereits in einigen Projektteams vorhandenen Scrum Master und agile Coaches. Als Treiber der Veränderung in den einzelnen Teams waren sie wichtige Multiplikatoren und Seismographen für die Befindlichkeit und die aktuelle Kultur in den Produktteams.

Die Projektmanager spielten eine wichtige Rolle

Gerade wir Projektmanager leisteten zu Beginn einen großen Beitrag, indem wir koordinierten und kommunizierten: Wir brachten inhaltlichen Input und Feedback aus unseren Projektteams mit und sorgten für die Transparenz und für das Verständnis vor allem innerhalb der bestehenden Entwicklungsorganisation. So wurden bestehende Probleme – wie wachsende Schwierigkeiten, die immer häufiger werdenden gesetzlichen Änderungen zeitnah zum Kunden zu bringen – aus den einzelnen Projektteams über die Projektmanager in die Initiative eingebracht. Wir Projektmanager berichteten zudem regelmäßig über die Fortschritte in der Initiative und holten so auch Feedback zu angedachten nächsten Schritten von den Teams ein.

Leitlinie: Mindset over Methodology

Unsere zentrale Einsicht zu Beginn war, dass eine agile Transformation zu Selbstverantwortung und Selbststeuerung nicht von oben vorgegeben und "ausgerollt" werden kann. Sie muss durch die Betroffenen selbst gewollt und getrieben werden. Die Initiative stand also vor der Aufgabe, eine Entwicklung in Gang zu bringen, ohne dabei die betroffenen Mitarbeiter zu übergehen oder für sie Entscheidungen zu treffen. Dieses Paradoxon aufzubrechen, war und ist eine echte Herausforderung.

Die Initiative löste dieses Paradoxon auf, indem sie es sich zur Aufgabe machte, Impulse für Veränderungen zu setzen. Sie hob Denkverbote und andere Hemmnisse auf und ermutige auch die anderen Mitarbeiter dazu. Das umfasste auch und besonders Vorgaben, welche die Teams selbst nicht hinterfragt hätten.

Beispiel: Wir empfahlen einem Team, welches keinen Scrum Master zugeteilt bekommen hatte, einen Teil seines bewilligten Projektbudgets zur Schaffung und Besetzung dieser Rolle einzusetzen.

Wie wir der agilen Philosophie treu blieben

Auch das Vorgehen zur Schaffung dieses agilen Clusters sollte den Grundsätzen von agilem Arbeiten entsprechen. Dies implizierte, dass kein – theoretisch am Reißbrett durchdachtes – Konzept entwickelt wurde, das dann ausgerollt werden würde. Unser Ansinnen war vielmehr, dass die Veränderungen in Form von einzelnen, kleinen Schritten ("Experimenten") erfolgen sollte, die leicht umgesetzt und deren Resultate zeitnah überprüft werden können. Wir haben uns darauf verständigt die Schritte "PLAN-DO-CHECK-ACT" (sog. Deming Cycle oder PDCA-Zyklus, siehe Bild 3) dabei möglichst häufig und kurz zu durchlaufen, um basierend auf Erfahrungen zu lernen und weitere Veränderungen und Optimierungen anstoßen zu können.

Bild 3: Der Deming- Cycle oder auch Deming-Rad, Shewhart-Cycle, PDCA-Zyklus beschreibt einen iterativen drei- bzw. vierphasigen Prozess für Lernen und Verbesserung des US-amerikanischen Physikers Walter Andrew Shewhart. Quelle: Wikipedia

Bild 3: Der Deming Cycle oder auch Deming-Rad, Shewhart-Cycle, PDCA-Zyklus beschreibt einen iterativen drei- bzw. vierphasigen Prozess für Lernen und Verbesserung des US-amerikanischen Physikers Walter Andrew Shewhart. Quelle: Wikipedia

Dieses iterative Vorgehen war umso wichtiger, als die Veränderungen im laufenden Betrieb durchgeführt werden und eine Störung der Release-Auslieferung nicht tolerierbar ist. Den Beteiligten war darüber hinaus klar und wichtig, dass es bei der Initiative nicht darum ging, den Zustand A in den Zustand B zu überführen, sondern dass damit ein kontinuierlicher Prozess angestoßen wird, der permanente Änderungen und Verbesserungen ermöglicht, ohne jemals zu einem "perfekten" Endzustand zu kommen.

Konsequentes Üben in agilem Arbeiten

Wichtig war, dass wir bereits während der Vorarbeiten in unserer Initiative einige wesentliche agile Praktiken anwendeten, wohlwissend, dass wir aufgrund der Zusammensetzung und Parallelität zum Tagesgeschäft nicht konsequent nach agilen Prinzipien oder innerhalb eines Scrum Frameworks agieren konnten. Uns darin dennoch zu versuchen war wichtig, um einen transparenten und kontinuierlichen Veränderungsprozess anzustoßen, bei dem Veränderung durch Überprüfung und Anpassung entsteht. Entscheidend war, dass wir einige Elemente aus dem agilen Umfeld nutzten um weitere Erfahrungen damit zu sammeln:

  • Erstellen und Führen eines Backlogs: Im initialen Kick-Off-Termin der Initiative sammelten wir Themen, Maßnahmen und Stories, die wir für das Initialisieren und Vorbereiten einer Transition als relevant ansahen. Diese Sammlung bildete die Basis für das Backlog. Wir formulierten die Themen in Form von User Stories. Für jede Story definierten wir Akzeptanzkriterien um sicherzustellen, dass wir alle das gleiche Verständnis darüber hatten, was mit der jeweiligen Story erreicht werden sollte. Als System zur Dokumentation und Verwaltung der Stories nutzen wir die Kollaborationssoftware "Trello" (www.trello.com) – eine leichtgewichtige, selbsterklärende Cloud-Plattform, die sich sehr bewährte. Trello bietet zwar nicht den Funktionsumfang und die Tiefe gängiger agiler Werkzeuge, wie beispielsweise JIRA, war für unsere Zwecke aber intuitiver anwendbar (siehe dazu auch die Fachbeiträge "Agiles Projektmanagement mit Trello" und "Tricks für die tägliche Projektarbeit mit Trello"). Jedes Mitglied der Initiative konnte das Backlog bearbeiten und erweitern. Es diente als Basis für die Sprint-Backlogs.
  • Durchführung von 4-Wochen-Sprints: Da die Teilnehmer der Initiative aufgrund anderer Aufgaben nicht in Vollzeit an den Themen arbeiten konnten, wurde ein 4-Wochen-Sprint-Rhythmus eingeführt, in dem die in den Plannings definierten Themen bzw. Stories bearbeitet wurden.
  • Review / Planning / Retro: Alle vier Wochen fand ein Halbtagsworkshop statt, bei dem wir uns die im Sprint bearbeiteten Themen gegenseitig vorstellten, diskutierten und anhand der Akzeptanzkriterien überprüften. Fertige Stories wurden abgeschlossen, nicht fertiggestellte Stories neu bewertet und entweder auf den nächsten Sprint verschoben oder ins Backlog zurückgelegt. Da es keinen Product Owner gab, erfolgte die Abnahme durch das gesamte "Initialisierungsteam". Im Anschluss daran wurde das Planning durchgeführt. Hier legten wir fest, welche Stories wir aus dem Backlog in der nächsten Iteration umsetzten und wer von uns sich an der Umsetzung jeweils beteiligte. Hierbei überprüften wir gemeinsam die Akzeptanzkriterien der einzelnen Stories und passten diese ggf. an.

Das Lexware Cluster erblickt das Licht der Welt

Intensiv überlegten wir in dieser Zeit, wie und wann alle betroffenen Mitarbeiter involviert werden sollten – bis zur gemeinsamen Entscheidung, die Initiative für alle betroffenen Mitarbeiter (potentiell über 200) zu öffnen und jedem die Mitarbeit zu ermöglichen. Dass es diese Initiative gab, war von Beginn an transparent und wurde auch von der Geschäftsführung bewusst so kommuniziert. Wir Projektmanager bildeten die Schnittstelle in die Projektteams.

Die Initiative öffnet sich

Die "Öffnung" der Initiative bedeutete den Startschuss für die Transition. Hierfür bereiteten wir – ebenfalls über mehrere Sprints – einen gemeinsamen Kick-Off-Termin vor, zu dem wir alle Beteiligten einluden und ihnen die Ausgestaltung und Umsetzung der Transition übertrugen. Die an der Weiterentwicklung der Lexware-Desktop-Produkten Beteiligten kommen aus unterschiedlichen Teams und Bereichen unseres Unternehmens. Es gibt also keine eigene Organisationseinheit für alle hier Beteiligten.

Um klarzustellen, welche Projektteams und Geschäftsbereiche die Transition umfassen wird, nannten wir den Zusammenschluss "Lexware Cluster". Die erste Initiative löste sich nach rund fünf Monaten Vorbereitungszeit zu diesem Zeitpunkt auf und die bisherigen Mitglieder wurden Mitglieder des Clusters (inkl. der beteiligten Geschäftsführer), wo sie ihre Ideen und Vorschläge einbrachten.

Kontinuierliche Veränderung durch (selbstorganisierte) Experimente

Das Cluster leistete von Beginn an einen handfesten Beitrag zur Weiterentwicklung des Unternehmens: Gleich im ersten Treffen äußerten die Teammitglieder bestehende Problemstellungen und Herausforderungen, welche aus ihrer Sicht gelöst oder verbessert werden müssten. Dazu entwickelten wir eine Reihe von Experimenten. Die Ideen dazu kamen von Mitgliedern des Clusters, die wir anschließend gemeinsam priorisierten. Um das agile Arbeiten zu üben, beschlossen wir, dass die Mitarbeiter diese Experimente im folgenden Monat selbstorganisiert während der Arbeitszeit durchführten. Erfolgreiche Experimente sollten zur Veränderungen und Weiterentwicklung des Lexware Clusters beitragen.

Reflektion und Weiterentwicklung durch Retrospektive

Seither trifft sich das Lexware Cluster monatlich zur halbtägigen "Overall-Cluster-Retrospektive". In dieser Retrospektive werden die Transitionsaktivitäten des Clusters zusammengeführt, entsprechend dem agilen Prinzip des "Inspect and Adapt", also einer kontinuierlichen Reflektion und Anpassung bzw. Weiterentwicklung. Ein über eine Retrospektive initiiertes Experiment wird in der nächsten Retrospektive auf dessen Ergebnis und Wirkung überprüft und falls notwendig angepasst.

Transparent dank Wiki

Transparenz stellen wir über ein Cluster-Wiki sicher, das wir bereits zum "Kick-Off" einrichteten. Dieses Wiki enthält sämtliche Inhalte zu allen im Cluster laufenden Experimenten. Die Inhalte werden stets aktuell gehalten und jeder Beteiligte im Cluster kann Kommentare hinterlegen, Feedback geben und Verbesserungsvorschläge einbringen.

Bild 4: Vorgehen der Initiative bei der Initialisierung und Start der Transition

Bild 4: Vorgehen der Initiative bei der Initialisierung und Start der Transition
Bild vergrößern

Auf diese Weise begannen wir eine schrittweise Transition in eine neue Struktur und in neue Prozesse, die wir sicherlich nie abschließen werden. Die in der Initialisierungsphase entwickelten Ergebnisse – in der Regel zum Verbessern der Rahmenbedingungen, dazu später mehr –, haben wir in die tägliche Arbeit des Lexware Clusters übernommen.

Ein Zielbild zur Orientierung und Ausrichtung

Das Zielbild für die Transition des Lexware Clusters entstand bereits in einer der ersten Iterationen des Initialisierungsteams. Um ein gemeinsames Verständnis zu erarbeiten, beschäftigten wir uns bereits zu Beginn der Initiative intensiv mit der Vision und den Zielen. Hier trafen unterschiedliche Vorstellungen aufeinander, was die weitere Arbeit sehr befruchtete. Durch die Auseinandersetzung mit den verschiedenen Aspekten aus unterschiedlichen Blickwinkeln entstand ein ausgewogenes und von Allen getragenes Zielbild. Neben einer übergreifenden Produktvision erstellten wir auch eine Beschreibung von der Struktur und der Arbeitsweise, die uns dabei helfen sollten, diese Vision zu erreichen.

Zielbild und Vision

Das Lexware Cluster ist eine Organisation zur Produkt-Entwicklung, die sich an Markt- und Unternehmenserfordernissen ausrichtet und Standardsoftware herstellt. Ausgehend von differenzierten und regelmäßig überarbeiteten Produktstrategien auf Basis der Unternehmens- und Bereichsstrategie liefert sie Produkte, die ein optimales Verhältnis von Kundennutzen, Gebrauchstauglichkeit, Profitabilität und Nachhaltigkeit aufweisen.

Struktur

• Wir arbeiten in kleinen, selbstorganisierenden Teams an Lexware On-Premise-Produkten.
• Die Linienzuordnung der Mitarbeiter spielt eine untergeordnete Rolle.
• Jeder Mitarbeiter gehört ausschließlich einem Team an.
• Es entsteht eine klare, simple und schlanke Struktur, die sich ihren Aufgaben anpasst.

Arbeitsweise und Kultur

Die Arbeit im Team ist attraktiv dank vielfältiger Aufgaben und Abwechslung. Interdisziplinäres Lernen und Entwickeln ist nicht nur möglich, sondern notwendig, denn so entsteht eine Kultur, die auf den Prinzipien des Agilen Manifests basiert. Transparenz und kontinuierliche Verbesserung sind Teil dieser Kultur.

Durch das Pull-Prinzip entstehen Freiräume für den Einzelnen, es bleibt Zeit für die Pflege sozialer Beziehungen und Innovation.

Die Arbeit wird über ein übergreifendes Cluster-Backlog priorisiert und gesteuert. Eine gemeinsame Backlog-Struktur sowie auch ansonsten gleichlaufende Arbeitsweisen der Teams – etwa in der Ausprägung der Rollen und genutzten Systeme, sowie der Taktung der Sprints –, unterstützen das Alignment der Teams im Hinblick auf das gemeinsame Ziel.

LeSS Huge als ein mögliches Ziel-Szenario

Als mögliches Ziel-Szenario identifizierten wir das Scrum-Skalierungsmodell "LeSS" bzw. "LeSS Huge", an welchem sich das Lexware Cluster orientieren und zukünftig annähern wird. Large Scale Scrum (LeSS) ist ein Rahmenwerk für agile Software-Entwicklung nach Scrum-Regeln mit bis zu acht Teams. LeSS Huge ist die erweiterte Variante für mehr als acht Teams, was bei der Größe des Lexware Clusters das relevante Rahmenwerk wäre. Bild 5 zeigt die Struktur und das übergreifende Prozessmodell von LeSS Huge. (siehe dazu auch den Fachbeitrag "Mit vielen Teams erfolgreich ein Produkt mit Scrum entwickeln", Projekt Magazin 09/2017)

 

LeSS baut auf Scrum auf, d.h. um LeSS praktizieren zu können, müssen erst die wesentlichen Elemente von Scrum verstanden und angewandt werden. Im LeSS Framework gibt es die gleichen Rollen wie in Scrum mit dem Unterschied, dass es neben einem Product Owner, der den Gesamtblick auf das Produkt hat, Area Product Owner gibt, die jeweils für einen Bereich des Produkts verantwortlich sind. Jedem dieser Area Product Owner sind mehrere DEV-Teams zugeordnet, die von Scrum Mastern betreut werden.

In LeSS koordinieren die Teams ihre Aktivitäten untereinander: Alle Teams arbeiten zusammen in einem Sprint, um ein gemeinsames, auslieferbares Produktinkrement herzustellen – und zwar in jedem Sprint. Die üblichen Scrum Ereignisse (Planning, Refinement, Review und Retrospektive) finden teilweise teamintern und teilweise teamübergreifend statt. Ziel ist es, die Aufmerksamkeit aller Teams auf das ganze Produkt zu lenken, anstatt nur auf einen Teil. Damit sollen Probleme wie Doppel-Entwicklungen, negative Auswirkungen bzw. Nebeneffekte auf andere Teile oder unabgestimmte Architekturentscheidungen gelöst werden.

Die Intention von LeSS ist es, die Organisation so einfach wie möglich zu gestalten und die Wertschöpfung zu erhöhen, indem vermeidbare Tätigkeiten wegfallen bzw. in wertschöpfende Aktivitäten umgewandelt werden. Hierzu sind in LeSS zehn Prinzipien und eine Reihe von Regeln bzgl. der Organisation und des Produkts definiert.

Was ist unser gemeinsames Produkt?

LeSS und LeSS Huge gehen von einem gemeinsamen Produkt aus. Die Klärung, was das gemeinsame Produkt ist, stellt für uns im Lexware Cluster eine der wesentlichen grundlegenden Fragstellungen dar. Je nachdem, wie wir diese Fragestellung im weiteren Verlauf der Transition beantworten, ergäbe sich nach diesem Skalierungsframework für uns eine Struktur nach LeSS Huge oder eine von mehreren LeSS’en. Aktuell liegt der Fokus vor allem darauf, dass die neu formierten Feature Teams sich kontinuierlich verbessern. Dies gilt natürlich auch für die Scrum Master und Product Owner. Erst wenn die Feature Teams für sich reif genug sind, sollte weiter in die Skalierung investiert werden. Zu viel Veränderung auf einmal wäre an dieser Stelle eher hinderlich bzw. überfordernd.

Was hat sich bislang verändert?

Anpassen von Rahmenbedingungen, Strukturen, Rollen und Prozessen

Schulungen und Trainings zu LeSS, PSM, PSPO, PSD

Es ist essentiell, dass alle im Team von vorne herein die theoretischen Grundlagen erlernen, um von diesem gemeinsamen Wissenstand "abspringen" zu können. Nur so wird es möglich, sich gemeinsam schrittweise in Richtung agiler Arbeitsweisen weiterzuentwickeln.

Um bei allen Beteiligten einen gemeinsamen Wissensstand zu schaffen, etablierten wir mehrere Schulungsformate. Das Schulen übernahmen überwiegend externe Trainer in Inhouse-Schulungen, weil das deutlich effektiver, mit mehr Praxisbezug und kostengünstiger ist, als alle auf eine externe Schulung zu schicken. Zum einen kann dann an konkreten gemeinsamen Praxisbeispielen diskutiert werden. Zum anderen fallen Reisezeiten und Reisekosten weg.

Die Schulungen zu PSM (Professional Scrum Master), PSPO (Professional Scrum Product Owner) und PSD (Professional Scrum Developer) vermittelten den jeweiligen Rollen sowohl das Wissen um Methodiken und Praktiken von Scrum als auch die hinter Scrum liegenden Werte und Prinzipien, die für eine erfolgreiche Implementierung wichtig sind. Damit konnte ein gemeinsames Verständnis sowohl über die Arbeitsweise als auch über die Kultur der Zusammenarbeit geschaffen werden.

Ziel der LeSS-Schulung war es, bei Product Ownern und Scrum Mastern ein Grundverständnis für die innere Logik und Struktur von LeSS zu schaffen und Fragen zur Machbarkeit zu adressieren. Insbesondere die Koordination zwischen den Feature Teams und den Aufbau des übergreifenden Backlogs und der Area Backlogs wurden dabei adressiert.

Einführen von Scrum-Rollen und -Ereignissen

Um agil arbeiten zu können, bildeten wir zunächst kleinere cross-functional Feature Teams. Zugunsten dieser funktionsübergreifenden Teams lösten wir die bisher bestehenden Teams aus den Fachbereichen auf. Jedes cross-funktional Team bekam einen "Servant Leader" (siehe dazu auch den Glossareintrag zu Scrum Master). Für jedes größere Produkt übernahm ein Mitglied aus dem Cluster die Rolle des Product Owners. Ergänzend wurden Product Backlogs aufgebaut, die die bestehenden Lasten- und Pflichtenhefte ablösten. Darüber hinaus führten wir in den Teams Scrum-Ereignisse wie Dailys, Plannings, Refinements, Reviews und Retrospektiven ein.

Da an ein paar wenigen Produkten auch mehrere Teams arbeiten, wurden hier im Verlauf der bisherigen Transition schrittweise übergreifende Scrum-Ereignisse (Overall-Planning, Overall-Retrospektive und Demo-Fair) eingeführt, um die Arbeit an einem gemeinsamen Produkt und damit an einem Product-Backlog zu koordinieren und zu optimieren.

Verschlanken von Strukturen und Prozessen

Ein starker Hebel zu mehr Effizienz war die Vereinfachung der Planungs- und Controllingstrukturen. Bisher war die Lexware-Desktop-Produktentwicklung in mehrere Projekte unterteilt, die einzeln geplant und budgetär gesteuert wurden. Wir konnten die Aufwände für Planung und (monatliches) Controlling deutlich reduzieren, indem wir einen Gesamtauftrag für alle Produkte definierten. Gleichzeitig haben wir durch eine produktgenaue Verrechnung der Ist-Aufwände nach wie vor eine hohe Kostentransparenz, auf deren Basis sich Entscheidungen treffen lassen.

Wie viele Unternehmen hatten auch wir ein variables Gehaltsmodell, das auf der Erreichung von individuellen Zielen basiert – und davon ausgeht, dass das Schaffen von monetären Anreizen für persönliche Leistung motivierend wirkt. Heute sind wir davon überzeugt, dass diese Anreize eher demotivieren und haben darum die individuellen Ziele der Mitarbeiter im Cluster durch Unternehmensziele ersetzt. Dies hatte eine wichtige Signalwirkung, unter anderem hinsichtlich der Zusammenarbeit in cross-funktional Teams in einem übergreifenden Cluster. Darüber hinaus sparen wir uns viel Zeit, die uns das Vereinbaren und Messen der diversen Einzelziele kostete.

Ein wichtiger Schritt zu mehr Klarheit und Einfachheit war das Festlegen auf Scrum als verbindliches Framework für alle Teams des Lexware Clusters. Diese Entscheidung erfolgte erst deutlich nach dem Start der Transition. In der Folge werden die unterschiedlichen Steuerungsrollen, die wir in der bisherigen Projektorganisation hatten und aktuell teilweise noch haben, in den nächsten Wochen abgeschafft. Die verbleibenden Aufgaben gehen auf die neuen Rollen und v.a. auf die Teams über. Die bisherige Doppelspitze, bestehend aus Produkt- und Projektmanager, haben wir durch die Rolle des Product Owners ersetzt. Teaminterne Steuerungsrollen wie Development- oder Testmanager werden wir auflösen und damit eine Struktur schaffen, in der es nur noch die in Scrum definierten Rollen des Product Owners, Scrum Masters und des Development Teams gibt.

Als logische Konsequenz werden diese Rollenanpassungen in der Folge auch in der Aufbauorganisation nachvollzogen, sodass Product Owner, Scrum Master und Mitglieder der Development Teams auch in Linienteams zusammengeführt werden. Damit einher geht auch eine veränderte Aufgabe der Linienführung (Team- bzw. Bereichsleitung): Sie versteht sich zukünftig als People Coach, der/die für die persönlichen Belange und die Weiterentwicklung der Mitarbeiter zuständig ist, hat dabei aber keinerlei fachliche Einflussnahme mehr auf die Arbeit der Mitarbeiter im Cluster.

Bisherige Erfolge und Erfahrungen

Das Ziel ist (auch) der Weg

Die Transformation einer klassisch über "Command & Control" funktionierenden Organisation in ein agiles, selbstorganisiertes Cluster, kann nicht top-down entschieden und vorgegeben werden, will man den Werten treu bleiben, die zu der Transition motivierten.

Nur Werte stiften Sinn

Schwerpunkt und Herausforderung jeder agilen Transition ist nicht die Struktur- oder Prozessveränderung, sondern der Wandel im Denken und in der Haltung der betroffenen Personen. Dies setzt die Bereitschaft voraus, sich mit diesem agilen Wertesystem auseinanderzusetzen und es zu seinem eigenen zu machen – damit kann es nicht von außen vorgegeben, sondern muss von den Betroffenen akzeptiert werden.

Agile Führung vs. Top-Down-Entscheidungen

Gleichzeitig braucht es die Impulse und die Unterstützung der aktuell verantwortlichen Rollen. Dieses Paradoxon auszuhalten und die Balance zwischen "Impulse setzen" und "darauf vertrauen, dass die Betroffenen selbst die wichtigen Punkte angehen", ist eine große Herausforderung für das Management. Zwar dauert dieser Weg mutmaßlich länger als ein klassischer Change Prozess, wir sind jedoch davon überzeugt, dass er nachhaltiger und am Ende wirksamer ist als das Durchdrücken einer Veränderung von oben nach unten.

Hier haben wir – auch durch Fehler – in den vergangenen Monaten viel gelernt: Zu Beginn gaben wir den Teams zu viel Freiraum und zu wenig Struktur. Wir erkannten dies daran, dass die von Teammitgliedern gestarteten Experimente wenig greifbare Ergebnisse einbrachten.

Zur Korrektur griff das Managements ein und traf Entscheidungen teilweise ohne die im agilen Kontext ratsame Beteiligung der Mitarbeiter. So wurden z.B. die neuen Product-Owner-Positionen im Management definiert und intern zur Besetzung ausgeschrieben, zunächst ohne eine Rücksprache mit den Personen, die bisher diese Aufgaben innehaben. Auch die organisatorische Ansiedlung der Scrum Master legte das Management fest, ohne Einbeziehung der bisher mit den Servenat-Leader-Aufgaben betrauten Personen. Dies führte bei Letzteren zu Irritationen.

Die Kommunikation zwischen Mitarbeitern und Management war aber so offen, dass die Verwirrung über diese Entscheidung konstruktiv besprochen werden konnte. Die Führungskräfte nahmen daraufhin Entscheidungen zurück, um sie im Dialog mit den Mitarbeitern neu zu treffen. Die bewusste Entschuldigung für diesen Fehler stellte Vertrauen und Akzeptanz wieder her und war gleichzeitig ein wichtiger Beitrag für unsere Fehlerkultur.

Veränderung als kontinuierlichen und selbstorganisierenden Prozess begreifen

Während konventionelle Change-Management-Ansätze einen Prozess beschreiben, der vom Zustand A in den (hoffentlich besseren) Zustand B führt, ist unser Transitionsprozess auf Dauer angelegt: Kontinuierliches, durch Experimente validiertes Lernen; kleine, aber durchgehende Veränderungen, die die Betroffenen selbst initiieren, sind dabei wesentliche Elemente. Dies impliziert auch, dass es niemals einen "perfekten" Endzustand geben wird – und keine Stabilität in dem Sinne, dass sich nichts mehr ändern wird.

Gleichlaufende Arbeitsweisen reduzieren die Komplexität

Wir haben gelernt, dass unterschiedliche Vorgehensweisen, sowohl bzgl. der Zusammenarbeit als auch was den zeitlichen Ablauf angeht, die adressierten Probleme nicht ausreichend lösen, weil so Abhängigkeiten und Kommunikationsverbindungen nicht nachhaltig verringert werden. Die unterschiedlichen Arbeitsweisen erschwerten das Zusammenarbeiten der Teams untereinander. Alle Feature Teams müssen sich im selben Sprintrhythmus organisieren und die gleichen agilen Ereignisse durchführen.

Relevanz und Bedeutung der Scrum Master und agile Coaches

Als sehr wichtig und zielführend hat sich die Einbeziehung der bereits vorhandenen Scrum Master und Agile Coaches in die Initiative erwiesen. Diese sind tagtäglich im direkten Kontakt mit den Entwicklungsteams und können so einerseits die vorhandenen Stimmungen und Einstellungen zu einer agilen Transition aufnehmen und andererseits als Coaches und Multiplikatoren, die auf ein gemeinsames Ziel hin ausgerichtet sind, in die Teams hineinwirken. Unterstützt werden muss dies allerdings durch breit angelegte Schulungs- und Trainingsangebote für alle beteiligten Mitarbeiter.

Darüber hinaus mussten wir uns zu Beginn damit behelfen, Scrum Master aus den bestehenden Teams zu entwickeln. Bedingt dadurch, dass diese Mitarbeiter an der inhaltlichen Arbeit des Teams weiterhin Anteil nahmen, – oder sogar daran beteiligt waren, weil sie anfangs meist noch in einer Doppelrolle arbeiteten – konnten sie ihre Scrum-Rolle nur eingeschränkt ausfüllen, was die gesamte Entwicklung zum Scrum-Team bremste. Ideal wäre es, wenn man bereits zu Beginn derartige Doppelrollen vermeiden könnte, indem man die Scrum-Master exklusiv für diese Aufgaben freistellt. Zudem wäre es ratsam, auch erfahrene Scrum Master ins Team aufzunehmen, um hier eine gute Mischung zu haben.

Lessons learned zum Teamsetting

Auch im Hinblick auf das Teamsetting haben wir in mehreren Entwicklungsschritten einiges gelernt und schrittweise optimiert:

  • Ein Team sollte nicht zu groß sein, da sich sonst Untergruppen bilden und Entscheidungsprozesse deutlich schwieriger werden. Zur Reduzierung der Kommunikationswege und Komplexität empfiehlt sich eine Team-Größe von fünf bis neun Personen.
  • Jedes Team sollte cross-functional zusammengesetzt sein, um den stetigen Austausch und die Zusammenarbeit zu fördern.
  • Ein Team an einem Standort findet viel leichter zusammen als ein verteiltes Team. Letzteres muss zusätzliche Hürden überwinden (neben der Notwendigkeit einer stetigen technischen Verbindung): Vor allem Retrospektiven und Teambildungsprozesse werden durch das Fehlen von persönlichem Kontakt (sowohl während der Arbeit in den Sprints, als auch in den Pausen, wie z.B. in der Teeküche oder beim Mittagessen) deutlich erschwert.

Herausforderung der Gleichzeitigkeit

Diese Initiative muss parallel zur laufenden Produktweiterentwicklung betreut werden. Eine Verschlechterung der Qualität, eine Reduzierung des Scopes oder die Verschiebung eines Releases müssen wir unbedingt vermeiden. Dies fordert von allen Beteiligten ein hohes Maß an Einsatz und eine Bereitschaft zu Multitasking. An vielen Stellen mussten wir feststellten, dass Beteiligte aufgrund ihrer hohen Auslastung durch das Tagesgeschäft zu wenig Focus auf die Themen der Initiative legen konnten und ihre kontinuierliche Beteiligung darunter litt. Zur Verbesserung dieser Situation führten wir u.a. ein Limit ein, sowohl für die Anzahl der aktiven Experimente, als auch für die gleichzeitige Teilnahme von Personen an mehreren Experimenten.

Erfolgsfaktor Management

Einer der wichtigsten Erfolgsfaktoren ist die Unterstützung und die Bereitschaft der Geschäftsleitung, der leitenden Personen sowie der Manager, Verantwortung und Macht abzugeben. Unabdingbar ist dabei, den Teams das nötige Vertrauen zu schenken, damit diese auch die Verantwortung übernehmen können. Nur so werden die Teams wichtige Entscheidungen treffen und in der Lage sein, aus Fehlern zu lernen und sich stetig zu verbessern.

Balance zwischen Freiraum und Struktur halten

Gleichzeitig ist es wichtig, die Teams nicht zu überfordern, indem man ihnen zu früh zu viel Freiraum gibt. Wir haben die Erfahrung gemacht, dass eine transparente und vor allem vertrauensvolle Zusammenarbeit von Management und Teams hilft, die Balance zwischen Loslassen und der – gemeinsamen – Schaffung neuer Strukturen zu halten. Dies gelingt nur, wenn keine Fronten aufgemacht werden und alle Beteiligten sich an einem gemeinsamen Zielbild orientieren.

Viele Aufgaben werden mittelfristig in die Teams wandern, einige Themen werden Product Owner und Scrum Master übernehmen und andere Dinge werden wegfallen. Für alle diese Veränderungen müssen Geschäftsleitung, Management und Projektmanager bereit sein, auch weil es schlussendlich bedeutet, dass dadurch Management-Aufgaben und damit auch -Positionen wegfallen können. Die Bereitschaft, die eigene Rolle in Frage zu stellen, erfordert eine gehörige Portion Mut, hat aber eine extrem hohe Vorbildfunktion für alle Beteiligten in diesem Veränderungsprozess.

Die agile Reise endet nie, daher sollte man genau klären, warum man sie antritt

Eine derart umfangreiche Transformation anzustoßen und letztlich durchzuführen, darf kein Selbstzweck sein. Es ist nicht ratsam, die Transition einer Produktentwicklungsorganisation anzugehen, nur weil "agil" eben modern ist. Vielmehr muss allen Beteiligten – über sämtliche Hierarchieebenen hinweg – klar sein, aus welchen Gründen und zu welchem Zweck eine Veränderung angestrebt wird.

Entscheidet sich eine Organisation begründet und zielorientiert, zukünftig nach agilen Prinzipien zu arbeiten, bedarf dies einer kontinuierlichen, auf "Insepect & Adapt" beruhenden Weiterentwicklung. Am Beginn einer agilen Transition kann es keinen fest definierten Endzustand geben. Vielmehr ist es wichtig, sich auf die agilen Prinzipien und Werte zu verständigen und sich an einer gemeinsam getragenen Vision auszurichten. All das erfordert Offenheit, Vertrauen, Transparenz, Mut, Zeit und viel Geduld.

Literatur

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
1 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 4
Kommentare 1

Alle Kommentare (1)

Hartmut
Goetze

Sehr gute Darstellung der Transformation bei der Haufe Group. Auf das Wesentliche reduziert. Vielen Dank!