Alle Beiträge von Felix Rüssel

Über Felix Rüssel

Felix Rüssel beschäftigt sich seit 2002 mit agilen Methoden und Projektmanagement. Mit Leidenschaft unterstützt er seine Kunden dabei eingefahrene Denkmuster und Strukturen zu überwinden, um Antworten auf aktuelle Herausforderungen zu finden. Er beschäftigt sich intensiv mit der Skalierbarkeit von Agilität und Fragestellungen die sich aus der Schnittstelle Markt/Business/Umsetzung ergeben. Felix Rüssel ist Scaled Agile Framework Program Consultant (SPC), Certified LeSS Practitioner, Certified Scrum Professional (CSP), Certified Scrum Product Owner (CSPO), zertifizierter Vertriebsingenieur und besitzt Abschlüsse in Informatik sowie Wirtschaft-Ingenieurwesen.

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.

 

 

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.

 

Sprint Review

Zu den elementaren Meetings in Scrum gehört neben Planning (1 und 2), den Dailies und der Retrospektive auch das Sprint Review. Ein gut vorbereitetes Sprint Review, in dem lauffähige Software in einem geschäftlichen Kontext demonstriert werden kann, ist der gelungene Abschluss eines Sprints.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

— Scrum Guide

image

Warum ist ein gutes Sprint Review wichtig?

Ein gutes Sprint Review ist nicht nur ein Meeting in dem es darum geht, Arbeitsergebnisse abzunehmen, sondern hier werden die erstellten Lösungen in einen Kontext gebracht: Es wird nochmals die Zielsetzung des Inkrements reflektiert und erläutert, warum die geplanten Ergebnisse wichtig für die Organisation sind. Hierdurch wird allen Beteiligten nochmals in Erinnerung gerufen, warum das Inkrement so geplant wurde. Das Umsetzungsteam hat zudem die Möglichkeit, gemachte Erfahrungen und Herausforderungen sowie besondere Leistungen und Lösungen vorzustellen.

Damit spiegelt das Review nicht nur die Arbeit des letzten Sprints wieder, sondern ist auch ein Hilfsmittel für die kommenden Sprints bzw. die weitere Zusammenarbeit innerhalb eines Teams.

Im Review trifft die Sichtweise des Auftraggebers (PO) und des Umsetzungsteams aufeinander und es findet ein intensiver Austausch statt. Die Vorstellung des Business hinsichtlich Zielsetzung und Anforderungen werden ebenso erörtert wie die durch das Umsetzungsteam gewählten Lösungsvariante. Hierbei können beide Seiten voneinander lernen, gegenseitiges Verständnis verbessern und das Gelernte in kommende Sprints einbringen.

Sprint Review weiterlesen

V-Modell XT 1.4

Stefan Hagen greift einen Artikel im GPM-Blog zum V-Modell XT 1.4 auf und verlinkt auch gleich auf weiterführende Dokumentation des V-Modells XT.

Das V-Modell XT wurde seit der Überarbeitung im Jahr 2005 u.a. auch stärker in Richtung agiler und inkrementeller Ansätze angepasst. Eingefleischte “Agilisten” ordnen das V-Modell XT aber recht klar der Kategorie der “Wasserfallmodelle” zu.

http://pm-blog.com/2012/06/04/v-modell-xt-in-der-version-1-4/

Die Agilisierung klassischer Phasenmodelle kann überall beobachtet werden. Zeit sich (mal wieder) mit der aktuellen Fassung des V-Modell XT zu bschäftigen ;-)

 

Iterationen erzwingen Entscheidungen

Führt man kurze Iterationen mit definiertem Inhalt ein, so stößt man relativ häufig auf Widerstand oder erlebt, dass die versprochenen Inhalte nur als „fast fertig“ geliefert werden oder das der Product Owner sich bereits in der Planungssitzung nicht festlegen möchte, was genau geliefert werden soll.

Stefan Roock hat in seinem Artikel „Understanding Sprints and Timeboxes“ meiner Meinung nach sehr gut zusammengefasst weshalb kurze Iterationen mit einem definierten Inhalt so wichtig sind:

Es müssen Entscheidungen zu konkreten Fragestellungen und zu Prioritäten getroffen und eingehalten werden.

Iterationen erzwingen Entscheidungen weiterlesen