Agiler Consultant, Scrum Master, Software Architekt

Im begleite aktuell ein Infrastruktur-/ Devops-Team und berate die Projektleitung, den Product Owner, sowie die weiteren, internen Scrum Master. Die aktuelle Herausforderung ist die zur Verfügung Stellung von Services für andere Entwicklungs-Teams der Behörde. Neben der virtualisierten Infrastruktur (Docker, Kubernetes auf Basis Tanzu-VMWare) vor allem die Bereitstellung von Continuous Integration Pipelines. Als SoftwareVersionierungs- und CI-Server setzen wir dafür Gitlab und Gitlab-Runner ein. Mir liegt die emergente (sich weiterentwickelnde) Architektur am Herzen. Ich setze mich für zentrale Repositories bzw. Wikis und eine homogene, prozessuale Sicht - wiederkehrende Anpassungen in der Architekturdoku sind hiermit gemeint- ein. Exemplarisch wurde hierbei arc42 für den Doku-, Review- und Genehmigungsprozess vorgestellt.

Die Bdr ist nicht nur Hersteller von Banknoten und Ausweisen für Kunden im In-und Ausland sondern auch Hersteller von Software im sicherheitsrelevanten und hoheitlichen Bereich, sowie Anbieter von Infrastruktur für Bund und Länder. Die Bundesdruckerei ist ein Substitut des Bundesfinanzministeriums.

 

Begleiten von anfänglich 3 Teams, bis alle Teams mit ihrem eigenen Scrum Mastern besetzt worden sind. Die drei Teams bestehend aus einem Webentwicklungsteam für ein Antragsportal, ein Team zur Erstellung einer Daten-Analyse Plattform für ein Forschungsdatenzentrum und ein Infrastruktur-/ Devops-Team.

 

Im begleite aktuell das Infrastruktur-/ Devops-Team. Alle drei Teams arbeiten im gemeinsamen 2 Wochen-Sprint-Rhytmus.

 

Die aktuelle Herausforderung im Devops-Team ist die zur Verfügung Stellung von Services für die anderen beiden Teams. Neben der virtualisierten Infrastruktur (Docker, Openshift mit Kubernetes) vor allem die Bereitstellung von Continuous Integration Pipelines für die DEV-, QA- und PROD-Stage. Als Softwareversionierungs- und CI-Server setzen wir Gitlab und Gitlab-Runner ein.

 

 

Zusätzlich zur Begleitung in den Scrum Regelmeetings habe ich folgende Schwerpunkte im Team Infrastruktur und Devops verfolgt :

 

• Versionierungs-Strategie (Pull-Request, Merge-Request)

• Code-Review und Branching-Strategie mit kurzlebigen Feature-Branches. Zeitnaher Merge in Origin (Master) als Qualitätskriterium der Definition-of-Done

• Speziell in Infrastruktur-Teams sind die Stories / Tasks häufig sehr technisch und Komponenten bezogen. Mithilfe von Spikes neue Tasks definieren, die dann erst realistisch geschätzt werden können.

=> Dies soll den Scope Creep begrenzen und realistische Aussagen über ein sonst ausuferndes Backlog ermöglichen.

• Schlankes und fokussiertes Abarbeiten, um wichtige Meilensteine z.B. Projektphasenende des Piloten einhalten zu können.

• Infosec: Devops Pattern (Paradigmen) des kontinuierlichen Lieferns fordern bestehende, traditionelle Wege des Security-Auditing heraus.

=> der Product Owner arbeitet bereits mit dem Infosec-Beauftragten zusammen. Das Dev Team aus Devops- und Infrastruktur-Experten berücksichtigt bereits Security bei der Umsetzung. Beispielhat sei hier Authentication, Authorization, Passwort Management und Encryption Libs und Services genannt. Sicherheit wird bereits im Code eingebaut anstatt ausschliesslich in einer nachrangigen Phase mittels Auditing später berücksichtigt zu werden (kein POST-Hardening)

• das Devops-Team stand immer in der Herausforderung, ob sie nach Scrum oder Kanban arbeiten. Da wir aber für unseren Kunden, das Gesundheitsministerium und das Bundesamt für Arzneimittelforschung mit den anderen beiden Teams ein gemeinsames Inkrement aus Infrastruktur, Datenanalyse und Antragsportal liefern müssen, blieben wir zumindest in der gemeinsamen Taktung. Aber wir hatten auch wesentliche Metriken von Kanban, wie Transparent machen der täglichen Arbeit mittes Sprint Board, verbessern der Durchlaufzeit durch kleinere Tasks und Stories. Allerdings hatten wir auch Herausforderungen, dass trotzdem wir Aufgaben erledigen mussten, die mehr als einen Sprint benötigten. Oft auch wegen externer Abhängigkeiten.

 

Darüber hinaus hatten wir ein tägliches Abstimmungsmeeting mit den anderen beiden Teams im Daily-Format – ein Scrum-of-Scrums. Wichtigste Herausforderung hierbei, dass die anderen Teams nicht nur die fertigen Komponenten als Blackbox nutzen können. Sondern die Teams auch diese vom Devops-Team zur Verfügung gestellten Komponenten selbständig bedienen und pflegen können. Wichtigstes Beispiel hier das Team Antragsportal, um den Gitlab-Runner für die Pipeline nutzen zu können. Um zum Beispiel selbständig den Build-Prozess (npm-install und java build mit maven) für die verschiedenen Stages konfigurieren zu können. => .gitlab-ci.yml Datei

 

 

Hierbei sind Abstimmungen und Beratung seitens Team Devops und Team Antragsportal immer wieder, auch über das Scrum-of-Scrums-Daily hinaus, notwendig geworden.

 

In der Agilen Crew, unserer Community aus Agilen Coaches und Scrum Mastern in den drei Teams des FDZ, habe ich ein Transition-Backlog und Transition-Board mit auf den Weg gebracht. Jeder Change soll auch messbare Metriken aufweisen. Wo wollen wir mit diesem Change hin, warum wollen wir diese Veränderung? Die Begleitung des Transformationsprozesses soll nachhaltig und stetig aber auch möglichst transparent und zielgerichtet ablaufen.

 

Zusätzlich zur Begleitung in den Scrum Regelmeetings habe ich folgende Schwerpunkte im Team Antragsportal verfolgt. Das Team Antragsportal habe ich aber im November 2021 an eine meiner Scrum Master-Kolleginnen abgegeben.

 

• Workshop Definition-of-Done, welche Qualität wollen wir uns leisten?

• Sprintziel schärfen im Planning

• Refinement, zum Beispiel bei der initialen Schnellschätzung des Backlogs. Schätzen der mit dem Kunden ausgehandelten Liefergegenstände und Liefermeilensteine inklusive Risikobeaufschlagung als zeitlicher Ausblick (Forecast)

• Schärfen der Rollen im Scrum Team, insbesondere Product Owner, Development Team, Scrum Master

• Planning, Teil II, Anlegen von Sub-Tasks propagiert. Als Transparenz-Unterstützung und Nachverfolgungshilfe im Daily

(Subtasks für Layout, Frontend, Backend, Test-Frontend, Test-Backend, Daten, Architektur, Spike)

 

Da die Teams untereinander Abhängigkeiten haben, sowohl auf dem Level der Anforderungen als auch bei den technischen Herausforderungen, habe ich ein Scrum-of-Scrums installiert (Integrations-Daily), damit regelmäßige Abstimmungen zwischen den Teams, nicht Adhoc, sondern in Regelmeetings stattfinden.

In der täglichen Arbeit im Sprint moderiere ich Meetings, führe in meinen Teams Retrospektiven durch und gebe agile Workshops. Als Mentor und Coach berate ich auch im Hintergrund auf Nachfrage bis hinein in die Projektleitung.

 

Meine Arbeit findet derzeit zu 100% remote mit den Tools Wire (Chat Tool), Outlook, Jira Server (Jira Software Data Center), Confluence, MS Office, MS Powerpoint, Zoom statt. Zoom-Moderation auch immer wieder mit allen drei Teams, dann mit Breakout-Rooms.

 

Als Whiteboard und gute Remote-Collaborationslösung nutze ich in diesem Projekt vor allem Miro.