Is SAFe evil? The answer …

Is SAFe evil?

Die Frage, ob das Scaled Agile Framework ein nützliches oder eher schädliches Hilfsmittel für die Skalierung von Agilität im Unternehmenskontext darstellt spaltet die agile Community seit mehreren Jahren.

Sehr erfrischend ist ein neues Video in dem die aktuellen Ansätze für die Skalierung von Agilität bei LEGO erläutert werden. Sehr schön auch der Einstieg, d.h. die „erste Präsentation“ ;-).

 

Henrik Kniberg erklärt die wichtigsten Konzepte aus SAFe

  • „SAFe = Shu-level scaling“, danach anpassen
  • momentan wird (bei LEGO) nach SAFe gearbeitet, in einem Jahr wird dies wohl anders aussehen. Mit dem SAFe Framework hat die Reise lediglich begonnen.

Lars Roost erklärt, wie diese bei LEGO eingesetzt werden – schöne Impressionen

  • Release Planning @ LEGO

Grundlegendes

  • Wichtige ist eine Grundhaltung: Es gibt viele Quellen der Inspiration: Nutze sie alle: NEXUS, LeSS, SAFe, DAD und viele, viele weitere …
  • Auch ohne SAFe muss man sich immer um die Portfolio- und die Team-Ebene kümmern.
  • Mehrwert im SAFe vor allem der „SAFe Program Level“, da dadurch Portfolio-Management und die agile Teams verunden werden. Hierbei spielt der Release Train Engineer („Chief Scrum Master“) eine sehr wichtige Rolle.
  • Gestaltet man diese teamübegreifende Ebene gut, dann wird die Vorhersehbarkeit verbessert (Mittelfristplanung).
  • SAFe macht wie Scrum bestimmte Probleme sichtbarer, was nicht bedeutet, dass diese automatisch gelöst werden.

Scaled Agile Framework- Chancen und Risiken 

  • LIKE
    • Einiges rund um das Release Planning: Die Energie, Release Planning als Social Event, Visualisierung (Transparenz!) über das Dependency Board und das Risk Board
  • BEWARE
    • SAFe – nicht alles auf einmal!
    • Nicht auf dem Shu-Level bleiben sondern Strukturen und Regeln anpassen
    • Queues & Batches – aufpassen, dass die Arbeit fließt und nicht gewartet wird
    • Mount Stupid – Hype & Anti-Hype
  • Warpup
    • SAFe als Hilfsmittel
    • SAFe basiert auf Lean & Agile Prinzipien
    • SAFe = Shu-level Skalierung
    • SAFe can be useful, wenn Teams voneinander abhängig sind
    • Nicht auf Shu-Level bleiben – viel experimentieren

 

Interessantes am Rande: Noch Ende 2014 war man bei CRISP viel kritischer eingestellt. So ändern sich die Zeiten bzw. die Einstellung, wenn man sich intensiv mit einem Thema beschäftigt.

Die Slides sind via einem Blog-Artikel bei Crisp abrufbar.

 

Large-Scale Scrum Site available

During a presentation @ QS-Tag 2014 in Nuremberg this November I summarized Large-Scale Scrum / LeSS like that:

less-summary

 

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

Scrum.org announces CIFScrum.org announces CIF

Kurzmitteilung

Finally the long awaited CIF (Continuous Improvement Framework) has been announced by Ken Schwaber / Scrum.org („Scale Scrum beyond your Team„).

A first overview has been made available to the public.

Time to cover CIF in our series about scaling Agile/Lean!Finally the long awaited CIF (Continuous Improvement Framework) has been announced by Ken Schwaber / Scrum.org („Scale Scrum beyond your Team„).

A first overview has been made available to the public.

Time to cover CIF in our series about scaling Agile/Lean!

Scaling Agile & Lean – Scrum of Scrums (SoS)

Scaling Agile & Lean – Scrum of Scrums (SoS)

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhinauf den Einsatz von Scrum / Kanban in einigen wenigen Teams und Projekten  beschränken. Ansätze, um über viele Teams hinaus zu skalieren (Scaling Agile) werden für größere Unternehmen nun immer wichtiger. Scrum Implementierungen scheitern jedoch häufig an übergeordnetem Koordinierungsbedarf und alleinige Fokussierung auf die Team-Ebene. Häufig wird zudem die Integration von agilen Organisationsteilen und weiterhin eher traditionell organisierten Organisationsteilen unterschätzt. Die Fragestellung, wie agile Methoden skaliert werden können ist jedoch nicht neu und mittlerweile gibt es viele Ansätze hierfür. In der Reihe „Scaling Agile & Lean“ gehen wir auf einige der bekanntesten Ansätze ein.

Scrum of Scrums (SoS)

Ein einfacher Ansatz zur Abstimmung über mehrere Teams hinweg ist der so genannte „Scrum of Scrums“ (abgekürzt “SoS”) bei dem Vertreter der beteiligtem Scrum Teams in ein übergeordnetes Meeting, dem „Scrum of Scrums“, entsandt werden, um sich dort zu Team-übergreifende Themen auszutauschen. Dieser Ansatz ist schon relativ alt, so soll der Ansatz bereits 2003 auf einer Konferenz  von Ken Schwaber vorgeschlagen worden sein. Mike Cohn beschreibt 2007 in einem Artikel etwas ausführlicher den Ansatz.

Scrum of Scrums (of Scrums)
Scrum of Scrums (of Scrums)

Herausforderung: Teilnehmer

Nicht immer ist es leicht, einen geeigneten Team-Vertreter (“Delegate”) zu benennen, derdie (richtigen) Informationen (in geeigneter Form) aus dem Team in das SoS trägt und entsprechend die Informationen aus dem SoS in das Team zurück. Hier hilft meist etwas experimentieren weiter.

Spezialisierte Scrum of Scrums

Scrum of Scrums werden gerne auch für spezialisierte Gruppen angewendet: Teilweise wird die Abstimmung über Teams hinweg mit einem SoS erreicht, teilweise gibt es spezialisierte SoS für Product Owner, Entwickler und Scrum Master. Bei einem solchen Ansatz muss kritisch geprüft werden, ob wirklich ein SoS vorliegt oder es sich eher um eine Community of Practice (CoP) handelt.

Grenzen von Scrum of Scrums

Wie Esther Derby in der Präsentation Agile Teams at Scale: Beyond Scrum of Scrums darlegt, stößt Scrum of Scrums schnell an Grenzen: Scrum of Scrums funktioniert, wenn eine kleine Anzahl Teams koordiniert werden müssen, die alle im selben Kontext arbeiten. Sie zeigt in ihrer Präsentation auf, welche Strategien verfolgt werden können, um Teams auch bei der Entwicklung größerer Systeme zu koordinieren, die mehr als einen Kontext aufweisen.

Scrum of Scrums dienen zur Koordination und nicht zur Planung

Ein weiterer Kritikpunkt ist, dass die Stärken eines Scrum of Scrums hauptsächlich im Austausch und Koordination zwischen Teams liegen und weniger in einer übergreifenden Planung. Ein Scrum of Scrums ist kein Planungsprozess im eigentlichen Sinne sondern ein stetiger Austausch. Wird ein konsolidierter Plan benötigt, so muss dieser gesondert erstellt werden.

Anatomy of Agile Enterprise

In dem Artikel „Scaling Aile Beyond Team“ greift Janne J. Korhonen ebenfalls den Ansatz von Scrum of Scrums auf, nennt die Limitationen dieser Team of Teams und führt eine weitere Skalierungebene, die “Agile Unit” ein. Teams innerhalb der Agile Unit koordinieren sich auch über Kontext-Grenzen hinweg. Diese “Kontext-Grenzen” sorgen immer wieder für Herausforderungen bei der Agilisierung von Unternehmensteilen, da ihre Auswirkungen auf selbstorganisierte Teams unterschätzt wird.

Agile Unit
Eine „Agile Unit“ fasst Team of Teams zusammen.

Demnächst: Scaling Agile & Lean – Patterns of Enterprise Scrum & Scaling Lean/Agile Development.

Deutschen Scrum 2012 und Scaling Agile

Deutsche Scrum 2012

Die diesjährige Deutsche Scrum fand am 15. und 16. November in Darmstadt bei der Telekom / Products & Innovations statt. Ich hatte dort die Gelegenheit an einer Diskussionsrunde zum Thema „Scaling Scrum“ („Scaling Agile“ wäre ggf. passender gewesen) teilzunehmen und ein Open Space zum Scaled Agile Framework anzubieten.

Die Problemstellung Agilität zu skalieren und mit einem häufig traditionell geprägten Umfeld in Einklang zu bringen zog sich durch diverse Vorträge. Im Rahmen einer Diskussionsrunde zum Thema „Scaling Scrum“ wurde die Problemstellung näher betrachtet.

Diskussionrunde „Scaling Scrum“

Zunächst wurde die Aufgabenstellung bei der Skalierung von Agilität („scaling agile“) diskutiert und auf die Herausforderungen hingewiesen. Ein kurzer Hinweis auf die Ergebnisse der Studie „SwissQ Agile 2012“ (laut der ca. 50% aller Unternehmen mit dem Stand der Agilisierung und den Ergebnisse unzufrieden sind) zeigte, dass die Einführung von Agilität in Unternehmen stets mit vielen Herausforderungen verbunden ist. Hinweis: Mit dieser und anderen Studien beschäftigt sich der Artikel „Studien: Erfolg agiler Methoden„.

Andererseits war doch der eine oder andere der Meinung, dass es gar nicht so schwierig sei …

In einem zweiten Schritt wurden einige bekannte Faktoren (vgl. u.a. Scott W. Ambler, „Agile Scaling Factors„) benannt, die helfen den Grad der Skalierung zu ermitteln. Faktoren sind beispielsweise die Anzahl an Teams, die geografische Verteilung der Teams und Team-Mitglieder, Komplexität der fachlichen und technischen Domäne, der Unternehmenskontext, das Produktportfolio (1 Produkt und 100 Produkte?).

In einem dritten Schritt wurden Ansätze diskutiert, wie Agilität skaliert werden kann.

Deutsche Scrum 2012

Die diesjährige Deutsche Scrum fand am 15. und 16. November in Darmstadt bei der Telekom / Products & Innovations statt. Ich hatte dort die Gelegenheit an einer Diskussionsrunde zum Thema „Scaling Scrum“ („Scaling Agile“ wäre ggf. passender gewesen) teilzunehmen und ein Open Space zum Scaled Agile Framework anzubieten.

Die Problemstellung Agilität zu skalieren und mit einem häufig traditionell geprägten Umfeld in Einklang zu bringen zog sich durch diverse Vorträge. Im Rahmen einer Diskussionsrunde zum Thema „Scaling Scrum“ wurde die Problemstellung näher betrachtet.

Diskussionrunde „Scaling Scrum“

Zunächst wurde die Aufgabenstellung bei der Skalierung von Agilität („scaling agile“) diskutiert und auf die Herausforderungen hingewiesen. Ein kurzer Hinweis auf die Ergebnisse der Studie „SwissQ Agile 2012“ (laut der ca. 50% aller Unternehmen mit dem Stand der Agilisierung und den Ergebnisse unzufrieden sind) zeigte, dass die Einführung von Agilität in Unternehmen stets mit vielen Herausforderungen verbunden ist. Hinweis: Mit dieser und anderen Studien beschäftigt sich der Artikel „Studien: Erfolg agiler Methoden„.


Deutsche Scrum 2012: Scaling Scrum Panel Discussion

Andererseits war doch der eine oder andere der Meinung, dass es gar nicht so schwierig sei …

In einem zweiten Schritt wurden einige bekannte Faktoren (vgl. u.a. Scott W. Ambler, „Agile Scaling Factors„) benannt, die helfen den Grad der Skalierung zu ermitteln. Faktoren sind beispielsweise die Anzahl an Teams, die geografische Verteilung der Teams und Team-Mitglieder, Komplexität der fachlichen und technischen Domäne, der Unternehmenskontext, das Produktportfolio (1 Produkt und 100 Produkte?).


Agile Scaling Factors

In einem dritten Schritt wurden Ansätze diskutiert, wie Agilität skaliert werden kann.

Session über Agile@Scale auf dem PMCamp 2012Session über Agile@Scale auf dem PMCamp 2012

Ich hatte eine kleine Session zu Agile@Scale auf dem PM Camp 2012.

Ausgehend von der Fragestellung, warum Skalierung von Agilität eine Rolle spielt und was man darunter versteht haben wir gemeinsam verschiedene Ansätze diskutiert.

Ein Tweet von spacedani aus der ersten Hälfte:

Eine Betrachtung/Diskussion weiterführender Prozess-Frameworks für Agilität im Großen wie Disciplined Agile Delivery (DAD) oder Scaled Agile Framework (SAFe) konnte jedoch auf Grund der vielfältigen Grundsatzdiskussionen oder Beharren auf “Wahrheiten” nur bedingt erfolgen.

Hier der Tafelaufschrieb:

image

Neuer Anlauf: Eine Session (Panel / Fishbowl) auf der DeutscheScrum 2012 (15.-16.11.2012 in Darmstadt) und später auf der Agile Tour 2012 Germany (22. November in Stuttgart). Im Rahmen der Agile Tour gibt es auch das erste SAFe Meetup in Deutschland.

Eine Betrachtung/Diskussion weiterführender Prozess-Frameworks für Agilität im Großen wie Disciplined Agile Delivery (DAD) oder Scaled Agile Framework (SAFe) konnte jedoch auf Grund der vielfältigen Grundsatzdiskussionen oder Beharren auf “Wahrheiten” nur bedingt erfolgen.

Hier der Tafelaufschrieb:

image

Neuer Anlauf: Eine Session (Panel / Fishbowl) auf der DeutscheScrum 2012 (15.-16.11.2012 in Darmstadt) und später auf der Agile Tour 2012 Germany (22. November in Stuttgart). Im Rahmen der Agile Tour gibt es auch das erste SAFe Meetup in Deutschland.

SAFe Meetup at Agile Tour 2012 Germany

There are not that many experts for the Scaled Agile Framework (SAFe) in Germany yet but it is becoming more and more popular. At the moment I am one of just two certified SAFe Program Consultants (SPC) in Germany. Together with other experts for SAFe we will meet at the Agile Tour in Stuttgart/Germany, November 22nd.

Part of the program for Agile Tour is a short introduction to the Scaled Agile Framework and Rally will demonstrate how their tools are supporting SAFe.

So in case you are interested in the Scaled Agile Framework you should not miss the opportunity to talk to the SAFe experts present at the Agile Tour.

There are also a lot of other highly interesting topics that are covered by the program and the best is: Its a real bargain! For only 50 EUR (which also includes food & drinks) you get a whole day of agile topics and the chance to network with agile experts and other agile adopters. Additionally there is a room for open space sessions where you might be able to put your topics on the agenda.

My advice: Don’t miss the chance and attend the first German Agile Tour event!

 

Please note: Most of the presentations will probably given in German.

Agile Portfolio Management Panel Discussion

Video

Eine Podiumsdiskussion rund um Agile Portfolio Management mit Dean Leffingwell sowie Vertretern von Rally und Chad Holdorf (Agile Scaling Coach / John Deere). Es wird auf Erfahrungen bei der Einführung von Agile@Scale bei John Deere eingegangen.

Ein anderes Video zu Agile Portfolio Management habe ich in hier verlinkt.

Eine weitere Q&A Session zu Agile Portfolio Management gibt es hier.

Scaling Agile: Scaling the Lean / Agile Enterprise – Ein Workshop mit Dean Leffingwell

Die Themen Agilität und Lean sind im Unternehmensalltag angekommen. In vielen Fällen geschieht die Einführung Bottom-Up: Einzelne Teams entscheiden sich für ein agiles Vorgehen bzw. Framework wie Scrum, erst in einem zweiten Schritt wird über ein koordiniertes Rollout von agilen Vorgehensweisen und grössere Änderungen in der Organisationsstruktur nachgedacht.

Die Praktiken in Scrum, wie sie die letzten Jahre vielfach diskutiert wurde, fokussieren sehr stark auf die Teamebene. Das Team als Kern der Wertschöpfung mit einzelnen Menschen die sich selbst organisieren und gemeinsam ihre Regeln definieren.

In der Realität steht man vielfach vor der Herausforderung, dass erfolgreiche Teams zwar die Bedingung für ein erfolgreiches Unternehmen sind, dies alleine aber nicht ausreicht. Möchte man skalieren („scaling agile“) und kann die betroffene Organisation nicht in weiten Teilen neu aufstellen, so muss man viele Kompromisse eingehen (ScrumBut) oder teure und riskante Reibungsverluste hinnehmen.

Wie kann es also gelingen systematisch agile/lean Vorgehensweisen und Strukturen zu skalieren? Dean Leffingwell gibt mit seinem Scalable Agile Framework (SAF) eine Antwort darauf.

Website http://scaledagileframework.com/

Anfang Juli 2012 hatte ich Gelegenheit Dean Leffingwell persönlich kennen zu lernen und ihm Heidelberg zu zeigen. Zudem konnte ich vor dem Scrum Day 2012 in Walldorf an seinem zweitägigen Workshop „Leading the Lean|Agile Enterprise: A Two-day Workshop for Leaders, Managers, and Executives“ teilnehmen. Dieser Workshop und intensive Diskussionen mit Dean haben mich davon überzeugt, mich weiter mit dem SAF zu beschäftigen. Der Workshop selbst war sehr interessant, wobei es nicht immer leicht war Dean zu folgen, da er in einer unglaublichen Geschwindigkeit ein wichtiges Thema nach dem nächsten behandelte. Alles war durchgetaktet und entsprechend anstrengend war es für alle Teilnehmer.