Wie agil reagieren Menschen auf Veränderungen?

Ausgangspunkt für diesen Artikel ist ein großes Software-Entwicklungs- und -Einführungsprojekt einer neuen SAP-Software für mehr als tausend Anwender in einem internationalen Großunternehmen.

Hierbei mussten zur bereits im System vorhandenen Standardfunktionalität einige für den Kunden essenzielle Funktionalitäten komplett neu entwickelt sowie bestehende Prozesse zunächst analysiert und zum Teil optimiert werden.

Agile Methoden sind in aller Munde und werden oftmals als „Heilsbringer“ für allerlei aus Software-Entwicklungsprojekten früherer Tage bekannte Probleme postuliert. Die relativ starre und lineare Vorgehensweise in der klassischen Wasserfall-(Projekt-)Methodik, bei der von der Bedarfsanalyse über die Lösungsdefinition und der anschließenden, oft langwierigen Entwicklungs- und Testphase auf ein schon zu Beginn des Projekts vollständig definiertes Endergebnis hingearbeitet wurde, barg zahlreiche Risiken, das eigentlich gewünschte Ergebnis am Ende dann doch nicht zu erreichen.

Zu viel Unvorhergesehenes konnte in den langen Projektlaufzeiten passieren: Anforderungen ließen sich zu Beginn gar nicht vollständig in jedem Detail definieren, Stakeholder änderten sich während der Projektlaufzeit, Technologien waren am Ende des Projekts bereits wieder veraltet oder die ursprünglichen Anforderungen haben sich schlicht während einer langen Entwicklungsphase geändert oder waren plötzlich obsolet geworden.

Da verspricht die iterative Vorgehensweise in agilen Projekt- und Entwicklungsmethoden deutlich mehr Flexibilität und Sicherheit, auf auftretende Veränderungen reagieren zu können.

Kurze Entwicklungszyklen von typischerweise ein bis zwei Wochen erlauben es, überschaubare Entwicklungspakete mit weniger Komplexität für die „Sprints“ zu definieren und zu liefern und in den darauffolgenden, immer wiederkehrenden Sprint Reviews mit den Auftraggebern auch auf sich ändernde Anforderungen entsprechend flexibel reagieren zu können.

Es drängt sich fast der Eindruck auf, jedes agil organisierte (Entwicklungs-)Projekt müsste folgerichtig automatisch zu einem Erfolg werden. Das ist jedoch leider nicht so.

Ein erfolgreicher Abschluss der Entwicklungsarbeiten definiert noch lange nicht den Projekterfolg eines großen Softwareentwicklungsprojekts. Die Software kann noch so gut und zielgerichtet zu einem funktionierenden Endergebnis komplett neu entwickelt, angepasst oder entsprechend erweitert worden sein und auch die Anforderungen der Auftraggeber können vollumfänglich erfüllt sein:

Echter Projekterfolg ist erst dann erreicht, wenn die neue Software erfolgreich im Unternehmen ausgerollt wurde und von der breiten Masse der Anwender akzeptiert und genutzt wird.

Die Einführung neuer Software geht meistens auch mit der Einführung neuer oder veränderter Prozesse einher. Prozesse jedoch, die von Menschen gelebt werden, lassen sich nicht „agil“ einführen oder verändern – denn Menschen unterliegen immer noch unterschiedlichen Veränderungsgeschwindigkeiten.

Da hilft auch keine noch so agile Projekt- oder Entwicklungsmethode. Wird der „Faktor Mensch“ nicht rechtzeitig wahr- und ernstgenommen, endet auch das agilste Softwareprojekt im Bestfall mit einer tollen Software, die zwar dem Auftraggeber und vielleicht noch einigen Stakeholdern gefällt, aber von der breiten Masse der User gar nicht oder nur ineffizient genutzt wird.

Der Erfahrung nach steigt das Erfolgsrisiko mit der Größe der späteren Nutzergruppe (oder des Unternehmens), weil eben oftmals doch keine repräsentative Gruppe der finalen Endanwender in den Feedbackrunden der einzelnen Entwicklungszyklen beteiligt war.

Zum einen wird in der Zusammenstellung der Stakeholder, speziell auch der für die Sprint Reviews, gern dazu tendiert, die ohnehin engagierten und eher veränderungsaffinen Mitarbeiter auszuwählen.

Darüber hinaus ist es schlicht ein Problem von Masse: Bei mehr als 1000 betroffenen Endanwendern und womöglich mehreren betroffenen Prozessen ist die Wahrscheinlichkeit sehr groß, dass die kleine Kerngruppe, von denen in der Sprint-Phase aktiv Feedback eingeholt wird, einfach nicht repräsentativ ist.

Was also tun, um ein Software-Entwicklungsprojekt mit einer großen Anzahl betroffener Anwender bestmöglich auf den Erfolgspfad zu bringen?
Aus unserer Sicht gilt es, die Vorteile moderner, agiler Methoden mit denen klassischer Methoden aus dem Projektmanagement und der Organisationsentwicklung zu kombinieren: agil entwickeln, klassisch ausrollen.

Im diesem Artikel zugrunde liegenden Software-Einführungsprojekt mit mehr als tausend betroffenen Anwendern wurde auf das bewährte Sirius-Projektvorgehen zurückgegriffen, bei dem die Vorteile der agilen Scrum-Methodik mit klassischen Projektmanagement-Vorgehensweisen und des organisatorischen Change-Managements kombiniert werden.

Es wird dabei schon möglichst frühzeitig versucht, mehrere Kommunikations- und Interaktionskanäle zu möglichst vielen (potenziell allen) End­anwendern aufzubauen.

Ein Integrieren nur einiger ausgewählter „Key-User“ ist aus unserer Sicht nicht ausreichend, um die Akzeptanz der einzuführenden neuen Software und ggf. anstehender Prozessänderungen zu erreichen. Vielmehr muss gerade in die gern aufgrund von Zeit-, Geld- und Ressourcenmangel weggelassenen Themenkomplexe Kommunikation und Veränderungsmanagement deutlich mehr investiert werden – und zwar von Beginn des Projekts an.

Es kann nicht zu viel Information und Transparenz zu den bevorstehenden Änderungen geben – nur zu wenig!

Phasen der Sirius- Projektmethodik

Konkret hat es sich auch im vorliegenden Projekt wieder bewährt, auf folgende Punkte in den einzelnen Projektphasen ein ganz besonderes Augenmerk zu legen:

Scoping

• Nehmen Sie sich die Zeit, den Projekt­scope klar und eindeutig zu definieren! Formulieren Sie sehr genau und konkret. Eigentlich selbstverständlich. Schreiben Sie aber auch explizit auf, was Sie NICHT im Scope haben.
• Formulieren Sie die Ziele und NICHT-Ziele des Projekts – zusätzlich zum Projektscope.
• Stellen Sie sicher, dass Sie Scope und Ziele mit allen wesentlichen Stakeholdern abgestimmt haben.
• Kommunizieren Sie Scope und Ziele bei jeder Gelegenheit. Leiten Sie jeden Workshop mit einer kurzen Folie ein, in der Sie nochmals klarmachen, was im Scope des Projekts ist und was eben nicht.

Design-Phase

• Stellen Sie sicher, dass in der Design-Phase eine repräsentative Auswahl an Anwendern beteiligt ist: Die im Kernteam des Projekts beteiligten Key-User sind in der Regel nicht ausreichend, um beim Design alle Nutzergruppen ausreichend berücksichtigt zu haben. Denken Sie explizit auch an Teams und Anwender in anderen Regionen – diese arbeiten ggf. anders als die dem Projekt zugewiesenen Experten und haben somit auch andere Anforderungen!
• Machen Sie lieber ein paar Design-Workshops mehr als einen zu wenig: Es geht in den Workshops nicht nur darum, die notwenigen Anforderungen an die Software herauszuarbeiten – die Workshops dienen auch als Kommunikationsmittel, um das Projekt und dessen Ziele an die (Schlüssel-)Anwender zu transportieren.Bereits in dieser Phase können Sie die Akzeptanz deutlich erhöhen, wenn Sie eine möglichst große Anzahl an Nutzern oder zumindest Repräsentanten der verschiedenen Nutzergruppen beteiligen.
• Integrieren Sie aktiv und explizit sehr kritische Anwender: Gern wird bei der Zusammenstellung von Projektteams und Workshop-Teilnehmern ein Bogen um die als „schwierig“ geltenden Mitarbeiter gemacht. Es kostet Zeit und Anstrengung, auch die problemorientierten Mitarbeiter abzuholen.Aber Sie werden so oder so, spätestens zum Rollout, mit deren Einwänden konfrontiert. Zu diesem frühen Zeitpunkt haben Sie aber noch die Chance, aktiv darauf zu reagieren und Einwände zu moderieren.
• Denken Sie an den Betriebsrat. Sehen Sie dies nicht als Hindernis, sondern als Chance, weitere Pluspunkte für die Akzeptanz Ihres Vorhabens zu sammeln.

Development Sprints

Nutzen Sie die Sprint Reviews dafür, wofür Sie gedacht sind: Verproben Sie die gelieferte (Teil-)Entwicklung mit der Erwartungshaltung der Anwender an die gelieferte Funktion.

Halten Sie die Teilnehmergruppe in den Review Sessions also nicht zu klein und integrieren Sie nicht nur die Key-User, sondern laden Sie weitere Anwender zu den Sessions ein. Dokumentieren Sie die Review Session.

Im vorliegenden Projekt wurde jedes Sprint Review als internationale Websession durchgeführt und aufgezeichnet. So geben Sie auch Stakeholdern aus anderen Regionen der Welt die Gelegenheit, den Review im Nachgang anzuschauen. Das ist deutlich besser, als „nur“ einen Foliensatz und ein Protokoll im Anschluss zu verschicken.

Testen Sie die gelieferte (Teil-)Funktion direkt in einer Review-Phase nach dem Sprint Review mit einer definierten Testgruppe. In einem Sprint Review Meeting, egal wie lang es ausfällt, fallen Ihnen schlicht nicht alle Punkte auf.

Erst wenn Sie mit mehreren Usern die gelieferte Softwarekomponente „ausprobieren“, fallen Ihnen Fehler, Design-Mängel und konzeptionelle Schwächen auf.

Process & Integration Tests

Testen Sie so früh wie möglich einen kompletten Prozessdurchlauf. Sobald die Summe der gelieferten Teil-Entwicklungen aus den Sprints einen kompletten Prozesstest zulässt, testen Sie diesen auch – erneut mit mehreren Anwendern. Was in den einzelnen Sprint Tests isoliert gut funktioniert hat, muss im kompletten Prozessdurchlauf nicht automatisch auch gut funktionieren.

Dehnen Sie für die abschließenden Integrations- und UATs die Gruppe der Tester aus. Lassen Sie hier auch Anwender testen, die an den Sprint Tests nicht beteiligt waren. Es zeigt sich immer wieder, dass die Anwender, die in allen Sprint Reviews beteiligt waren, gegen Ende die Software in ihrer Gesamtheit nicht mehr unvoreingenommen beurteilen.

Roll0ut

Nutzen Sie für den Roll0ut der neuen Software alle verfügbaren modernen Medien in Ihrem Trainingskonzept. Erstellen Sie neben dem obligatorischen Handbuch auch Kurzversionen für die wesentlichen Funktionen, die die Anwender in ihrem typischen Arbeitsalltag benötigen.

Fertigen Sie kurze Tutorial-Videos für die wichtigsten Funktionalitäten an. Diese müssen nicht aufwändig produziert werden – im Gegenteil, es fördert die Akzeptanz, wenn „Mitarbeiter für Mitarbeiter“ diese Videos besprechen.

Nutzen Sie eine zentrale Sammelstelle für alle Informationen zu Ihrem Projekt – inklusive der Trainingsmaterialien, FAQs, Tutorials, Websessions, News etc. Kommunizieren sie diese, z.B. Intranet-Seite, bereits während der gesamten Projektlaufzeit immer und immer wieder. Binden sie den Link zu dieser Seite in jedes von ihrem Projekt veröffentlichtes Material ein.

Berücksichtigen Sie für die Trainings die Zeitzonen der Mitarbeiter in den anderen Lokationen. Es wird immer gern vergessen, dass eine Websession zu einer für uns in Deutschland komfortablen Zeit für Kollegen in Asien oder den USA zu einer Nachtveranstaltung wird.

Es steigert die Akzeptanz Ihres Projekts deutlich, wenn Sie diesen Umstand aktiv berücksichtigen und explizit Trainings und Infosessions auch zu komfortablen Zeiten für die im Ausland lebenden Anwender einplanen.

Begleitende Kommunikation, Marketing & Organizational Change Management: Die Aktivitäten in diesem Block werden immer wieder vernachlässigt, sind sie doch in den Augen vieler nur unnötiger Ballast und Kostentreiber. Genau das Gegenteil ist jedoch der Fall!

Hier entscheidet sich, ob das Projekt am Ende erfolgreich sein wird oder nicht:

Informieren Sie die Organisation über das Projekt und die damit verbundenen Ziele. Wiederholen Sie dies regelmäßig und berichten Sie über die Fortschritte. Nutzen Sie dafür, gerade in Großunternehmen, alle Ihnen zur Verfügung stehenden Mittel.

Je mehr Transparenz, desto einfacher haben Sie es während des Rollouts. Im konkreten Fall wurden neben regelmäßigen Newslettern monatlich auch kurze Info-Websessions zum Projekt abgehalten – für alle potenziell betroffenen Anwender.

Jeder durfte teilnehmen. Die Sessions wurden weiterhin aufgezeichnet, um auch wirklich allen Anwendern die Möglichkeit zu bieten, die Sessions zu sehen.

Zusätzlich wurden große „Fact Sheets“ in den Teamräumen der verschiedenen Lokationen aufgehängt, die prägnant auf einer Seite alle wichtigen Informationen zum Projekt darstellten. Darüber hinaus hat das Projektteam viele Teams in ihren Teammeetings besucht und das Projekt vorgestellt.

Zum Thema Kommunikation kann nur gesagt werden: Zu viel gibt es nicht! Sprechen Sie über Ihr Projekt und die damit verfolgten Ziele so viel und so oft wie möglich – beginnen Sie dies bereits mit dem Start des Projekts.

Denken Sie an den Veränderungsprozess, den jeder Mitarbeiter durchlaufen muss und wird. Versuchen Sie ihn dabei so gut wie möglich transparent mit Informationen zu versorgen.

Fazit

Agile Methoden in Entwicklungsprojekten haben es deutlich einfacher gemacht, zielgerichtet zum gewünschten Endergebnis zu kommen. Mit der Fertigstellung der Software zum Stichtag X wird aber das Projekt noch lange nicht automatisch zu einem Erfolg.

Erst wenn die Anwender die neue Software akzeptieren und im Idealfall sogar als Unterstützung in ihrer täglichen Arbeit wahrnehmen, kann das ganze Projekt als Erfolg betrachtet werden – das ist jedenfalls das Projektverständnis von Sirius.

Sobald es um Menschen und ihren individuellen Umgang mit Veränderung geht, helfen agile Methoden nur eingeschränkt weiter. Menschen sind, was Veränderungen angeht, nur bedingt „agil“.

Klassische Projektmethoden bieten hier zum Glück immer noch sinnvolle und richtige Konzepte – man muss sie nur auch ernsthaft anwenden. Mit der richtigen Kombination aus den richtigen Methoden für den richtigen Zweck wird auch das nächste Projekt wieder ein Erfolg.