{"id":544,"date":"2021-11-28T12:39:06","date_gmt":"2021-11-28T11:39:06","guid":{"rendered":"https:\/\/rainergrau.com\/wordpress\/?p=544"},"modified":"2021-11-28T12:39:06","modified_gmt":"2021-11-28T11:39:06","slug":"radikale-innovation-4-safe","status":"publish","type":"post","link":"https:\/\/rainergrau.com\/wordpress\/radikale-innovation-4-safe\/","title":{"rendered":"Radikale Innovation f\u00fcr SAFe?"},"content":{"rendered":"\n
\"\"
SAFe – eine Folge kleiner Wasserf\u00e4lle statt eines best\u00e4ndigen Flow ?<\/figcaption><\/figure>\n\n\n\n

Es ist mir bewusst. Mit diesem Artikel kratze ich an einem Grundpfeiler von SAFe<\/a>. Trotzdem, auch auf die Gefahr f\u00fcr immer verstossen zu werden (von wem eigentlich und wohin?) liegt es mir auf dem Herzen diesen Artikel zu schreiben.<\/p>\n\n\n\n

Der letzte kleine Anstoss war meine Anfrage an einen Epic Owner, ob er eine halbe Stunde Zeit hat f\u00fcr den Austausches zu einem Thema, das er selbst angeregt. Die abschl\u00e4gige Antwort lautete ungef\u00e4hr: \u00abIch bedauere, in drei Wochen haben wir unser PI-Planning und ich bin mit der Vorbereitung vollkommen zu.\u00bb DREI WOCHEN PLANUNG um ein Planungs-Event, n\u00e4mlich das PI-Planning vorzubereiten!? SAFe Consultants haben bestimmt recht mit der Vermutung, SAFe k\u00f6nnte hier eventuell nicht ganz ideal gelebt werden. Nun gut, dieses Erlebnis war ja auch nur der letzte Anstoss diesen Artikel zu schreiben.<\/p>\n\n\n\n

Pers\u00f6nlich halte ich das SAFe Framework f\u00fcr eine gute Sammlung von good practices aus den verschiedenen Bereichen Entwicklungsarbeit agil und kollaborativ zu gestalten. SAFe ist ein veritabler Startpunkt f\u00fcr Unternehmen, die eine st\u00e4rkere F\u00fchrung und Strukturierung auf dem Weg zu (Enterprise) Agilit\u00e4t ben\u00f6tigen. Der starke Nachteil von SAFe liegt nicht im Framework selbst, sondern in der Art wie SAFe in Unternehmen eingebracht wird, n\u00e4mlich zum einen zumeist auf die IT-Entwicklung beschr\u00e4nkt 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\u00e4ufig die Anpassung einzelner Elemente an den Kontext des Unternehmens, also das Inspect & Adapt. <\/p>\n\n\n\n

Zudem, ist die Evolution von SAFe \u00fcber die Zeit einseitig. Viele Methoden, wie zuletzt Design Thinking, haben Eingang gefunden. So ist das Framework zu einer erschreckenden Gr\u00f6sse angewachsen, die eher schon an Hermes oder Prince erinnert, daf\u00fcr sind gewisse technologische und organisatorische Grundkonzepte nicht der Evolution gefolgt. \u00dcber die Zeit sind f\u00fcr mich eine ganze Anzahl an Defekten in SAFe sichtbar geworden, die es sich lohnt zu analysieren und zu \u00fcberdenken. Seit der ersten Version von SAFe hat sich viel ver\u00e4ndert. J\u00fcngstes 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. <\/p>\n\n\n\n

In diesem Artikel hinterfrage ich insbesondere das Konzept des PI und des PI-Planning<\/a>. 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.<\/p>\n\n\n\n

Punkt 1: Wir brauchen keine Releases mehr<\/h2>\n\n\n\n

Die Namen PI und Release Train kommen nicht von ungef\u00e4hr. PI bedeutet Product Increment und ein Release Train ist eine Menge an Personen, die nach drei Monaten ein Product Increment \u00abreleasen\u00bb, d.h. operativ setzen.<\/p>\n\n\n\n

Das mag damals, als SAFe in 2011 in der ersten Version ver\u00f6ffentlicht wurde, ein wichtiges Konzept gewesen sein. Damals (damals klingt schon richtig nach Historie – und ist es auch) waren die meisten Systemlandschaften in Unternehmen eng \u00fcber alle Systeme hinweg gekoppelt. Nur wenn alle Systeme ihre Change Requests korrekt und konsistent implementiert hatten, war es m\u00f6glich eine neue Version der Systemlandschaft operativ zu setzen. Das war ein l\u00e4ngerer 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\u00fcr ein Release h\u00e4ufiger 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.<\/p>\n\n\n\n

SAFe hat dieses Prinzip mit dem PI ber\u00fccksichtigt, um anschlussf\u00e4hig zu sein an die Release Zyklen in den Zielunternehmen \u2013 was damals ja vollkommen ok und richtig war. <\/p>\n\n\n\n

Und heute: Rund die H\u00e4lfte der modernen Systemlandschaften lebt in einem (Biz)DevOps Environment. Autonome Teams oder ARTs sind potentiell kontinuierlich f\u00e4hig eine neue Version ihrer IT-Bausteine operativ zu setzen. Feature Toggling, Interface Versioning und \u00e4hnliche Ans\u00e4tze erlauben einem IT-Baustein einen unabh\u00e4ngigen Release Zyklus von anderen IT-Bausteinen zu fahren und vollkommen unabh\u00e4ngig von dem Zeitpunkt, an dem ein Feature gegen\u00fcber dem Kunden operativ verf\u00fcgbar geschalten wird. Releases aus technischen Gr\u00fcnden sind kein Argument f\u00fcr ein PI, eine gesunde System Architektur vorausgesetzt.<\/p>\n\n\n\n

Es k\u00f6nnte noch ein Argument sein, dass ein operativer Einsatz, also das \u00abScharfschalten\u00bb gegen\u00fcber dem Kunden mit dem Marketing abgestimmt sein sollte und das PI sich dazu eignet. Um das Argument zu entkr\u00e4ften, gen\u00fcgt wahrscheinlich ein kurzer Austausch mit dem Marketing. Wenn das Marketing einmal das Konzept des Feature Toggle erlebt hat, also die M\u00f6glichkeit durch Konfiguration ein Feature oder einen neuen Service per Konfiguration innerhalb einer Sekunde zu genau dem gew\u00fcnschten Zeitpunkt einzuschalten, wird es die Freiheit geniessen mit optimaler Wirkung beim Kunden ein Scharfschalten von Services durchzuf\u00fchren \u2013 und in allen Bereichen einfordern. <\/p>\n\n\n\n

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 \u00fcberholt. Es gibt zwar noch Produkt Inkremente \u2013 aber wahrscheinlich in naher Zukunft jeden Tag mehrere von jedem einzelnen Team. Vielleicht w\u00e4re Value Stream Train heutzutage ein besserer Name, der das kontinuierliche Arbeiten du noch besser den inhaltlichen Bezug st\u00e4rker ausdr\u00fcckt. Wie dem auch sei: Die Anforderung nach der Synchronisierung eines Release alle drei Monate \u00fcber ein Set an Teams ist kein Argument mehr das PI beizubehalten.<\/p>\n\n\n\n

Punkt 2: Die Teams m\u00fcssen sich alle drei Monate synchronisieren<\/h2>\n\n\n\n

Synchronisation ist notwendig. Ohne Synchronisation laufen die Dinge auseinander. Wor\u00fcber ich stolpere im Ansatz des PI-Planning ist das \u00aballe gemeinsam\u00bb. Hier ist ein Prinzip, das im Kleinen sinnvoll und notwendig ist, auf eine Ebene gehoben, auf der das Prinzip keinen Sinn mehr macht.<\/p>\n\n\n\n

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\u00fcr Organisationen, Gesch\u00e4ftsprozesse, f\u00fcr Geb\u00e4ude, im Sportverein. Zwei wesentliche Prinzipien sind<\/p>\n\n\n\n