• Aktuell begleite ich ein Scrum-Team mit Kanban-Anteilen (Scrumban).
• Scrumban deswegen, weil das Team einerseits Objectives zum Sprintende (Sprintziel) fokussert und abarbeitet, auf der anderen Seite Tagesgeschäft und nicht den Features im Planning Interval (PI) zuzuordnende Anforderungen umsetzt.
• Darüber hinaus arbeite ich im SAFe-Releasetrain mit. Zum Beispeil durfte ich im Inspect & Adapt Event im Problem Solving Workshop eine Gruppe mit Root-Cause-Fragetechnik (5 Why?s) moderieren. Zusammen mit meinen Scrum-Master Kollegen*innen unterstütze ich den RTE.
• Ansonsten haben wir im Team alle Scrum-Rollen, inklusive Product Owner, besetzt und arbeiten auch mit allen notwendigen Events inklusive Sprint Retrospektive, Sprint Review und Sprint Planning innerhalb der Iteration. Ich gebe Schulungen zu Agilität, Scrum, Kanban, Devops, agilem Anforderungsmanagement,
• Refinement, Spikes. Mein Schwerpunkt liegt hier bei testbaren Akzeptanzkriterien.
• Ein weiterer Fokus waren in meinem Team zuerst Kanban-Metriken, wie die Durchlaufzeit und die Leadtime (Vorlaufzeit), um die T2M (Time-to-Market) und somit die Reaktionszeit zu verbessern. 
• Das ist uns in einem Zeitraum von 4 Wochen durch folgende Aktionen gelungen.
  • Kanban-Workshop durchführen und Fokus auf Transparenz, Work in Progress (WIP) und Pull-Request verfahren 
  • Estimation-/Refinement-Workshop, um den Forecast zu verbessern
  • kleinere Arbeitspakete, um verlässlicher zu liefern

• Nachdem die Durchlaufzeit mehr als halbiert wurde, war die nächste Herausforderung die #Bugs zu reduzieren. Hierfür wurde mehrere Qualitäts-Workshops durchgeführt.
• Qualitäts-Workshops durchgeführt inkl
  • Definition-of-Done
  • Technical Debts (Technische Schulden)
  • Agiles Refactoring im Gegensatz zu klassischem Refactoring. Emergente Architektur
  • Unit Tests, Integrations-Tests
  • 12Factor-App (Trennung der Stages, Sourcecode, Config-Files)
  • Devops
• An der Metrik ?weniger #Bugs" sind wir aktuell noch in einem kontinuierlichen Verbesserungsprozess (KVP) dran.
• Der Kunde arbeitet im Agilen Release Train und somit auch in meinem Team mit Jira und Confluence.
• Wir arbeiten im Team und im Releasetrain mit Miro.

• Ich begleite aktuell ein Infrastruktur-/ Devops-Team und berate den Product Owner sowie die internen Scrum Master bzw. Architekten.
• Ich setze mich für zentrale Repositories bzw. Wikis und eine homogene, prozessuale Sicht ein.
• Exemplarisch sei hier Arc42 für den Doku-, Review- und Genehmigungsprozess genannt, das ich initial vorgestellt habe. Das Template wurde dann im Projekt CCI eingeführt.
• Als Agiler Consultant habe ich von Beginn an und dann immer wieder den Shift-Left-Ansatz und Infrastructure as Code geschult. Damit die Reproduzierbarkeit bzw. Wiederverwendbarkeit unserer Arbeitsergebnisse gewährleistet ist
• Das tue ich als Agiler Coach mit Bedacht und Weisheit, ohne in die Domain-Hoheit des Teams einzugreifen und deren Expertise als technisch versierte Experten zu verletzen.
• Wir experimentieren (?spiken?) viel und probieren notwendige Tools der Cloud aus. Daher musste ich nach einer anwendbaren Strategie aus dem Wissensmanagement suchen, so dass unser Wissen nachhaltiger und wiederverwendbar ist
• Vor allem soll agiles Wissen leichtgewichtig dokumentiert werden. Damit können die Spike-Ergebnisse auch später, in zukünftigen Sprints, umgesetzt werden
• Wissensdokumente aus Spikes sollen, ähnlich wie Requests for Changes (RfC), um die vorhandene Lösungsstruktur der jeweiligen Configuration Items (CI) angeordnet werden
• Der Kunde setzt als CMDB-Lösung Prolin (Itil) ein.

• Begleiten von anfänglich 3 Teams interimsweise, 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.
• Alle drei Teams arbeiten im gemeinsamen 2 Wochen-Sprint-Rhytmus mit skalierten Scrum Modus. Es bestehen Abhängigkeiten zwischen den Teams. Die aktuelle Herausforderung im Devops-Team ist die zur Verfügung Stellung von Services für die anderen beiden Teams.
• Wir hatten ein tägliches Abstimmungsmeeting mit den anderen beiden Teams im Daily-Format ? ein Scrum-of-Scrums.
• Zusätzlich zur Begleitung in den Scrum Regelmeetings habe ich folgende Schwerpunkte im Team Antragsportal verfolgt.
  • 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
  • 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
• 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.
• Ich 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.

• 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[1]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 Buy-Entscheidung. 
  • 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[1]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-Could-Would) 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

Tätig als Trainer in der Ausbildung von Scrum Mastern, Product Ownern, Management, Scrum Teams, Developern

• Workshop ?Agile Projekte mit Scrum oder Kanban starten - Was Sie für den Anfang brauchen?
• Workshop ?Scrum Master - Product Owner - Training zur Vorbereitung auf die Zertifizierung bei Scrum.org.?

Arbeiten aktuell nach Kanban mit mir zusammen 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. 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-Projekt-Administrator tätig.

• 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 Abschluss 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-Projekt-
  Administrator tätig.

International tätige Personalberatung

• Als Agiler Trainer, Scrum Trainer zweitägigen Workshop  durchgeführt
• Workshopthema „Scrum Master - Product Owner Kombi-Training zur Vorbereitung auf die Zertifizierung bei Scrum.org“
• 6 Teilnehmer aus dem Bereich Produktmanagement und Projektmanagement
• Ausbildung in den Prinzipien und der Prozesstheorie von Scrum ausgebildet und auf die Prüfung bei Scrum.org vorbereitet

International tätiger Telefonkonzern

• Als Agiler Trainer, Scrum Trainer dreitägigen Workshop durchgeführt
• Workshopthema „Scrum Master - Training zur Vorbereitung auf die Zertifizierung bei Scrum.org“
• 10 Teilnehmer aus dem Bereich Projektleitung und Projektmanagement
• Angehende Scrum Master wurden in den Prinzipien und der Prozesstheorie von Scrum ausgebildet und auf die Prüfung bei Scrum.org vorbereitet

International tätiger Telefon- und Internetkonzern

• 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
• Dies geschieht derzeit im Supervised Learning durch das Trainieren der Modelle durch Data Scientisten im Team nach ausgewählten Kategorien
• In den ersten Wochen die beiden Teams in den agilen Prinzipien Agilität - Scrum - Kanban - agilen Entwicklungspraktiken - Aufbereitung, sowie der Kommunikation, von Softwareanforderungen geschult.
• Im SIP-Team haben wir aktuell 4 Missionen, die wir verfolgen.
  
  • Mission: Anforderungsmanagement und Dokumentation im Annotations Management
  • Mission: Regelmässiges und frühestmögliches Feedback
  • Mission: Verfügbarkeit der Teammitglieder im Squad
  • Mission: Entscheidungsfindung, welche Methode Scrum oder Kanban das SIP-Team zukünftig einsetzen wird
• Im Web-Team haben wir aktuell 2 Missionen, die wir verfolgen.
  • Mission: Bessere Umsetzungsqualität von Anforderungen bis zum Deployment
  • Mission: mehr neue Anforderungen umsetzen
• In einen kontinuierlichen Verbesserungsprozess (KVP), wo wir uns immer wieder und fallweise um dann wichtige Team-Probleme (Impediments) kümmern und, als Teil des agilen Changeprozesses, der regelmäßigen Abarbeitung zuführen.
• 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

International tätiger Telefonkonzern

• Als Agiler Trainer, Scrum Trainer dreitägigen Workshop durchgeführt
• Workshopthema „Scrum Master - Training zur Vorbereitung auf die Zertifizierung bei Scrum.org“.12 Teilnehmer aus dem Bereich Projektleitung und Projektmanagement
• Angehende Scrum Master wurden in den Prinzipien und der Prozesstheorie von Scrum ausgebildet und auf die Prüfung bei Scrum.org vorbereitet

• Tätig als Agiler Coach, Trainer und Mentor eingesetzt im konzerneigenen Software Labor (Start Up) Crvsh
• 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

Tätig als Trainer in der Ausbildung von Scrum Mastern, Product Ownern, Management, Scrum Teams, Developern.

1. Workshop [Name auf Anfrage]

Der 2-tägige Workshop unterstützt bei der Entscheidung für eine der agilen Methoden Scrum oder Kanban. Beim Start agiler Projekte gefährliche Klippen umschiffen und gleich zu Beginn die Basis für ein erfolgreiches ITProjekt legen.

• Entscheidungshilfen zu der Frage : Kanban oder Scrum, mit welcher Methode starte ich?
• Welche Methode paßt zu meinem Kundenprojekt?
• Hintergründe und Insider-Wissen zu agilen Projekten und agilem Projektmanagement aus der Praxis
• Die Startphase gut überstehen ... mit konkreten Praxisbeispielen
• Kommunizieren von Kundenanforderungen und die strategischen Vorteile von agilen Dokumentationstechniken
• Wesentliches zu Epics, User Stories und Akzeptanzkriterien
• Wie sollen das Benutzerhandbuch oder die Projektdokumentation verfaßt werden? Welche strategischen Vorteile erhalte ich dadurch für die Zukunft?
• Einblick in die Arbeit von agilen Development Teams, deren Praktiken und Methoden
• Vertragsformen in Scrum. Eine agile Vorgehensweise im Projekt macht nämlich nur Sinn, wenn der Rahmen im Vertrag dies auch zulässt.
• Project Launch. Wichtige Informationen für den Start von agilen Projekten in klassischen, nicht-agilen Unternehmen.

2. Workshop [Name auf Anfrage]

• Angehende Scrum Master und Product Owner wurden in den Prinzipien und der Prozesstheorie von Scrum ausgebildet und auf die Prüfung bei Scrum.org vorbereitet. Training fanden als 3-Tages-Kombi-Kurs für Scrum Master und Product Owner statt.
• Alle wichtigen Scrum-Rollen, Meetings und Artefakte wie das Product Backlog wurden beschrieben.
• Das Scrum Master Training deckte die Prinzipien und die empirische Prozesstheorie ab, die das Scrum Framework untermauern, sowie die Rolle des Scrum Masters darin. Der Kurs kombinierte Unterricht und teambasierte Übungen und vermittelt, was der Kernpunkt der Scrum und Agile Bewegung ist.
• Das Product Owner Training beschäftigte sich mit der Rolle des ProductOwners als Geschäftsmann. Ein professionelles Produktmanagement geht weit über das Erstellen von Anforderungen hinaus. Ein ProductOwner weiß um seine Verantwortung für den Gesamterfolg eines Softwareproduktes und füllt diese selbstbewußt aus.

In zwei Teams das Produktbacklog mit Trello aufgesetzt. Das PB soll später 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.

• 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).

ein grosses, international tätiges Unternehmen im Bereich Einzelhandel

• 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.

Eine 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. Der Kunde arbeitet mit den Atlassian Tools JIRA, Version 7, und Confluence, Version 5.

• 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 Storieskonnten 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.

Rollen:

agiler Consultant, Scrum Master, Scaled Professional Scrum
Order Management MCC CIO/CSO Division

Unternehmensdetails:

• Unternehmen im Bereich der Feinwerktechnik

Projektdetails:

• 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

Unternehmensdetails

grosse, deutsche Werbeagentur im Full-Service

Projektdetails:

• 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.

Unternehmensdetails:

gemeinsamer IT-Dienstleister der Industrie- und Handelskammern in Deutschland, des Deutschen Industrie- und Handelskammertags in Berlin

Projektdetails:

• 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

Rolle:

zuerst Vollzeit, dann ab Dezember in Part-Time (50%)

Unternehmensdetails:

großer, deutscher Modehersteller (Opus, Someday)

Projektdetails:

• 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, aberauch 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.

• Mitarbeit am Kundenportal, das die beiden Ausbaustufen
• Leistungsabwicklung und Vertragsübersicht für den Endkunden über das Internet verfügbar machen soll. Initiale Vorbereitung und Durchführung des Kickoffs sowie der Nachbereitung des selbigen. Ich habe beim Kickoff eines von zwei internen Provinzial Teams, das Team Leistungsabwicklung, moderiert und in den Wochen nach dem Kickoff den Kunden-Projektleiter IT beim Strukturieren des Backlogs, dem Requirements Engineering und den User Stories unterstützt.
• Als Basis für die Informationsverwaltung wurde von mir ein Wiki mit dem hausinternen Confluence der Fa. Atlassian aufgesetzt. Hier wurde insbesondere nach dem Kickoff von mir ein Abgleich der Epics mit den Anwenderzielen vorgenommen. Aus den Epics wurden die Userstories mit den Akzeptanzkriterien als Grundlage für die Unit-Tests konkretisiert.
• Einweisung und Übergabe des initialen Backlogs an die jeweiligen Product Owner, Vertragsübersicht und Leistungsabwicklung. Des weiteren habe ich einen vorhandenen Frontend-Prototypen in AngularJS bewertet, beginnend mit beispielhaften Akzeptanzkriterien als Grundlage für die Unit-Tests. Zusammen mit den Unit-Tests konnte ich den Produktivcode des Prototypen erweitern und umschreiben (Refactoring). Test Driven Development (ATDD).
• Moderation wichtiger Prinzipien wie CleanCode und Dependency Injection (Angular).

Der Kunde gehört zu den innovativen Vorreitern der Landwirtschaft und setzt mit Industrie 4.0 neue Maßstäbe. Er verbindet klassische IT wie Farm- Management-ERP mit GPS, Fahrzeug-Responder (Telemetrie) und kombiniert diese Daten für den Landwirt auf Satellitenbildern und Hofkarten für weitere Auswertungen und Wirtschaftlichkeitsbe-rechnungen. Mitarbeit an der Weiterentwicklung des Frontends in einem von drei agilen Developerteams nach SCRUM mit Daily Scrum (Stand up), Sprint Planning I + II, Retrospective, Estimations mit wiederkehrender, rollierender Bewertung der zukünftigen Anforderungen in Story Points. Sprint Länge 2 Wochen. Intensive Kommunikation mit dem Product owner und den Produkt-Managern, Permanentes Vertreten der Arbeitsergebnisse sowie final im Sprint Review. Scrum Organisation mit Atlassian Jira und Confluence

Wurde nach ursprünglich geplanten 3 Monaten nochmals verlängert. Eingesetzt in der Konzeption, der Schnittstellenprogrammierung zu den Incoming-(Hotel) Agenturen weltweit und bei der Webentwicklung administrativer Inhouse-Tools, Als Teammitglied Schulungen in KANBAN und SCRUM bei den Softwareentwicklern des Kunden und fallweise Moderation des Entwicklungsprozesses bei den Freelancer-Kollegen.

Remedy-System abgelöst. Hierbei ein neues, an ITIL angelehntesTicketmanagementsystem im Entwicklungsteam, vollständig neu konzipiert, Daten migriert und als abgesicherte Intranetanwendung, browserbasiert, umgesetzt.

Unterstützung bei der Fachkonzept-erstellung, Erstellung DVKonzept mit Daten-Modell unter Oracle, Umsetzung als Webanwendung, entwickelt mit HTML, CSS, Javascript, JQuery, Backendprogrammmierung, AJAX