Schlagwörter
Skills
Ich unterstütze Teams dabei ihre Reaktions- und Wettbewerbsfähigkeit durch die Einführung geeigneter agiler Methoden zu erhöhen.
Als ein bei scrum.org ausgebildeter
und bis zur PSM III durchzertifizierter Scrum Professional
https://www.scrum.org/user/215131
durfte ich die letzten 8 Jahre bereits für mehr als ein Dutzend verschiedene Kunden, in mehrmonatigen, agilen Projekten als Scrum Master und Agiler Coach arbeiten.
Ich besitze zusätzliche Zertifizierungen in ganzheitlicher Unternehmensführung nach EBM, Cobit und Servicemanagement nach Itil.
Ich arbeite gerne entlang von Wertströmen, Effektivitätsmetriken (Kunde, Stakeholder) und Effizienzmetriken (Lean, Kosten).
Damit die Ziele der agilen Teams auch den Zielen der Organisation zuarbeiten.
Ich war selber mehr als 20 Jahre Fullstack-Entwickler, bevor ich mich auf das agile Training, Begleiten und Mentoring von Teams und Leadership spezialisiert habe.
Projekthistorie
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.
Internationaler und führender Hersteller von Medizin- und Dialysetechnik
Anpassungen und Neuentwicklungen im vorliegenden Projekt PAED (Paediactric Dialysis, Dialyse Verfahren speziell für Kinder) unterliegen hohen Qualitätsanforderungen, obligatorischen, TÜV-zertifizierten Arbeitsschritten und Dokumentationen. Der Kunde arbeitet bis dato mit dem Workflowsystem Polarion, möchte aber MS Azure Devops mehr nutzen. Eine agile Prozessveränderung führt hier nur zum Erfolg, wenn die gesetzlichen Vorschriften (Inkl. Approvement) weiterhin eingehalten werden. Zusätzliche Vorteile von Agilität bzw. Kanban oder Scrum, vor allem das Arbeiten im Team (Zusammenarbeit von Individuen) und die tägliche Abstimmung, werden als sinnvolle Ergänzung gesehen. 7 interne und ein externes Team arbeiten entlang des Wertstroms. Der Kunde arbeitet im skalierten Bereich nach SAFe, in einem agilen Release-Train (ART) mit quartalsweisen Programm-Inkrements und 3-wöchigen Sprints.
In der letzten PI-Woche (Ende März) habe ich die SAFe-System Demo durchmoderiert, den Release Train Engineer unterstützt und beim SAFe-Inspection&Adaption Meeting, zusammen mit meinen Scrum Master-Kollegen, in einem WorldCafe-Format (50 Beteiligte) zu umsetzungsfähigen Action Items geleitet.
In der täglichen Arbeit im Sprint moderiere ich Meetings, führe in meinem Team und anderen Teams Retrospektiven durch und gebe für den gesamten Release-Train agile Workshops.
Ich habe mich auf das agile Training, Begleiten und Mentoring von Teams und Leadership spezialisiert, unterstütze und berate diesbezüglich auch meine vier anderen Scrum Master Kollegen/innen. Meine Arbeit findet derzeit zu 100% remote mit den Tools MS Teams, Outlook, Sharepoint, Azure Devops, MS Office, MS Powerpoint, Trello statt.
Als Whiteboard und gute Remote-Collaborationslösung haben wir sowohl für den Programm Increment (Planning, Inspect&Adapt) als auch für die Sprint-Events zuerst auf Mural und jetzt auch auf Miro gesetzt.
Unterstützung der Orga in der agilen Transition Ich unterstütze hier vor allem in der Portfolio-Analyse. Wesentlich ist, dass es im Wertschöpfungs- und Genehmigungsprozess einen transparenten, standardisierten und für alle (Produktmanagement, Consulting, Vertrieb, Geschäftsleitung) nachvollziehbaren und damit gerechten Prozess gibt. Wie sind die Chancen (ROI) neuer Produkte, Apps und Initiativen? Sind die Anforderungen eher bekannt / unbekannt, sind die technischen Herausforderungen eher bekannt / unbekannt (Stacey Graph). Gibt es bei neuen Geschäftsideen die Möglichkeit regelmäßig Kundenfeedback einzuholen? Ist überhaupt ein agiles Vorgehen notwendig - dann in den Squads - oder eher eine klassische (Wasserfall) Projektvorgehensweise? Dann evtl. auch Make or BuyEntscheidung. Passt eine neue Produktinitiative zur bestehenden Roadmap und Produktvision? Die Produkt Manager, das Consulting, der Vertrieb, die GL, der Solution Owner, sollen sich regelmässig in diesem transparenten, mehrstufigen Prozess austauschen. Evtl. die Product Owner aus den Squads beratend hinzuziehen. Die Agile Guilde evaluiert auch regelmässig neue Managementsysteme, z.B. OKR‘s, Objectives and Key Results. Hier wurde meine Expertise aus einem vergangenen Projekt erbeten. Die Herausforderungen bei OKR‘s besteht darin, sie auf Scrum zu mappen. Zum Beispiel Produktziele sollten ins Product Backlog eingegliedert werden. Agile Teams sind normalerweise reaktionsschneller als die 3 Monatszyklen von OKR‘s. Team-Ziele, die die Verbesserung der Qualität und den Lieferprozess betreffen, werden normalerweise in einer Retrospektive (Action-Items, Definition-of-Done, Qualtitäsmetriken) regelmäßig nachverfolgt. Die Produkt-Roadmap war noch zu sehr „Wasserfall“ getrieben und Projektplan-bezogen auf mehrere Jahre ausformuliert (detailliert). Sie spiegelte aber nicht die Realität der Product Backlogs und der Inkremente wieder. Wir halten zwar jetzt weiterhin die Roadmap-Timeline ein, aber die inhaltlichen Ziele werden nach dem Moscow-Prinzip (Must-Should-CouldWould) jetzt viel gröber und trotzdem transparent als Forecast in der weiteren Zukunft definiert. Die Detaillierung nimmt allerdings rollierend zu, je näher der Termin an den aktuellen Zeitpunkt rückt. Da ich bei scrum.org im wesentlichen durchzertifiziert bin, bilde ich beim Kunden neue Scrum Master und Product Owner aus.
Alle Stories der bis dato nicht unterstützten Prozesslücken wurden stichpunktartig ermittelt und im Schnellverfahren geschätzt. So konnte ein erster Ausblick gegeben werden. Es ist gelungen, anhand der Story Map die Lücken im System vorab zu sehen und die richtigen Fragen direkt an die internationalen Stakeholder zu stellen. Durch Priorisierung der Stories konnten Lösungsansätze mit optionalen und alternativen Komponenten sichtbar werden. Nur durch Priorisierung und das Bilden eines Minimal Viable Products (MVP) kann der Zeithorizont, als oberste Prämisse der Auslieferung, gehalten werden. Zusätzlich zu Jira wurde als Transparenz- und Kommunikationsunterstützung ein magnetisches Whiteboard eingeführt, anhand dessen das Pull-Request-Verfahren eingeübt wurde. Das Board kann auch besser Abhängigkeiten der eigenen Tasks zu anderen Microservices und Teams darstellen. Es dient beim Daily dem Team als Kommunikationshilfe. Die Herausforderung der Change Initiative – Transition - bestand vor allem darin, daß Abhängigkeiten der Teams reduziert werden sollen, die mit der gleichen Codebasis arbeiten. Verschiedene Teams, die agil zusammenarbeiten – skaliert – und auf der gleichen Codebasis ihre Ergebnisse einchecken, haben höheren Aufwand an Vorab-Planung und Koordination. Daher ist der Ansatz, diese Teams durch Komponenten-Verantwortlichkeit zu entkoppeln. Jedes Team ist für getrennte Komponenten, hier Mikroservices, verantwortlich und hat sein eigenen Product Owner und sein eigenes Product Backlog. Es sind aber noch immense Anstrengungen nötig, die Architektur zu entkoppeln. Der Kunde arbeitet mit den Atlassian Tools JIRA, Version 7, und Confluence, Version 5.