Es ist mir bewusst. Mit dieser Blogserie kratze ich an Grundpfeilern von SAFe. Trotzdem, auch auf die Gefahr für immer verstossen zu werden (von wem eigentlich und wohin?) – es liegt mir auf dem Herzen diesen Blog zu schreiben.
Der letzte kleine Anstoss zum Schreiben war meine Anfrage an einen Epic Owner, ob er eine halbe Stunde Zeit habe für den Austausch zu einem Thema, das er selbst angeregt hatte. 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 um ein PI Planning vorzubereiten!? SAFe Consultants haben bestimmt recht mit der Vermutung, SAFe könnte hier eventuell nicht ganz ideal gelebt werden. Nun gut, die Episode war ja auch nur der letzte Anstoss.
Über die Zeit sind für mich eine ganze Anzahl von Aspekten sichtbar geworden, die es sich lohnt, zu analysieren und das Konzept des PI und des PI Planning zu hinterfragen. Da die ganze Diskussion der Aspekte mehr Raum einnimmt, als das der typische Blogbeitrag gestattet, werde ich diesen das folgende Set an Blogs widmen
- Teil 01: Es galt ein konsistentes Release zu bauen (unten)
- Teil 02: Mythos: Wir müssen uns alle gemeinsam synchronisieren
- Teil 03: Die gemeinsame Business und Architektur Vision
- Teil 04: Entwicklung ist etwas kontinuierliches und kein drei Monat-Sprint
- Teil 05: Können wir das PI nicht einfach weglassen
Die Blogs dieser Serie werden wir nach und nach veröffentlichen. Also – stay tuned, wie man so nett auf Deutsch sagt, hier ist der erste Blog der Serie, weitere folgen. Ich bin jetzt schon gespannt auf das Feedback.
Es galt, ein konsistentes Release zu bauen
SAFe, 2011 in der ersten Version veröffentlicht, ist mittlerweile über 10 Jahre alt. 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, bis an einem Sonntag früh zum Halali, also zur Produktivsetzung gerufen wurde. Daher gab es in Unternehmen, typischerweise Banken und Versicherungen, maximal vier Releases pro Jahr. Es war einfach nicht wirtschaftlich, den Aufwand für ein Release häufiger als vier Mal pro Jahr zu leisten.
SAFe hat dieses Prinzip 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. Releases aus technischen Gründen sind, eine gesunde System Architektur vorausgesetzt, kein Argument für ein PI.
Es könnte noch ein Argument sein, dass ein operativer Einsatz, als 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, 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 Release greift in modernen Cloud (Biz)DevOps Systemumgebungen nicht mehr. Eigentlich ist damit auch der Name Release Train überholt. Vielleicht wäre Value Stream Train ein besserer Name. Wie dem auch sei: Die Synchronisierung eines systemweiten Release ist jedenfalls kein Argument, das PI beizubehalten.
Der nächste Blog diskutiert die Synchronisierung zwischen Teams und/oder ARTs, also die Ebene, auf der Abhängigkeiten zwischen Teams und/oder ARTs erkannt werden und diese zu berücksichtigen sind.
