Passend zum Artikel in dem das Scaled Agile Framework (SAFe) vorgestellt wird, habe ich eine einfache Mindmap mit den wichtigsten Elementen aus SAFe erstellt:

Die Mindmap wurde mit XMind erstellt und eine editierbare Version kann via xmind.net heruntergeladen werden.

Über Kommentare / Verbesserungsvorschläge freue ich mich.

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework (Abkürzung: SAFe) ist ein umfangreiches, deskriptives Framework, um Agile/Lean auf der Team-, Programm- und Portfolio-Ebene zu ermöglichen und für große Organisationen handhabbar zu machen. Hierzu beschreibt es Strukturen, Rollen, Prozesse und Artefakte die relevant sind für ein agiles/lean Programm- und Portfoliomanagment. Eine komplette interaktive Beschreibung von SAFe befindet sich auf der Webseiten des Frameworks:  http://scaledagileframework.com/.

Adressierte Problemfelder

Mit SAFe werden vielfältige Herausforderungen in einem skalierten Umfeld adressiert. Hierzu gehören:

• Entropie / Varianz und lokaler Optimierung: Agilität auf der Team-Ebene mit selbstorganisierten Teams und nicht koordinierten Product Ownern führt zu einer hohen Entropie / Varianz. Kurz: Es kommt zu lokaler Optimierung die einer organisationsweiten Optimierung entgegenwirkt.
• Intransparenz: Hohe Freiheitsgrade und mangelndes Alignment führt global gesehen zu einer reduzierten Transparenz. Die möglicherweise gesteigerte Produktivität einzelner agiler Einheiten kann nicht mehr übergreifend gebündelt werden und Steuerungsmechanismen versagen. Dies wiederum führt zu einer Gegenbewegung und Fehlentscheidungen.
• Agilität bei Großkonzernen: Viele agilen Frameworks fokussieren in ihren Implementierungspraktiken auf die Team-Ebene als Kern des Wertschöpfungsprozesses. Vereinfachte Konzepte wie “PO definiert Business Value” versagen jedoch in einem skalierten Umfeld, in dem der PO aufgerieben wird zwischen Anforderungen aus der Trägerorganisation, Kontakt zu Markt/Kunden und Verfügbarkeit für das Team. Basierend auf Praxiserfahrungen wurden im SAFe Konzepte definiert die auch in einem skalierten Umfeld tragfähig sind.

Ursprünge des Scaled Agile Frameworks

Die Grundlagen des Scaled Agile Frameworks wurden in einem viele Jahre dauernden Prozesses entworfen bzw. zusammengefügt. Historisch gesehen hat SAFe seine Wurzeln in iterative-inkrementellen Frameworks wie dem Rational Unified Process (RUP), so war der “Vater” von SAFe, Dean Leffingwell zu Beginn auch an der Ausgestaltung und Verbreitung von RUP maßgeblich beteiligt. Leffingwell wurde wurde später zu einem Anhänger grundlegender agiler Frameworks wie Scrum und (nach einer Phase der Skepsis) eXtreme Programming. Er kombinierte diese Ansätze mit Lean Thinking sowie den von Donald Reinertsen formulierten Prinzipien zum Lean Product Development (Buch “The Principles of Product Development Flow: Second Generation Lean Product Development“). Das so entstandene Framework wurde inkrementell entwickelt und in der Praxis verprobt. Frühe Elemente sind in den beiden Büchern “Scaling Software Agility: Best Practices for Large Enterprises (2007)” und “Agile Software Requirements: Lean Requirements for Teams, Programs and the Enterprise (2011)” sowie in dem Blog “Scaling Software Agility” beschrieben. Die Arbeit an der publizierten Version von SAFe (damals noch “SAF”) begann Ende 2011 (Blog Post von Alex Yakyma) und Anfang 2012 wurde das Framework mittels der interaktiven Webseite und einem Trainings- und Zertifizierungsprogramm der Öffentlichkeit zugänglich gemacht.

Lean Management / Lean Thinking House

Die Grundsätze des Lean Managements werden in SAFe mittels eines “Lean Thinking House” visualisiert, welches im Grundsatz dem Lean Thinking House von Larman/Vodde (vgl. das Buch “Scaling Lean And Agile – Thinking Organizantional Tools“) entspricht, mit dem Unterschied, dass Donald Reinertsen‘s Prinzipien (s.o.) die dort definierten 14 Prinzipien ersetzen (Säule 2):

• Zielsetzung / Dach: Wertschöpfung, Wertsteigerung als Ziel einer Organisation
• Konkret umgesetzt als: Kurze Durchlaufzeiten, Kundenzufriedenheit, Fokussierung auf Wertschöpfung, hohe Qualität, Kostensenkung, Sicherheit
• Säule 1: Respektiere und achte Deine Mitmenschen
• Säule 2: Lean Product Development Flow (Wirtschaftschaftlichkeitsbetrachtung, Warteschlangentheorie, kleine Los-Größen, schnelles Feedback, dezentralisierte Kontrolle und andere)
• Säule 3: Andauernde Verbesserung
• Grundlage / Basis: Moderne Führung, Managementunterstützung

Werte im Scaled Agile Framework

Grundsätze und Werte spielen in agilen Methoden eine wichtige Rolle, auch das Scaled Agile Framework verweist auf vier wichtige Werte:

• Alignment bzw. einer übergreifenden Ausrichtung
  • um Entropie und lokale Optimierung zu minimieren
  • Ausrichtung auf das gleiche Ziel bei Anwendung gleicher Regeln für alle
  • Nutzung von Rahmenwerken für Entscheidungen
• Transparency / Transparenz
  • als Voraussetzung, um Entscheidungen treffen zu können
  • Informationen fließen zwischen allen Ebenen, vor allem ist die Rückmeldung aus den umsetzenden Einheiten sehr wichtig
• Code Quality / Code Qualität
  • um Rückläufer und Störungen zu minimieren)
  • Schlechte Qualität skaliert nicht
• Program Execution bzw. die erfolgreiche Umsetzung in Programmen
  • Ohne Ausführung ist Strategie nicht wert, Ausführung = Strategie
  • Fokussierung auf Programme als organisatorischer Rahmen für Wertschöpfungsketten

Big Picture und die drei Organisationsebenen

Die Beschreibung des Frameworks ist frei im Internet verfügbar, als Einstieg und zentraler Orientierungspunkt dient das “Big Picture“, welches die drei Ebenen Portfolio, Programm und Team unterscheidet.

Team-Ebene

Auf der Team-Ebene finden sich die klassischen Scrum-Elemente, wobei die Rolle des Product Owners (PO) etwas anders ausgelegt wird als im Scrum Guide: Der PO verantwortet die Realisierung von Software mit 1-2 Teams und wird auf der Programm-Ebene ersetzt durch einen Produktmanager (PM). Anforderungen in Form von Features (Programm-Ebene, verantwortet durch PM) werden für die Team-Ebene auf Stories hinuntergebrochen (Aufgabe des POs). Für den aktuellen Release werden die Sprints im Rahmen einer Release-Planung vorgeplant, die Teams committen sich auf 4-6 Sprints, wobei der Fokus auf Einhaltung der formulierten Sprint-Ziele und Erreichung der Release Objectives liegt.

Sowohl die Aufgabentrennung PO/PM als auch diese Vorausplanung sind typische Kritikpunkte (Verringerung der Agilität), die jedoch gerade bei grossen Unternehmen mit heterogenen Prozesslandschaften (nicht alles agil/lean) grossen Anklang finden.

Programm-Ebene

SAFe Programme werden um Wertschöpfungsketten herum aufgesetzt. Die Planung und Steuerung der Umsetzung findet aus Sicht der Auftraggeber auf der Programm-Ebene statt. Auf Ebene des Programms werden die (Zwischen-) Releases / Potential Shipable Increments (PSI) geplant und die Umsetzung in sogenannten “Agile Release Trains (ART)” organisiert.

Zur Umsetzung werden die Geschäftsziele und größen Anforderungsblöcke (Epics) in Features heruntergebrochen und auf einen Zeitstrahl verortet. Zudem dient die Programm-Ebene dazu, die Informationen aus den Teams so zu aggregieren und transparent zu machen, dass ein Soll-/Ist-Abgleich für das gesamte Vorhaben durchgeführt werden kann.

Die Programm-Ebene dient zudem zur Integration und dem Alignment der sich weitgehend selbst organisierenden agilen Teams.

Zudem werden auf der Programm-Ebene einige neue Rollen eingeführt, u.a. ein Produktmanagement (PM), welches für das Programm die Aufgaben des Product Owners übernimmt (s.o.). Andere wichtige Rollen sind die des Releasemanagements, des Systemarchitekten und des Systemteams.

Portfolio-Ebene

Auf der Portfolio-Ebene werden die Programme anhand ihrer Bedeutung für die Unternehmensstrategie mit Mitteln versorgt (“Investment Themes”) und es werden geschäftliche Zielvorgaben formuliert (“Epics”), die häufig strategischer Natur sind (“Wir wollen Marktführer beim Videostreaming werden…”). Im Gegensatz zu vielen anderen agilen Methoden werden größere technische Maßnahmen bzw. Entscheidungen die die Unternehmensarchitektur betreffen explizit transparent gemacht und unterliegen den gleichen Mittelzuweisungsprozessen (und damit auch einer Wirtschaftlichkeitbetrachtung und Priorisierung) wie die inhaltlichen/geschäftlichen Zielstellungen.

Auf der Portfolio-Eben findet eine Überwachung und über die Mittelzuteilung auch eine Steuerung der Programme statt.

Rollen im Scaled Agile Framework

Im Vergleich zu Frameworks wie Scrum gibt SAFe auf den unterschiedlichen Ebenen relativ viele Rollen vor.

Die Rollen im Scaled Agile Framework werden in einem Folgeartikel genauer betrachtet.

Artefakte im Scaled Agile Framework

Im SAFe werden mehr Artefakte im Big Picture aufgeführt als in den meisten anderen agilen Framework.

Die Artefakte im Scaled Agile Framework werden in einem Folgeartikel genauer betrachtet.

Architektur und technische Investitionen

In Abgrenzung zu einigen anderen agilen Vorgehensweisen werden Fragestellungen die sich aus der Technik und Architektur ergeben auf allen Ebenen explizit gemacht und transparent behandelt. Es gibt explizite Rollen wie Enterprise Architect (Portfolio-Ebene) und System Architect (Programm-Ebene) sowie ausgewiesene “Arbeitspakete” (Architectural Epics, Architectural Feature, Spikes/Refactors) die gesondert budgetiert werden.

Wie bereits erwähnt, unterliegen technische Fragestellungen ebenfalls Prozessen in denen Mittelzuweisungen (Portfolio-Ebene) und Prioritäten geklärt werden.

Im Scaled Agile Framework wird unter dem Stichwort “Architectural Runway” das Investment in technische Themen verstanden, um später verlässlich geschäftliche Initiativen zu realisieren oder Erfordernisse der umgebenden Organisation zu erfüllen.

Trainings, Zertifizierungen und Community

Zum Scaled Agile Framework gibt es mit der ScaledAcademy eine Organisation, die Trainings und Zertifizierungen anbietet. Aktuell werden drei verschiedene Zertifizierungen angeboten, die die Teilnahme an bestimmten Trainings voraussetzen:

Leading SAFe (SAFe Agilist)

In dem zweitägiger Kurs „Leading SAFe“ wird den Teilnehmen das notwendige Wissen vermittelt, um mit Hilfe des Scaled Agile Frameworks und den zugrundeliegenden Prinzipien (Lean Thinking, Product Development Flow) eine unternehmensweite Einführung von Agilität zu leiten. Die Teilnehmer dieses Kurses sind nach erfolgreicher Teilnahme und bei Erfüllung der Voraussetzungen dazu berechtigt den Online-Test zum Scaled Agile Framework Agilist (SAFe Agilist) abzulegen.

SAFe ScrumXP (SAFe Practitioner)

Der zweitägige Kurs SAFe ScrumXP für Teams geht über Scrum hinaus. Er vermittelt Grundlagen zu Lean Thinking Tools, Rollen, Prozesse und benötigte Software- Entwicklungspraktiken, um Scrum in einem Unternehmenskontext zu skalieren.

Die Teilnehmer dieses Kurses sind nach erfolgreicher Teilnahme und bei Erfüllung der Voraussetzungen dazu berechtigt den Online-Test zum Scaled Agile Framework Practitioner (SAFe Practitioner) abzulegen.

SAFe Program Consultant

Durch ein erweitertes Leading SAFe Training (nur angeboten durch Dean Leffingwell und 1-2 anderen Trainers) sowie eine Prüfungsvorbereitung, können Teilnehmer zu SAFe Program Consultants (SPC) ausgebildet werden, vorausgesetzt sie bestehen einen umfangreichen Test. Diese SPCs sind wiederum berechtigt die beiden Einstiegstrainigs LeadingSAFe und SAFe ScrumXP zu lehren.

Community

Neben geschlossenen Gruppen, die beispielsweise den zertifizierten Teilnehmern der offiziellen Kurse zugänglich sind gibt es immer mehr öffentliche Communities zum Thema Scaled Agile Framework. Für den deutschsprachigen Raum gibt es beispielsweise die Community SAFeDACH, die sich momentan hauptsächlich via Google+ organisiert.

Kritik an SAFe

Während SAFe von vielen Praktikern aus großen Unternehmen grundsätzlich positiv bewertet wird, gibt es auch viele Agile Coaches, die dem Framework sehr ablehnend gegenüberstehen. Ein gutes Beispiel für die ablehnende Haltung finde sich im dem Artikel “The horror of the Scaled Agile Framework“:

Scrum scales perfectly well without this framework, thank you very much! [...] Why synchronise the whole frigging organisation’s product development?! Yeah like that will work. Means any one team can’t adapt their process because it’s locked in to the organisation’s “Agile” framework.

Typische Kritikpunkte

SAFe ist zu schwergewichtig

SAFe erscheint vielen Verfechtern agiler Methoden im Vergleich zu Scrum und Kanban als schwergewichtiges Framework. Es gibt deutlich mehr Rollen, mehr Artefakte und mehr Vorgaben.

Die Frage ist jedoch, welche alternativen Frameworks existieren. Ein genauer Blick in verschiedene Enterprise Scrum Implementierungen bringt ebenfalls neue Rollen und Abstimmungsprozess zu Tage.

SAFe vernachlässigt kulturelle Aspekte

Ein Kritikpunkt aus der agilen Community ist, dass SAFe sich zum großen Teil auf Strukturen und Prozesse konzentriert und kulturelle Aspekte vernachlässigt. SAFe würde Unternehmen dazu bringen “Agile zu machen” aber nicht “Agile zu sein”. Schnell wird deshalb ein Widerspruch mit dem agilen Manifest vermutet (People & Interaction vs Processes & Tools).

An diese Stelle ist wahrscheinlich die Umsetzung entscheidend. Im SAFe Lean Thinking House sind explizit kulturelle Werte verankert, diese gilt es jedoch auch bewusst aufzugreifen und im Unternehmensalltag zu verankern.

Hierarchie & Alignment vs Netzwerkstruktur & Selbstorganisation

Viele Vertreter agiler Prozesse die sich auf die Team-Ebene konzentrieren stehen der hierarchischen Struktur (Portfolio > Programm > Team) kritisch gegenüber und bevorzugen sich selbst organisierende Systeme / Strukturen.

Diese Organisationsvarianten setzen jedoch eine ausreichend reife Organisation und Teams voraus, die in vielen Fällen (noch) nicht existieren sondern durch jahrelange Investitionen erst aufgebaut werden müssen. Die Kritiker stellen den Mehrwert von Standards und angeglichenem Vorgehen in Frage und ziehen die Erzeugung lokaler Optima vor. Dahinter steckt wohl auch, dass zu häufig die Ziele von Standardisierungsvorhaben nicht erreicht wurden.

Ein kleines Fazit

Das Scaled Agile Framework (SAFe) ist das aktuell am detailliertesten beschriebene Rahmenwerk für Agilität im Großen. Dies ist ein Vorteil (Guidance, Governance) und gleichzeitig auch in gewisser Weise eine Limitation, wenn es nicht gelingt via Inspect & Adapt die Vorgaben aus dem Standard an die eigenen Gegebenheiten anzupassen, Regeln zu verändern und ein agiles Mindset zu etablieren.

Das Scaled Agile Framework bietet ein sehr hilfreiches Rahmenwerk für große Unternehmen, die agiler arbeiten möchten. Selbst wenn man es bewusst nicht ein-/umsetzt, sollte man sich damit beschäftigten. Es enthält Antworten auf viele Fragestellungen, die in großen Unternehmen relevant sind. Auch wenn man diese Antworten nicht für richtig hält, so helfen sie doch dabei, die eigenen Ansätze dahingehend zu verifizieren, ob diese ebenfalls ausreichend Antwort auf die Fragestellungen geben. Kurz: SAFe gibt zu Fragestellungen großer Unternehmen eine passende Antwort – in der Praxis sind jedoch häufig noch viele andere Ansätze valide.

Quellen

• Informationen zum Scaled Agile Framework: http://scaledagileframework.com/
• Weiterbildung / Zertifizierungen: http://www.scaledagileacademy.com/
• Deutschsprachige Community SAFeDACH: https://plus.google.com/u/0/communities/102594827271924887702

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 in irgendeiner Form 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.

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

Photo: The Scaled Agile Framework (SAFE) strategy – this time visually translated ‘In a Nutshell’. My second… tmblr.co/ZaJLkwjf4FYf

— Isabelle Hörl (@IsabelleHorl) 27. April 2013

Scaled Agile Framework ”Big Picture – In a Nutshell” art work. Really like this one!

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.

New article: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. ow.ly/fhmZg

— Henrik Kniberg (@henrikkniberg) 14. November 2012

how spotify scaled up and stayed agile, VERY GOOD reading, via #victorlima @concretes, tackling large scale structures scribd.com/embeds/1136179…

— Fernando de la Riva (@fdelariva) 20. November 2012

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.

Ziel ist es, Squads so zu definieren, dass ein Squad für ein Teil des Produktes voll verantwortlich ist und selbstständig neues Features implementieren kann. Dies erfordert stabile Teams, die auch längerfristig Verantwortung übernehmen können, und eine gute Zusammenarbeit und Kommunikation zwischen verschiedenen Squads eines Tribes. Hierfür wird die entsprechende Umgebung bereitgestellt (Räume, Whiteboards) was den Abstimmungsaufwand reduziert. Die Squads haben größtmögliche Entscheidungsfreiheit, um ohne erhöhten Kommunikationsaufwand zu übergeordneten Stellen schnell Lösungen finden und Entscheidungen treffen zu können.

Because each squad sticks with one mission and one part of the product for a long time, they can really become experts in that area – for example what it means to build an awesome radio experience.

Um den Austausch und die Kommunikation zwischen den Squads und Tribes zu fördern, sowie kontinuierliche Verbesserung zu erlauben, werden ca. 10% der Zeit in gemeinsame Innovation investiert (“Hack Days”).

Tribe

Squads die im gleichen Kontext (z.B. “Music Player” oder “Backend Infrastructure”) arbeiten werden in einem so genannten “Tribe” gebündelt, wobei auf die “Dunbar’s Number” geachtet wird: Kein Tribe hat viel mehr als 100 Mitgliedern, da sonst die Kommunikation und Abstimmung leidet. Jede dieser Gruppen hat einen “Tribe Leader”, der dafür verantwortlich ist, dass die zugehörigen Squads optimal arbeiten können. Regelmäßig werden Meetings auf der Tribe-Ebene abgehalten. Diese dienen zum Informationsaustausch und bei Bedarf zur übergreifenden Planung. Zudem wird der aktuelle Stand der Produkte präsentiert und die Zugehörigkeit zum Tribe gestärkt.

In anderen Ansätzen wie dem Scaled Agile Framework wäre ein Tribe vergleichbar mit dem Agile Release Train und die Abstimmungsmeetings mit dem Release Planning Meeting auf Programm-Ebene. Detailliert wird auf diese Konzepte im Artikel über das Scaled Agile Framework eingegangen.

Abhängigkeiten und Abstimmung

Handhabung von Abhängigkeiten

Abhängigkeiten zwischen Squads werden transparent gemacht und aktiv adressiert (Organisation, Architektur, Fokussierung). Ziel ist es die Anzahl der Abhängigkeiten bzw. deren Auswirkungen (Verzögerungen, Risiken, Transaktionskosten) zu minimieren. Abhängigkeiten zwischen Squads führen dazu, dass Entscheidungen nicht mehr in der kleinen Gruppe getroffen werden, sondern Abstimmungsaufwand mit anderen Squads anfällt.

Dies wird noch arbeits- und zeitintensiver, sobald Abhängigkeiten zu anderen Tribes besteht. Abstimmungsaufwände zwischen den Tribes verlängern nicht nur die Durchlaufzeiten einzelner Features und erhöhen damit das Risiko Produktauslieferungen zu verzögern, sondern steigern auch den Kommunikationsaufwand und hierdurch die Komplexität zwischen den Tribes. Aus diesem Grund wird alles dafür getan diese Abhängigkeiten zu eliminieren.

Abstimmung und Ausrichtung

Die Schattenseite autonomer Teams ist eine höhere Entropie (mehr Unterschiedlichkeit / Abweichungen), schnell kann das übergeordnete Ziel zu Gunsten lokaler Optimierung aus den Augen verloren gehen. Um Skaleneffekte realisieren zu können und ein ausreichende Ausrichtung auf gemeinsame Ziele nicht aus den Augen zu verlieren findet eine übergreifende Abstimmung in so genannten Chapters und Guilds statt, die den Communities of Practice aus anderen Modellen entsprechen..

If each squad was fully autonomous and had no communication with other squads, then what is the point of having a company?

Chapter

Personen mit ähnlichen Skills aus dem gleichen Tribe treffen sich und tauschen sich aus. So gibt es Chapter für “Web Development” oder “Testing” in denen grundlegende Themen diskutiert werden und eine Abstimmung hinsichtlich Standards und eingesetzten Frameworks stattfindet.

Guild

Eine Guild ist eine Gruppe, die sich über Grenzen von einzelnen Tribes bildet, um Wissen auszutauschen, Werkzeuge und Herangehensweisen anzugleichen und Praktiken einzuüben.

System Owner & Chief Architect

Bei autonomen Squads die im Grunde überall im System Änderungen durchführen dürfen, besteht ein Risiko, dass die Architektur des Systems leidet. Aus diesem Grund gibt es einen “System Owner”, der eine Beratungsinstanz bei architektonischen Änderungen darstellt. Da Squads trotzdem selbst entscheiden dürfen, stellt der System Owner kein Bottleneck dar – allerdings stimmen sich die Squads ganz bewusst mit ihm ab, um Risiken zu reduzieren.

Tiefgreifende architektonische Änderungen und Neuentwicklung ganzer Systeme werden durch einen Chief Architect überprüft. Wobei auch der Chief Architect lediglich beratend tätig ist – die finale Entscheidung liegt bei den Squads, da diese auch die Konsequenzen tragen müssen.

Kultur

Bei Spotify hat Transparenz als agiler Wert eine große Bedeutung und wird im Unternehmen gelebt. Dies geschieht unter anderem mit dem regelmäßig ermittelten “Happyness-Index”. Hierbei werden die Mitarbeiter der einzelnen Squads anonym befragt wie zufrieden / glücklich sie mit ihrem ProductOwner, ihrem Agile Coach, Operations udgl. sind.

Wichtiger als die Momentaufnahme ist bei dieser Erhebung aber die Rückmeldung, ob sich im Zeitverlauf Verbesserungen oder Verschlechterungen ergeben haben. So kann ein Teammitglied beispielsweise seinen Product Owner nur durchschnittlich bewerten aber auch darauf hinweisen, dass die Performance sich weiter verbessert.

Mittels einer solchen Metrik kann nicht nur der Ist-Stand einer Änderung (z.B. Schulung,…) gemessen werden, sondern auch ob sich kleine Änderungen abzeichnen. Ähnlich kann man einen negativ-Trend auch schon als Frühindikator verwenden, um schnell und pragmatisch gegenzusteuern.

Im Gegensatz zum SAFe hebt der der Ansatz bei Spotify kulturelle Aspekte sehr stark hervor und vermeidet die Nutzung etablierter Begrifflichkeiten: Grundlegende Konzepte aus der Matrix-Organisation werden “trendig verpackt” und durch eine Spotify-eigene Terminology ersetzt. Bewusst werden Entscheidungsbefugnisse sehr stark auf die operative “Squad-Ebene” verschoben, wodurch wiederum die Identifikation mit dem (Teil-) Produkt und die Fokussierung auf eine schnelle Auslieferung zunimmt.

Quellen

• Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
• Artikel von Henrik Kniberg
• Detaillierter Artikel (PDF)

Cool, all attendees of our course who took the SA exam are now certified Scaled Agile Framework Agilists! #safede #safedach

— Agile Rescue (@AgileRescue) 23. Februar 2013

Scaled Agile Framework & Disciplined Agile Delivery

Zweit der wichtigsten Vertreter für Agile/Lean @ Scale treffen aufeinander: Sowohl Dean Leffingwell (Scaled Agile Framework) als auch Scott Ambler (Disciplined Agile Delivery) geben sowohl Trainings als auch Keynotes auf der Goto Zurich for Leaders.  Vielleicht gibt es auch mehr (erste echte) Informationen zum Continuous Improvement Framework (CIF) von Ken Scwaber / Scrum.org?

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)

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.

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.

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

Das 2. Kapitel des Buches “Agile Software Requirements” von Dean Leffingwell ist in einer überarbeiteten Fassung nun auch in Deutsch verfügbar.

Übersetzt und aktualisiert durch Hans-Peter Korn, erscheint als Teil des Buches “Agiles IT-Management in großen Unternehmen”, veröffentlicht durch Symposion Publishing.

Wieder ein äusserst lesenswerter Artikel von Henrik Kniberg.

Die Zusammenfassung gibt es hier: http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

Den vollständigen Artikel als PDF hier: https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf