Schlagwort-Archive: #scaledagile

#RTEBarCamp 2020

Die Rolle des Release Train Engineers (RTE) in SAFe ist von zentraler Bedeutung und sehr anspruchsvoll. Als RTE kümmert man sich um die die Weiterentwicklung des Agile Release Trains (ART) – dem Team-of-Team Konstrukt welches eines der zentralen Organisationsmuster im SAFe darstellt.

Die Aufgaben eines RTEs sind vielfältig; Die Verantwortung und Anforderungen sind groß. Vor diesem Hintergrund ist es essentiell sich stetig zu lernen und sich weiter zu entwickeln. Die beste Gelegenheit bietet sich im Austausch mit anderen Personen die ähnliche Aufgaben zu erledigen und Herausforderungen zu meistern haben.

#RTEBarCamp 2019

Dies war der Grund warum wir 2019 das erste #RTEBarCamp ins Leben gerufen haben. Das Feedback der mehr als 40 Teilnehmer zu dieser ersten Veranstaltung war sehr positiv und uns darin bestätigt, dass es einen großen Bedarf für Austausch auf Augenhöhe gibt.

#POPMBarCamp 2020

Ähnlich positives Feedback haben wir auch für das erste #POPMBarCamp bekommen, auf dem sich mehr als 60 Interessierte rund um Produktentwicklung austauschen konnten. Eines der Highlights auf dem #POPMBarCamp war sicherlich die sehr inspirierende Keynote „Awesome Superproblems“ vom Agilen Urgestein Luke Hohmann mit dem wir die Tage zuvor eine SAFe Partner Masterclass zum neuen Training „Agile Product Management“ verbringen konnten.

#RTEBarCamp 2020

Für diesen Juli haben wir die Neuauflage vom #RTEBarCamp geplant – dieses Mal wohl mit einem Schwerpunkt rund um extrem große Organisationen – den Large Solutions – in denen es darum geht viele hundert Personen in einer Produktentwicklung zu koordinieren. Damit rückt die Rolle des Solution Train Engineers (STE) in den Fokus.

Ich freue mich darauf, mich mit euch auf dem kommenden #RTEBarCamp auszutauschen, gemeinsam mit euch zu lernen und mit euch zu wachsen. Sei es bei Diskussionen rund um Themen für den Scrum Master, für den Release Train Engineer oder für den Solution Train Engineer.

Infos zum Termin, zur Location und zur Agenda findet ihr hier:

The hidden power of SAFe PI Objectives

Establish the feedback loop with PI Objectives

In the Scaled Agile Framework (SAFe) the „PI Objectives“ are a summary of what an Agile Team (Team PI Objectives) and what all the Teams together as the Agile Release Train (Program PI Objectives) intend to achieve in the next Program Increment (same is true for the further aggregation of PI Objectives for the Solution Train).

The PI Objectives are a key element to create alignment on what the really important stuff is we need to focus on. They help to create a shared understanding of what Business Value means to the business and by which outcomes it can be realized for the ART in the Program Increment.

They are written and agreed on in the PI Planning (including the assignment of „Business Value“) and tracked during PI Execution. They finally close the feedback loop for the PI at the System Demo when planned and delivered outcomes are compared and we get a better understanding of the level of predictability we have reached. 

They are of such high importance that they are so-called „first-class citizens“ and are prominently displayed on the SAFe Big Picture.

PI Objectives –
First Class Citizen in the Scaled Agile Framework

PI Objectives provide a way to work goal-oriented and check understanding, however often they are not used at all. Why is that and what is missing when you don’t use PI Objectives? 

Scrum Sprint Goals

Very early in the history of Scrum, the concept of a team having clear goals and trying everything to meet these goals was a key idea the inventors and early adopters of Scrum emphasized again and again. Still, the practice of defining Sprint Goals is still being ignored by a lot of Scrum teams while the importance of defining and following goals is more and more emphasized in the recent iterations of the Scrum Guide where it is stated that the Sprint Backlog includes selected backlog items plus a plan to deliver the product increment and realize the Sprint Goal. The backlog items are just there to make the work visible required to realize the Sprint Goal. While most Scrum Teams learn that with the Sprint Planning the Sprint Backlog gets logged-in, this is not what is stated in the Scrum Guide ( In the guide, it is clearly stated that the Sprint Backlog may emerge during the Sprint as the Team learns more about how to achieve the Sprint Goals.

To put it in a clear way: It’s meeting the Sprint Goals that count not mechanically delivering the set of backlog items (often „User Stories“) with their Acceptance Criteria and DOD!

„A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint.“

Many SAFe implementations underuse PI Objectives

In Scrum, the Sprint Goals define an important focus point where all value delivered, progress and all effort spent is measured against and a way which is used to create alignment in the Team and between the Team and all the stakeholders. In SAFe the concept of Iteration Goals has the same purpose for the Team and the Iteration.

Take this concept and scale it up and you will end up with something like PI Objectives as described in SAFe. 

Team PI Objectives, Iteration Goals and Stories/Features – all related

While the problem of not working „goal oriented“ is present in most Scrum implementation the same is true for many Scaled Agile Framework (SAFe) implementations. In most Agile Release Trains (ARTs) the PI Objectives are constantly underused and often there is a strong resistance to use them at all as „we do have the Features and Stories we need to deliver“.

Looking at the official training material on this topic it becomes clear that there is not enough guidance on how to write and use PI Objectives in a productive, value-generating manner. While it is clearly communicated that in the standard PI Objectives belong to the expected results of a PI Planning event the examples displayed in the official SAFe 4.5 training material may even point you in the wrong direction on how to do it (IMHO got much better in the SAFe 4.6 material).

Some additional guidance for PI Objectives

Beside the guidance article found on the official SAFe site there are some additional articles and presentations available describing the importance of PI Objectives in a different way and giving better guidance on writing and using them.

The Role of PI Objectives

In this advanced topic guidance article for SAFe Fellow Eric Willeke summarizes the role of PI Objectives. We will refer to this article later in more detail…

The Synergistic Nature of PI Objectives

Charlene Cuenca give a good overview of the role and importance of PI Objectives in this presentation she gave at the Global SAFe Summit 2018 in Washington.

Measuring Business Value

This presentation (also Global SAFe Summit 2018) by Drew Jemilo & Jennifer Fawcett contains an explanation of how to write better PI Objectives and how to assign Business Value in the PI Planning. The slides explaining the concept and application of PI Objectives are very valuable and many readers like this approach more than the SAFe 4.5 training material. The talk is available on video.

What are good PI Objectives?

PI Objectives are one of the results of a PI Planning event in which we were able to agree on some shared goals (outcomes) that the Teams / the full ART should deliver in the next Program Increment. Teams in the ART commit to doing everything in their power to deliver their Team PI Objectives or make it immediate transparent when a PI Objective is at risk.

The objectives are written in a common language and understandable by the other Teams, the Stakeholders and Business Owners. They might be connected to a specific milestone like a tradeshow, maybe an aggregation of Features or a combination of different elements.

Most important is that benefits and value are clearly understandable and connected to the overall goal and the strategy of the organization and the ART which means a PI Objective may reflect directly business goals or might emphasize important enablers (gaining information, investing into technology).
Therefore the PI Objectives are describing what value is going to be produced by the Agile Release Train and as such supporting the primary principle of the Agile Manifesto:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

PI Objectives do not need to map directly to Features in the Backlog but they sometimes might be a very important Feature or an aggregation of Features where the aggregation as such makes sense from a business perspective – which is not „Deliver Feature 1-3“ but something like „Initial autonomous parking capability in standard parking lots type 1“ (which probably includes functionality specified in Features 1-3).

By agreeing on the objectives of the whole ART including its Stakeholders are aligned to a shared mission, everybody knows what are the goals for the next Program Increment. This helps to decentralize decision-making and usually improves the flow of value.

PI Objectives help not to get lost in the details.

What benefits will you get if you use PI Objectives correctly?

Using PI Objectives helps to establish a culture of goal orientation instead of task orientation and with that focus on outcome instead of output. Used in the right way, a very valuable feedback loop with a lot of communication and collaboration between Business and Dev is created which creates high transparency and full alignment. This is important for building trust between Business and Dev and created real ownership & commitment on both sides.

Good PI Objectives provide the following benefits:

Benefits of PI Objectives

PI Objectives establish a critical feedback loop & foster collaboration between Development and Business

In his article „The role of PI Objectives“ SAFe Fellow Eric Willeke explains the following aspects of PI Objectives in more detail:

  • Validate understanding of the intent 
  • Focus alignment on outcomes rather than process 
  • Summarize data into meaningful and steerable information

Let’s have a closer look on how the feedback loop is established between Business and Development:

  1. Business and Product Management state at the beginning of the PI Planning the enterprise strategy, enterprise context, the business goals and the product vision for the next PI. While there should be an ongoing communication about these aspects during the PI Execution, everybody in the ART gets an updated clear understanding what the mission for the next PI is.
  2. The Teams take the prepared and discussed Features related to these business and technical goals and start figuring out a way how to deliver a maximum of value to their enterprise. They do this by breaking Features down to smaller chunks of work, typically User Stories, which they check for dependencies and other constraints. Then these smaller chunks of work are planned to be developed in a specific Iteration where enough capacity is available. While this might change during PI Execution it’s their base plan on how to implement work items that contribute to delivering Business Value to their enterprise. They finally summarize all the goals they want to achieve in (Team) PI Objectives and Stretch Objectives.
  3. Later in the PI Planning the Teams explain their plan using the PI Objectives and the Business Owners understand what Development will do and rates that in „Business Attractiveness“ (Business Value). This is typically a highly collaborative process where the teams explain and refine the PI Objectives and the Business Owners understand the constraints and alternatives identified by the team. Development gets better in understanding which elements are delivering value, Business understands better what is possible with the given constraints (capacity, expertise, ..). This is a core element in bridging the gap between Business and Dev and for building trust. This is part of the feedback loop in the PI Planning and critical for the collaboration and alignment between Business and Development in planning and executing the PI.
  4. An agreement is found how maximum Business Value can be delivered with the given constraints. The PI Objectives then become the business summaries of what outcomes each team intends to realize in the upcoming PI.

With all this it become clear that working with PI Objectives is a key element in SAFe as it creates transparency and alignment in a highly collaborative way. The whole organization focuses on outcomes (create business value) instead of output (deliver specific Stories / Features in a specific Iteration).

Note: This text was drafted quite some time ago and the idea was to create a series of articles about the PI Objectives. I never had the time/focus to do that but while it might not be perfectly written I see some value in publishing it now. Feel free to comment.

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.

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


Bas Vodde zu Large-Scale Scrum (und SAFe)

Die Konferenz Adventures with Agile (AWA) fand vor kurzem in London statt. Einige interessant Vorträge sind via YouTube zugänglich, u.a. ein Vortrag von Donald Reinertsen sowie ein Vortrag von Bas Vodde, einem der beiden Autoren von LeSS.

Bas Vodde geht in seinem Vortrag auf die Entstehung und Grundsätze des Large-Scale Scrum (LeSS) ein. Personen die sich mit der Skalierbarkeit agiler Ansätze beschäftigen bekommen hierbei interessante Einblicke, wie LeSS bei Nokia Networks sich langsam herausgebildet hat.

Interessant ist, welche Grundzüge von LeSS Bas betont:

  • Bei der Produktentwicklung stets den Kunden bzw. den Kundennutzen im Auge behalten (customer centric whole product focus) und eben nicht abstrakte Prozesse- oder Systemlandschaften mit deren „Ownern“ befriedigen.
  • Die Bedeutung von Feature-Teams. Ohne Feature-Teams ist LeSS nicht möglich, da nur mit Feature-Teams Abhängigkeiten aufgelöst bzw. drastisch reduziert werden können.
  • Die Unterscheidung zwischen „Multi-Team Scrum“ (LeSS) und „Multiple Scrum-Team“ Ansätzen und die unterschiedliche Sichtweise auf die Skalierung von Scrum Praktiken.
  • Verlagerung von Verantwortung (und Entscheidungsbefugnissen) in das Team bzw. in die Teams. Damit geht einher, dass koordinierende Rollen abgeschafft werden. Für Koordination, Abstimmung und Klärung sind die Teams alleinig verantwortlich.
  • Der grundlegende Überzeugung „Less is More„: Durch konsequente Eliminierung von Prozesselementen (Rollen, Artefakte, Prozess-Schritten) wird Raum geschaffen für echte, für mehr Verbesserungen. Dahinter steckt das Zusammenspiel von übertragener Verantwortung und geschaffenem Gestaltungsspielraum durch konsequente Reduzierung von Vorgaben.


Im zweiten Teil wird „dem Elefanten im Raum“, dem Scaled Agile Framework (SAFe) einiges an Zeit eingeräumt. Bas erklärt, weshalb er Ansätze wie SAFe für schädlich für eine echte Agilisierung von Unternehmen hält. Im besten Fall wäre SAFe ein „workaround in a context where the real (hard) questions are not answered“. Hierbei bezieht er sich u.a. auf die Etablierung von Featureteams, die sich im Großen und Ganzen selbst organisieren können (Verantwortung übernehmen, Gestaltungsspielraum erhalten), was letztendlich dem Aufbrechen aller existierender Strukturen entspricht.

Diese Einschätzung wurde vor mehr als einem Jahr aus meinem LeSS Kurs auch durch Craig Larman vermittelt. Viele LeSS Praktiken oder Ideen können zunächst in einem „mäßigen“ Umfeld erfolgreich eingeführt werden. Ähnlich wie einer Scrum-Einführung im Kleinen, stößt man aber schnell an die Grenzen, falls die Trägerorganisation an ihren existierenden Strukturen und Rahmenbedingungen festhalten will.

Ein Muster, das sich übrigens auch in Larman’s Laws of Organizational Behavior wieder findet:

Larman’s Laws of Organizational Behaviour

  1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
  2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
  3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, „religion“, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
  4. Culture follows structure.