Radikale Innovation für SAFe?

Es ist mir bewusst. Mit diesem Artikel kratze ich an einem Grundpfeiler von SAFe. Trotzdem, auch auf die Gefahr für immer verstossen zu werden (von wem eigentlich und wohin?) liegt es mir auf dem Herzen diesen Artikel zu schreiben.

Der letzte kleine Anstoss war meine Anfrage an einen Epic Owner, ob er eine halbe Stunde Zeit hat für den Austausches zu einem Thema, das er selbst angeregt. Die abschlägige Antwort lautete ungefähr: «Ich bedauere, in drei Wochen haben wir unser PI-Planning und ich bin mit der Vorbereitung vollkommen zu.» DREI WOCHEN PLANUNG um ein Planungs-Event, nämlich das PI-Planning vorzubereiten!? SAFe Consultants haben bestimmt recht mit der Vermutung, SAFe könnte hier eventuell nicht ganz ideal gelebt werden. Nun gut, dieses Erlebnis war ja auch nur der letzte Anstoss diesen Artikel zu schreiben.

Persönlich halte ich das SAFe Framework für eine gute Sammlung von good practices aus den verschiedenen Bereichen Entwicklungsarbeit agil und kollaborativ zu gestalten. SAFe ist ein veritabler Startpunkt für Unternehmen, die eine stärkere Führung und Strukturierung auf dem Weg zu (Enterprise) Agilität benötigen. Der starke Nachteil von SAFe liegt nicht im Framework selbst, sondern in der Art wie SAFe in Unternehmen eingebracht wird, nämlich zum einen zumeist auf die IT-Entwicklung beschränkt und zum anderen wie ein Rezept angewendet und nicht wie ein Framework. Vor allem das zweite bedeutet: Unternehmen nehmen viel zu viel aus dem Framework in ihre Organisation, statt nur die notwendigen Elemente. Das entspricht nicht einem Lean Gedankengut. Zudem fehlt häufig die Anpassung einzelner Elemente an den Kontext des Unternehmens, also das Inspect & Adapt. 

Zudem, ist die Evolution von SAFe über die Zeit einseitig. Viele Methoden, wie zuletzt Design Thinking, haben Eingang gefunden. So ist das Framework zu einer erschreckenden Grösse angewachsen, die eher schon an Hermes oder Prince erinnert, dafür sind gewisse technologische und organisatorische Grundkonzepte nicht der Evolution gefolgt. Über die Zeit sind für mich eine ganze Anzahl an Defekten in SAFe sichtbar geworden, die es sich lohnt zu analysieren und zu überdenken. Seit der ersten Version von SAFe hat sich viel verändert. Jüngstes Beispiel ist der Fakt, dass mit der Pandemie Covid-19, Home-Office Pflicht und Kollaborationsplattformen ein Team nicht sieben Tage in der Woche co-located an einem Ort sitzt. 

In diesem Artikel hinterfrage ich insbesondere das Konzept des PI und des PI-Planning. Ich denke wir haben in der agilen Community seit dem Etablieren des PI vor zehn Jahren gelernt und pfiffige Wege gefunden kontinuierlicher zu arbeiten als in einem drei Monate Planungsrhythmus. Darum geht es ganz wesentlich in diesem Artikel: Mehr Flow etablieren.

Punkt 1: Wir brauchen keine Releases mehr

Die Namen PI und Release Train kommen nicht von ungefähr. PI bedeutet Product Increment und ein Release Train ist eine Menge an Personen, die nach drei Monaten ein Product Increment «releasen», d.h. operativ setzen.

Das mag damals, als SAFe in 2011 in der ersten Version veröffentlicht wurde, ein wichtiges Konzept gewesen sein. Damals (damals klingt schon richtig nach Historie – und ist es auch) waren die meisten Systemlandschaften in Unternehmen eng über alle Systeme hinweg gekoppelt. Nur wenn alle Systeme ihre Change Requests korrekt und konsistent implementiert hatten, war es möglich eine neue Version der Systemlandschaft operativ zu setzen. Das war ein längerer Aufwand im Testen, im Durchlaufen von Staging Umgebungen. Es galt alle Server sowohl hardware- als auch softwareseitig zu aktualisieren und die Schnittstellen zwischen Systemen aufzubauen und zu testen. Meist war dies eine Wochenendaktion. Ich selbst war in solchen Aktionen im letzten Jahrtausend oft genug beteiligt. Wegen diesem grossen Aufwand gab es in Unternehmen, typisch Banken und Versicherungen, maximal vier Releases pro Jahr. Es war nicht wirtschaftlich den Aufwand für ein Release häufiger als viermal pro Jahr zu leisten. Wir waren damals auch nicht in der Lage das Deployment von dem operativ Schalten einer Software zu trennen, wie wir es heute mit Feature Toggling sind.

SAFe hat dieses Prinzip mit dem PI berücksichtigt, um anschlussfähig zu sein an die Release Zyklen in den Zielunternehmen – was damals ja vollkommen ok und richtig war. 

Und heute: Rund die Hälfte der modernen Systemlandschaften lebt in einem (Biz)DevOps Environment. Autonome Teams oder ARTs sind potentiell kontinuierlich fähig eine neue Version ihrer IT-Bausteine operativ zu setzen. Feature Toggling, Interface Versioning und ähnliche Ansätze erlauben einem IT-Baustein einen unabhängigen Release Zyklus von anderen IT-Bausteinen zu fahren und vollkommen unabhängig von dem Zeitpunkt, an dem ein Feature gegenüber dem Kunden operativ verfügbar geschalten wird. Releases aus technischen Gründen sind kein Argument für ein PI, eine gesunde System Architektur vorausgesetzt.

Es könnte noch ein Argument sein, dass ein operativer Einsatz, also das «Scharfschalten» gegenüber dem Kunden mit dem Marketing abgestimmt sein sollte und das PI sich dazu eignet. Um das Argument zu entkräften, genügt wahrscheinlich ein kurzer Austausch mit dem Marketing. Wenn das Marketing einmal das Konzept des Feature Toggle erlebt hat, also die Möglichkeit durch Konfiguration ein Feature oder einen neuen Service per Konfiguration innerhalb einer Sekunde zu genau dem gewünschten Zeitpunkt einzuschalten, wird es die Freiheit geniessen mit optimaler Wirkung beim Kunden ein Scharfschalten von Services durchzuführen – und in allen Bereichen einfordern. 

Fazit: der historische Aspekt des Product Increment und des Release Train greift in modernen Cloud (Biz)DevOps Systemumgebungen nicht mehr. Der Name Release Train ist überholt. Es gibt zwar noch Produkt Inkremente – aber wahrscheinlich in naher Zukunft jeden Tag mehrere von jedem einzelnen Team. Vielleicht wäre Value Stream Train heutzutage ein besserer Name, der das kontinuierliche Arbeiten du noch besser den inhaltlichen Bezug stärker ausdrückt. Wie dem auch sei: Die Anforderung nach der Synchronisierung eines Release alle drei Monate über ein Set an Teams ist kein Argument mehr das PI beizubehalten.

Punkt 2: Die Teams müssen sich alle drei Monate synchronisieren

Synchronisation ist notwendig. Ohne Synchronisation laufen die Dinge auseinander. Worüber ich stolpere im Ansatz des PI-Planning ist das «alle gemeinsam». Hier ist ein Prinzip, das im Kleinen sinnvoll und notwendig ist, auf eine Ebene gehoben, auf der das Prinzip keinen Sinn mehr macht.

Sehen wir uns dazu Prinzipien einer Architektur an. Ich rede hier nicht von Software oder System Architektur. Grundlegende Architekturprinzipen, die Einfluss auf das Design eines komplexen Systems besitzen, gelten nicht nur in der IT. Sie gelten auch für Organisationen, Geschäftsprozesse, für Gebäude, im Sportverein. Zwei wesentliche Prinzipien sind

• Seperation of concerns: Zwei orthogonale (also voneinander unabhängige) Aspekte werden unabhängig voneinander formuliert und bewirtschaftet.
• High cohesion and loose coupling: Eine qualitativ hochwertige Architektur weist folgende Eigenschaften auf: Elemente, die aufgrund eines gemeinsamen Aspekts zusammengehören, bilden ein lokales (dezentrales) Netz mit hoher Kopplung und Interaktion der Elemente. Die lokalen Netze sind untereinander durch die minimal mögliche Anzahl an Abhängigkeiten lose gekoppelt. Die Abhängigkeiten zwischen den lokalen Netzen sind (ideal) unkritisch im Sinne der Funktionsweise des Gesamtnetzes.

Wenden wir diese Architekturprinzipien auf eine Organisation an. Wird eine Organisation und ihre darin lebenden Geschäftsprozesse nach einem Domain Driven Ansatz formuliert, so ist schnell zu erkennen, dass die Organisation aus vielen Subdomains (Elementen, die aufgrund eines gemeinsamen Aspekts zusammengehören) besteht. Eine Subdomain kann als lokales, dezentrales Netz interpretiert werden, welches einen klaren Kontext besitzt mit einer ebenso klaren Abgrenzung gegenüber anderen Kontexten (Subdomains). Martin Fowler nennt dies einen bounded context. 

Subdomains besitzen Abhängigkeiten zueinander. Die maximal mögliche Anzahl Abhängigkeiten der Subdomains beträgt mathematisch gerechnet n*(n-1)/2, mit n als die Anzahl der Subdomains. Besteht ein Geschäftsmodell eines Unternehmens aus zum Beispiel 25 Subdomains, so beträgt die theoretische Anzahl an Abhängigkeiten 300. Wenn jede dieser Abhängigkeiten im Schnitt vier Kommunikationsschnittstellen verschiedener Informationstypen aufweist, wären insgesamt 1200 Schnittstellen zu pflegen.

Ein nicht wissenschaftlicher Check von mir der Umgebungen, die ich kenne aus Transport, Versicherungen und eHealth, weist in Realität eine erheblich geringere Anzahl an Abhängigkeiten zwischen den fachlichen Subdomains des Unternehmens aus, geschätzt ein Viertel davon. Ich bin überzeugt, dass dies einmal einer wissenschaftlichen Untersuchung wert wäre.

Kommen wir zu den Auswirkungen auf die Organisation. Wenn autonome Teams für die Entwicklung von Subdomains verantwortlich sind, dann müssen sich genau diejenigen Teams synchronisieren, die Abhängigkeiten besitzen. Es ist also möglich Cluster von Teams mit Abhängigkeiten zu identifizieren. Nehmen wir das Beispiel von oben mit 25 Subdomains. Statt mit 24 anderen Subdomains Abhängigkeiten zu diskutieren, wäre es nur 6 Subdomains. Es müssten sich theoretisch nur je 6 Teams zueinander synchronisieren. In der Realität sind die Abhängigkeiten allerdings nicht gleichverteilt. Es existieren Subdomains, wie zum Beispiel «Produkt Informationen (PIM)» im Retail Business, die wesentlich mehr Abhängigkeiten besitzen. Hingegen existieren ebenso Subdomains, die eventuell nur eine oder zwei Abhängigkeiten besitzen. 

Zurück zum PI-Planning. Konsequent zu Ende gedacht bedeutet diese Erkenntnis: NICHT ALLE TEAMS müssen sich gemeinsam an EINEM Event synchronisieren. Es genügt, wenn sich die Cluster von Teams synchronisieren, welche Abhängigkeiten zueinander besitzen. 

Hier spielt noch ein weiterer Aspekt zu Kadenz und Synchronisierung eine Rolle. Es ist relevant, dass die verschiedenen Meetings (Events) in einem Unternehmen abgestimmt aufeinander in einem gemeinsamen Takt stattfinden. Idealerweise gilt dieser Takt nicht nur in der Entwicklung, sondern auch in den operativen Einheiten des Unternehmens, ideal bis zur Geschäftsleitung. Ein gemeinsamer Takt bedeutet jedoch nicht, dass alle Synchronisierungen zum identischen Taktschlag stattfinden müssen. Ein Cluster von Teams, welches kundennahe agiert in einem sich schnell veränderndem Umfeld, bevorzugt eventuell ein Synchronisierungsevent jede zweite Woche, einem Cluster von Teams, welches im Kontext des Accounting in einer SAP-Umgebung aktiv ist, genügt eventuell eine Synchronisierung jede vierte oder achte Woche. Um es musikalisch auszudrücken: Das ganze Unternehmen schwingt im 4/4 Takt, allein gewisse Cluster spielen eine Achtel Noten Melodie, andere Cluster spielen eine tragende Melodie im zwei ganze Schläge Rhythmus. So kann unterschiedlichen Veränderungsgeschwindigkeiten im Unternehmen Rechnung getragen werden.

Nun steckt in SAFe der Gedanke von ARTs einschliesslich der Idee, dass ein ART nach dem Gedanken des Domain Driven Ansatzes identifiziert wird und genau somit dem zweiten Architektur Prinzip folgt. Ein ART wäre dann so ein Cluster an Teams, die Abhängigkeiten besitzen und ihrer Gesamtheit einen Wertstrom des Unternehmens repräsentieren. Wenn wir die Realität von ARTs in Unternehmen ansehen, wird dem Prinzip (leider) nur geringfügig gefolgt. Das Framework SAFe bietet im PI-Planning eine Praktik an, um diese Abhängigkeiten zu managen. Dies ist bedauerlich. Anstatt einen Ansatz zur Verfügung zu stellen, wie Abhängigkeiten vermindert werden können, um das Organisationdesign zu verbessern, verwaltet SAFe Defekte im organisatorischen Ansatz ohne Anreiz zu dieser Optimierung. Domain Driven Design oder Values Stream Design sind Ansätze für ein optimiertes Organisationsdesign.

Mein Plädoyer: Es ist sehr wertvoll in ein für das Unternehmen geeignetes Domänenmodell zu investieren (bitte nur ein einziges) und anschliessend den Clustern von Teams (wir können diese ja als ARTs organisieren) maximal mögliche Autonomie zu geben. Dann können wir das PI für alle kippen und die einzelnen Cluster ihre spezifischen Abhängigkeiten mit geeigneten Synchronisierungsmechanismen adressieren lassen, abgestimmt auf den im ganzen Unternehmen geltenden Takt.

Fazit: Mit einem geeigneten Domain Driven Design Ansatz für die Geschäftsmodelle des Unternehmens ist es möglich Abhängigkeiten zwischen (Cluster von) Teams zu vermindern und damit die Komplexität im System besser beherrschbar zu gestalten. Dieser Ansatz erlaubt es Clustern mehr Autonomie zu geben mit weniger Notwendigkeit zur Synchronisierung unter Clustern. Der Aufwand für das Management von Abhängigkeiten sinkt, so dass dieser Aspekt in einem gemeinsamen PI-Planning überflüssig ist.

Punkt 3: Eine gemeinsame Vision

Eine gemeinsame Vision aufzubauen und im Unternehmen zu kommunizieren ist ein elementares Element des agilen Arbeitens. Das PI Meeting enthält einen entsprechenden Block, in welchem die gemeinsame Vision von Business und Architektur kommuniziert wird, also das Einschwören auf den Nordstern, der alle unsere Entscheidungen im kommenden PI leiten wird. Es ist relevant das «Warum» verständlich zu erklären, ideal verbunden mit der Chance Feedback zum Warum zu bekommen. Denn auch das Warum ist nicht festgenagelt und verändert sich über die Zeit.

Ich hatte die glückliche Chance in einigen PI Planning Meetings in verschiedenen Unternehmen Member zu sein und auch Gast sein zu dürfen. Nach meiner Beobachtung war die Kommunikation der Vision für die Entwicklung der Business und System Architektur eher ein One-Way-Monolog, zumindest in den grösseren Unternehmen. Das Gefühl stand präsent im Raum: Die Geschäftsleitung gibt den Marschbefehl in Richtung X, die Enterprise Architekten haben im stillen Kämmerchen ausgeheckt wie in Richtung X gelaufen wird und wir als Betroffene haben nun nur noch zu laufen. Die Chance zum Feedback und Challenging war gering. Feedback und Challenging sind jedoch wichtige Elemente, um ein strategisches Alignment im Unternehmen zu erreichen.

Ein Szenario für ein strategisches Alignment könnte wie folgt institutionalisiert werden. Geschäftsleitung und Enterprise (Business, System) Architekten treffen sich regelmässig (in Events mit fixer Kadenz) mit je einem Team Cluster einer (Sub)Domain in einer Challenging Session. In dieser stellen Geschäftsleitung und Enterprise Architekten den Nordstern, die Vision, die strategische Entwicklung vor – wie auch immer das Unternehmen diesen Begriff nennen mag. Mehr Zeit sollten Geschäftsleitung und Enterprise Architektur in diesem Event dem Challengen des Nordsterns gönnen. Sie sollten den Teilnehmer:innen den Raum öffnen für Feedback oder das Einbringen von Bottom-up Ideen. In einem Unternehmen mit immerhin über eintausend Mitarbeiter*innen, welches nicht nach SAFe organisiert ist, durfte ich dieses Prinzip erleben. Ein besseres Alignment über alle Ebenen im Unternehmen habe ich persönlich noch nicht erlebt. 

Fazit: eine Vision, den Nordstern, den Purpose – oder wie auch immer wir das nennen wollen – im Unternehmen zu verbreiten ist ungemein wichtig, um fokussiert, erfolgreich und gemeinsam das Unternehmen zu entwickeln. Die beste Art und Weise ist dazu der direkte Austausch über alle Ebenen im Unternehmen hinweg. Das PI-Planning mit seiner eher One-Way ausgelegten Kommunikationsform ist für mich persönlich nicht das ideale Mittel. Nehmen wir doch dieses Element aus dem PI Meeting heraus und schaffen ein eigenes Gefäss für diese sehr relevante Kommunikation. So generieren wir einen höheren Wert für das Unternehmen – nämliche echtes gegenseitiges Verständnis und Alignment.

Punkt 4: Den Flow fördern

Flow im Unternehmen zu etablieren ist wertschöpfend. Mit der Optimierung des Flow minimieren wir den Anteil des Waste in unserer Organisation. Queueing Theorie, Kadenz und Synchronisierung sind wichtige Elemente der Flow Optimierung. Kadenz und Synchronisierung habe ich in dem Artikel bereits diskutiert, nun gilt es mit diesen Konzepten den Flow fördern.

Die Frage sei erlaubt, warum wir denn so an dieser drei Monate Kadenz des PI hängen. Mit diesem, wie in Stein gemeisselten, drei Monate Mega-Sprint sehe ich im heutigen Setup von Arbeitswelten und Teamsetup mehr Nachteile wie Vorteile.

Nachteil eins ist der, meiner Wahrnehmung nach, ebenso missbrauchte wie unnötige Innovation & Planning Sprint. Gut gedacht scheitert er in der Realität. Die Realität in den meisten Unternehmen ist (leider) noch immer das Push Prinzip auf der Ebene des Portfolio, also an dem noch immer vielfach existierenden Übergang vom «Business» zur «Entwicklung». Das Business wünscht sich … und die agile Entwicklungsorganisation versucht nach bestem Wissen und Gewissen die Wünsche zu realisieren. Da historisch die Entwicklungsorganisation unter dem Erklärungszwang des Effizienzmangels leidet, setzt sie sich ebenso dem Push aus, wie das Business seine Breitseite an Wünschen erfolgreich formuliert, vielleicht sogar in Form von Verträgen mit Partnern im Ökosystem manifestiert (“nun haben wir den Vertrag geschlossen, nun müssen wir als Unternehmen auch liefern”) und dies durch eine ambitionierte GL gestützt. Wenn wir ehrlich sind – das ist nach wie vor die Realität in vielen Unternehmen. Der ganze Pull in der Entwicklungsorganisation ist nur ein kleiner Teilerfolg, wenn der Rahmen rund um die Entwicklungsorganisation im Push agiert.

In der Folge wird systematisch zu viel Arbeit in das PI-Planning hineingenommen. Eigentlich genau das, was jedes agile Prozess Framework versucht zu vermeiden. In Scrum erfolgt dies durch das Team beschränkter Grösse, das sich und seine Leistungsfähigkeit durch kurze Sprints bestens kennt und so mit schnellem Feedback überprüft. In SAFe dauert das PI drei Monate, bis zu hundert Mitarbeiter*innen sind in einem ART. Das scheitert die gesunde Selbsteinschätzung, die ein Team von fünf bis acht Mitarbeiter:innen sich erwerben kann. Der typische Defekt ist der Missbrauch des IP Sprint, um zumindest das meiste des PI Umfang doch noch abzuschliessen. Nur sehr selten wird der Innovation, also dem “I” in “IP” überhaupt Zeit gewidmet und viel zu wenig dem Planning, also dem “P” in “IP”, welches ja das nächste PI vorbereiten soll. Das hat weitere Konsequenzen. Da dem «Planning» zu wenig Zeit gewidmet wird, ist das nächste PI schlecht vorbereitet. Um zumindest etwas in den Händen zu halten, sind Epic Owner, Business Analysten etc. im Dauerstress vor dem PI-Planning. Sie sind ja noch vom aktuellen PI im Stress, weil es gilt all diese Capabilities und Features abzunehmen, die zu spät ihre DoD (Definition of Done) erreichen. Da das Business noch immer Wünsche hat, man selbst schlecht vorbereitet ist und keine ausreichende Transparenz über die eigene Leistungsfähigkeit besitzt, nehmen die Teams mit dem Prinzip Hoffnung eben doch wieder mehr hinein als verdaubar ist – ein Teufelskreis. Machen Sie einen einfachen Test (siehe meine Einleitung): fragen Sie während des IP Sprints eine der Product Managerinnen oder Epic Owner*innen ob sie Zeit für ein Afterwork Beer hat, um sich über die Ideen aus dem “I” zu unterhalten. Die Antwort ist wahrscheinlich…?

Um noch ein Argument hinzuzufügen: Innovation fest auf den Zeitstrahl gesetzt hat noch nie funktioniert. Kreativität funktioniert einfsch nicht nach Plan. Das Grundprinzip für Innovation ist Slack Time. Slack Time ist (ein gewisses Mass an) freie Zeit, über die ein Team frei verfügt, die das Team ganz nach Belieben und Bedarf einsetzen kann. Ist das Alignment im Unternehmen erfolgreich und das Team positiv motiviert, so setzt es seine Slack Time für das Unternehmen ein. Ein Team ist genau dann kreativ, wenn der Zeitpunkt dazu reif und die Zeit vorhanden ist – und nicht zwischen dem 13.07 ab 8:00 Uhr bis zum 15.07 14:30. Wie Innovation funktioniert mit einem geeigneten Mix an kontinuierlicher Innovation und radikaler Innovation füllt ein Buch. Daher lasse ich diesen Ausflug in Kreativität und Innovation hier aus mit der Feststellung: so jedenfalls funktioniert es nicht.

Fazit: der Takt von drei Monaten ist geeignet, um auf einer abstrakteren Ebene als der Team Ebene das Alignment zu adressieren, auch um Transparenz über den taktischen Fortschritt zu bekommen und über einen ungefähren Forecast in die Zukunft. Ein drei Monate Abschnitt ist jedoch weder geeignet, um den Scope einer Planung festzuzurren, noch um Innovation nach Stundenplan unterzubringen. Drei Monate sind ein zu langer Zeitraum, um Flow zu etablieren. Aktivitäten, die im Sinne des Flow häufiger stattfinden sollten wie Planung, Integration, Synchronisation konzentrieren sich auf den Zeitraum des PI-Planning. Das zerstört den Flow der kontinuierlichen Entwicklung. Der Flow profitiert, wenn das PI-Planning auseinandergenommen würde und die einzelnen Elemente des PI-Planning in durchaus unterschiedlicher Kadenz im Flow eingesetzt werden. Elemente, welche abstraktere Konstrukte adressieren drehen typisch langsamer, etwa im zwei ganze Schläge Rhythmus des Takts, als konkrete Elemente, die im Achtel Noten Rhythmus spielen.

Punkt 5: Warum nicht das PI evolutionär zum Flow weiterentwickeln?

Gehen wir noch einmal an den Anfang von SAFe zurück. Historisch gesehen war das PI ein guter Start. In den letzten zehn Jahren, von SAFe Version 1.0 bis Version 5.1 hat sich viel verändert, sowohl technologisch als auch organisatorisch. Nicht zuletzt hat Covid-19 eine erhebliche Veränderung in unserem Arbeits- und Sozialverhalten bewirkt. Wir haben gelernt und unsere Arbeitsweisen haben sich verändert. Leider reflektiert sich dies meiner Meinung nicht an allen Stellen im SAFe Framework. 

Wenn ich an diese Stele etwas zynisch sein darf: Wahrscheinlich hat das auch mit Marketing zu tun. Ein Lacoste Hemd ist eben nur ein Lacoste Hemd, wenn ein Krokodil auf dem Hemd zu sehen ist. SAFe ist nur dann SAFe, wenn es ein drei Monate dauerndes PI besitzt. Rund um SAFe wird eine Menge Consulting und Schulung angeboten. Es gälte eine Menge an Consultants zu schulen – wobei, da liesse sich wieder Geld durch Zertifizierung verdienen. Ich persönlich hoffe auf radikale Innovation auch bei SAFe.

Trotz aller Kritik von meiner Seite, das PI-Planning enthält charmante, wichtige und relevante Elemente. Es ist sehr sinnvoll regelmässig zu synchronisieren, ob wir uns im Grossen und Ganzen in Richtung Vision bewegen. Es ist sehr sinnvoll alle Mitarbeiter*innen mit in die Kommunikation zu nehmen. Es ist sehr sinnvoll die Architecture Vision und Runway zu erklären, um debt transparent werden zu lassen und zu bekämpfen. Viele weitere sinnvolle Elemente sind im PI-Planning enthalten. 

Ich stelle die ketzerische Frage: Ist es mit der Entwicklung von Cloud & Container Technologie, BizDevOps Ansätzen, Virtualisierung von Teamarbeit, Home-Office Konzepten, vielfältigen arten Flow mit einer Anzahl kleiner, aufeinander abgestimmter und fokussierter Events in Kadenz zu etablieren, Value Stream Erfahrungen, Kanban und Scrum etc. noch sinnvoll alle Mitarbeiter*innen in Abständen von drei Monaten zwei Tage lang kompakt mit einen PI-Planning zu «belästigen» und anschliessend alle in einen drei Monate Super Sprint zu schicken?

Ich behaupte: Nein, es macht keinen Sinn – wir haben valide Alternativen entwickelt. Nehmen wir uns doch einmal Zeit und hinterfragen kritisch, von einem neutralen Standpunkt aus, die einzelnen Elemente eines PI-Planning. Warum nicht in Analogie zu liberating structures überlegen, das PI-Planning in seine Elemente zu zerlegen und neu, Flow gerecht, zu arrangieren. Jedes einzelne der Elemente mag sinnvoll sein, aber nicht in der drei Monate Kadenz alles zusammen.

Wie wäre es 

• In kürzeren Abständen als drei Monate ein Team übergreifendes (ART) Planning durchzuführen? 
• ARTs wirklich nach einem Domain Driven Ansatz zu identifizieren und Abhängigkeiten minimieren statt managen?
• Den Mut haben und in trägen Subdomains wie Zahlungsfluss, Asset Management in langsamerer Kadenz zu synchronisieren als in kundennahen Subdomains?
• Die Führung animieren, statt die Vision einmal alle drei Monate vom Vortragspult aus im Monolog zu verkünden, diese direkt in die ARTs zu tragen und dort eine für alle sinnstiftende Diskussion zu führen?
• Das ganze Unternehmen in einen Takt bringen mit fein aufeinander abgestimmten, sehr spezifischen, kurzen, fokussierten Events in für die (Sub)Domain spezifischer Kadenz
• Und…und…und…

So könnten wir jeden Aspekt des PI und des PI-Planning durchgehen und entscheiden, ob wir ein eigenes Event dafür einsetzen wollen in einer dem Kontext spezifischen Kadenz, oder ein gemeinsames, fokussiertes, welches einem übergreifenden Alignment dient.

Der gemeinsame Takt mit aufeinander abgestimmten Events in spezifischer Kadenz bedeutet mehr Fokus pro Event, deutlich weniger Abhängigkeiten in der Planung der Planung (…in der Planung der Planung … das gefällt mir), weniger Waste. Es bedeutet weniger Lastspitzen bei gewissen Rollen vor dem PI-Planning. Es bedeutet  mehr Flow und Autonomie von Teams.

Aus meiner persönlichen Wahrnehmung in der Arbeit mit Unternehmen, die nicht mit SAFe gestartet sind und ihr eigenes skalierendes agiles System etabliert haben, entsteht ein solches System. 

Sind wir mutig und experimentierfreudig oder Rezept gläubig?

Um das ganze abzurunden: Es gibt ein nett zu lesendes Buch von Tom de Marco aus uralten Zeiten mit dem Titel «Adrenalin Junkies and Template Zombies». Darin findet sich eine Sammlung aus Verhaltensweisen in Unternehmen, anekdotisch beschrieben, die sowohl eine zu konservative als auch eine zu progressive Haltung karikieren. Eine der Geschichten zielt darauf ab, dass eine Methode, ein Verfahren einfach so in Stein gemeisselt ist, dass es nicht mehr ohne Risiko für den Hinterfragenden hinterfragt werden darf.

Ich habe das Gefühl mit dem PI und dem PI-Planning sind wir an dem Punkt. Das Prinzip war einmal gut, es funktioniert auch nach wie vor – suboptimal. In den letzten zehn Jahren hat sich viel verändert, organisatorisch, technologisch, methodisch. Es wird Zeit mutig zu sein und zu experimentieren, ob wir nicht eine als unverrückbares Grundprinzip wahrgenommene Gewohnheit durch pfiffigere Ansätze ersetzen können.