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.


Gefühlte zehn Jahre nach dem Start habe ich mich heute dazu entschlossen mein erstes Blog „Armerkater“ komplett offline zu nehmen.

Das Blog hat mich auf eine humorvolle Art auf einer Reise vom Projektleiter hin zum „Agile Coach“ begleitet und mir Raum gegeben mich kritisch mit populären Ideen aus dem Bereich PM & Agile auseinander zu setzen und den einen oder anderen Wahnsinn in diesen Bereich auch als solchen zu benennen.

Viele Themen sind später auch von anderen Seiten aufgegriffen worden, was für mich stets spannend war.

„Hach, stimmt. Darüber habe ich auch vor ein paar Jahren geschrieben!“ kam mir immer mal wieder in den Sinn.

Vielleicht werde ich etwas Zeit finden die eine oder andere Perle zu polieren und hier nochmal online zu stellen („Best of Armerkater“).

So sei es nun, Rest in Peace Armerkater!


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.


The Cummulative FlowEfficiency Diagram – new Kanban Metric

I’ve been working on ways of getting data out of Jira that is a actually helpful.
As you know, boards (and reports) in most tools are just views on the data that is there.
So you can combine different workflow-states in different boards to highlight interesting facts.

One of these visualisations is what I call a Cummulative FlowEfficiency Diagram (CFED).
In this Diagram I combine all the queueing states (waiting) and all the working states to see how the FlowEfficiency of the Kanban System changed over time.

This is a first manifestation of that chart.

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 :-)