dot.kunden - LeSS oder SAFe? Das beste Framework?

David Berger
14. Januar 2020

SAFe und LeSS dominieren den Framework-Markt für skalierte Agilität. In diesem Beitrag möchte ich beide Frameworks gegenüberstellen und bei der Auswahl des richtigen Frameworks unterstützen. Willkommen. 

Vorab: Ich bin mit beiden Frameworks vertraut. Ich berate Unternehmen in beiden Frameworks. Ich bin aber nicht mehr oder weniger mit einem Framework "liiert", ich halte keine Aktien und habe keine weiteren Interessen hinsichtlich der Frameworks, die ich hier offenlegen müsste. Ich bin also weitgehend unbefangen und kann hier von meinen Erfahrungen und Beobachtungen beider Frameworks berichten. 

Wie vergleichen?

Ich möchte die beiden Frameworks hinsichtlich folgender Dimensionen vergleichen: 

  • Vorbedingungen: Was sind die Vorbedingungen der Einführung? Wann kann man starten? 
  • Einführung: Wie gestaltet sich die Einführung des Frameworks? Was ist die Einführungsstrategie? 
  • Anwendung: Wie ist die Anwendung des Frameworks? Schwierig, einfach? Welche Herausforderungen sind bei der Anwendung zu berücksichtigen? 
  • Organisation: Wie kann das Framework in die bestehende Organisation integriert werden? Wie hoch sind die eigenen "Organisationsleistungen" des Frameworks? 
  • Kontext: In welchem Kontext ist das Framework prädestiniert?

Vorbedingungen

Was sind die Vorbedingungen der Einführung? Wann kann man starten? Welche Voraussetzungen müssen erfüllt sein? 

LeSS Vorbedingungen

dotag-blog-content-less-adoption-overview

LeSS bedingt keine "Initiative", kein Vorhaben und identifiziert sich auch nicht als einmaliger Prozess, sondern als Haltung. LeSS spricht deswegen auch von der sogenannten Adoption. LeSS verneint auch die "Dichotomie" von Top-Down oder Bottom-Up. LeSS müssen alle wollen. LeSS ist eine Haltung, stets sich weiterzuentwickeln und keinem "Rezept" folgen zu können. Sobald diese Haltung gereift ist, kann die Adoption von LeSS starten. 

SAFe Vorbedingungen

dotag-blog-content-safe-implementation-roadmap

SAFe liefert eine ausführliche Implementation Roadmap. Darin werden die generischen Schritte zur erfolgreichen SAFe-Einführung zusammengefasst. Die Vorbedingung für SAFe ist der sogenannte Tipping Point. Zwei Optionen sind möglich:

  1. Burning Platform: Die Situation ist dermassen vertrackt, siehe auch veraltete Menschen wie Maschinen, dass eine Veränderung geradezu offensichtlich und nicht (mehr) zu leugnen ist. 
  2. Proactive Leadership: Das Management, siehe auch Rolle des Managements, ist prospektiv und propagiert daher eine Veränderung. 

Sind entweder Burning Platform und/oder Proactive Leadership erfüllt, kann die Implementation Roadmap abgefahren werden. Diese startet mit ausgiebigen Schulungen. 

Einführung

Wie gestaltet sich die Einführung des Frameworks? Was ist die Einführungsstrategie? Gibt es eine "Blaupause"? Brauche ich externe Unterstützung?

LeSS Einführung

Die LeSS Einführung hat folgende Schritte:

  1. Ausbildung: Mithilfe eines (externen) Coaches sollen die Schlüsselpersonen angemessen ausgebildet werden. Grosse Beratungsfirmen, die blaupausenhaft LeSS kopieren wollen, sind zu vermeiden
  2. Produkt definieren: Was ist das oder ein Produkt? Diese Antwort begrenzt den (organisatorischen) Umfang der LeSS Adoption. 
  3. Definition of Done definieren: Wann ist eine Aufgabe erledigt? Diese Antwort skizziert die Breite der (IT-)Disziplinen, die in einem LeSS-Team zusammengefasst werden müssen. 
  4. Teams strukturieren: Die Teams sollen sich selber konstituieren, sodass sie alle notwendigen (IT-)Disziplinen beinhalten und möglichst autonom Features entwickeln können. Das unterstützende Tool hier heisst Feature Team Adoption Map
  5. Der PO beliefert das Team: Fokus für die neu strukturierten Teams ist sehr wichtig, daher darf bloss eine Person, der Product Owner, Team-Aufgaben delegieren. Der Product Owner (PO) verantwortet die Priorisierung. 
  6. Projektleitende fernhalten: Typischerweise werden die Aufgaben des Projektleitenden zwischen den LeSS-Teams und dem LeSS-PO aufgeteilt. Aus geschäftspolitischen Überlegungen kann während einer LeSS Adoption die Rolle überdauern, doch diese muss von den LeSS-Teams möglichst ferngehalten werden.

Alles weitere in LeSS ist Bestandteil der kontinuierlichen Verbesserung, die im LeSS-Prozess durch die entsprechenden Retrospektiven abgedeckt ist. 

SAFe Einführung

Die SAFe Implementation Roadmap ist ausführlich und ergiebig. SAFe praktiziert einen typischen Top-Down-Ansatz. Nach den obligaten Schulungen müssen zunächst die Prozesse analysiert werden. Der Operational Value Stream beschreibt den "normalen" Geschäftsprozess, der Development Value Stream den Entwicklungsprozess. SAFe unterstützt hier mit Vorlagen und Referenzmodellen für gewisse Branchen.

Sobald die Systeme und Personen betroffen sind, die in einem Development Value Stream den Operational Value Stream befähigen, können sogenannte Agile Release Trains (ART) geschnitten werden. Ein ART ist eine Sammlung von Systemen und Personen, die irgendwie zusammengehören, technische wie fachliche Abhängigkeiten haben, aber von anderen ART abgegrenzt werden können. 

Danach kann alles recht schnell gehen. Das erste gemeinsame PI Planning besiegelt den Start eines Agile Release Train - kurz ART.

Anwendung

Wie ist die Anwendung des Frameworks? Schwierig, einfach? Welche Herausforderungen sind bei der Anwendung zu berücksichtigen? 

LeSS Anwendung

LeSS ist eine Haltung, die man einnimmt. More with LeSS ist der Slogan von LeSS. Manchmal ist weniger mehr. LeSS hat nicht den Anspruch, alles zu erklären, sondern akzeptiert, dass nicht alles standardisierbar ist. LeSS fokussiert wenige Prinzipien. Ein Prinzip ist die kompromisslose, kontinuierliche Verbesserung - nicht nur des Produktes, sondern auch des Prozesses und der zugrundeliegenden Organisation. Der Nordstern ist stets die Perfektion. 

Die LeSS Strukturen sind minimalistisch. LeSS arbeitet mit "Hinweisen" und "Optionen". Beispielsweise listet LeSS für die Integration und Koordination unterschiedlicher Feature Teams bloss Möglichkeiten wie "Just Talk" oder "Communicate in Code". Die Organisation muss selbst die passende Option wählen. Das bedingt eine lernende Organisation, die hinterfragen und Unsicherheit auch aushalten muss/kann. 

Daher kann LeSS auch die meisten klassisch geführten Unternehmen überfordern. LeSS beschwört stattdessen den mündigen Mitarbeitenden und will ganz im Sinne von Reinventing Organizations Potenziale befreien. 

SAFe Anwendung

Stay SAFe, so das Motto von Dean. SAFe ist "safe". SAFe hat sich in diversen Branchen bewährt. SAFe verspricht eine Blaupause für mehr Engagement, Qualität, Produktivität und zudem eine kürzere Time-to-Market. SAFe beantwortet alle Fragen. Auch für fortgeschrittene Themen - wie beispielsweise Requirements Abstraktion Model oder Arbeitsplatzgestaltung (hier unsere Meinung zum perfekten Scrum Büro) - leitet SAFe eine Anwendung an. Das entspannt und beruhigt Organisationen. SAFe wird thematisch immer breiter. SAFe etabliert sich allmählich als Lean-Agile-Full-Stack-Provider; in SAFe 5.0 werden nochmals weitere Disziplinen angeschlossen

Die wichtigsten Rollen in SAFe haben auch spezifische Ausbildungen. Darin werden die häufigsten operativen Fragen geklärt. Die Schulungsunterlagen sind standardisiert und werden durch den SAFe-Betreiber weiterentwickelt. Auch SAFe-Berater sind zertifiziert und haben unterschiedliche "Ränge". Deren Firmen sind ebenfalls gelistet

Bei all diesen guten Praktiken, erfolgreichen Beispielen, unzähligen Schulungsmaterialien und externen Beratern droht das Risiko der falschen Sicherheit. Dass die Organisation nicht nachhaltig lernt und sich weiterentwickelt, sondern bloss dort SAFe rezitiert, wo es gerade schicklich ist. Die unzähligen halbherzigen und schliesslich halbfertigen SAFe-Implementationen gerade hierzulande mahnen zur Wachsamkeit. Andy vom DasScrumTeam erinnert bei SAFe an Widerstand, Konformität und Verantwortung. 

Organisation

Wie kann das Framework in die bestehende Organisation integriert werden? Wie hoch sind die eigenen "Organisationsleistungen" des Frameworks? Muss ich meine Organisation ändern?

LeSS Organisation

Weil klassische Organisationen den LeSS-Betrieb stören, empfiehlt LeSS eine sofortige organisatorische Anpassung. LeSS stellt daher ein generisches Organigramm bereit. Das Organigramm ist maximal vereinfacht. Die Teams sind autonom und direkt einem Head of Product Group angesiedelt. Der Product Owner ist auf derselben Stufe wie die Teams. Daneben kann noch ein sogenanntes "Undone Department" existieren. Darin können Analysten, Tool- oder Plattform-Spezialisten und andere Spezien vereinigt werden, die nicht gemäss Definition of Done ein lauffähiges Produktinkrement liefern, sondern lediglich den Teams zuarbeiten. 

SAFe Organisation

SAFe hat sich lange Zeit als rein "virtuelle" Ablauforganisation verstanden. SAFe ist somit sehr kompatibel mit der bestehenden Organisation und kann als reine Ablaufschicht aufgetragen werden. In SAFe werden neue Rollen geschaffen, die durch überkommene Rollen besetzt werden können wie z. B. Managers in der Krise. Mit der Version 5.0 hat SAFe allerdings ein neues Prinzip freigegeben, das sich mit der Organisation als solche beschäftigt: Organisiere um Wert.

Darin fordert SAFe die Etablierung eines dualen Organisationsmodells des Unternehmens. Also die SAFe-Ablauforganisation soll sich auch in der Aufbauorganisation wiederfinden, weil ansonsten strukturelle Widersprüche und Reibungen entstehen, die den Fluss (im SAFe konsequent als Flow) stören. Die SAFe Agile Release Trains skizzieren dabei den Organisationsschnitt

Kontext

In welchem Kontext ist das Framework prädestiniert? Für wen eignet sich eher LeSS oder SAFe? Beeinflusst die Art des "Produktes" die Wahl des Frameworks? 

LeSS Kontext

LeSS ist streng. LeSS ist diszipliniert. LeSS ist eine Haltung. LeSS eignet sich somit für einen Kontext mit vergleichsweise hoher Maturität hinsichtlich Menschen wie Maschinen. LeSS ist somit für fortgeschrittene und vor allem komplexe Kontexte ausgezeichnet. Das ist tendenziell in Organisationen mit stabilem Purpose möglich. Organisationen, die bereits allgemeinen an ihrem Purpose zweifeln, erfüllen tendenziell nicht die Anforderungen an Menschen wie Maschinen. 

Eine klare Definition des "Produktes" ist bekanntlich für LeSS unumgänglich. Also überall dort, wo das Produkt nicht umreisst werden kann, ist LeSS ebenfalls riskant einzuführen, siehe auch Adrians Blog über die Frage "Was ist ein Produkt?".

SAFe Kontext

SAFe ist nicht auf Produkte oder Branchen, sprich Kontexte, beschränkt. Die Vorbedingungen für SAFe sind trivial. Man muss bloss "wollen". SAFe kann auch mit nicht-maturen Organisationen gestartet werden. SAFe kann als grossartige und vor allem gemeinsame Lerngeschichte erzählt werden. 

Und wir?

Beide Frameworks haben Vorteile, aber auch Nachteile. Ein pragmatischer Ansatz ist meistens zielführender. Es ist also kein Entweder-Oder, sondern ein Sowohl-Als-Auch zu empfehlen. Je nach Reifegrad der Organisation können LeSS- wie auch SAFe-Elemente geschickt kombiniert werden. Allerdings kann man sich dann nicht vergleichen. Man ist dann weder LeSS noch SAFe. Für die Identität der Beteiligten kann eine eindeutige Zuweisung helfen - kann, muss aber nicht. In Organisationen mit starkem Purpose genügt es in der Regel, das Richtige richtig zu tun. 

Mit unserem dot.benchmark können wir dein Teamumfeld systematisch erheben und Verbesserungspotentiale identifizieren. Sei es SAFe oder LeSS ein anderes Organisationsmodell

tschegg.io

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Newsletter Anmeldung