Archiv der Kategorie: Management

The hidden power of SAFe PI Objectives

Management, Scale, ,

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 (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.“

http://www.romanpichler.com/blog/effective-sprint-goals/
Creating Effective Sprint Goals

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.“

https://agilemanifesto.org/principles.html

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.

Is SAFe evil? The answer …

Management, Scale, Watch and see, ,

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.

 

Bas Vodde zu Large-Scale Scrum (und SAFe)

Management, Scale, Watch and see, , , ,

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.

http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

 

Workshop zu Lean Product Development Principles mit Donald Reinertsen

Event, Management, Product Owner, ,

Viele Agilisten ist nicht bewusst, auf welchen grundlegenden Prinzipien agile Methoden basieren und warum manche Praktiken eben nicht immer hilfreich sind, auch wenn sie im Kanon der agilen Frameworks einen Stammplatz haben.

Bei Nachfragen wird schnell auf das agile Manifest und die zugehörigen agilen Prinzipien verwiesen. Der eine oder andere wird es noch um die „agilen Werte“ ergänzen (vgl. Scrum Values).

Diese Betrachtungsweise – so hilfreich und inspirierend sie sein mag – ist jedoch für tiefergehende Überlegungen jedoch nur bedingt geeignet. Da sowohl Manifest als auch die zugehörigen „Agile Principles“ aus einem bestimmten Kontext heraus formuliert wurden, gibt es immer wieder Bemühungen diese zu aktualisieren und in ihrer Anwendbarkeit auszuweiten (z.B. durch Scott Ambler). Mangels Problembewusstsein vieler agiler Protagonisten bleiben diese Bemühungen bisher leider eher unbeachtet.

Seit einigen Jahren wird neben „Agile“ auch zunehmend über „Lean“ gesprochen, welches unter dem Stichwort „Lean Production“ und „Lean Management“ im produzierenden Gewerbe schon länger bekannt und im Einsatz ist.

Lean Product Development

Es wurde immer wieder versucht die Prinzipien aus der Lean Production auf die Produktentwicklung anzuwenden – häufig mit mäßigem Erfolg. Dies liegt daran, dass einige grundlegende Regeln und Prinzipien bei der Produktentwicklung anders sind als bei der Produktion von Produkten. Richtig verstanden, helfen diese Lean Product Development Principles dabei, geeignete Praktiken und Bewertungsfunktionen für Agile und Lean Prozesse zu definieren bzw. einzuordnen.

Genau mit diesen Prinzipien im „Lean Product Development“ beschäftigt sich der auf dieem Gebiet international als Vordenker bekannte Donald Reinertsen seit Jahren. Sein Buch „The Principles of Product Development Flow: Second Generation Lean Product Development“ kann hier mittlerweile als Standardwerk angesehen werden.

 

Executive Workshop mit Donald Reinertsen

Im März konnte ich zusammen mit ca. 30 anderen Beratern und Executives an einem Workshop mit Donald Reinertsen teilnehmen. Herzlichen Dank an dieser Stelle an die Organisation durch bor!sgloger training KG und KEGON AG, die diesen Workshop möglich gemacht haben.

Der Einstieg in den Workshop war eine kurze Zusammenfassung, wie Lean die Produktion verändert hat und warum dies die Ertragslage von Unternehmen verbessert. Im nächsten Schritt verdeutlichte Don nochmals die Unterschiede zwischen Produktion und Entwicklung um dann über die momentan existierenden Spielarten (Schulen) von Lean Product Development zu sprechen:

  • Toyota School – Toyota definiert Lean und man muss nur Toyota kopieren, um Erfolg zu haben. Interessant an dieser Stelle war der Hinweis auf die begrenzte Innovationskraft von Toyota (Welche Innovationen neben Prius / Hybrid kommen von Toyota?)
  • Repackaging – Einfach die Ideen aus dem Lean Production übernehmen und unreflektiert anwenden.
  • Basic Principles – Identifikation von logischen und mathematischen Prinzipien im Lean Manufacturing und diese dann übertragen auf Lean Production. Übernahme fortschrittlicher Konzepte aus anderen Domänen (Verkehrswesen, moderne Kriegsführung, Internet/Netzwerkoptimierung).

Der restliche Workshop war ausgerichtet an der bekannten Strukturierung aus seinem Buch:

  • Ökonomische Betrachtung / Wirtschaftlichkeit: Wir müssen Attraktivität und Investitionsbedarf bewerten und vergleichen können.
  • Warteschlangen: Zu hohe Auslastung als primärer Grund, dass Systeme kollabieren bzw. nicht mehr zu beherrschen sind und der Investitionsbedarf („Kosten“) immer weiter steigt.
  • Variabilität / Schwankungen: Wenn in der Entwicklung Wert erzeugt wird, dann steigt automatisch auch die Variabilität . Dies ist jedoch nicht automatisch negativ zu bewerten.
  • Losgröße: Die Funktion aus Lagerkosten und Transaktionskosten muss optimiert werden.
  • Umlaufbestand (WIP, unvollendete Arbeit): Bedeutung von Transparenz, um für das Problem des Umlaufbestands zu sensibilisieren.
  • Umgang mit Unsicherheit: Bedeutung von Rhythmus und Synchronisation beim Umgang mit Unsicherheit.
  • Schnelles Feedback: Varianz und Risiken sind immer Teil einer Produktentwicklung – umso wichtiger ist schnelles Feedback.
  • Kontrolle & Entscheidungen: Zentral vs. Dezentral – soviel wie möglich „vor Ort“ entscheiden, da „Warten auf Entscheidungen“ eine erhebliche Investition darstellt und Risikokosten steigen (da der Markt sich weiter bewegt).

Diese Inhalte des Buches waren mir bereits bekannt, allerdings wurden sie durch weitere Erläuterungen und Beispiele sehr anschaulich und eingängig erläutert. Besonders die immer wieder angesprochenen Fallbeispiele konnten deutlich machen, welche Relevanz die Product Development Principles gerade bei grundlegenden Entscheidungen für das Management haben.

Für mich ist erstaunlich, wie wenig die meisten agilen Praktiker und Berater über diese Prinzipien wissen, reden und umsetzen. Im Vergleich zu der fundierten Betrachtungsweise die die Lean Product Development Principles darstellen, kann man viele beliebte Beiträge auf unseren „agilen Konferenzen“ eher dem Unterhaltungsgenre zuordnen: Schöne bunte Bilder, unterhaltsame Geschichten und ein wenig Zauberei und Show.

Hierzu bot der Workshop ein klares Kontrastprogramm:

  • Keine bunten Bilder sondern eher altbackene Folien. Dafür gut erläuterte (minimalistische) Skizzen auf Flipcharts und wenige, klare Zahlen mit hoher Aussagekraft.
  • Keine leicht verdaulichen Anekdoten sondern Einblicke in schwierige Fallbeispiele mit gekonnter, detaillierter Erläuterung des Kernproblems – und dem Hinweis, dass es eben nicht die eine Wahrheit gibt sondern das Formulieren einer hilfreichen Lösung schwere Arbeit ist.
  • Keine Zauberei sondern relativ trocken aber absolut fundierte Argumentationsketten.

ReinertsenSkizze

Herrlich! Zumindest ein Kontrastprogramm nach einem (durch mich wahrgenommenen) Zuviel an Marktschreierei und Esoterik auf den üblichen Veranstaltungen, welches gerade die letzten 1-2 Jahre durch das Thema „Agile @ Enterprise“ bzw. Skalierung von Agilität zugenommen hat.

Mein Fazit: Ein gut investierter Tag für jeden Entscheider, der dazu bereit ist seinen eigene Sichtweise zu hinterfragen und nach mehr sucht als das, was wir heute häufig als agile Rezepte verkauft bekommen.

Hinweis: Eine weitere Zusammenfassung des Workshops findet sich im Blog von KEGON.

KEGONLogo300dpi