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.
