Eine der besten Methoden, agile Produktentwicklung zu sabotieren, ist, das Backlog zu vermurksen. ✔️ In unserer interaktiven Präsentation am PO&RE Days gaben Stephan Adler und ich ein paar Tipps, wie man trotz dieser Sabotageversuche ein marodes Backlog vermeiden kann.
Eine der besten Methoden, agile Produktentwicklung zu sabotieren, ist, das Backlog zu vermurksen. In unserer interaktiven Präsentation am PO&RE Days gaben Stephan Adler und ich ein paar Tipps, wie man trotz dieser Sabotageversuche ein marodes Backlog vermeiden kann.
Unsere Anti-Pattern Karten sind aus unserer jahrelangen Arbeit mit Kunden, und den daraus gewonnenen Erfahrungen entstanden. Sie sollen euch dabei helfen, selbst Fettnäpfchen zu erkennen, die wir schon von außen erlebt haben, oder in die wir sogar teilweise selbst schon getreten sind. Wenn ihr noch andere Anti-Patterns kennt, dann schickt sie uns unter https://mayflower.de/agile-antipattern.
Mein Scrum ist kaputt und das Meeting passt leider nicht und die Rollen sind auch nicht gut verteilt. Wie agile Softwarentwicklung mit Scrum funktionieren kann, zeigt Ulf Mewe von der HEC Gmbh.
Bei agilen Projekt ist Scrum zurzeit die Nr. 1. Trotzdem entscheiden sich Unternehmen immer wieder Scrum nur unvollständig einzuführen. Aber ist das wirklich eine gute Idee und kann das funktionieren?
In diesem Vortrag wird anhand von Praxisbeispielen gezeigt, was eine teilweise Einführung in der Realität bedeutet. Wir erfahren hierdurch, welche Elemente von Scrum unabhängig eingeführt werden können, aber was verloren geht, wenn Scrum nicht vollständig eingeführt wird. Außerdem gehen wir der Frage nach, ob es wirklich immer Scrum sein muss.
Bei agilen Projekt ist Scrum zurzeit die Nr. 1. Trotzdem entscheiden sich Unternehmen immer wieder Scrum nur unvollständig einzuführen. Aber ist das wirklich eine gute Idee und kann das funktionieren?
In diesem Vortrag wird anhand von Praxisbeispielen gezeigt, was eine teilweise Einführung in der Realität bedeutet. Wir erfahren hierdurch, welche Elemente von Scrum unabhängig eingeführt werden können, aber was verloren geht, wenn Scrum nicht vollständig eingeführt wird. Außerdem gehen wir der Frage nach, ob es wirklich immer Scrum sein muss.
Eine der besten Methoden, agile Produktentwicklung zu sabotieren, ist, das Backlog zu vermurksen. In unserer interaktiven Präsentation am PO&RE Days gaben Stephan Adler und ich ein paar Tipps, wie man trotz dieser Sabotageversuche ein marodes Backlog vermeiden kann.
Unsere Anti-Pattern Karten sind aus unserer jahrelangen Arbeit mit Kunden, und den daraus gewonnenen Erfahrungen entstanden. Sie sollen euch dabei helfen, selbst Fettnäpfchen zu erkennen, die wir schon von außen erlebt haben, oder in die wir sogar teilweise selbst schon getreten sind. Wenn ihr noch andere Anti-Patterns kennt, dann schickt sie uns unter https://mayflower.de/agile-antipattern.
Mein Scrum ist kaputt und das Meeting passt leider nicht und die Rollen sind auch nicht gut verteilt. Wie agile Softwarentwicklung mit Scrum funktionieren kann, zeigt Ulf Mewe von der HEC Gmbh.
Bei agilen Projekt ist Scrum zurzeit die Nr. 1. Trotzdem entscheiden sich Unternehmen immer wieder Scrum nur unvollständig einzuführen. Aber ist das wirklich eine gute Idee und kann das funktionieren?
In diesem Vortrag wird anhand von Praxisbeispielen gezeigt, was eine teilweise Einführung in der Realität bedeutet. Wir erfahren hierdurch, welche Elemente von Scrum unabhängig eingeführt werden können, aber was verloren geht, wenn Scrum nicht vollständig eingeführt wird. Außerdem gehen wir der Frage nach, ob es wirklich immer Scrum sein muss.
Bei agilen Projekt ist Scrum zurzeit die Nr. 1. Trotzdem entscheiden sich Unternehmen immer wieder Scrum nur unvollständig einzuführen. Aber ist das wirklich eine gute Idee und kann das funktionieren?
In diesem Vortrag wird anhand von Praxisbeispielen gezeigt, was eine teilweise Einführung in der Realität bedeutet. Wir erfahren hierdurch, welche Elemente von Scrum unabhängig eingeführt werden können, aber was verloren geht, wenn Scrum nicht vollständig eingeführt wird. Außerdem gehen wir der Frage nach, ob es wirklich immer Scrum sein muss.
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...Joël Krapf
Die Migros ist zwar die grösste Arbeitgeberin der Schweiz, doch eigentlich ist sie ein Verbund von kleinen Organisationen. Rund 100'000 Mitarbeitende arbeiten in rund 100 verschiedenen Unternehmen innerhalb der Gruppe. Wie viele andere auch, hat die Migros vor nicht allzu langer Zeit eine agile Reise gestartet. Nach erstem Anfangserfolg wurde ein erster Versuch gestartet, diese Reise zu beschleunigen und zu skalieren. Hierfür wurde ein eigenes "Playbook" entwickelt. Das sogenannte Migros Ways-of-Working (WoW) für Agilität. Doch das WoW hat nicht zu einem Wow-Erlebnis geführt, vielmehr hat es politische Graben verstärkt. Im Vortrag wird aufgezeigt, weshalb zuerst ein eigenes Playbook erarbeitet wurde sowie was aus dem F.A.I.L gelernt wurde, um nun seit rund einem Jahr auf einer sehr erfolgreichen agilen Reise zu sein
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...Frank Düsterbeck
Keine Lust mehr auf schlecht initialisierte Projekte? Keine Lust mehr, Fehler mühsam auszubügeln, die beim Projektstart gemacht wurden? Keine Lust mehr auf unnützen Stress? DoPI richtet sich an alle, die Projekte initialisieren oder unter einer schlechten Initialisierung leiden (also an alle). DoPI zeigt, wie man sich mittels ihrer gut auf die Unsicherheiten der Produktherstellung vorbereitet und gibt Impulse, wie man Unwissen zu Wissen, Ungewissheit zu Gewissheit und Risiko zu Chance werden lässt. Das Wissen um komplexe Systeme hilft dabei, ein tiefes Verständnis für die Projektinitialisierung zu gewinnen.
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...QAware GmbH
GPM Regionalgruppe Chemnitz (Patrick Albert)
Wegen ihres Umfangs und Komplexität sind größere SAFe-Programme bereits in Präsenz hinsichtlich ihres Managements und ihrer Steuerung anspruchsvoll. Aufgrund von COVID19 jedoch war eine Verlegung in den virtuellen Raum im beschriebenen Praxisfall unausweichlich. Das Management hatte hierbei sicherzustellen, dass die Programmziele trotz des verminderten Kontaktes allen beteiligten Teams dauerhaft klar und präsent sind und dass die in den Teams umgesetzten Funktionen außerdem den genannten Programmzielen dienen.
Besonders wichtig ist dieses Alignment im Rahmen der regelmäßigen PI-Plannings, in welchen alle Teams gleichzeitig die jeweils kommenden Iterationen planen und dabei auch teamübergreifende Abhängigkeiten zuverlässig berücksichtigen müssen.
Es werden Erfolgsfaktoren für den virtuellen Einsatz von SAFe herausgearbeitet und beleuchtet.
Agile WoW @ Migros: bei der Group IT des MGB haben wir aufgrund unserer Heterogenität mit unseren Agile Coaches & Community of Practices ein eigenes Agile Ways of Working (agile WoW) erstellt. Dabei haben wir auf bestehenden Best Practices aufgebaut (Scrum, Scrum of Scrum, LeSS, SAFe). Das Agile WoW wird derzeit in ersten Piloten verprobt und dabei von unseren Experten und Community of Practices kontinuierlich weiterentwickelt. Wir freuen uns auf einen Erfahrungsaustausch innerhalb und ausserhalb der Migros–Gruppe. Bitte einfach melden an: agile@mgb.ch
About Dogs and Cats - über DevOps in großen KonzernenStefan Bauer
Die zunehmenden Möglichkeiten der Automatisierung hat die DevOps Bewegung in den letzten Jahren massiv vorangetrieben. Die Technologieveränderungen scheinen jedoch die klassischen Konflikte in den IT-Abteilungen nicht zu reduzieren.
Was bedeutet diese massive Technologieveränderung für die tägliche Arbeit in einem großen IT-Konzern?
Unterstützen die klassische Arbeitsabläufe und Organisationsstrukturen die Effizienz der neuen Technologien?
Wie kann ein Wandel in der IT-Industrie vorwärts bewegt werden?
Dieser Vortrag soll Erfahrungen vermitteln und Denkmodelle vorstellen, um ein gemeinsames Bild von Technologie und menschlichen Organisationen zu entwickeln.
Anhand dieses Dokuments haben wir bis Februar 2012 unsere Produktentwicklung organisiert.
Das Cheat Sheet wurde gemeinsam mit dem Team erarbeitet und nach jeder Retrospective angepasst.
Ein kurzer Rundumschlag zum Thema Agiles Anforderungsmanagement. Aufgrund der Größe der Themas kann dieser Vortrag ruhigen Gewissens als "quick & dirty" bezeichnet werden.
For projects like building a power plant or a train tunnel, tough project managers are needed. But when it comes to developing digital or physical products, the role of a project manager has an increasingly difficult standing. During agile or digital transformations, new roles emerge to take over project management tasks. So, are project managers needed in these areas in the future?
Testen hoch 10 - Für den Bahnverkehr der ZukunftChristoph Wolf
Testen von Software, die komplexe Situation real-time lösen muss, die auf unscharfen Regeln basiert und die Erfahrung, Intuition und Bauchgefühl ersetzen soll – ist das überhaupt möglich? Nach unseren Erfahrungen: "Nicht vollständig". Aber am Swiss Testing Day zeigten Roman Caspar und ich, wie wir versuchen, beim Testing das Optimale herauszuholen – für den Bahnverkehr der Zukunft
Más contenido relacionado
Similar a How to f... up your backlog - PO &RE Day
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...Joël Krapf
Die Migros ist zwar die grösste Arbeitgeberin der Schweiz, doch eigentlich ist sie ein Verbund von kleinen Organisationen. Rund 100'000 Mitarbeitende arbeiten in rund 100 verschiedenen Unternehmen innerhalb der Gruppe. Wie viele andere auch, hat die Migros vor nicht allzu langer Zeit eine agile Reise gestartet. Nach erstem Anfangserfolg wurde ein erster Versuch gestartet, diese Reise zu beschleunigen und zu skalieren. Hierfür wurde ein eigenes "Playbook" entwickelt. Das sogenannte Migros Ways-of-Working (WoW) für Agilität. Doch das WoW hat nicht zu einem Wow-Erlebnis geführt, vielmehr hat es politische Graben verstärkt. Im Vortrag wird aufgezeigt, weshalb zuerst ein eigenes Playbook erarbeitet wurde sowie was aus dem F.A.I.L gelernt wurde, um nun seit rund einem Jahr auf einer sehr erfolgreichen agilen Reise zu sein
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...Frank Düsterbeck
Keine Lust mehr auf schlecht initialisierte Projekte? Keine Lust mehr, Fehler mühsam auszubügeln, die beim Projektstart gemacht wurden? Keine Lust mehr auf unnützen Stress? DoPI richtet sich an alle, die Projekte initialisieren oder unter einer schlechten Initialisierung leiden (also an alle). DoPI zeigt, wie man sich mittels ihrer gut auf die Unsicherheiten der Produktherstellung vorbereitet und gibt Impulse, wie man Unwissen zu Wissen, Ungewissheit zu Gewissheit und Risiko zu Chance werden lässt. Das Wissen um komplexe Systeme hilft dabei, ein tiefes Verständnis für die Projektinitialisierung zu gewinnen.
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...QAware GmbH
GPM Regionalgruppe Chemnitz (Patrick Albert)
Wegen ihres Umfangs und Komplexität sind größere SAFe-Programme bereits in Präsenz hinsichtlich ihres Managements und ihrer Steuerung anspruchsvoll. Aufgrund von COVID19 jedoch war eine Verlegung in den virtuellen Raum im beschriebenen Praxisfall unausweichlich. Das Management hatte hierbei sicherzustellen, dass die Programmziele trotz des verminderten Kontaktes allen beteiligten Teams dauerhaft klar und präsent sind und dass die in den Teams umgesetzten Funktionen außerdem den genannten Programmzielen dienen.
Besonders wichtig ist dieses Alignment im Rahmen der regelmäßigen PI-Plannings, in welchen alle Teams gleichzeitig die jeweils kommenden Iterationen planen und dabei auch teamübergreifende Abhängigkeiten zuverlässig berücksichtigen müssen.
Es werden Erfolgsfaktoren für den virtuellen Einsatz von SAFe herausgearbeitet und beleuchtet.
Agile WoW @ Migros: bei der Group IT des MGB haben wir aufgrund unserer Heterogenität mit unseren Agile Coaches & Community of Practices ein eigenes Agile Ways of Working (agile WoW) erstellt. Dabei haben wir auf bestehenden Best Practices aufgebaut (Scrum, Scrum of Scrum, LeSS, SAFe). Das Agile WoW wird derzeit in ersten Piloten verprobt und dabei von unseren Experten und Community of Practices kontinuierlich weiterentwickelt. Wir freuen uns auf einen Erfahrungsaustausch innerhalb und ausserhalb der Migros–Gruppe. Bitte einfach melden an: agile@mgb.ch
About Dogs and Cats - über DevOps in großen KonzernenStefan Bauer
Die zunehmenden Möglichkeiten der Automatisierung hat die DevOps Bewegung in den letzten Jahren massiv vorangetrieben. Die Technologieveränderungen scheinen jedoch die klassischen Konflikte in den IT-Abteilungen nicht zu reduzieren.
Was bedeutet diese massive Technologieveränderung für die tägliche Arbeit in einem großen IT-Konzern?
Unterstützen die klassische Arbeitsabläufe und Organisationsstrukturen die Effizienz der neuen Technologien?
Wie kann ein Wandel in der IT-Industrie vorwärts bewegt werden?
Dieser Vortrag soll Erfahrungen vermitteln und Denkmodelle vorstellen, um ein gemeinsames Bild von Technologie und menschlichen Organisationen zu entwickeln.
Anhand dieses Dokuments haben wir bis Februar 2012 unsere Produktentwicklung organisiert.
Das Cheat Sheet wurde gemeinsam mit dem Team erarbeitet und nach jeder Retrospective angepasst.
Ein kurzer Rundumschlag zum Thema Agiles Anforderungsmanagement. Aufgrund der Größe der Themas kann dieser Vortrag ruhigen Gewissens als "quick & dirty" bezeichnet werden.
For projects like building a power plant or a train tunnel, tough project managers are needed. But when it comes to developing digital or physical products, the role of a project manager has an increasingly difficult standing. During agile or digital transformations, new roles emerge to take over project management tasks. So, are project managers needed in these areas in the future?
Testen hoch 10 - Für den Bahnverkehr der ZukunftChristoph Wolf
Testen von Software, die komplexe Situation real-time lösen muss, die auf unscharfen Regeln basiert und die Erfahrung, Intuition und Bauchgefühl ersetzen soll – ist das überhaupt möglich? Nach unseren Erfahrungen: "Nicht vollständig". Aber am Swiss Testing Day zeigten Roman Caspar und ich, wie wir versuchen, beim Testing das Optimale herauszuholen – für den Bahnverkehr der Zukunft
European Product Owner & Requirements Engineering Day 2019:
Design Thinking ist ein populärer Innovationsansatz zum Lösen von Problemen und zur Entwicklung neuer Ideen, der die Kundenbedürfnisse in den Mittelpunkt stellt. In unserem Workshop erlebt ihr hautnah die Methoden und das Mindset von Design Thinking.Ihr durchlauft alle Schritte des Design-Thinking-Prozesses und gestaltet in kleinen Teams mit viel Empathie und Spass kreative und nutzerzentrierte Lösungen für Herausforderungen.
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)Christoph Wolf
Testing im skaliert-agilen Umfeld (SAFe): Finnova ist ein führender Anbieter von Bankensoftware auf dem Finanzplatz Schweiz. Vor über zwei Jahren wurde begonnen, auf skaliert-agile Software-Entwicklung umzustellen. Es wurde SAFe mit derzeit ca. 25 Scrum-Teams und drei Agile Release Trains eingeführt. Dabei muss natürlich sichergestellt sein, dass sowohl die einzelnen, von den Teams gelieferten Module als auch das integrierte Produkt eine hohe Qualität haben. In diesem Vortrag präsentieren wir Antworten auf die Frage, wie wir Quality Assurance bzgl. Organisation, Methoden, Dienstleistungen und Strategie auf der SAFe Team- und Programm-Ebene gestalten.
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...Christoph Wolf
Bisher wurde bei Sunrise die Testfälle ausschliesslich auf Basis des IT-Designs erstellt. Dies hatte den Nachteil, dass Fehler aufgrund von ungenügenden Anforderungen oder Fehler beim Erstellen des IT-Designs in der Test-Phase zu spät oder gar nicht erkannt wurden. Weiterhin wurde die Testplanung erschwert. Daher haben wir an der Schnittstelle von Anforderungs- und Test-Management zwei Methoden eingeführt: Requirements Validation und Requirements-based Testing
Business Analysis @ Sunrise - REConf CH 2010Christoph Wolf
2009 wurde bei Sunrise ein neues Team gegründet, das sich speziell auf Business Consulting und Requirements Engineering fokussieren soll. Dieser Vortrag beschreibt das Vorgehen, die Resultate und die Erfahrungen nach einem Jahr Business Consulting & Analysis @ Sunrise.
2. Beliebte Situationen …
Ablehnen der Implementierung beim Review
mit nachvollziehbaren Argumenten.
A
Sprint-Review schlecht besucht wegen zu
technischer Storys.
Hoch detaillierte User Storys
Skalierte Priorisierung ist inkonsistent
Storys werden nicht fertig aufgrund
Verfügbarkeit & Abhängigkeiten
B
C
D
E
Just-in-Time: Produktbacklog = Sprintbacklog
F
Initiales Backlog = Alle User Storys aus dem
Produktkonzept
Die Summe aller Storys ist das Epic (Story
Points)
Storys mit vielen Abhängigkeiten zu externen
Personen
G
H
I
3. Ablehnen der Implementierung beim Review
mit nachvollziehbaren Argumenten.
Situation
Beim Review werden
Implementierungen von Storys oft
abgelehnt.
Die Argumente von Business oder
dem Product Owner sind
nachvollziehbar.
Das Team muss die
Implementierung ändern.
Was tun?
(1) Kein Problem, dazu machen wir ja
Iterationen.
(2) Definition-of-Ready besser
durchsetzen.
(3) Akzeptanzkriterien schärfen und
mit dem Owner verifizieren.
(4) Prototypen (z.B. GUI) erstellen
und vor dem Sprint oder am
Sprintanfang abstimmen.
A
European PO & RE Day - Juni 2021
Auflösung
Business hat wahrscheinlich keine
richtige Vorstellung, was sie möchten.
Wiederholte Implementierung ist
Verschwendung.
DoR durchsetzen ist oft schwierig.
Detaillierung der AKs zwingt
Business, sich genauer
festzulegen.
Prototyen erleichtern, sich
vorzustellen, was man will
?
✓
✓
4. Sprint-Review schlecht besucht wegen zu
technischer Storys.
Situation
Das Team liefert in 2 Wochen
Sprints und die User Storys sind so
geschnitten, dass sie innerhalb des
Prints fertig werden. Einige der
Storys betreffen dann eher
technische Aspekte, da es trotz
kleiner Storys zu lange dauert E2E
zu entwickeln.
Die Kunden und Stakeholder
kommen nicht zur Sprint Review,
weil sie aufgrund zu technischer
Storys den Wert der Demo nicht
sehen.
Was tun?
(1) Sprint-Länge vergrössern
(2) Prozess-Fluss optimieren
(3) Storys besser schneiden
(4) Kanban einführen
(5) Teams besser aufstellen
(6) Team im Präsentieren von
Resultaten coachen
B
European PO & RE Day - Juni 2021
Auflösung
Kurze Sprints nur zu machen weil es
"agiler" ist, ist Blödsinn. Nur wenn ich
in der Review gutes, relevantes
Feedback erhalte, macht sie Sinn..
Kurzfristig die Sprints verlängern
Prozess optimieren, automatisieren
oder entschlacken, falls möglich
Storys konsequent schneiden
(kleiner, nicht kürzer)
Kanban und bessere
Teamaufstellung fixen in diesem
Fall nicht das Feedbackproblem
✓
?
?
5. ✓
✓
✓
Storys werden nicht fertig aufgrund
Verfügbarkeit & Abhängigkeiten.
Situation
Am Ende vom Sprint sind viele
Storys des Sprintbacklogs noch
nicht beendet.
Es stellt sich heraus, dass
Teammitglieder während des
Sprints kurzfristig andere
Aufgaben erledigen mussten.
Weiterhin blockieren
Abhängigkeiten zu anderen Teams,
die zwar bekannt waren aber trotz
Zusagen nicht eingehalten wurden,
den Fortschritt.
Andere Teams sind aber nicht von
uns abhängig.
Was tun?
(1) Verfügbarkeit und damit
Sprintbacklog verkleinern.
(2) So lange sich niemand beschwert,
kann man das ignorieren.
(3) Von den anderen Teams
verlangen, dass sie bei
Abhängigkeiten ihre Zusagen
einhalten.
(4) Von Scrum auf Kanban umstellen.
C
Auflösung
Hier ist es wichtig, die Ursache der
Probleme detaillierter anzuschauen..
Realistische Einschätzung der
Verfügbarkeit ist wichtig. Den
Sprint mit niedrigerer
Verfügbarkeit planen und Stretch-
Goals hinzufügen.
Agile basiert auf Vertrauen,
Transparenz und Commitment.
Das sollten auch die anderen Team
beachten.
Wenn die Aufgaben innerhalb des
Teams und nach aussen keine
Synchronisation benötigen, kann
Kanban die bessere Methodik sein.
?
?
?
European PO & RE Day - Juni 2021
6. Hoch detaillierte User Storys.
Situation
Hoch detaillierte User Storys, eine
für die Anzeige eines Feldes, eine
für die Eingabe, eine für das
Löschen.
Die Akzeptanzkriterien beschreiben
die genaue Grösse (sichtbare
Zeichen) des Feldes und die exakte
Feldvalidierung. Die Entwicklungs-
firma will es so.
Was tun?
(1) Teamzusammensetzung stärken
(2) Definition of Done verbessern
(3) Aufhören, mit User Storys zu
arbeiten
(4) Mitarbeiter schulen
(5) Noch detaillierter aufschreiben
und Entwicklung nach Indien
outsourcen
D
European PO & RE Day - Juni 2021
Auflösung
Ist eine User Story eine umbenannte
"Requirements Spezifikation", dann
habe ich den Gedanken von
kompetenten, selbst organisierten,
E2E Teams aufgegeben.
Teams so zusammensetzen, dass
ich die notwendigen Kompetenzen
im Team habe
DoD schärfen, so dass es für
gängige Ansätze eine Konvention
gibt
Alternativ, sollten Verträge und
Umstände es nicht anders
zulassen: klassische mit
Spezifikationen arbeiten und nicht
Agilität vortäuschen
✓
✓
?
?
?
Als Nutzer hätte ich gerne ein Eingabefeld für
den Vornamen, …
AK:
• Das Feld muss 30x150px gross sein.
• …
7. Skalierte Priorisierung ist inkonsistent.
Situation
Eine Analyse der Backlogs zeigt,
dass die Priorisierung im Team-/
Train-Backlog nicht zu der im
Portfolio passt
Es wird nicht an den hoch
priorisierten Portfolio Epics
gearbeitet.
Was tun?
(1) SAFe einführen und die Rolle des
Business Owners sauber
ausfüllen.
(2) Klare Verantwortlichkeit und
Rahmenbedingungen für die
Priorisierung schaffen.
(3) Hohe Transparenz und
Feedbackprozesse sicherstellen.
(4) Team Input auf Portfolio Level
stärker einbringen.
(5) Team Backlogs durch das Portfolio
priorisieren und abnehmen
lassen.
E
European PO & RE Day - Juni 2021
Auflösung
Was offensichtlich fehlt ist ein
gegenseitiger Austausch und
Transparenz, so dass die
gegenseitigen Einschätzungen
frühzeitig geklärt werden.
Transparenz stärken, alle Backlogs
und die Verlinkung ist sichtbar
Sicherstellen, das der Input der
Teams auf Portfolio Level mit
einfliesst und vice versa
SAFe: Das ist der Job der Business
Owner: coacht sie zum Big Room
Planning zu kommen
Sicher nicht: Team-
Micromanagement durch die
Geschäftsleitung.
?
?
✓
?
8. Just-in-Time: Produktbacklog = Sprintbacklog
Situation
Am Sprintende ist immer praktisch
auch Produkt-Backlog-Ende.
Was tun?
(1) Nichts tun, Just-in-Time ist die
Kür
(2) Anderen PO finden
(3) PO sollte andere Aufgaben
abgeben
(4) Proxy-PO einführen als
Unterstützung
(5) Team unterstützt stärker bei der
Erarbeitung der Storys
(6) Kanban einführen
A
European PO & RE Day - Juni 2021
Auflösung
Habe ich lieber einen guten PO mit
wenig Zeit, oder einen Proxy PO mit
viel Zeit? Kurzfristig kann und sollte
ein gutes Team einen PO stark
entlasten
Kanban verringert den Druck alles
zur Sprint-Planung bereit zu
haben.
Längerfristig: PO organisatorisch
entlasten oder ersetzen, aber nicht
durch einen Proxy
?
?
✓
✓
9. Initiales Backlog = Alle User Storys aus
dem Produktkonzept
Situation
Es wurde ein vollständiges
Produktkonzept erarbeitet.
Das Konzept wurde 1:1 in Features
und User Storys geschnitten
Alles wurde in Jira wurden die
Backlog-Items dokumentiert.
Wir enden mit rund 400 User
Storys und einem komplett
unübersichtlichen Backlog, das
gemanagt werden sollte.
Was tun?
(1) Kein Produktkonzept mehr
erstellen
(2) Epics aus dem Konzept ableiten,
priorisieren, Refinement
(3) Eine Storymap schafft Übersicht
(4) Das ist OK, aber konsequentes
Nachführen der User Storys ist
wichtig
A
European PO & RE Day - Juni 2021
Auflösung
Nehmen wir mal an, es braucht das
Konzept (Budget, Regulator) - danach
sollte trotzdem ein sauberes Backlog
geführt werden - DEEP (Detailed
appropriately, Estimated, Emergent,
Prioritized)
Nur die Top Level Themen/Epics
aus dem Konzept ins Backlog
aufnehmen, priorisieren und dann
Refinement auf der hohen Priorität
Storymaps unterstützen die
Übersichtlichkeit stark
Alle Storys auf einmal zu erstellen
und bei allen Änderungen
nachzuführen ist die Kombination
der Worst Practises aus agilem
und traditionellem RE
✓
?
10. Storys mit vielen Abhängigkeiten zu externen
Personen
Situation
Ein Scrum Team ist häufig auf externe
Personen oder Prioritäten
angewiesen, die auch nicht unbedingt
in einem agilen Team organisiert sind.
Operative Ressourcen
Stark gefragte Spezialisten (der da
für das SAP Modul X zuständig ist)
Zuarbeit von einem Vendor /
Fachabteilung
Was tun?
(1) Eine Story mit Abhängigkeit
gehört nicht in den Sprint
(2) Klare Zusagen einholen, sonst
repriorisieren
(3) Abhängigkeiten/Kompetenzen
temporär ins Team holen
(4) Auflösung der Abhängigkeit als
eigener Backlog-Eintrag
(5) Alle Storys mit Abhängigkeiten
sind Stretch-Goals
(6) Als Blocker markieren und
eskalieren
(7) Kanban einführen, Spalte für
"blockierte" Storys anlegen
A
European PO & RE Day - Juni 2021
Auflösung
Ein Commitment für ein Sprint
Backlog, macht nur Sinn, wenn das
Team ausreichend Kontrolle über die
Erreichbarkeit hat.
Abhängigkeiten müssen geklärt
sein, sonst gehören sie nicht ins
Commitment für den Sprint.
Teamkompetenz stärken,
Ressourcen dazu holen
Notfalls die Storys mit
Abhängigkeiten erst angehen,
wenn die Abhängigkeiten erledigt
sind (als separater Tasks ohne
Commitment)
?
✓
✓
?
?
Blocked
Blocked
Blocked
11. Die Summe aller Storys ist das Epic (Story
Points)
Situation
Ein Epic wird geschätzt.
Später wird die Epic in Storys
geschnitten, die Storys werden
geschätzt.
Das Management fordert, dass wir
keine "Inflation in der Schätzung"
haben und dass die Summe der
Story-Schätzungen die Schätzung
des Epics nicht überschreiten darf.
Schätzung Vorgabe
31 SP 31 SP
Was tun?
(1) Das ist eine angemessene
Forderung des Managements
(2) Management austauschen, da
diese Forderung Blödsinn ist
(3) Management weiterbilden
(4) Puffer in die Epic-Schätzung
einbauen
(5) Regelmässige "Clean-up Sprints"
einführen, zum Fertigstellen der
Storys aus vorherigen Sprints
Anm.: Integrations/Innovations
Sprints, vor allem im skalierten
Umfeld sind etwas anderes.
A
European PO & RE Day - Juni 2021
Auflösung
Schätzung sind primär in
Verantwortung der Teams. Das
Management/Business sollte sich auf
den gelieferten Wert konzentrieren
Schätzungen, Velocity und Sprint
Commitments sind keine
Management Tool
Wir lernen kontinuierlich dazu,
Schätzungen müssen sich ändern
(dürfen)
Ein falscher Fokus des
Management erodiert Vertrauen
und Transparenz, genauso wie
Puffer und Clean-up Sprints (wir
nehmen unsere Schätzungen und
DoD nicht ernst)
?
✓