SAFe Big Picture 2.5

Big Picture 2.5 veröffentlicht

Für das Scaled Agile Framework ist die Version 2.5 des Big Picture (und damit der Einstiegsseite) veröffentlicht worden.

„I am excited for the SAFe community to visit the updated portfolio content (Portfolio Vision, Value Streams, and Portfolio Backlog) and program updates (Release Planning, Program Objectives, and Team PSI Objectives). In addition, we’ve further built out our case studies and made it a top-level navigation menu.“ –Dean Leffingwell

Die meisten Änderungen betreffen die mittlere Ebene (SAFe Program). Dort wird jetzt besonders hervorgehoben, welche Ziele das Release Planning verfolgen soll: Ausgehend von einer Vision, Roadmap und einem Planungszenario erarbeiten Geschäftsseite und Technikseite gemeinsam einen belastbaren Plan. Für jeden Sprint formulieren die Teams ihre eigenen Sprint-Ziele, zudem formuliert jedes Team ein Ziel für das gesamte PSI (Release). Diese „Team PSI Objectives“ werden schließlich zu „Program PSI Objectives“ aggregiert. Dies geschieht immer im Zusammenspiel mit Vertretern aus dem Management, den sogenannten „Business Ownern„. Da diese sehr wichtig sind und meist auch Programm-übergreifend tätig sind, werden diese nun im Big Picture erwähnt (zuvor wurde lediglich auf sie verwiesen und waren im BP implizit dem Program Portfolio Management und ggf. dem Product Management zugeordnet).

Neu auf der Programm-Ebene sind zudem die DevOps, deren Aufgabe die Sicherstellung einer enge Zusammenarbeit zwischen Entwicklungs- und Betriebsorganisation ist (die oft noch weiter gefassten Definitionen von DevOps finden hier zunächst keine Anwendung). Zuvor wurde diese Aufgabe zum Teil durch das System Team wahrgenommen.

Übersicht Änderungen

Portfolio-Ebene

  • Value Streams werden explizit erwähnt

Programm-Ebene

  • DevOps – als primäre Rolle eingeführt
  • „Shared“ – Rolle entfällt aus dem BP
  • BO / Business Owner – als primäre Rolle eingeführt
  • PSI Program Objectives – als Artefakt aufgenommen
  • Team PSI Objective – als Artefakt aufgenommen
  • Deliver on Demand – als Guidance aufgenommen
  • generell wurde das Layout etwas geändert (Arch, UX, RTE auf den ART, ein gewöhnungebedürftiges Grün für Auslieferungen)

Team-Ebene

  • Sprint Goals – als verbindliches Artefakt jetzt in das BP aufgenommen (war auch zuvor in der Beschreibung zum Release Planning als verbindlich beschrieben)
  • DBT (Design-Build-Test) – entfällt (eine Änderung, die Kritik hervorgerufen hat)
  • Code Quality – jetzt explizit erwähnt im BP
  • Develop on Cadence – als Guidance aufgenommen
  • EXE – Guidance zu „Sprint Execution“

Für das Scaled Agile Framework ist soeben die Version 2.5 des Big Pictures veröffentlicht worden.

 

Dean Leffingwell hierzu: „I am excited for the SAFe community to visit the updated portfolio content (Portfolio Vision, Value Streams, and Portfolio Backlog) and program updates (Release Planning, Program Objectives, and Team PSI Objectives). In addition, we’ve further built out our case studies and made it a top-level navigation menu.“

 

Die meisten Änderungen betreffen die mittlere Ebene (SAFe Program). Dort wird jetzt besonders hervorgehoben, welche Ziele das Release Planning verfolgen soll: Ausgehend von einer Vision, Roadmap und einem Planungszenario erarbeiten Geschäftsseite und Technikseite gemeinsam einen belastbaren Plan. Für jeden Sprint formulieren die Teams ihre eigenen Sprint-Ziele, zudem formuliert jedes Team ein Ziel für das gesamte PSI (Release). Diese „Team PSI Objectives“ werden schließlich zu „Program PSI Objectives“ aggregiert. Dies geschieht immer im Zusammenspiel mit Vertretern aus dem Management, den sogenannten „Business Ownern„. Da diese sehr wichtig sind und meist auch Programm-übergreifend tätig sind, werden diese nun im Big Picture erwähnt (zuvor wurde lediglich auf sie verwiesen und waren im BP implizit dem Program Portfolio Management und ggf. dem Product Management zugeordnet).

Neu auf der Programm-Ebene sind zudem die DevOps, deren Aufgabe die Sicherstellung einer enge Zusammenarbeit zwischen Entwicklungs- und Betriebsorganisation ist (die oft noch weiter gefassten Definitionen von DevOps finden hier zunächst keine Anwendung). Zuvor wurde diese Aufgabe zum Teil durch das System Team wahrgenommen.

 

In Summe gibt es folgende Änderungen:

Portfolio-Ebene

  • Value Streams werden explizit erwähnt

Programm-Ebene

  • DevOps – als primäre Rolle eingeführt
  • „Shared“ – Rolle entfällt aus dem BP
  • BO / Business Owner – als primäre Rolle eingeführt
  • PSI Program Objectives – als Artefakt aufgenommen
  • Team PSI Objective – als Artefakt aufgenommen
  • Deliver on Demand – als Guidance aufgenommen
  • generell wurde das Layout etwas geändert (Arch, UX, RTE auf den ART, ein gewöhnungebedürftiges Grün für Auslieferungen)

 

Team-Ebene

  • Sprint Goals – als verbindliches Artefakt jetzt in das BP aufgenommen (war auch zuvor in der Beschreibung zum Release Planning als verbindlich beschrieben)
  • DBT (Design-Build-Test) – entfällt (eine Änderung, die Kritik hervorgerufen hat)
  • Code Quality – jetzt explizit erwähnt im BP
  • Develop on Cadence – als Guidance aufgenommen
  • EXE – Guidance zu „Sprint Execution“

Vorstellung SAFe bei der AgileRM – Zusammenfassung und Folien

Vorstellung des Scaled Agile Frameworks beim Treffen der Agile User Group Rhein Main

Am 20. Juni hatte ich Gelegenheit im Rahmen eines Treffens der Agile User Group Rhein Main (#agileRM) eine Einführung in das Scaled Agile Framework (SAFe) zu geben.

Herzlichen Dank für die Fotos an Tobias Cieplik.

scaled_agile-06516
SAFe Big Picture

Die Räumlichkeiten für das Treffen stellte die Seibert Media GmbH in Wiesbaden zur Verfügung. An dieser Stelle einen herzlichen Dank an alle Organisatoren!

Trank und Speis wurde durch Atlassian (Jira, Confluence) gesponsort. Es gab auch genug Bier, um so auch die kritischen Geister etwas zu beruhigen ;-).

Jeder der sich mit bereits intensiver mit der Skalierung von agilen Konzepten und dem Scaled Agile Framework im Besonderen beschäftigt hat, weiß um die Schwierigkeiten eine kurze und in sich stimmige Einführung in das Thema zu geben.

scaled_agile-06501
Teams in SAFe

Für alle Interessenten hier die Folien: 20130619_AgileRM_SAFe_presentation

Der Teilnehmerkreis bestand aus mehr als 20 Interessenten, teilweise erfahrene Agile Consultants / Coaches mit umfangreicher Erfahrung. Dies spiegelte sich auch in den hochwertigen Fragen und der Diskussionsqualität wieder.

scaled_agile-06448
Erläuterung der Rollen Produktmanagement, Product Owner und Entwicklungsteam

Weitere Informationen

Die deutschsprachige Community „SAFeDACH“ (#safede, #safedach) organisiert sich via Xing und Google+.

An dieser Stelle sei auch der sehr gelungene Vergleich von Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) und Path to Agility (P2A) erwähnt, die Lutz Ehrlich (EnBW) in einer Präsentation auf dem Karlsruher Entwicklertag vorgestellt hat.

Agile User Group Rhein-Main: Scaled Agile Framework und Erfahrungsaustausch Agile auf Enterprise-Level

Am 20. Juni trifft sich die Agile User Group Rhein-Main in Wiesbaden, um sich rund um das Thema Scaled Agile Framework sowie „Enterprise Agile / Agilität auf Enterprise-Level“ auszutauschen.

Hierzu werde ich eine Einführung in das Scaled Agile Framework (SAFe) geben und im Anschluss wird darüber diskutiert, welche Erfahrungen Unternehmen mit Agilität im Großen bisher sammeln konnten und welche Ansätze hierbei hilfreich waren.

Mehr Informationen zum Event und die Möglichkeit zur Anmeldung gibt es im Blog von Seibert Media.

Eine kurze Zusammenfassung des Scaled Agile Frameworks gibt es hier: Scaling Agile & Lean – Scaled Agile Framework (SAFe).

Die deutschsprachige Community „SAFeDACH“ organisiert sich via:

SAFe Mindmap 0.5SAFe Mindmap 0.5

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.For the article (German only) about the Scaled Agile Framework (SAFe) I also created a simple mind map that consists of the most important elements of SAFe:

Scaling Agile & Lean – Scaled Agile Framework (SAFe)

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 adressiert, die für große Vorhaben und Organisationen nicht unüblich sind. Hierzu gehören:

  • Entropie / Varianz und lokaler Optimierung: Agilität auf der Team-Ebene mit sich selbst organisierenden 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 unternehmensweit gesehen zu einer geringen 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 und Vorgehensweisen definiert, die auch in einem skalierten Umfeld tragfähig sind.

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

Goto Zurich for Leaders – Wo sich SAFe & DAD treffenGoto Zurich for Leaders – Where SAFe & DAD meet

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?

Scaled Agile Framework & Disciplined Agile Delivery

Two of the leading minds for Agile/Lean @ Scale will meet in Switzerland: At the  Goto Zurich for Leaders trainings and keynotes will be held by Dean Leffingwell (SAFe / Scaled Agile Framework) and Scott Ambler (DAD / Disciplined Agile Delivery)! Curious if we can also learn a little bit more about the Continuous Improvement Framework (CIF) Ken Scwaber / Scrum.org started to promote now …