Hm. Ich bin seit ein paar Wochen in einem „Projekt“ drin, das nach Scrum und übergeordnet nach SAFe arbeitet (allerdings ohne die Portfolio-Ebene).

Die Methode

Scrum ist eine Methode aus der agilen Softwareentwicklung. Ich habe theoretisch natürlich damit schon zu tun gehabt, aber bisher noch nicht in einem echten derartigen Projekt gearbeitet. SAFe skaliert Scrum-Teams und macht so das Arbeiten an größeren Projekten, in denen mehrere Scrum Teams benötigt werden, möglich.

Organisiert wird das alles als ART = Agile Release Train. Wichtiger Bestandteil ist das sogenannte PI Planning oder Big Room Planning genannt. Ein PI ist ein Program Increment, und beinhaltet mehrere Sprints (Entwicklungsphasen mit vorher genau geplanten und festgelegten Ergebnissen), für die geplant wird. Unsere Sprints dauern 2 Wochen, ein PI besteht aus 4 echten Sprints und einem Inspect & Adapt Sprint.

Vergangene Woche war nun das 7. PI Planning, aber das erste, an dem ich teilnahm.

Es treffen sich dafür alle Beteiligten in einem Raum, und planen über 1,5 Tage das nächste Program Increment. Dabei wird natürlich je Team geplant, wichtiger ist aber das Erkennen und Bewerten von Abhängigkeiten über Teams hinweg. Bei Scrum ist eine maßgebliche Größe die Team-Velocity, also wieviel kann das Team in einem Sprint an Arbeitsleistung erbringen (berechnet auf Grundlage der bisherigen Lieferleistungen). Davon abhängig wird festgelegt, welche Inhalte das Team bearbeiten kann. Im Gegensatz zum klassischen Vorgehen, wo meist das Ziel feststeht, und die Teamgröße angepasst wird, ist hier also das Ziel (bzw. die Lieferergebnisse) variabel, und Team + Zeit fix.

Cloud

Das „Projekt“ dreht sich um das Bereitstellen einer OnPremise-Cloud-Infrastruktur-Platform (also eine Plattform, die mit State-Of-The-Art Techniken arbeitet wie Kubernetes („K8s“ in Nerdistan 🙂 – bloß keinen Buchstaben zuviel schreiben – zwischen K und s befinden sich 8 Buchstaben, daher die 8), Kafka, Elastic, PostgreSQL, einer CI/CD-Pipeline (Continuos Integration/ Continuos Delivery) etc., dabei aber lokal bei uns in den Rechenzentren läuft. Stichworte sind z.B. Container, Docker, Skalierung, SaaS (Software as a Service), IaaS (Infrastructure as a Service), PaaS (Platform as a Service) u.v.m. Ziel ist immer das schnelle Ausrollen von Neuerungen sowie Ausfallsicherheit.

Für mich ist diese Welt übrigens auch noch relativ neu. Ich bin ja auch in der klassischen IT groß geworden. Als ich studiert habe, war von Cloud Computing noch nix zu hören (in Labors vielleicht schon… Anfang der 1990er wurde die Verteilung von Computern auf das Netz prophezeit, 1995 gab es erste Systeme, die man heute als Cloud bezeichnen würde). Und bei meinen bisherigen Arbeitgeberinnen war das auch noch kein Thema gewesen.

„Fertig“ war gestern

Projekt in Anführungszeichen, da es sich eigentlich nicht um ein Projekt im klassischen Sinne handelt, das irgendwann zu Ende ist und die Plattform dann dasteht und betrieben wird. Sondern eine solche Umgebung lebt, und zwar ziemlich schnell. Die Tools ändern sich, die Methoden, usw.

Daher ist so etwas nie fertig, es ist beständig im Wandel. Ok, das ist sowieso ein Merkmal der „neuen“, digitalen Welt – Stillstand oder „Fertig“ gibt es nicht mehr.

Operability

So. Und was mache ich in dem Ganzen?

Die „Cloud-Jungs“ (tatsächlich habe ich in den 2 Tagen PI Planning mit ca. 50 Personen) gerade mal 3 weitere Frauen entdeckt… eine Business Ownerin, eine ist externer Coach, eine arbeitet im Test Team, und ich) haben bisher hauptsächlich sehr explorativ am Aufbau der Umgebung gearbeitet. Derzeit laufen auch noch keine unternehmenskritischen Anwendungen darauf. Nun muss das Ganze aber betriebsfertig aufgestellt werden. Sprich Belange wie Revisionsanforderungen, Wartbarkeit, Dokumentation, Unterstützung durch unser 24/7 Operating, Einbindung in Change & Incident Prozesse etc. müssen allmählich implementiert/ erledigt werden. Und in diesem Team bin ich beheimatet, das sich genau darum kümmert.

Wir stellen also auch Anforderungen, die auf wenig Gegenliebe stoßen, da sie ein Stück weit ein Erwachsenwerden der Bastelstube fordern.

Das ist aber gar nicht mein Problem. Das macht mir ja prinzipiell Spaß.

Formalismen

Nein, ich tu mich im Moment noch etwas schwer mit der Arbeitsweise. Mir ist da einiges deutlich zu formell dran. Scrum und SAFe bedeuten eben verschiedenste Formalien, die wahrscheinlich auch Sinn machen, damit die übergreifende Zusammenarbeit funktioniert. Nur bin ich eben eher die Macherin. Bevor ich ewige Zeit mit Planen verbringe, tu ichs lieber gleich.

Wir verbringen gefühlt 50% unserer Zeit damit, über Methodisches zu reden statt über Inhalte. Und in diesem Team sind wir bis auf einen alle nur mit 1 Tag/ Woche dabei, also nicht unendlich viel Zeit.

Ein weiterer Punkt ist, dass ich irgendwie mit der Denke unseres Product Owners nicht so ganz klarkomme. Ich mag ihn wirklich, er ist auch ein ganz netter. Aber wenn wir über Dinge diskutieren, merke ich, dass ich völlig anders denke. Und das macht es für mich schwierig. Ich kann nicht richtig meine Punkte einbringen, weil sie nicht passen, jetzt da nicht hingehören, in eine andere Richtung gehen, whatever….

Aber wahrscheinlich muss sich das erst noch einspielen. So richtig ins Arbeiten sind wir bisher noch gar nicht gekommen, das fängt endlich kommenden Freitag an.

Ich bin gespannt und warte ab.

Nachtrag

Als ich den Artikel geschrieben habe und durchlas und ergänzte und korrigierte und etwas recherchierte und wieder was hinzufügte – und schlußendlich fand, das ich doch nur an der Oberfläche kratze – ist mir bewusst geworden, wie komplex das ganze ist, wieviel ich offensichtlich darüber nun schon gelernt habe, und wie schwer das in einfachen Worten zu erklären ist (und ja ich weiss, ich habe oben viel zu viele Fachbegriffe verwendet)….