12 Tipps die, die Erfolgswahrscheinlichkeit einer agilen Transformation um 100% erhöhen

Bei der Einführung agiler Methoden gibt es diverse Stolpersteine und Herausforderungen die man zwangsläufig bewältigen muss. Im folgenden Beitrag gebe ich 12 Tipps, wie eine erfolgreiche agile Transformation gelingen kann.

Agile Transformation braucht die richtigen Beweggründe.

1. Start with why

Wieso wollen wir eigentlich agil arbeiten?
Welche Probleme, die wir heute haben, wollen wir mit Agilität lösen?
Welche Ziele wollen wir erreichen?
Was sind wir tatsächlich bereit an unserer Arbeitsweise, an unserer Organisation, Prozessen und nicht zuletzt an uns selbst zu verändern?
Mit den Erkenntnissen, die durch die Beantwortung dieser Fragen entstehen, wird man in die Lage versetzt jederzeit die aktuelle Position und den eingeschlagenen Weg zu überprüfen. Es ist empfehlenswert, auf dem Weg zur agilen Transformation regelmäßige Feedbackschleifen einzubauen und zu reflektieren ob die Antworten immer noch valide sind, ob sich neue Erkenntnisse ergeben oder sich Rahmenbedingungen verändert haben oder Ziele evtl. sogar schon erreicht worden sind.

2. Start im Kleinen

Versucht man in einem großen Wurf direkt ganze Abteilungen oder die gesamte Organisation zu verändern handelt man sich zwangsläufig Probleme ein, die im schlimmsten Fall zu einer Lähmung der gesamten Organisation führen können. Deshalb rate ich jedem, zunächst mit einem Scrum Team zu starten und es eine Weile agil arbeiten zu lassen und dabei zu lernen. Das Team wird bei seiner Reise jede Unterstützung brauchen. 

Gemeinsam mit dem Team wird dann erarbeitet wie die agile Arbeit in der Organisation verbessert werden kann, in dem Probleme, die dieses Pilot Team hat, gelöst werden. Alleine durch dieses eine Team werden schon extrem viele Learnings stattfinden und neue Impulse für Veränderungen in der Organisation zusammen kommen, die auf dem weiteren Weg zu einer agilen Organisation von unschätzbarem Wert sind.

3. Einbindung aller Beteiligten

Bei der Einführung von Agilität nach Scrum im Unternehmen sollen nach Möglichkeit so viele Mitarbeiter wie möglich eingebunden werden. Ihnen muss der Grund erklärt werden, warum das passieren soll, was die aktuellen Probleme sind, die durch eine agile Transformation gelöst werden sollen. 

Im Idealfall wird mit den Mitarbeitern zusammen die Zielsetzung erarbeitet, bis wohin soll die agile Transformation gehen (agile Arbeitsweisen in einzelnen Projekten bis hin zur Netzwerkorganisation). Ein gutes Format zum Start ist ein Open Space, in dem alle Mitarbeiter zusammen kommen und in kleineren Gruppen alle relevanten Themen bearbeiten und Lösungen kreieren.

4. Training für alle Beteiligten

Es ist nur bedingt hilfreich, wenn ausschließlich die direkt Betroffenen Mitarbeiter in agilen Methoden trainiert werden. Ebenso wichtig ist es alle anderen Beteiligten einzubeziehen, also die Menschen die Schnittstellen zu den agilen Teams haben genauso wie das Management, das eine Vorstellung davon haben muss, wie agiles Arbeiten funktioniert. Passiert das nicht, kann es passieren, dass die neue Arbeitsweise immer wieder (unbewusst) torpediert wird, was zu Frust bei allen Beteiligten führt.

5. An den Scrum Guide halten

Falls die Wahl auf Scrum als Framework fällt, sollte man sich, vor allem zu Beginn, komplett an den Scrum Guide halten. Die Rollen Scrum Master und Product Owner sollten so wie beschrieben sind besetzt und gelebt werden. (Nein, der Product Owner kann nicht auch Scrum Master sein und diese Rolle ist auch nicht optional). Alles was im Scrum Guide beschrieben ist, ist wichtig und kann nicht weggelassen werden. 

Entsteht der Impuls davon abzuweichen, sollte man sich die Frage stellen, ob Scrum tatsächlich das richtige Vorgehen ist, oder ob vielleicht Kanban der erfolgsversprechendere Weg ist. Kanban verfolgt einen evolutionären Ansatz, der mit der Zeit verbessert wird, während Scrum direkt beim Start auf einen Paradigmenwechsel setzt.

6. Es gibt keine Abkürzungen

Viele Berater versprechen, dass man auch eine große agile Transformation einfach starten kann und sofort agil wird, wenn man auf bspw. das „Spotify-Modell“ und das Scaled Agile Framework (SAFe) setzt. Das sog. Spotify Modell ist ca. 2012 bei Spotify entstanden und war das Ergebnis von von vielen Experimenten, die mal gut, mal weniger gut funktioniert haben und alle darauf einzahlten, die damaligen Probleme und Herausforderungen von Spotify zu lösen. 

Falls man also vor den gleichen Herausforderungen steht wie Spotify 2012 kann man auf das Modell setzen, ansonsten sollte man es lieber sein lassen. SAFe verleitet in vielen Fällen dazu, dass man seine Organisationsstruktur gleich lässt, Rollen einfach umbenennt und sich am Ende wundert, dass sich eigentlich kaum etwas geändert hat, obwohl man doch eigentlich agil sein wollte.

Beide Modelle haben gemeinsam, dass nach dem „Rollout“ ein essentieller Lernschritt fehlt, nämlich der, wie diese Modelle entstanden sind. Die Modelle sind durch konsequentes Inspect & Adapt entstanden. Man hatte eine Herausforderung zu bewältigen und hat dafür eine Lösung gesucht. Das ist eines der Hauptproblem, durch diesen abgekürzten Weg fehlt häufig die Fähigkeit einfach mal innezuhalten, zu reflektieren und den Weg anzupassen. Weitere Details zu dem Thema finden sich hier

7. Änderung der Art und Weise, wie Produkte entwickelt werden

Nicht nur die Arbeitsweise sondern auch die Art wie Produkte entwickelt ändert sich im Zug der Einführung Agilität. Wo früher komplette Konzepte erzeugt wurden, die dann in die Umsetzung gingen und irgendwann an den Kunden ausgeliefert wurden, wird beim agilen Arbeiten in jeder Iteration ein komplett funktionsfähiges Inkrement der Software ausgeliefert. Potentiell kann also alle 1-4 Wochen ein Release an den Kunden geliefert werden und das von Anfang an. 

Das eröffnet komplett neue Möglichkeiten, die auch genutzt werden müssen. Werden weiterhin komplette Konzepte geschrieben und die Software erst nach der Lieferung von mind. 100% der erdachten Features ausgeliefert, wird die ganze Kraft der agilen Methoden nicht im Ansatz spürbar. Es ist vergleichbar mit dem Kauf eines Ferraris, den man hauptsächlich dazu nutzen möchte einen Wohnwagen zu ziehen. Kann man machen, muss aber nicht sein und dem Ferrari tut es auch nicht gut. 

Essentiell ist es, dass immer wieder die wichtigeren Features von den weniger wichtigen unterschieden werden können und entsprechend priorisiert und auszuliefern. Wie das geht könnt könnt Ihr hier nachlesen. Ausserdem werde ich auf der diesjährigen Modern RE eine Session zum Thema Impact und Story Mapping geben, wo ich das Thema Priorisierung nochmal eingehender betrachten werde.

8. Einbeziehung der Kunden

Agile Produktentwicklung ist sehr stark auf Kundenfeedback angewiesen. Nur wenn wir unsere Produkte dem Kunden zeigen und ihn dazu befragen (oder messen), können wir die wichtigen von den weniger wichtigen Dingen die entwickelt werden sollen. Wie häufig passiert es, dass Produkteigenschaften, die sich auf dem Papier großartig anhören in der Realität von den Kunden überhaupt nicht genutzt werden? 

Produkte werden jahrelang entwickelt und am Ende fehlt der Markt und kein Kunden möchte das tolle Produkt haben. Um dem entgegenzuwirken ist es unglaublich wichtig die potenziellen Kunden und Nutzer so früh wie möglich ins Boot zu holen. Sei es durch Prototypen, Testprogramme, Befragungen. Am Besten mit funktionierenden Produkten, nur so könnt Ihr echtes Feedback bekommen und das Produkt stetig an die Kundenanforderungen anpassen.

9. Betrachtung der gesamten Wertschöpfungskette

Agiles Arbeiten in der Entwicklung einzuführen ist meist noch relativ trivial und geht recht zügig von statten. Was sich aber häufig beobachten lässt ist, dass das Team scheinbar nicht weiter kommt. Die Entwicklung der Produkte ist von der Idee bis zur Auslieferung an den Kunden kein Stück schneller geworden. Die Leistung des Teams scheint zu stagnieren. 

Deshalb macht es nur bedingt Sinn ausschließlich einen Teilbereich (bspw. Die Software-Entwicklung) agil machen zu wollen. Um die gesamte Wertschöpfung zu beschleunigen muss auch der gesamte Ablauf wie ein Produkt von der ersten Idee bis zur Auslieferung an den Kunden entwickelt wird betrachtet werden.

Wer trifft wann welche Entscheidungen? Wie lange dauern die einzelnen Prozessschritte?
Wer darf über welche Produkteigenschaften entscheiden?
Dabei wird der Gesamtzeitaufwand von der Idee bis zur Auslieferung betrachtet und gemessen wie groß der Anteil der agilen Teams daran ist. Ist er zu klein, wird man letztendlich mit einem agilem Vorgehen nicht viel gewinnen. Hier gilt es immer die gesamte Wertschöpfungskette anzupassen.

10. Cultural Safety – Etablierung einer Kultur des Lernens und Scheiterns

Auf dem Weg zu einer agilen Organisation muss man zwangsläufig viele Dinge ausprobieren von denen einige funktionieren und einen voran bringen und mit anderen Experimenten wird man scheitern und merken, dass man nochmal zwei Schritte zurück gehen muss. In komplexen, sozialen Systemen wie Organisationen es sind ist dies aber der Einzige Weg herauszufinden was wirklich funktioniert. 

Man kann sich von anderen Beispielen und Best Practices inspirieren lassen, aber was in einer anderen Firma, in einem anderen Team funktioniert muss noch lange nicht im eigenen System funktionieren funktionieren. Umgekehrt ist es im Übrigen genauso, nur weil irgendetwas woanders (oder auch zu einer anderen Zeit) nicht funktioniert hat, heißt das noch lange nicht, dass es nicht im Hier und Jetzt funktionieren kann.

11. Unnötige Prozesse in Frage stellen

Es reicht einfach nicht aus, eine neue Arbeitsweise einzuführen, wenn der komplette Organisationsrahmen mit all seinen Prozessen unangetastet bleibt. Die agilen Teams müssen Prozesse und Rituale aus der alten Welt bedienen und der Rest der Organisation versteht nicht warum die agilen Teams tun was sie tun. Das sorgt auf Dauer nicht nur für extremen Frust sondern auch dafür, dass man auf Sicht genau das Gegenteil von dem erreicht was man eigentlich wollte (man wollte ja agiler und produktiver werden). 

Plötzlich hat man das Schlechte aus beiden Welten (der klassischen und der agilen) verheiratet und es kommt zum kompletten Stillstand. Deshalb sollten auch immer alle Prozesse und Rituale, die die agilen Teams bedienen müssen die Frage gestellt werden: Ist das wirklich notwendig oder gibt es einen anderen, agileren Weg?

Eine Antwort auf diese Frage lassen sich am besten in Kollaboration der agilen und der nicht agilen Teams erarbeiten, sie werden am besten wissen, wie sie sinnvoll zusammenarbeiten und die Bedürfnisse beider Welten vereinbaren können. Diese Kollaboration kann muss unbedingt auf Team bzw. Mitarbeiterebene stattfinden. Es macht keinen Sinn, wenn Abteilungsleiter-/Teamleiter diese Absprachen für Ihre Mitarbeiter treffen.

12. Lern- und Prozessbegleiter

Auch wenn es banal klingt, ein großer Erfolgsfaktor ist es, sich einen externen Begleiter für die Einführung ins Haus zu holen. Ein erfahrener Agile Coach ist jederzeit in der Lage neue Impulse von außen zu setzen, Euch ermutigen Fehler zu machen und nicht zu guter Letzt als Sparringspartner zur Verfügung zu stehen. Wofür es einen Agile Coach sonst noch so gibt, könnt ihr hier lesen.

Thorsten Schiffer – Profil auf www.staryou.de 

Ich bin freiberuflicher (Agile-)Coach, Organisationsentwickler und zertifizierter LEGO Serious Play Facilitator. Mit 20 Jahren Erfahrung in Software Entwicklungsprojekten in verschiedensten Rollen (Entwickler, Architekt, Teamlead) ist es heute meine Herzensangelegenheit Menschen und Organisationen auf Ihrem Weg von „doing agile“ bis hin zu „being agile“ zu begleiten und jeden Tag die Welt ein kleines Stückchen besser zu machen. Für mich ist Agilität dabei kein Ziel sondern nur ein Weg ein großartiges Unternehmen für die Kunden und Mitarbeiter zu sein.

Unter https://thorsten-schiffer.com blogge ich über Agilität, New Work sowie innovative und nachhaltige Geschäftsmodelle.