Bei der Einführung agiler Methoden gibt es diverse Stolpersteine und Herausforderungen die man zwangsläufig bewältigen muss. Im folgenden Beitrag nenne ich 12 Erfolgsfaktoren, wie eine erfolgreiche Einführung gelingen kann.
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 regelmäßige Feedbackschleifen einzubauen. Diese Feedbackschleifen unterstützen dabei zu reflektieren ob die Antworten immer noch valide sind. Haben sich neue Erkenntnisse ergeben? Haben sich Rahmenbedingungen verändert? Sind einige Ziele mittlerweile erreicht worden? Mit der Beantwortung dieser Fragen bietet sich die Möglichkeit regelmäßig den Weg dynamisch anzupassen.
Versucht man in einem großen Wurf direkt ganze Abteilungen oder die gesamte Organisation zu verändern handelt man sich zwangsläufig Probleme ein. Diese Probleme führen im schlimmsten Fall zu einer Lähmung der gesamten Organisation. Deshalb rate ich jedem, zunächst mit einem Team zu starten. Während dieses Team agil arbeitet und lernt wird es jede Unterstützung brauchen. Gemeinsam mit dem Team wird dann erarbeitet wie die agile Arbeit in der Organisation verbessert werden kann. Probleme, die dieses Pilot Team hat, löst man. Durch das konsequente Aufdecken und Lösen dieser Probleme verändert sich die Organisation schon fast von alleine. Es entstehen viele neue Impulse und Erkenntnisse, die auf dem weiteren Weg zu einer agilen Organisation von unschätzbarem Wert sind.
Bei der Einführung von Agilität 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 sind die aktuellen Probleme, die durch Agilität gelöst werden sollen? Im Idealfall wird mit den Mitarbeitern zusammen die Zielsetzung erarbeitet. Wohin soll die agile Transformation gehen (agile Arbeitsweisen in einzelnen Projekten bis hin zur Netzwerkorganisation)? Ein gutes Format zum Start ist ein Open Space. Hier kommen alle interessierten Mitarbeiter zusammen um in kleineren Gruppen alle relevanten Themen zu bearbeiten und Lösungen zu kreieren.
Es ist nur bedingt hilfreich, ausschließlich die direkt Betroffenen Mitarbeiter in agilen Methoden zu trainieren. Ebenso wichtig ist es alle anderen Beteiligten einzubeziehen. Das sind bspw. die Menschen die Schnittstellen zu den agilen Teams haben. Ebenso 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.
Falls die Wahl auf Scrum als Framework fällt, ist es hilfreich, vor allem zu Beginn, sich komplett an den Scrum Guide zu halten. Die Rollen Scrum Master und Product Owner konsequent einzusetzen. (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, stellt man sich besser die Frage, ob Scrum tatsächlich das richtige Vorgehen ist. Vielleicht ist Kanban der erfolgsversprechendere Weg. Kanban verfolgt einen evolutionären Ansatz, der mit der Zeit verbessert wird, während Scrum direkt beim Start auf einen Paradigmenwechsel setzt.
Viele Berater versprechen, dass man auch eine große Transformation einfach starten kann und sofort agil wird. Dabei setzen sie häufig das „Spotify-Modell“ und das Scaled Agile Framework (SAFe) ein. Das sog. Spotify Modell ist ca. 2012 bei Spotify entstanden und war das Ergebnis von vielen Experimenten. Diese haben mal besser und mal weniger gut funktioniert. Alle haben aber darauf eingezahlt, 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. Durch die vielen Rollen, entsteht oft der Impuls, die vorhandenen Rollen einfach umzubenennen. Am Ende wundert man sich dann, 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. Das Lernen des Lernens! 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 Hauptprobleme. Durch die vermeintliche Abkürzung fehlt häufig die Fähigkeit einfach mal innezuhalten, zu reflektieren und den Weg anzupassen. Weitere Details zu dem Thema finden sich hier
Nicht nur die Arbeitsweise sondern auch die Art wie Produkte entwickelt ändert sich im Zug der Einführung Agilität. Früher entstanden komplette Konzepte, die man danach umgesetzt und schließlich an den Kunden geliefert hat. Beim agilen Arbeiten hingegen entsteht in jeder Iteration eine komplett funktionsfähige Version der Software. 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 man nutzen kann. Schreibt man weiterhin komplette Konzepte und liefert die Software erst nach der Fertigstellung von mind. 100% der erdachten Features, 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, immer wieder die wichtigeren Features von den weniger wichtigen zu unterscheiden und entsprechend zu priorisieren und auszuliefern.
Wie das geht, könnt Ihr hier nachlesen.
Agile Produktentwicklung ist sehr stark auf Kundenfeedback angewiesen. Nur wenn wir unsere Produkte dem Kunden zeigen und ihn dazu befragen (oder sein Verhalten messen), können wir die wichtigen von den weniger wichtigen Dingen unterscheiden. 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? Man entwickelt jahrelang Produkte 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.
Agiles Arbeiten in der Entwicklung einzuführen ist meist noch relativ trivial und geht recht zügig von statten. Häufig kann man beobachten, 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 zu machen. Um die gesamte Wertschöpfung zu beschleunigen muss man den gesamten Ablauf von der ersten Idee bis zur Auslieferung an den Kunden betrachten.
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.
Auf dem Weg zu einer agilen Organisation probiert man zwangsläufig viele Dinge aus von denen einige funktionieren und einen voran bringen.Anderen Experimente scheitern und man merkt, 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. 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.
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. 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. Schlimmstenfalls kommt es dadurch zum kompletten Stillstand. Deshalb sollten auch immer bei allen 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 findet sich am besten in Kollaboration der agilen und der nicht agilen Teams. 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 Abteilungs-/Teamleiter diese Absprachen für Ihre Mitarbeiter treffen.
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.
Hat Dir der Artikel gefallen? Dann würde ich mich sehr freuen wenn Du ihn auf Deinen Social Media Kanälen teilst oder mir eine Nachricht zukommen lässt.
Beitragsbild von eberhard grossgasteiger auf Pexels
Mach Dein nächstes Projekt zum vollen Erfolg
Über 70 % aller großen IT-Projekte scheitern, weil die Fehler an der falschen Stelle gesucht werden. Lerne die wahren Erfolgstreiber für Leuchtturm-Projekte kennen.
Im E-Book "Endlich erfolgreiche Projekte" decken wir die 3 Hauptgründe für das Scheitern von Projekten auf!
KOSTENFREIES E-BOOK
Sichere Dir jetzt unser Gratis E-Book "Endlich erfolgreiche Projekte"
