Scrum Master, Software Architekt, Product Owner, Softwareentwickler

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.

 

Der Kunde lehnt sich mit Squads an Spotify an, die konkrete Projektierung und Umsetzung in den Teams findet nach Scrum statt. Meine Aufgabe ist die des Scrum Masters in drei Squads aber ich gebe auch als agiler Trainer, Moderator und agiler Consultant Unterstützung in der agilen Transition des Unternehmens. Unterstützung in den Squads Refinement, Unterstützung beim Schneiden von User Stories z.B. anhand der Akzeptanzkriterien. Klassisch stellt der Product Owner im Refinement seine User Stories (Feature-bezogen) vor. Da wir aber auch einige architektonische Herausforderungen haben und viele technische Stories evaluieren müssen, sind wir dazu übergegangen, diese Tech Stories auch vorab zu „refinen“. In der Retrospektive haben wir beschlossen, dass die beiden Architekten quasi als Technische PO‘s auch technische Refinements durchführen. Das soll dazu dienen, dass ein grundlegendes technisches Verständnis für Technische Stories und die Abhängigkeiten im Vorfeld des konkreten Sprints im Dev Team aufgebaut wird. Nicht nur für Feature-Stories. Herausforderung Homeoffice vor allem in der Retrospektive. Die Squads pinnen in einer Timeline selbständig ihre Tickets an das Board und stellen diese auch persönlich vor (was lief gut? Was ist verbesserungswürdig?). In einem Lean-Coffee-Format diskutieren wir Lösungsvorschläge, ab und dann nutzen wir auch die 1-2-4-All Methode aus den Liberating Structures. Wir bilden dann erste Action Items, die dann im nächsten Sprint einer Lösung zugeführt werden. Dieser Prozess fand bis zur Pandemie vor Ort an physischen, haptischen Boards statt. Damit die Interaktion nicht von mir als Scrum Master sondern weiterhin vom Team gestaltet wird und das Team weiterhin selber interaktiv, für alle sofort sichtbar, selber weiterhin Karten „anpinnen“ kann, nutzen wir seit März 2020 Trello. Mit Chat-Voting und Priorisierung und PowerUp „Thumbs up or down“ In den Squads gebe ich Workshops zu Qualität (agiles Refactoring, DevOps, DoD, Testing-Strategien), zum Sprint-Ziel und Swarming. Ich unterstütze die Product Owner mit Story Mapping und Eventstorming.
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.

Unterstützen des KV Core Teams beim Teamaufbau und der Teamgestaltung. Methoden und Frameworks für verschiedene agile Methoden und Frameworks, hier Scrum, Kanban und Grundzüge von XP (Extreme Programming), vorgestellt. Wir arbeiten aktuell nach Kanban mit selbst erarbeitetem physikalischem Kanban-Board. Danach das Board inklusive Backlog in Jira überführt. Analysieren und verbessern bestehender agiler Prozesse im kontinuierlichen Verbesserungsprozess (KVP), auch während der regelmässigen Retrospektive. Ausbilden des internen ARAG-Scrum Masters mit Abschluß zum PSM I bei scrum.org. Coachen der Gatekeeper und des Product Owners beim Ermitteln des MVP‘s, kundenzentrierten Produkten und Services in der Versicherungsbranche. Leiten von Workshops, Schulungen und Projektarbeitsphasen im oben beschriebenen Kontext. Kontinuierliches, begleitendes Coaching und Mentoring. Unterstützen des Product Owners und des Teams in technischen und fachlichen Fragen rund um die Gestaltung des Backlogs. Ziel hierbei ist die Erhöhung des Automationsgrades mit Jira 7.11 Server-Edition, aktuell mit diversen Filtern. Hier war ich zusätzlich als Jira-Trainer und Jira-ProjektAdministrator tätig.

Betreuung zweier Squads, einem Fullstack-Webteam (Backend PHP) für die Mail-Plattformen GMX, WEB.de und einem Team (Backend Java und Python) für Machine Learning. Letztgenanntes Team verantwortet die Entwicklung einer sog. Smart Inbox Plattform (SIP) zur automatisierten Annotation von Emails. In den ersten Wochen die beiden Teams in den agilen Prinzipien Agilität - Scrum - Kanban - agilen Entwicklungspraktiken - Aufbereitung, sowie der Kommunikation, von Softwareanforderungen geschult. Die Herausforderung besteht im Tribe, zu dem beide Squads gehören, darin, dass das genutzte Managementsystem „Objectives and Key Results“ (OKRs) auf die angewandten agilen Methoden und vorhandenen Frameworks zu mappen. Die inhaltlichen Ziele des Produktes und die abgeleiteten Maßnahmen aus den OKR‘s müssen abgeglichen werden und sollen ins Product Backlog eingegliedert werden. Agile Teams sind normalerweise reaktionsschneller als die 3 Monatszyklen von OKR‘s

Innerhalb des Tribes "Digital Accelerator" diverse Squads und darüber hinaus auch Scrum Teams aus der Delivery betreut. Die Squads organisieren sich nach Scrum oder Kanban und verantworten verschiedene Initiativen und Channel. Die Herausforderung besteht hierin, dass die SQUADS derzeit noch fallweise auf separate Delivery-Teams angewiesen sind. Diese Delivery-Teams sind zwar auch agil, hier nach Scrum organisiert, arbeiten aber noch autark. Mein Anliegen war es, die Lücke zwischen Business und Deployment besser zu schließen, anhand des eigentlichen Wertstroms im Vodafone Webshop einen kontinuierlichen Verbesserungsprozess (KVP) herbeizuführen. Durch ein gemeinsames Verständnis für einander in den verschiedenen Teams sollte so die Lücke zwischen Business und Deployment, entlang des Wertstroms, weiter geschlossen werden. Unterstützt von Transparenz und einer bessere Kommunikation miteinander. Ich bildete in diesen 4 Monaten auch diverse Scrum Master, Product Owner und Scrum Developer aus und bereitete sie auf die Prüfung bei scrum.org vor

Initial zwei Teams ausgebildet und als Scrum-Teams geformt. Team 1 im Bereich Integration Workbench (INWB) und Team 2 im Bereich proALPHA ERP Next Generation (Next Gen). Die Herausforderung im Team Next Gen besteht einerseits darin, erste Features schnell am Markt zur Evaluierung zu platzieren, einen wertschöpfenden Prozess, der Mehrwert erzeugt, zu etablieren. Sich mit Objektorientierten Ansätzen modularisiert aufzustellen. => emergente Architektur. Das zweite Team INWB musste sich durch ein Sprint Ziel schlank am Prozess orientieren (LEAN). Im Pull-Request-Verfahren geht die Anforderung vom Kunden aus. Sprint für Sprint sich permanent Freiraum für neue Features schaffen. So wird gewährleistet, dass nicht nur Maintenance und Bugs die Ressourcen im Team bestimmen. Zentral dafür war in beiden Teams das Produktbacklog (PB), was wir schnell in Trello aufgesetzt haben. Das PB soll später mal durch Jira abgelöst werden. Wichtig ist hierbei, mittel- und langfristig angedachte Features wurden auf mein Anraten hin vom Product Owner frühzeitig ins PB aufgenommen. Mit einer Kategorie-Einteilung 1. Spalte : Product Backlog, 2. Sp : Refinement, 3. Sp. :Ready for Development, 4. Sp: Next Sprint Planning ist es möglich, von links nach rechts sukzessive Requirements und Bugs in die richtige granulare Grösse zu überführen. Dies geschieht über einen längeren Zeitraum, zusammen mit dem Team, währed der Refinements in den 1-Wochen-Sprints (in beiden Teams).

agile Transition des Unternehmens Lidl ECI „Agile“ bedeutet zwar in der Übersetzung flexibel, meint aber in agilen Projekten die Kundenorientierung entlang einem Kunden-Wertstrom und ein flexibles reagieren. Agile Teams wollen fokussiert zusammenarbeiten. Daher wurde das Team im Projekt ALM von mir in agilen Workshops im agilen Mindset geschult. Scrum-Teams sind meistens sehr haptisch (faceto-face) aufgestellt. Viele erfolgreiche Scrum-Teams arbeiten daher oft gemeinsam in gemeinsamen, physischen Team-Räumen und mit physischen Boards. Die Verbesserung der Produktliefersituation in ALM bleibt ein wichtiges Thema. Scrum ist keine nur kurzfristige Erfolgsmethode des "auf Sicht fahrens". Alles hängt aber von einem vorausschauend gepflegten Backlog ab. Das Backlog in agilen Projekten übernimmt die Projekt- und Releaseplanung gleich mit. Es ist daher für agile Projekte zentral. Ein agiles Backlog fokussiert immer wieder das Wesentliche und trennt es in agilen Projekten, durch häufige Kommunikation und Priorisierung, vom Unwesentlichen. Ein stetig gepflegtes Backlog gewährleistet auch, dass sich das Development Team nach dem Pull-Request-Verfahren – Lean - selbständig die Items ziehen kann, die auch als nächstes dran sind. Gut gepflegte Backlogs sind daher frühzeitig und voraus blickend gepflegte Backlogs. Sie fördern durch das frühzeitige Konmmunizieren, zum Beispiel im Refinement, somit auch die selbständige Arbeit von Teams, deren verantwortliches Mitdenken und deren Selbstorganisation. Ein frühzeitig und dynamisch gepflegtes Backlog entlastet auch langfristig den Product Owner von Mikromanagement und reduziert den Koordinierungsaufwand. Verschiedene Aktivitäten, verschiedener Teams mussten aufeinander abgestimmt werden, da diese Teams an der gleichen Codebasis arbeiten. Alle diese Tätigkeiten sollten daher frühzeitig mit den Lösungen des Teams ALM in einen Gleichtakt gebracht und synchronisiert werden. Es fand daher regelmäßig ein reger Austausch mit den agilen Kollegen in den anderen Teams statt, die entlang des gleichen Wertstroms arbeiten. Ziel war die Implementierung eines täglichen Abstimmungsdailies der Team-Delegierten (Scrum-of-Scrums) und ein regelmäßiges Abstimmungsmeeting zwischen den Product Ownern, einem so genannten Cross-Team-Refinement. Ziel war und sollte weiterhin sein, die Reduktion der Komplexität und Abhängigkeiten in dem skalierten Projekt.

Obwohl in sogenannten Verticals eigenständige Verantwortlichkeiten bestehen, arbeiten verschiedene Abteilungen bei den Requirements entlang gemeinsamer User Journeys und auf einer gemeinsamen Codebasis. Es bestehen daher auf allen Ebenen, ausgehend von den Epics bis runter zu den Datenbank-Layern, viele Abhängigkeiten. In der Vergangenheit liefen die Teams situativ und ad-hoc, durch Arbeiten der anderen Teams an der gleichen Codebasis, in ungeplante Verzögerungen. Daher wurde von mir, zusätzlich zu den Team-Dailies, erst einmal ein Integration-Daily (Scrum-of-Scrums) eingeführt. Vor allem, was jedes Team innerhalb der nächsten 24 h auf der gemeinsamen Codebasis bearbeiten wird, hilft sehr. Es ist eine erste Vorab-Information und hilft beim Integrieren und Testen. Eine weitere Herausforderung bestand darin, dass das Produktmanagement im April 2017 eine langfristige Aussage zum bestehenden Auslieferungstermin im September 2017 für eine neue, modulare Handelsplattform und eine dazugehörige Product Roadmap haben wollte. Der langfristige Ausblick gelang hier initial durch Story Mapping.
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.

Analyse der Wertströme und der Lösungsprojekte, der Langläufer und der Kurzläufer-Projekte. Unterstützung beim Schneiden der agilen Teams, entweder als Scrum- oder Kanban-Team. Unterstützung bei der Product Roadmap, um auch langfristige Ausblicke bei agilen Projekten geben zu können. Unterstützung bei der langfristigen Kapazitätsplanung, mit der Herausforderung trotzdem agil, zeitnah vom Plan abweichen zu können. Durchführung von Workshops, in denen insbesondere agile Praktiken des Vertragsmanagements und agile Angebotstaktiken vorgestellt wurden. Workshops zu Anforderungsmanagement wie z.B Epics, User Stories und Akzeptanzkriterien. Workshops zu agilen Softwareentwicklungspraktiken, zum Pull-Request-Verfahren, um das Management von Mikromanagement zu entlasten.

Scrum Master und Kanban Coach für 6 digitale Teams im Bereich Web-/ Contentmanagementsysteme. Durchführung von Workshops, in denen Agilität, insbesondere Scrum, Kanban, das Anforderungsmanagement wie z.B Epics, User Stories und Akzeptanzkriterien zusammen erarbeitet wurden. Da der Agenturbetrieb immer wieder von neuen Kundenprojekten bestimmt wird, soll die Agentur selber in die Lage versetzt werden, neue Projekte als Scrum- oder Kanbanprojekte zu evaluieren. Damit vom Start weg das neue agile Projekt richtig aufgesetzt wird. In den Workshops werden viele Kunden-Themen und Projekte thematisiert und Entscheidungen getroffen. Ich führe Retrospektiven durch. In einem Scrum Team haben wir zum Beispiel das Backlog vervollständigt und alle aktuellen Epics, User Stories geschätzt.

Workshops zur Evaluierung der einzusetzenden agilen Methoden, zu Agilität, Scrum, Kanban, agilem Anforderungsmanagement, Dokumentation in agilen Projekten, zu agilen Softwarepraktiken wie Refactoring, Clean Code, Testing, e2e-Tests, Unit-Tests, Test Driven Development (TDD), Continuous Integration. Parallel ein physikalisches Kanbanboard zur Flusskontrolle und Transparenzunterstützung eingeführt. Darüber hinaus regelmäßig Retrospektiven durchgeführt.

Scrum Master für drei Teams, ein Scrum Team und zwei Kanban Teams. Die ersten 6 Wochen im Kickoff mehrere Kundenschulungen und Workshops durchgeführt, in denen Agilität, insbesondere Scrum, Kanban und einige Development Praktiken, die speziell bei der agilen Softwareentwicklung eine Rolle spielen, vorgestellt wurden. Viele Kunden-Themen und Projekte wurden dabei thematisiert und Entscheidungen getroffen. Danach Umsetzung der zweiten Phase, der permanenten Verbesserung des Entwicklungsprozesses. Im Scrum Team arbeiten wir am B2C-Webshop. In diesem Projekt kommen alle klassischen Scrum Events, Scrum Rollen und Artifakte zum Einsatz. Der Kunde löste bis dato seine Softwareanforderungen zwar schnell, aber auch situativ und zwar nicht nur auf Ebene von Bugs sondern auch Ad hoc auf Ebene der Requirements. Daher wurden für die anderen Tasks außerhalb des Scrum Projektes zwei Kanbans Team gebildet, das von mir eine regelmäßige Unterstützung in einer Kanban-Retrospective erhielt. Im Kanban Team habe ich ein visuelles Kanban-Board eingeführt. Neben dem B2C-Shop gibt es auch andere Projekte, wie einen B2B-Shop und ein Logistik Projekt. Als Projektmanagement-Umgebung kommt Atlassian mit seiner ganzen Toolfamilie wie Jira, Confluence, Hipchat, Stash, Bamboo zum Einsatz.