Agile Transformation beginnt im Kopf
Die sechs größten Vorurteile zum Thema Agilität
Das Thema Agilität und agile Transformation ist bei den meisten Unternehmen als Alternative zu klassischen Arbeitsabläufen angekommen. Doch bis heute halten sich sowohl bei den Befürwortern als auch den Kritikern des agilen Arbeitens hartnäckig einige Irrtümer.
Agilität ist chaotisch
Bis heute glauben viele Entscheider in Unternehmen, dass agil zu arbeiten bedeutet, dass es keine festen Verantwortlichkeiten gibt. Folge daraus sei ein organisatorisches Chaos, das keiner überschauen kann. Tatsächlich aber gibt es auch bei der agilen Arbeitsweise Vorgaben, die erfüllt werden müssen. Nicht festgelegt wird die Art und Weise, wie diese umzusetzen sind. Die Verantwortung dafür liegt im Team. Vorteil ist, dass es für Schuldzuweisungen keine Grundlage gibt und der Fokus auf der Lösung des Problems liegt.
Wenn ich agile Methoden anwende, bin ich agil
Ein weiterer Irrglaube besteht darin, dass es bereits ausreicht, agile Methoden wie Scrum oder ein Kanban Board einzuführen, um von den Vorteilen des agilen Arbeitens profitieren zu können. Doch zur Agilität gehört weit mehr. Voraussetzung für die gelungene Umsetzung der agilen Transformation ist, dass diese in die Unternehmensziele aufgenommen wird. Denn nur so kann sich ein entsprechendes agiles Mindset bei den Mitarbeitern und der Unternehmungsleitung entwickeln.
Agilität funktioniert nur bei der Software-Entwicklung und bei StartUps
Wenn man von dieser Voraussetzung ausgeht, ist auch schnell klar, dass agiles Projektmanagement in vielen Bereichen funktioniert. Denn Agilität ist eine Sache der Mentalität und bedeutet vor allem, dass alle Mitarbeiter bereit sind, Verantwortung zu übernehmen und ihre Prozesse selber so zu gestalten und zu adaptieren, wie es die zu lösenden Aufgaben erfordern. Dadurch können Unternehmen besser auf die sich immer schneller ändernden Umstände reagieren.
Agiles Arbeiten ist die Antwort auf alles
Im Umkehrschluss bedeutet das jedoch nicht, dass agiles Arbeiten für jedes Unternehmen oder jede Aufgabenstellung sinnvoll sind. Funktionieren die vorhandenen Strukturen und Abläufe gut, besteht per se kein Grund, diese anzupassen, da Wandel Unruhe verursacht und begleitet werden muss. Eine regelmäßige Überprüfung der bestehenden Organisation ist immer sinnvoll, denn wie die Corona-Pandemie gezeigt hat, können sich die Umstände schnell ändern.
Agile Transformation ist in drei Monaten erledigt
Die Erfahrung mit der Pandemie und die damit verbundenen, notwendigen Anpassungen haben gezeigt, dass Veränderung Zeit braucht. Das Gleiche gilt umso mehr bei der Einführung der agilen Arbeitsweise. Es müssen nicht nur die Abläufe angepasst, sondern die gesamte Unternehmenskultur gewandelt werden. Die Transformation hin zum agilen Arbeiten ist ein ständiger Prozess, bei dem das in jedem Unternehmen existierende Narrativ neu erarbeitet und entwickelt werden muss.
Agilität braucht keine Führung mehr
Mit dem letzten Irrtum schließt sich der Kreis. Denn natürlich benötigen agile Organisationen Führung. Allerdings ist das Verständnis einer Führungskraft ein anderes. Sie ist Teil des Teams und wird zum Coach und schafft die Rahmenbedingungen, damit die Teammitglieder ihre Arbeit möglichst ungestört umsetzen können. Wichtig hierbei ist eine Kommunikation auf Augenhöhe und eine ausgeprägte Toleranz für Fehler. Sieht man sich diese Irrtümer genauer an, lassen sich daraus mehrere Schlussfolgerungen ziehen: Erstens: jedes Unternehmen sollte für sich prüfen, ob und wie weit agiles Arbeiten für die eigene Aufgabenstellung Sinn macht. Zweitens: Wer sich für die agile Transformation entscheidet, sollte sich darüber im Klaren sein, dass sich neben den äußeren Strukturen auch die Einstellung der Mitarbeiter ändern muss. Denn Agilität beginnt im Kopf. Deshalb braucht der agile Wandel Zeit und oft Unterstützung von außen.
Inhalt:
Skalierungsframeworks Nexus, LeSS und SAFe
Tabellarische Gegenüberstellung
Megatrends wie die Digitalisierung, die Globalisierung und die Flexibilisierung verändern unsere Arbeitswelt heute rapide. Die Erwartungen und Ansprüche der Kunden passen sich in immer kürzeren Abständen den digitalen Möglichkeiten an. Auch an Produkte werden permanent neue Anforderungen gestellt. Teams können über die ganze Welt verstreut sein und trotzdem hervorragend zusammenarbeiten. Alles wird schneller, interaktiver und agiler – entsprechend werden auch die Produktentstehungszyklen immer kürzer.
Eine Methode, die diesen Anforderungen gerecht wird – heute in aller Munde – ist Scrum. Jedoch! Was tun, wenn das Produkt so groß und umfassend ist, dass viele Teams, unterschiedliche Fachbereiche oder gar die ganze Organisation daran zusammenarbeiten soll? Die passende Skalierung für eine effiziente und zufriedenstellende Zusammenarbeit bietet den Teams Orientierung und Unterstützung. Aber: wie entscheidet man, welches skalierbare Framework das Beste ist? Welches Framework kann genutzt werden, wenn die Prozesse von Scrum für 3, 4, 5, … Teams zu klein gedacht sind? Die Suche nach dem optimalsten Vorgehen stellt für viele eine große Herausforderung dar.
Um Ihnen einen groben Überblick über die gängigen skalierbaren Frameworks zu bieten, habe ich eine Übersicht zusammengefasst, die die Unterschiede der einzelnen Frameworks herausstellt: Nexus (Framework for Scaling Scrum), LeSS (Large-Scaled Scrum) und SAFe (Scaled Agile Framework).
Nexus
Der Vater des Frameworks Nexus, Ken Schwaber, bezeichnet dieses selbst als Exoskelett, das drei bis neun Scrum-Teams verbindet um ein Produkt zu entwickeln. Es ist ein Prozess-Rahmenwerk auf Basis des agilen Manifests und Scrum.
Nexus besticht durch seine Schlichtheit. Scrum wird in seinen Rollen, Events und Artefakten skaliert. Der Schwerpunkt liegt auf teamübergreifenden Abhängigkeiten und Integrationsthemen, die bei der Skalierung über mehrere Teams auftreten und legt Wert auf Transparenz.
LeSS
LeSS möchte durch seine Einfachheit bestechen (more with less) und setzt auf klare Prinzipien. Die Teams unter einem Product Owner sind für die komplette Produktentwicklung zuständig und tragen eine große Verantwortung, die auch die Kommunikation Richtung Kunden und Umfeld einschließt. Bei einer Größe von mehr als acht Teams wird das System zu LeSS Huge in einer zusätzlichen Skalierungsphase expandiert.
SAFe
SAFe ist ökonomisch ausgerichtet und hat die stetige Verbesserung der Wertströme im Auge. Mit seiner hierarchischen Struktur betrachtet es über das Team hinaus die Programm-, Solution und Portfolio-Ebenen sowie die Gesamteinbettung in das Unternehmen. Rollen, Methoden und Artefakte sind klar beschrieben und unterstützen die Einführung in das skalierte agile Arbeiten.
Diese Gegenüberstellung soll Ihnen eine Orientierung bieten, damit Ihnen die ersten Schritte bezüglich der Entscheidung in welche Richtung Sie gehen wollen – Nexus, LeSS oder SAFe – leichter fallen. Auf die Vor- und Nachteile sowie die Grenzen dieser Frameworks ist hier bewusst nicht eingegangen worden.
Jedoch, bevor Sie sich für eines der Skalierungsframeworks entscheiden können, müssen Sie genau überlegen welches zu Ihrer Unternehmenskultur und Ihren Unternehmenswerten passt. Prüfen Sie, was Ihr Ziel ist, was wollen Sie erreichen? Wie sieht das Umfeld aus und welche agilen Methoden kommen in Ihrem Unternehmen bereits zum Einsatz?
Meine Empfehlung ist, aus den bekannten Frameworks die Elemente, die am besten zu Ihrer Organisation passen, herauszunehmen und ein agiles Skalierungsframework zu adaptieren.
Einsatz?
Quellen:
SAFe – https://www.scaledagileframework.com/, zuletzt geprüft am 30.09.2019
LeSS – https://less.works/de, zuletzt geprüft am 30.09.2019
THE NEXUS™ GUIDE – https://www.scrum.org/resources/nexus-guide, zuletzt geprüft am 30.09.2019
Agile Skalierungsframeworks: Safe, Less und Nexus im Vergleich – https://t3n.de/news/agile-skalierungsframeworks-safe-less-nexus-1150190/, zuletzt geprüft am 30.09.2019
Das beste agile Framework – 5 Large-Scale Ansätze im Überblick – https://www.mosaiic.com/agile_framework/, zuletzt geprüft am 30.09.2019
Fehlerkultur - eine Klarstellung
Was ist ein Fehler
Ein Fehler ist eine Abweichung (Ist-Wert) von einem vorab als richtig definierten Zustand (Soll-Wert). Der Prozess des Organisierens macht allerdings aus der Möglichkeit, sich freiwillig entweder für Alternative A oder für Alternative B zu entscheiden, ein „Nur-A!“. Organisieren ist also Alternativvernichtung. Dafür gibt es durchaus gute Gründe: Mal geht es darum, Gefahren zu vermeiden, mal darum, Prozesse effizienter zu gestalten, mal darum, Schritte zu vereinfachen. Wer nach der Alternative B handelt, begeht dann einen Fehler. …
Der Einzelne hat also in einer konkreten Situation eine angemessene Entscheidung zu treffen (das nennt man Verantwortung), die wird aber durch zu straffe Organisation allerdings zur Sorgfaltspflicht verengt. Es geht dann nicht mehr darum, situativ die richtigen Dinge zu tun. Sondern nur noch darum, die Dinge richtig zu tun – um sich hinterher rechtfertigen zu können. Vor jedem Handeln wird dann immer erst nach der Richtlinie, dem Präzedenzfall, dem Handbuch gefragt. Das ist der Preis, der für die Alternativvernichtung fällig ist.“ Es bleibt dabei, bei klaren Regeln, gilt es diese einzuhalten und alles zu tun Fehler zu vermeiden, wenn sie dann aber doch passieren, sind diese zu analysieren.
Wann spricht man von einem Experiment?
Misslingt mal der Versuch etwas Neues zu wagen oder tritt nicht das gewünschte Ergebnis ein, sollte man nicht von einem Fehler sprechen, sondern von Experimenten. „Bei Experimenten, ist das Ergebnis immer offen. Man kann vorab nicht wissen, ob es funktioniert oder nicht. Es hat zuvor keine Entscheidung zwischen Ist- und Soll-Wert gegeben, weil weder der eine noch der andere bekannt ist. Man hat lediglich eine vage Vorstellung von etwas, das funktionieren könnte. Aber was und wie genau, das kann man per Definition nicht wissen.“ Ein Experiment, das scheitert, ist kein Fehler. Es hat bloß nicht das gewünschte Ergebnis gebracht.
Alles Innovative ist auch an das Scheitern gebunden, an den Misserfolg – aber nicht an den Fehler. Es braucht vielleicht erst ein paar Misserfolge, um am Ende wirklich erfolgreich zu sein. Wenn agile Transitionen nicht gleich funktionieren, wird schnell vom Management behauptet es war ein Fehler, ich sage nein, denn um im Markt zu bestehen sind Innovationen und Schnelligkeit gefragt. Es gibt hierbei kein richtig oder falsch, aber um ganz vorne mitzuspielen, reicht es nicht Fehler zu vermeiden, man muss auch etwas riskieren, es wäre ein Fehler es nicht zu probieren.