Archiv der Kategorie: Scale

Looking back: Reasons for adopting the Scaled Agile Framework

In the year 2002, I started to study and apply agile thinking tools, principles, methods, and practices while working as software developer. First steps were injecting agile ideas into a small team and influence the project organization to see the benefits of implementing some aspects/ideas of Scrum and using some elements of XP to improve the engineering process and the quality of the products we were developing.

At that time I was working in Karlsruhe which is known to be one the regions where Scrum and XP have its roots in Germany. In Karlsruhe I was able to benefit from the first agile initiatives in Germany with several Scrum Trainers, Scrum Consultants, and XP experts living there and inspiring more and more companies.

With other early adopters of agile ideas, we founded „KAgile“ (Methods of agile software development Karlsruhe) in 2002. This group stopped existing after 2 years but later has found a successor in the Scrum User Group Karlsruhe which is still active today.

In 2006 I joined a medium sized company that decided to use agile concepts in the product development. At that time I was quite fluent in Scrum on the team level but still missing an official certification.

In the subsequent years I have been working occasionally as Scrum Master but soon the shift was towards being a Product Owner for developing custom solutions based on a common platform but driven by customer projects. In that role, I was sort of PO towards the team and sort of project manager towards the customer in the sense that we had limited time and resources to deliver expected outcomes. Often we had requirement specifications which we were able to „agilize“ in the sense of shifting the discussion to focus on intended outcomes instead of deliverables.

During that time the company was adopting Scrum to develop their products. This was great for the teams focusing on core product development but as we were missing any portfolio management and cross-team planning we run constantly into bottlenecks and had meetings with VP level executives for hours – every sprint.

The organization refused to plan ahead, to create a shared roadmap including critical deliveries from the project perspective backed up by teams included in the planning process. The Product Management, being part of the development group was responsible to plan the features in their products (platform) but did not take into account the needs of the projects. Following the Scrum mantra, they were pushing all responsibilities to the Project Managers – which had no power to decide anything but were the messengers that usually were slaughtered by the customer for bringing the news of additional delays and missing functionality.

During my days in that company, I saw how well paid Scrum Coaches came in and tried to implement a „Scrum by the Book“ approach without grasping the very essence of it – looking at the whole value chain not just a few (development) Scrum teams! While this approach had some positive results on the team level everything outside the development teams was in deep trouble as the „balance of power“ between roles that had a more customer-centric view and roles that had a more team-centric view was destroyed.

Looking back this sounds quite strange as the agile mindset aims to improve the relationship between customer and team instead of destroying it. Unfortunately, I saw this pattern several times in other organizations as well – agile teams losing contact with the real customer as Scrum Masters and Agile Coaches tried to „protect“ them but actually doing some local optimization.

Clearly, this setup was not working at all: Either you completely stop working on customer projects as they might inject „chaos“ into your product development organization and focus on product development only – or you had to improve customer-Dev relationship which also means to rethink the project manager role and include the project manager people in a more productive manner in the agile planning process. Additionally, it became clear that the planning process must be improved to look ahead more than one Sprint so that we all have the chance to figure out what is really valuable for the enterprise.

At this time (probably 2008/2009) I run into concepts of scaling Agile and soon I came across the work of Craig Larman/Bas Vodde as well as Dean Leffingwell.

The books written by Craig & Bas caught my attention as they are breathing an agile mindset and their idea of running experiments instead of proposing „best practices“ was resonating deeply for me. The same is true for their fantastic Large-Scale Scrum (LeSS) framework which describes some great ideas and concepts.

The books written by Dean helped me to navigate through the challenges when scaling agile development. While his early writings might not have been completely agile-minded and he was not challenging/rethinking everything from scratch it was unbelievable useful as it provided a much better overview, map or Big Picture for me at this time.

In 2012 Dean made it to the Scrum-Day conference and presented his Scaled Agile Framework in Germany for the first time. I joined his workshop and three months later the first SAFe Program Consulting training in London becoming one/the first SPCs in Germany.

Starting from that time on I was referring to the work of Dean in a way that the Scaled Agile Framework provides a great map for orientation, highlighting a lot of topics/challenges that you need to work on during an Lean-Agile transition. You then might adopt the patterns as described in the standard framework or you might need to rethink them so that they better fit your context but you will always have a handy map for orienting.

To do that successfully you need to understand the value, mindset, and principles. Unfortunately, this is something which is often skipped in many Agile, Scrum and Scaled Agile implementations. I usually try to emphasize the importance in trainings I give but often the ask is to spend more time on the practices described in the Scaled Agile Framework – and that’s probably one of the largest risks applying SAFe in your organization: Cargo Cult.

So one of the main challenges you face as coach for Lean-Agile transitions – regardless of being Scrum-based or SAFe-style – is to look out for cargo cults and try to emphasize the importance of Lean-Agile principles and values.

SAFe mal ganz einfach

Das Scaled Agile Framework (SAFe) wird häufig gleichgesetzt mit dem Big Picture mit seinen vielen Elementen. Was sind aber davon die wichtigsten Elemente?

Hierfür wurde das Essential SAFe definiert, jetzt mit dem SAFe 4.5 Launch die  Konfiguration „ESSENTIAL SAFe“.

Mir sind die Themen rund um Werte und Prinzipien in SAFe wichtig, da diese die Grundlage für erfolgreiche Implementierungen darstellen. Was aber, wenn man sich auf die wichtigsten „mechanischen“ Elemente beschränken möchte?

Hier ein Video mit dem Versuch einer Erklärung (noch in SAFe 4.0 Nomenklatur).

Zweiter Teil dreht sich um eine SAFe Konfiguration die wir von KEGON zusammen mit Seibert-Media entwickelt haben.


Impediment as cow on the track

Unterhaltsame Session von Sarah Scott (Northwestern Mutual) auf dem diesjährigen SAFe Summit in dem sie ihre SAFe Implementierung vorstellt.

Besonders die Visualisierung von Impediments in Form von Kühen hat zum Schmunzeln angeregt, obwohl dahinter eine richtige Geschichte steckt:

Und dazu passend das „Cow Board“ mit dem visualisiert wird wie der Status der verschiedenen Agile Release Trains (ART) ist:

  • Ready for SAFe
  • Vorbereitung
  • erstes PI Planning
  • Weitere Betreuung / Professionalisierung
  • weitere PIPs
  • Reduktion des Coachings..


SAFe Cow Board
SAFe Cow Board

Natürlich inklusive Cow Impediments :-)



Eine Einführung in das Scaled Agile Framework (SAFe) und das Problem dabei genügend Luft zu bekommen…

Beginnt man sich mit dem Scaled Agile Framework (SAFe) zu beschäftigen und sucht eine Kurzeinführung SAFe, dann fällt der Blick zuerst auf das sogenannte „Big Picture“ welches die Startseite von dominiert.

Hat man bisher bereits Erfahrungen mit agilen Teams gesammelt und ist stets dem Agilen Prinzip

Simplicity–the art of maximizing the amount of work not done–is essential. (

gefolgt, dann kommt es häufig zu einer Gegenreaktion im Sinne von „DAS kann doch nicht agil sein!“.

Es gibt nun diverse kurze Einführungen in SAFe die hauptsächliche auf die Elemente, Struktur und Abläufe fokussieren, wie sie im Big Picture abgebildet sind.Sehr schön ist beispielsweise das SAFe 4-0 in 5 Minuten Video von Inbar Oren:

Diese Darstellungen sind sehr nützlich, um einige wichtige Praktiken und Mechanismen zu verstehen. SAFe alleine auf die konkreten Praktiken zu reduzieren ist allerdings weniger hilfreich, weil diese recht konkret sind und sicherlich nicht in jedem Kontext passend.

Mein Ansatz in Trainings zum Scaled Agile Framework ist deshalb, relativ viel Zeit mit Themen wie

zu verbringen. Gerne wedel ich dabei auch mit den Büchern von Donald Reinertsen (Flow) und Kotter (Change Management) herum.

Dies sind Grundlagen, die sicherlich nicht direkt die konkreten und aktuellen Probleme der Teilnehmer adressieren. Sie müssen jedoch verstanden sein, damit SAFe im eigenen Kontext richtig interpretiert und adaptiert werden kann.

Vor ein paar Tagen durfte ich nun sehr kurzfristig für meinen Kollegen Thorsten Janning, dem ersten deutschen SPCT, kurzfristig einspringen, um eine Kurzeinführung SAFe beim Agile Roundtable Rhein-Main zu geben.

Was tun, wenn keine Zeit für eine intensive Vorbereitung da ist? Klar, man nimmt sich eine der Standardpräsentationen und eine gehörige Portion Improvisation dazu. Meine Wahl fiel auf die „SAFe in 8 Pictures“ Präsentation, wie sie über die Seite verfügbar ist (



Schön, ich habe ca. 45 Minuten Zeit und kann einen komprimierten Überblick über SAFe geben. Da Prinzipien, Werte und das House of Lean nicht Teil dieser Präsentation ist, kommen diese Dinge auf ein Flip und ich erkläre (leider nur) kurz etwas dazu.


Es gab nur einen kleinen Schönheitsfehler bei diesem Plan – statt der erhofften 45 Minuten gabs für alles zusammen nur einen Slot von 20 Minuten.

Sehr schön, vor allem wenn man bedenkt, dass ein beliebtes Feedback für die zweitägigen Trainings ist, dass diese mindestens drei Tage lang dauern sollten :-)

Egal, nicht erschrecken lassen sondern Gas geben und noch ein bisschen Humor einstreuen, u.a. die Frage wer denn diesen Satz lesen kann:


Eine kurze Summar im Sinne von „Hey, da gibts auch noch etwas reduziertes“ mit dem Hinweis auf das Essential SAFe gabs am Schluss auch noch …

Für mich waren die 20 Minuten (die ich recht gut einhalten konnte) ein spannender, schneller Sprint mit der zentralen Frage: „Hole ich Luft oder geht noch ein weiterer Satz?“. Die Antwort war zumindest zwei mal ein lautes Luftholen :-). Na, da steckt doch noch ein bisschen Energie in den alten Knochen …

Da ich früher gehen musste, konnte ich die versprochenen Zertifikate „I survived the SAFe speed run“ doch nicht an die Teilnehmer verteilen – vielleicht das nächste Mal :-).


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.