Weiteres Video zur SAFe Implementierung bei LEGO

In dem Video „Is SAFe Evil?“ (letzter Beitrag) wurde bereits darauf eingegangen, wie das Scaled Agile Framework als Startpunkt für die „Scaled Agile Implementierung“ bei LEGO® genutzt wurde.

Auf der Lean Kanban Europe 2015 gab es nun einen weiteren Vortrag hierzu.

Das Video ist via vimeo verfügbar:

Learnings from SAFe @ Lego – Mattias Skarin & Eik Thyrsted Brandsgård at LKCE15 from Lean Kanban Central Europe on Vimeo.

Wichtige Punkte:

  • Impressionen zum Release Planning Event (16:00) – hier kann man richtig Spaß haben!
  • Was machen wir eigentlich mit SAFe? Das gleiche wie im Kindergarten (17:50) :-)
  • Schöne Visualisierungen, welche Prinzipien hinter SAFe stecken. Es ist eben nicht das „Big Picture“ sondern diese Prinzipien, die die Basis für eine Scaled Agile Implementierung sind.
  • Generell „play it unsafe“ – bewusst Dinge anders tun als in SAFe beschrieben. Hier heißt es keine Angst vor Experimenten! Sich dumpf an die Vorgaben zu halten ist langfristig nicht sinnvoll (als Startpunkt aber ok).
  • Algorithmus, um zu entscheiden was beibehalten und was wegfallen sollte:
    • die Elemente die Energie erzeugen – behalten
    • die Elemente die dazu führen, dass alle einschlafen – entfernen

Das Video enthält viele Ideen, wie das SAFe Release Planning Event adaptiert werden kann. Die eine oder andere Idee eignet sich dafür, sie direkt in der eigenen Scaled Agile Implementierung auszuprobieren.

Die Slides zu dem Vortrag sind via einem Blog Artikel bei Crisp verfügbar.

Ich halte die Impressionen von der SAFe Implementierung bei LEGO für sehr erfrischend. Hier in Deutschland neigen wir – gerade bei großen Organisationen – dazu, uns zu ernst zu nehmen und in Details zu verlieren. Es geht nicht darum, stumpf Backlogs abzuarbeiten, sondern wir sollten auch gemeinsam Spaß haben und eine Vision teilen.

Zudem ist es wichtig zu verstehen, dass SAFe lediglich der Startpunkt für die eigene Scaled Agile Implementierung („Land of Awesome“) ist. Dies versuche ich bei meinen „SAFe“ Implementierungsprojekten stets zu vermitteln. Je größer die Unternehmen, umso weiter jedoch der Weg zur Erkenntnis, dass sich Innovationen nicht standardisieren lassen.

 

 

Alistair Cockburn über Use Cases vs User Stories

Kurzmitteilung

Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

Auszug aus einem lesenswerten Artikel („Why I still use use cases“), in dem Alistair Cockburn erklärt, warum er Use Cases für ein wertvolles Mittel zur Identifikation und Dokumentation von Anforderungen hält.

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

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.

A new new taskboard for product development

There are loads of blog posts covering topics on how to shape the perfect taskboard (Kanban/Scrumban/Scrum/Task-boards) for your agile team. My team tries to complete an ever changing project with less than twelve two-day sprints, which puts our regular board design to its limits. We tried to create a board that can actually accommodate our ever changing ideas (and solutions) and thereby created a completely different kind of taskboard.

This is how we did it:

Product Owner, UX experts and the development team sketched the components (and interactions, events, …) for a new feature onto a plain whiteboard and thereby drew the goal for the next iterations. By doing so the board even became part of the documentation as all UI elements are already displayed (and prioritized) as part of the daily work. This clearly increased the teams product focus and made the goal of the current super short iteration visible: Finish the component you are currently working on!

The current task for each developer is shown with his very own magnet. Our WIP-Limit at hand is one – so there is just one magnet per team member. Whenever a task (e.g. frontend-element) is finished the developer reviews it with another team member. If both agree, that it fulfills our definition of done (DoD) both just put a checkmark on it.
Things that are not sketchable on the board like profiling, backend-services or stylesheets have their bubbles outside the drawn userinterface.
As many other teams we also have technical dept. For bugs we have our very own fastlane bubble where bugs can be placed and the next free developer can start working on them.

On a board like this it is difficult to visualize the priority of work items. For that reason we scribbled the priority of the UI elements directly onto the front end elements. That leads to the drawback that one has to search the board when looking for the “next important” element, but this seems to be a small price to pay for such a taskboard.

By the way, since the task board has been designed and the elements have been visualized ,we were much more successful to identify further important improvements (to be addressed in the next 2 day iteration) while working on the elements.

At the moment we are very satisfied with the results we get – but we are still in the beginning of our project with only a few two-day sprints finished. We believe that there are still loads of opportunities to further improve the design of the taskboard and the way we are working with it.

Our “inspect and adapt” cycle has just started.

TaskBoards müssen nicht gleich aussehen

Update: English version available.

Es gibt unzählige Artikel im Netz, wie man ideale Taskboards – (Kanban/Scrumban/Scrum-Boards)  für agile Teams erstellen kann. Mein Team versucht zur Zeit ein sich oftmals änderndes Projekt mit weniger als 12 Zwei-Tages Sprints umzusetzen.

Die Idee war nun, unser Taskboard den sich ändernden Umständen anzupassen und eine völlig andere Form für dieses Board zu finden.

Das Ergebnis erfüllt zur Zeit all unsere Anforderungen. Tasks (Frontend-Elemente) werden abgearbeitet (siehe Magneten der Entwickler) und können abgehakt werden, wenn sie unserer Definition of Done entsprechen. Dinge die nicht im skizzierten Userinterface ersichtlich sind (z.B. Profiling-Tasks, CSS-Änderungen,…) haben eine eigene Bubble in der die entsprechenden Teammitglieder kleben.

Altlasten in Form von maintainance oder Bugs werden als Postits ans Board geklebt oder anders dargestellt.

Taskboard 2.0

Da ein skizziertes Board schlecht mit Priorisierungen einher gehen kann, schrieben wir die entsprechende Priorität des UI-Elements einfach auch ans Board. Dies bedeutet zwar, dass man ein wenig länger suchen muss, um das nächst-wichtige Steuerelement zu finden, dies ist aber ein kleiner Preis den man für solch ein Taskboard zahlen muss.

Durch die spielerische Art, mit der die UI skizziert ist, wurden auch noch während des Arbeitens Änderungen eingebracht und gleich im nächsten Zwei-Tages-Sprint umgesetzt.

Bis jetzt mögen wir unser Board; aber wir sind ja auch erst im zweiten Sprint – was noch viel Raum für Veränderungen lässt. Wenn Ihr gute Ideen für uns habt, lasst es uns wissen. Frei nach dem Motto: „inspect and adapt“.

Mike Cohn zu Release Planning

Zitat

Mike Cohn in einer (sehr interessanten) Diskussion über Release Planning nach einem Hinweis, dass viele Teams glauben nur ihre Sprints planen zu müssen:

I had spent years as a VP of Development and if my teams had ever come to me with statements like that as part of selling me on a great new process, I would have not tried the new process. Some amount of predictability is valuable (and easily achieved).