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.
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.
Ä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.
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.
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 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 (https://scrumguides.org/scrum-guide.html). 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.“
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
Und dazu passend das „Cow Board“ mit dem visualisiert wird wie der Status der verschiedenen Agile Release Trains (ART) ist:
Ready for SAFe
erstes PI Planning
Weitere Betreuung / Professionalisierung
Reduktion des Coachings..
Natürlich inklusive Cow Impediments :-)
Hinweispflicht zu Cookies
Webseitenbetreiber müssen, um Ihre Webseiten DSGVO konform zu publizieren, ihre Besucher auf die Verwendung von Cookies hinweisen und darüber informieren, dass bei weiterem Besuch der Webseite von der Einwilligung des Nutzers
in die Verwendung von Cookies ausgegangen wird.
Der eingeblendete Hinweis Banner dient dieser Informationspflicht.
Sie können das Setzen von Cookies in Ihren Browser Einstellungen allgemein oder für bestimmte Webseiten verhindern.
Eine Anleitung zum Blockieren von Cookies finden Sie