In Scrum gehört nach jedem Sprint eine Retrospektive in den Zeitplan. In diesem Meeting wird reflektiert, wie der vergangene Sprint gelaufen ist, was gut war, was verbessert werden kann, wie Stärken gestärkt und Schwächen ausgebügelt werden können. Natürlich ist diese Methode weder eine Erfindung von Scrum, noch auf Scrum beschränkt. Wie man es machen kann, warum man es tut, was der Product Owner dabei zu tun hat, und nicht zuletzt was alles schiefgehen kann hört Ihr in dieser Episode.
Serie "Scrum Essentials", 4. Teil: Retrospektive — am Ende des Sprints kommt nach dem Review Meeting die Retrospektive (kurz: Retro).
Retrospektiven
00:01:25
Es geht darum, auf Personen, Beziehungen, Prozesse und Werkzeuge zu schauen (Was lief gut, was lief weniger gut?) — Rückblick mit Fokus auf Veränderung — "Wie so immer im Agilen geht's ums Lernen" (Toby) — Wichtigstes Instrument für den Scrum Master (Wenn man die Retro immer macht, kommt man irgendwann zum richtigen Prozess) — Buch: "Agile Retrospectives" (5 Phasen der Retrospektive) .
Phase 1: Set the stage / "Reinkommen"
00:03:47
(Aus dem alltäglichen ausbrechen, um in die Vogelperspektive zu gelangen) — Eisbrecher: jeder soll am Anfang was sagen, damit man später auch spricht — ganz kurze Phase, vielleicht nur 1 Minute.
Phase 2: Gather Data / Daten erheben
00:07:46
Mad / Sad / Glad — bei Spielen versucht man zu gewinnen, bei der Retro wollen wir Erkenntnisse gewinnen — Es geht darum, möglichst viele oder möglichst die richtigen Daten zu finden, über die man hinterher sprechen kann — Kartenlimit bei Mad / Sad / Glad sorgt für Filter und Fokus — "Mad" ist nicht unbedingt eine Steigerung von "Sad".
Daten betrachten und analysieren — Muster erkennen und bearbeiten — Wichtigestes Wort: Why? Warum? — "5 whys" als Technik an die unsprünglichen Gründe zu kommen — Schwierigster Teil der Retrospektive.
Phase 4: Decide what to do / Sich für Ziele entscheiden
00:15:10
"Actionable items" finden, auf die sich das Team als Maßnahme eignet — Wenn die Erkenntnisse aus "Generate insights" klar verstanden sind, findet man leicht gute Ziele — Akronym SMART (spezifisch, messbar, ausführbar, realistisch, terminiert) .
Phase 5: Close the retrospective / Retrospektive beenden
00:17:57
Für Mitarbeit bedanken, denn Retro ist Arbeit — Feedback zur Retro einholen (Delta / Plus) — Ziel der Retro sind ein bis zwei Maßnahmen oder Experimente — In der nächsten Retro prüfen, ob sie erreicht sind und sinnvoll waren — Teams sollen besser, effizienter und vor allem auch glücklicher werden — "Ein heeres Ziel" (Toby, zu glücklichen Teams).
Zeitpunkt für Retrospektiven
00:21:51
Im Scrum Guide steht: nach dem Review, vor dem Sprint Planning — Für Retrospektiven sollte man sich genug Zeit nehmen, daher in einwöchigen Sprints vielleicht auch nur nach jedem zweiten Sprint — Retro kann auch dann stattfinden, wenn genug Themen vorhanden sind (täglich sammeln) — Retrospektiven in Kanban oder anderen Techniken ohne feste Iteration: regelmäßig einplanen — Retrospektiven kann man auch in Nicht-Software-Entwicklungs-Teams erfolgreich einsetzen — Für alle Teams, die an sich selbst arbeiten wollen — Supervision (eigentlich etwas anderes).
Rolle des Produktmanagements in der Retrospektive
00:26:29
Das Meeting ist für das Team, eigentlich gehört der Product Owner nicht dazu — Wenn der PO nicht disziplinarisch vorgesetzt ist, geht es problemlos — Hilft, um sehr nah am Team dran zu sein — Häufig fallen auch Aufgaben für den PO ab — Stakeholder Management — Es spricht für ein gutes Vertrauensverhältnis, wenn der PO dabei sein "darf".
Was kann schief laufen bei Sprint Reviews?
00:29:50
Retro ist zum Aufzeigen von Fehlern da (als Beispiel ziehen wir Review Meetings heran, da wir es in der letzten Episode vernachlässigt haben — kein Feedback von Stake Holdern — keine Stellungnahme vom Product Owner — schlechter Umgangston — Inkrement wird auf lokalem Rechner gezeigt — unfertige Ergebnisse werden präsentiert — PO kennt den Zustand nicht) .
Welche Probleme können bei der Retrospektive auftreten?
00:34:12
Es werden keine Maßnahmen beschlossen (oder schlechte Maßnahmen, die nicht erfüllt werden können) — Dinge ausblenden, weil man annimmt, dass man sie nicht ändern kann — Es kann sehr emotional werden (nicht notwendigerweise schlecht oder ein Fehler) — Man muss auch mit unangenehmen Situationen klarkommen — Emotionales auszublenden kann auch sehr schlecht sein — Teile des Teams sind nicht anwesend (bei Urlauben nicht zu vermeiden, aber es sollte nicht die Regel sein) — Zeit zu knapp, so dass keine Maßnahmen beschlossen werden können oder Themen hintenüberfallen (der Agile Coach muss auf die Zeit achten — Drei Stunden für vierwöchige Wochen Sprints — Wenn die Sprints sehr kurz sind, kann man abwechselnd lange und kurze Retros machen) — verschiedene Formate erfordern unterschiedlich viel Zeit — es gibt nicht nur Mad / Sad / Glad — Retromat von Corinna Baldauf.
Verabschiedung
00:41:27
00:00:00.000 Anfang und Begrüßung
00:01:25.000 Retrospektiven
00:03:47.000 Phase 1: Set the stage / "Reinkommen"
00:07:46.000 Phase 2: Gather Data / Daten erheben
00:12:00.000 Phase 3: Generate Insights / Erkenntnisse gewinnen
00:15:10.000 Phase 4: Decide what to do / Sich für Ziele entscheiden
00:17:57.000 Phase 5: Close the retrospective / Retrospektive beenden
00:21:51.000 Zeitpunkt für Retrospektiven
00:26:29.000 Rolle des Produktmanagements in der Retrospektive
00:29:50.000 Was kann schief laufen bei Sprint Reviews?
00:34:12.000 Welche Probleme können bei der Retrospektive auftreten?
00:41:27.000 Verabschiedung
Nach dem Sprint ist vor dem Sprint. Im Sprint Review Meeting stellt das Team das Sprint Ergebnis vor. Der Product Owner überprüft das Ergebnis und entscheidet, welche Stories fertig sind, wobei das Team optimalerweise bereits vorher weiß, was Sache ist. Dann können die Stake Holder Stellung beziehen, Feedback geben und Fragen stellen. Gemeinsam wird am Ende geprüft, ob der aktuelle Plan noch richtig und gut ist.
Sprint Review Meeting — Am Ende des Sprints will das Team zeigen, was es geschafft hat — Product Owner läd ein: Team, Scrum Master, Stakeholder — öffentliches Meeting innerhalb der Firma — Review Meeting kann 4 Stunden pro Monats-Sprint dauern — Toby hat meist kürzere Review Meetings — Ziele des Review Meetings.
Testabdeckung — Wenn Stake Holder im Meeting sind, lieber schon vorher abnehmen — No surprises: das Team sollte nicht überrascht werden von der Meinung des POs — Unfertige Stories kommen zurück ins Product Backlog, nicht automatisch in den nächsten Sprint — Beim Unterbrechen von unfertigen Stories sollte man Rüstkosten berücksichtigen.
Product Owner stellt das aktuelle Product Backlog vor
00:12:15
(Ausblick auf den nächsten Sprint) — Moderation des Sprint Reviews könnte beim Scrum Master liegen (dann hat der PO mehr Zeit sich auf die Stories und das Feedback der Stake Holder zu konzentrieren — (Nachtrag: das Experiment war sehr erfolgreich, und Alex moderiert jetzt immer das Review)) — Exkurs Lean Startup: wichtig ist nur, wie schnell man lernt, und nicht was man schon geschafft hat — "Liebe Zuhörer von Goodgame, Ihr bekommt keine Post, tut mir leid" (Toby).
Markt betrachten
00:16:56
Sind wir noch auf dem richtigen Weg? Haben sich die Umstände geändert? — "Das Review Meeting ist das Kernstück des agilen Produktmanagements" (Toby) — Hier ist die Stellschraube, an der man nach jedem Sprint regeln kann — Es ist nicht das wichtigste Meeting für den PO, vielleicht ist Sprint Planning noch wichtiger — Vielleicht ist das Grooming Meeting noch wichtiger — "Das Backlog ist die Manifestierung der Ideen, die für das Produkt umgesetzt werden sollen" (Toby).
Velocity messen
00:21:53
Nach der Abnahme durch den PO misst man, wieviel Arbeit man geschafft hat — Velocity hilft, Vorhersagen über die wahrscheinliche Performance der Zukunft zu machen (nicht zur Bewertung des Teams — nicht für Personalakten) — Velocity kann für das Team interessant sein, wenn sie stark abweicht.
Ausblick und Verabschiedung
00:24:43
Es wird Episoden zu Retrospektive, Board und Backlog geben.
00:00:00.000 Anfang und Begrüßung
00:04:51.000 Demo des Produktinkrements
00:08:12.000 Product Owner nimmt die Stories ab
00:12:15.000 Product Owner stellt das aktuelle Product Backlog vor
00:16:56.000 Markt betrachten
00:21:53.000 Velocity messen
00:24:43.000 Ausblick und Verabschiedung
Heute geht es im Detail um das Daily Stand Up Meeting und die Rolle des Product Owners, der eigentlich in diesem Meeting gar keine Rolle spielen muss. Aber er kann, und da kommt es natürlich wie immer auf das Team an. In der nächsten Episode aus der Reihe der Scrum Basics gehen wir nicht auf ein Meeting ein, sondern auf das Board. Ich freu mich schon drauf!
Heute startet eine neue Staffel, in der Alexander Fürstenau und ich die einzelnen Meetings des Scrum Zyklus durchnehmen wollen. Wir fangen mit dem ersten Meeting in einem Sprint an, dem Sprint Planning. Wie immer sind wir für Feedback zum Format sehr dankbar!
Im Gegensatz zu den ersten drei Episoden, in denen allgmein auf das Thema Agil, agiles Produktentwicklung und den Job als Produktmanager in der agilen Welt eingegangen worden ist, wird es jetzt deutlich spezieller. Wir betrachten das Thema Sprint Planning, bei dem aus dem Product Backlog eine Reihe von Aufgaben für den kommenden Sprint ausgewählt werden. Dabei achten wir darauf, dass die Perspektive des Product Owners immer wieder genauer beleuchtet wird. Es geht um den Ablauf und den Sinn des Meetings, sowie um die Struktur (erst Aufgaben wählen, dann Aufgaben herunterbrechen), und zuletzt auch um die Vorbereitung. Am Ende geht es noch darum, wie lange denn ein Sprint Planning dauern soll, aber wie immer kommt es natürlich darauf an.
In dieser Episode spreche ich mit Roman Pichler, Autor des einzigen deutschsprachigen Buchs zum Thema "Agiles Produktmanagement". Es geht um Hintergründe von Product Ownern, wo sie herkommen, wie sie zu Product Ownern werden, und wie sie sich weiterbilden können. Dabei kommt natürlich auch viel zur Sprache, was ein Product Owner können muss.
Gast Roman Pichler () — Produktbezogen — Roman lebt in der Nähe von London — Bücher und Blogs auf Englisch erreichen mehr Leute.
Vorstellung Roman Pichler
00:02:39
Coaching für Product Owner — Hilfe für Organisationen, agil zu werden — Produkte für eigenes Unternehmen (Schulungen — Coaching — Bücher) .
Thema: Wie wird man Product Owner?
00:03:58
Gegenbeispiel: Software-Architekten ohne Vorbereitung zum PO befördern — Es gibt keine Studiengänge zum PO (Breit gefächerte Community mit vielen Hintergründen) — "Klassische Produktmanager" sind nicht gleich agile Product Owner (betriebswirtschaftliches Wissen ist dennoch sehr wichtig) — Kommunikation zu Vertrieb und Marketing bei Product Launch — Fachliche vs. disziplinarische Verantwortung: Karriere? — Product Owner Aufgaben sind in klassischen Systemen über mehrere Leute verteilt.
Was bedeutet es, als PO zu arbeiten
00:10:45
(PO ist für den Produkterfolg verantwortlich — PO muss in der Lage und bevollmächtigt sein, Produktentscheidungen zu treffen — PO muss nicht alleine entscheiden — kann und muss sich Hilfe holen um gut informierte Entscheidungen treffen zu können — "PO ist ein agiles Produktmanager" — Produktlebenszyklus begleiten — Product Roadmap erstellen) — Ein PO ist nicht ein Projektleiter, der Aufgaben verteilt — Certified Scrum Product Owner (CSPO) Kurs — Business Model Canvas — Empowerment / Bevollmächtigung (auch zu wichtigen Stake Holdern "Nein" sagen können) — Steve Jobs: wichtigster Aspekt der Innovation ist "Nein" zu sagen — In Produktentscheidungen findet man nicht immer einen Konsens, der PO muss entscheiden — Team und Stake Holder in Entscheidungen einbeziehen.
Weiterbildungsmöglichkeiten als PO
00:19:40
Coaching durch z.B. Roman — Schulungen (z.B. zum CSPO) — Lernen von Kollegen, wenn die Organisation bereits agil ist — Bausteine zur Weiterentwicklung (Geschäftsmodell und Strategie — Schaffen der Produktvision — Marktforschung und Ideenvalidierung — Kundenbeobachtung — Wettbewerbsanalyse — Personas) — PO skill assessment nach Marty Cagan — Roman findet Technological Knowledge nicht so wichtig — "Picasso-eyed-PO: mit einem Auge nach außen, mit dem anderen Auge nach innen schauen" (Roman) — Romans Kunde: Electronic Arts (Physics Engine aus Baustein der Spiele) — POs sollten wenigstens wissen, was technisch möglich ist, ohne es selbst umsetzen können zu müssen — Entwickler-Team ist wichtig für den technischen Blick — Stake Holder Management (Empathie — zum Sprint Review Meeting einladen — Sprint Retrospektive nutzen) — Mutig sein (lieber hinterher um Vergebung bitten anstatt vorher zu fragen — nicht auf Empowerment warten, sondern selbst ergreifen) — Zeitmanagement (Aufgaben des Product Managers sind so vielfältig, dass man gut entscheiden muss, was man tut) — Zielorientiert arbeiten (Sprint Ziele) .
Wo kommt die Mehrheit der Product Owner her?
00:39:10
Roman sieht es sehr gemischt (klassische Produktmanager — Projektleiter — Business Analysten — Programmierer) — Alle müssen sich das Empowerment nehmen — Einige können schon einiges, anderes muss immer gelernt werden — Einige Eigenschaften kann man nicht lernen, z.B. Kommunikationsbereitschaft — Fertigkeiten wie "Arbeiten mit User Stories" kann man lernen — Es gibt wenige explizite Product Owner Bücher (Inspired — Lean Startup — Four steps to epiphaniy — Business Model Generation) — Benutzertests und MVPs können helfen, das Product Backlog zu erarbeiten (Benutzertest — Minimum viable product) — Verständnis von Scrum und Agile (Iteratives Vorgehen zum gezielten Lernen) — "Design as if you were right, but test as if you were wrong".
Communities
00:50:13
(Product Camps und Product Tanks) — UX Community — starke Scrum Master Community — Abschluss mit Bitte um Feedback und Dank.
00:00:00.000 Anfang
00:02:39.000 Vorstellung Roman Pichler
00:03:58.000 Thema: Wie wird man Product Owner?
00:10:45.000 Was bedeutet es, als PO zu arbeiten
00:19:40.000 Weiterbildungsmöglichkeiten als PO
00:39:10.000 Wo kommt die Mehrheit der Product Owner her?
00:50:13.000 Communities
Am kommenden Mittwoch um 11 Uhr sendet Relive Radio die dritte Episode der Gesprächsreihe Agiles Produktmanagement, in der ich mit Roman Pichler, dem Autor von Agiles Produktmanagement mit Scrum über Eigenschaften und Fähigkeiten von Product Ownern spreche, sowie über Hintergründe, Werdegänge und Fortbildungsmöglichkeiten. Sei dabei, komm in den Chat, hilf bei den Shownotes!
Eine knappe Stunde lang erklären Alexander und Toby, was agile Produktentwicklung ist, und dabei gehen sie auf das Wasserfallmodell ein, die Änderungen durch agile Entwicklung, den Rahmen durch Scrum und die Rollen darin. Danach berichten sie vom Product Camp 2013 in Berlin.
Beschränken auf Softwareentwicklung — "Produkt" heißt: nicht Projekt für einzelne Kunden, sondern Produkt für viele Kunden — Produktbegriff ist streitbar — Marty Cagen — C2C — B2B — "Jetzt ist die Frage: Wie macht man das denn?" (Toby) — Erst: Analysephase (Anforderungsdokument) — Lastenheft und Pflichtenheft — MRD (Marketing Requirements Document) considered harmful — Prozess: Anforderungsanalyse, Entwicklungsphase, Qualitätssicherung, Auslieferung, Ende — Vergleich: Feedback-Zyklus im Wasserfallmodell mit Wasserzyklus — "Das Wasser fließt nicht mehr zurück, das ist auch schon der Punkt." (Alex) — Das Feedback kommt zu spät, man hat keine Chance mehr, darauf zu reagieren — Man versucht, vorab möglichst viel über das Ergebnis zu wissen, weil Softwareentwicklung so teuer ist — Softwareentwicklung wird immer günstiger, weil Rechner und Systeme günstiger werden — Lochkarten-Systeme waren sehr teuer — Heutzutage haben Smartphones mehr Speicher als die Mondlandungsrechner — COBOL — Erwünscht war eine möglichst genaue Projektion der Zukunft — Die Krux ist, dass man die Zukunft so schlecht vorhersagen kann — Änderungen passieren immer schneller — Erster Kontakt mit agiler Welt für Alex: Scrum Master ca. 2006 — Toby: ArgoUML (Poseidon for UML (GentleWare)) — Ablaufdiagramm — UML Spezifikation — Extreme Programming XP (CRE 28) — "Embrace Change" von Kent Beck — Extreme Modelling — Das agile Manifest — XP 2000 conference — RUP Rational Unified Process — Coremedia — Product Owner in Scrum sollten nicht gleichzeitig Entwickler sein — Halb Scrum Master, halb Entwickler ist auch ungünstig — Personalverantwortliche sollten auch keine Product Owner werden — Matrixorganisation.
Zusammenfassung: Wasserfall vs agile Produktentwicklung
00:26:58
Am Anfang wird möglichst genau festgelegt, was gebaut werden soll — Misserfolgsquote bei Wasserfall: ca. 80% — "Gerade der Wunsch nach mehr Kontrolle führt dazu, dass Projekte weniger kontrollierbar sind." (Toby) — Beispiel: Kontrolle über das Auto — Die Lösung für dieses Problem ist: agile Produktentwicklung — In agiler Produktentwicklung hat man mehr Kontrolle (durch iteratives Vorgehen — nach jeder Iteration wird Kundenwert geliefert — nach jeder Iteration kann man nachsteuern) .
Zyklen mit fest vorgeschriebener Dauer (Sprint) (zwischen einer und vier Wochen) — Toby arbeitet lieber mit kurzen Sprints: eine Woche — Sprint Planning (erfordert Product Backlog) — Absolut priorisiertes Backlog — Der Product Owner darf die Priorisierung ändern — Im Sprint Planning werden die jeweils obersten Aufgaben aus dem Product Backlog "in den Sprint genommen" — Sprint Backlog (enthält einige User Storys — das Team wählt, wie viele — früher "Commitment", heute "Forecast" — Product Owner darf während des Sprints die Priorität nicht ändern — Der Entwicklungsflow im Sprint soll nicht unterbrochen werden) — Sprint Review Meeting (Team stellt Sprint-Ergebnis vor — Product Owner macht Abnahme) — Wichtig ist das Vertrauensverhältnis — Agile Coach — Daily Scrum Meeting "Daily Standup" (Team trifft sich jeden Tag zur Koordination — Jeder sagt: was habe ich zuletzt gemacht, was habe ich vor, was behindert mich) — "Das Wichtigste ist, zu sagen, dass man Hilfe braucht, wenn man nicht weiterkommt." (Alex) — Sprint Retrospektive (Das Team überlegt, was man im Prozess verbessern könnte — "Das Meeting gehört dem Scrum Master." (Toby)) — Durch iteratives Vorgehen lernt man auf zwei Ebenen: (Fachlich, ob man das richtige baut — Methodisch, wie man effektiver das beste Ergebnis liefern) — Retrospektiven kann man auch in anderen Situationen anwenden — "Unser Bestes versuchen, die nächste Iteration besser zu machen." (Alex) — Das fertige Produktinkrement sollte nach dem Sprint auch ausgeliefert werden, sonst lernt man nichts.
Scrum Rollen
00:45:13
Krossfunktionales Entwicklungsteam (Backend, Frontend, Qualitätssicherung — alle notwendigen Skills sollten vorhanden sein) — Test-Driven-Development — Jeder sollte alle Aufgaben übernehmen, die er übernehmen kann — Scrum Master (ist für den Prozess verantwortlich — soll dem Team helfen, sich ständig zu verbessern) — Ist nicht der Projektleiter — Das Team soll die Aufgaben selber verteilen, i.d.R. im Pull — Rolle: Product Owner (ist dafür verantwortlich, dass das Produkt den maximalen Erfolg hat) — Ist verantwortlich für das Product Backlog — Leider ist der PO nicht genauer beschrieben (ist sehr von den Umständen abhängig) — Trägt die fachliche Verantwortung — hat die notwendigen Fähigkeiten dazu (hat sowohl die richtigen Kompetenzen — als auch die Ermächtigung, Entscheidungen zu treffen) — Es gibt "das eine Buch" von Roman Pichler — 15-minütiges Video von Henrik Kniberg.
Product Camp 2013
00:53:14
Barcamp/Unconference — Kein festes Programm "Unconference", die Teilnehmer schlagen direkt vor Ort Sessions vor — Bei einer Konferenz gibt es ein festes Programm, das von einem Programmkommitee entschieden wird — Bei diesem Product Camp gab es vorab die Möglichkeit, Sessions vorzuschlagen (die Vorschläge wurden aber nicht direkt übertragen) — Sechs Konferenzräume bei ImmobilienScout — Product Camp <www.productcampberlin.org/> — Zalando hat eine Club-Mate-Theke gesponsort (Bild auf Twitter) — Barcamp — Circa 180 Teilnehmer — Circa 28 Sessions (von sehr allgemeinen Themen — über Tiefergehendes — bis hin zu sehr speziellen Themen wie Grooming Sessions) — Teilnehmer haben sich auf die Sessions aufgeteilt ("War das Camp auch was für Coaches?" – Ja!) — Interessante Leute kennenzulernen war das Zweitwichtigste des Camps — Immanuel Kants "Kritik der reinen Vernunft" — Einschlafen-Podcast.
Erste Session Alex: Gibt es in zehn Jahren noch Scrum?
01:06:29
Halbe Stunde "Kurzvorstellungen" — Wenig Zeit für das Thema — Hoffentlich gibt es dann keine Titel mehr (Junior, Senior, Associate) — "Wir befürchten, dass es Organisationen auch noch in zehn Jahren gibt." (Alex).
Zweite Session Toby: Work more, meet less
01:08:09
(Katrin Dreyer — und Lydia Grawunder) — Sehr guter Vortrag über Discovery und Grooming mittels Design Thinking und Game Storming — Game storming für Toby nicht neu, schon bei XING gelernt — Trotzdem toller Vortrag — Rainer Gibbert.
Zweite Session Alex: konkretes Problem
01:11:42
Schon die Formulierung der Session hat Alex aufgeregt — Im Team waren Mitglieder mit unterschiedlichem Output — "Wie kann ich positive Competition in das Team bringen?" — Alex hat argumentiert, dass das Team nicht gegeneinander ausgespielt werden sollte — Gamification — Sie führt unter Entwicklern eher dazu, dass sie auf die Competition achten, nicht auf das Produkt — Jenkins Plugin Sonar — Code Metriken sollten nur für das Team da sein, nicht für externe — "Sobald irgendein Manager die Zahlen nutzt, um Teammitglieder zu bewerten, das macht man nicht, das ist falsch." (Toby) — Vergleich von Zahlen oder Velocity führt zu kontraproduktivem verstecktem Minderleistungsvorwurf — Rückgriff auf Scrum: Velocity ist die mittlere Summe der geschafften Aufgaben pro Sprint — Bestrafung für "Build kaputtmachen" — USB Raketenwerfer — Er trifft nicht, ist aber lustig — Vorschlag von Alex zur Lösung des Problems: Werte ermitteln.
Dritte Session (gemeinsam): How to convince your manager...
01:20:31
Missverständnis: es ging um den Pitch, nicht um Einführung von "agile" — Schwierige Diskussion, typische Barcamp Session — Ulrike Gruel — XING — Soll man lügen, um den Pitch zu gewinnen? — Schampusflaschen, um Manager zu beeinflussen — Die Frage, wie man der Zahlenbeschönigung von Konkurenzprojekten gleichauf kommen kann, konnten sie nicht lösen — "Agile Projekte sind nicht notwendigerweise schneller fertig als Wasserfallprojekte, aber die Wahrscheinlichkeit, dass was Sinnvolles dabei rauskommt, ist größer." (Toby) — Der Scrum Guide (und dessen Aktualisierung) .
Vierte Session Toby: Grooming
01:27:26
Bisschen aufgeregt, weil die Latte hoch gelegt war — Toby war vergleichsweise wenig vorbereitet — Thema: Wie macht man Grooming Sessions? — Früher: Triage, um User Stories für die Estimation vorzubereiten — "Fertig triagierte Storys" — Barney Stinson aus "How I Met Your Mother": man muss sich eigene Wörter ausdenken (Barney Stinson) — "Man muss auch Wörter ausdenken können." (Toby zitiert Barney) (in "How I Met Your Mother" S02E14) — Erst werden Storys besprochen, am Ende gegebenenfalls geschätzt — Gewünschtes Ergebnis des Groomings: besser gefülltes Product Backlog mit geschätzten Storys — Risiko und Komplexität gegen Kundenwert abschätzen können — Riskante, unverstandene Storys sollten schnell (max. 2 Tage) analysiert werden ("Evaluate" Stories) — Die Session war ein Brainstorming zum Thema Grooming mit drei Listen (Was wünscht man sich aus einem Grooming? — Was muss man dafür tun? — "What can go wrong?") — Toby möchte einen Blogbeitrag zu dem Thema schreiben und anschließend eine Episode dazu aufnehmen.
Stefan Haas (PO Dojo <www.podojo.com>) — Shu ha ri — Skype Channel immer Donnerstags um 14:30 (MESZ) — Jurgen Appelo macht Google Hangouts — Motto "Lurkers are always welcome." — Thema: Product Owner Competency (Folien:) — Brainstorming ("Ein Product Manager muss wie Google Maps sein – reinzoomen und rauszoomen" (Zitat Vlore Kryeziu)) — Vlore Kryeziu) — Eigentlich muss man Google Earth sein, man darf nur nicht die Orientierung verlieren — Oder man muss wie ein Krieger sein, oder wie ein Tänzer — Schwierig, zwischen Eigenschaften und Skills zu unterscheiden — Schwer messbare Skills (Humor — Authorität) — Man muss A/B-Tests durchführen können, und das kann man lernen — Anwendungsfälle einer Competence Map (Selbsteinschätzung — Personalsuche — "es anderen erklären können" — hilft bei Delegation Poker) — Management 3.0 (Management 3.0: Leading Agile Developers, Developing Agile Leaders) — Stufen der Delegierung: Tell, Sell, Consult, Agree, Advice, Inquire, Delegation — Beispiele für Delegation Poker (Auswahl einer Produktvision) — Delegation Poker in ausgedachten Szenarien üben ist schwierig (wenn das Szenario nicht klar ist, funktioniert das Spiel nicht) — Delegation Poker kann man transitiv spielen — MongoDB — MySQL — "Wann immer eine Frage mit 'wie' beginnt, ist das ein Hinweise, dass die Frage vom Team beantwortet werden muss." (Alex) — Gehört der Interaction Designer zum Team? — Delegation Poker ist spannend und bringt zwei Werte: (erstens: man spricht darüber — zweitens: das Ergebnis ist dokumentiert) — Das Ergebnis kann später geändert werden, wenn sich die Rahmenbedingungen ändern — Beispiel: Elektrozaun anfassen (aus Jurgens Buch) — Beispiel: Wasserlinie beim Schiffsrumpf.
Fazit des Tages und O-Töne
02:03:43
Es folgen O-Töne — "Es war ein super Tag." (Toby) — Podcasten hilft beim Erinnern — Abschied.
O-Ton Rainer Gibbert, Daniel Neuberger, Christoph
02:04:59
(Und ab! ("Go For it – nicht lange schnacken, machen.") — "Ship it" — Tofis Schwimmlehrer "Und ab!"# — ImmoNet.
O-Ton Alexander Fürstenau
02:06:08
Es gibt ganz viele Leute, die "agil" lernen wollen, es aber nicht sind (nicht das richtige Mindset haben).
Value Proposition Map war sehr gut (Empathie zum Verstehen der User — Starker Bedarf für Product Owner Competence Model) — HR (Human Resources) Bereich — Creative Commons — "Wieso gehen Grooming Sessions schief?" war lustig.
"Mein EIndruck ist, dass die Leute hier wesentlich konservativer sind als auf anderen Barcamps." (Michael) (verschlossene Türen — Unterschrift für WLAN — Keine Getränke in den Vortragsräumen erlaubt) — Michael war schon auf vielen Camps.
Gutes Feedback war super, alle Leute haben es geliebt — Der gleiche Vortrag stieß intern auf nicht so gute Resonanz — Leider von den Sessions nicht viel mitbekommen (Lydia war Volunteer und hat bei der Durchführung des Camps mitgeholfen) .
Konzept Open Knowledge — Road Map — "Ich fand es sehr bereichernd für mich, und ich hatte auch das Gefühl, dass die Leute bereichert waren." (Dirk).
Ende
02:16:17
00:00:00.000 Anfang
00:04:37.000 Einführung in agile Produktentwicklung
00:26:58.000 Zusammenfassung: Wasserfall vs agile Produktentwicklung
00:31:10.000 Scrum
00:45:13.000 Scrum Rollen
00:53:14.000 Product Camp 2013
01:01:19.000 Erste Session Toby: Value Proposition Canvas
01:06:29.000 Erste Session Alex: Gibt es in zehn Jahren noch Scrum?
01:08:09.000 Zweite Session Toby: Work more, meet less
01:11:42.000 Zweite Session Alex: konkretes Problem
01:20:31.000 Dritte Session (gemeinsam): How to convince your manager...
01:27:26.000 Vierte Session Toby: Grooming
01:36:44.000 Vierte Session Alex: Kanban auf Portfolio Level
01:38:35.000 Podojo Sessions
02:03:43.000 Fazit des Tages und O-Töne
02:04:59.000 O-Ton Rainer Gibbert, Daniel Neuberger, Christoph
02:06:08.000 O-Ton Alexander Fürstenau
02:06:55.000 O-Ton Stefan Haas
02:08:27.000 O-Ton Alexander Benker
02:09:10.000 O-Ton Markus Hippeli
02:09:42.000 O-Ton Michael Nordmeyer
02:11:17.000 O-Ton Lydia Grawunder
02:13:10.000 O-Ton Achim Grunwald
02:13:33.000 O-Ton Heike Röttgers
02:14:14.000 O-Ton Dirk Bartels
02:16:17.000 Ende
In der ersten Episode der Gesprächsreihe über Agiles Produktmanagement spreche ich mit Victoria und Bernd Schiffer, die nicht nur seit vielen Jahren als agile Entwickler, Coaches und Produktmanager leben, sondern sogar ihre Hochzeit und ihr Auswandern nach Australien mit Kanban organisiert haben.
(Vicky findet den ersten Punkt "Individuals and Interactions over tools and processes" am wichtigsten) — Bessere Kommunikation führt zu besserer Software (ermöglicht Responding to Change) — Bernd hat keinen Lieblingssatz (es ist zu individuell pro Kunde / Situation) — Bernds Lieblingsprinzip: "Simplicity--the art of maximizing the amount of work not done--is essential." — Tobys Lieblingssatz: "Responding to change over following a plan" — Requirements Document (Pflichtenheft) — QA (Quality Assurance) — Following a Plan — Eliminating the waste (Verschwendung) — Kanban — Toby arbeitete in Rapid-Response-Team.
Scrum oder Kanban?
00:19:41
Macht man in Produkt-Teams eher Scrum und in Maintenance Teams eher Kanban? (Scrum — Kanban) — Vicky: "Sowohl als auch" — No-Estimates Diskussion (Blog über No Estimates) — Vorhersagbarkeit ohne "Estimates", bspw. Iterativ mit Budget — Wie immer: es kommt drauf an, was man erreichen möchte — "Hauptsache ihr achtet darauf, dass ihr irgendwo Platz habt, euren Plan anzupassen" (Toby) — Three contraints (Randbedingungen) (regelmäßig Produkte fertig stellen — Den Kunden zufrieden stellen, "delight the customer" — kontinuierlich verbessern) — Personal Kanban — Portfolio Kanban — Bernd: Teams wechseln häufig von Scrum nach Kanban oder anders herum — Kanbans WIP limits (WIP = work in progress) — Jemandem, der Kanban machen will, sollte man kein Scrum verkaufen — Retrospektive (wird oft bei Kanban vergessen) — Operation Reviews — David Anderson (Lessons in Agile Management: On the Road to Kanban by David J. Anderson, Alan Shalloway and Stephen Denning (Aug 2, 2012)) — "Lernen unterschiedliche Dinge zu messen um zu lernen" (Bernd) — "Whatever floats your boat" (Bernd) (Erklärung im Wiki) .
Product Owner-Rolle in Scrum oder Kanban
00:30:25
Kanban hat keine Anforderung an die Rollen (nimmt was da ist, PO ist nicht erforderlich) — Visualisieren des Value-Stream — In Scrum ist ein Product Owner vorgeschrieben (inklusive fester Rollenbestandteile als "Owner") — PO-Rolle aus Scrum geht genau so in Kanban.
Woher kommt der Wunsch in Firmen, ins Agile zu wechseln?
00:33:13
Meist kommen Anfragen von Sandwich-Managern "Head of Development" — "Du hast einen Haufen Produktmanager" (Bernd) (natürlich nicht negativ gemeint) — Was heißt die Rolle eines Produktmanagers (und was ist eigentlich ein Produkt?) — Produktmanager schaffen im agilen Umfeld häufig viel mehr als im Wasserfall — Der Kollaborationsmoment, das direkte Feedback wurden schnell klar und geliebt — Die Sorge, Kontrolle zu verlieren, weicht schnell der guten Erfahrung, viel mehr zu schaffen — Ideenentwicklung und Entscheidungen — Vertrauensgewinn — im Agilen hat man mehr Kontrolle, weil man viel schneller nachjustieren kann — Investitionsentscheidungen anhand der Information, was am Ende herauskommt (kann man bei komplexen Produkten sowieso nicht) — Wartung — "Save-my-Ass Policy" (Toby).
Gibt es Projekte, in denen Wasserfall sinnvoll ist?
00:43:42
kurze 3-4 Wochenprojekte können evtl. auch als Wasserfallprojekt durchgezogen werden (Toby) — Das Logo von Bernds Firma Bold Mover wurde auch agil entwickelt (täglich gingen Mails hin und her) — "Landing Page" — Man sollte sich vorher über das Mindset im Klaren sein — "Du kannst nicht agil machen, du kannst nur agil sein" (Bernd) — Toby dachte an Projekte, bei denen im Voraus schon alles klar ist (es fällt ihm aber kein Beispiel ein) — Sobald man im agilen Mindset ist, macht man alles agil — "Agil ist kein Selbstzweck" (Bernd) — Wenn man gute Erfahrung im Agilen gemacht hat, warum sollte man es dann noch anders machen? — Vicky wüsste gar nicht mehr, wie man "Wasserfall" machen sollte (ist gar nicht schwer, außer man macht RUP) — Vicky empfiehlt, einfach mal auszuprobieren.
Personal Kanban: agiles Heiraten
00:52:10
Küche in Hamburg, Schränke mit Post-Its beklebt — Heirat in vier Spalten Kanban (Backlog ,Todo, Doing, Done) — Reviews auf Produkt-Ebene — Bernd musste die Einladungen machen, VIcky hat ihn getrieben — Kanban machte den Fortschritt besser sichtbar und für beide einfacher zu erkennen — Stand Up nicht nötig, sie waren eh die meiste Zeit in der Küche (sehr hohe Transparenz) — Nicht nur die Hochzeit, sondern auch die Auswanderung nach Australien lief über Kanban (noch viel mehr Karten als bei der Hochzeit) — Personal Kanban sollte man in einem Raum machen in dem man oft ist/vorbei kommt — Auch Personal Kanban Iterationen planen, z.B. "Visum" — Erst war geplant, die Möbel auf eBay zu verkaufen — Glücklicherweise merkten sie frühzeitig, dass sie nicht alle Möbel auf eBay stellen können — Umplanung auf Hausflohmarkt statt eBay — Personal Kanban war erfolgreich ("Wir sind in Australien, wir haben geheiratet..." (Bernd)) — Die Rolle des Produktmanagers wurde untereinander aufgeteilt — "Produktmanagement at it's best" (Victoria).
Verabschiedung
00:59:59
00:00:00.000 Anfang
00:03:47.000 Agilisten waren vorher oft Entwickler
00:08:34.000 Was bedeutet "Lean"
00:14:16.000 Lieblingssätze im Agilen Manifest
00:19:41.000 Scrum oder Kanban?
00:30:25.000 Product Owner-Rolle in Scrum oder Kanban
00:33:13.000 Woher kommt der Wunsch in Firmen, ins Agile zu wechseln?
00:43:42.000 Gibt es Projekte, in denen Wasserfall sinnvoll ist?
00:52:10.000 Personal Kanban: agiles Heiraten
00:59:59.000 Verabschiedung
Die erste Episode der Gesprächsreihe, die dieses Blog begleitet, ist aufgenommen und wird am Sonntag veröffentlicht. Um 10 Uhr wird die Sendung auf Relive Radio ausgestrahlt, so dass alle Interessierten zeitgleich hören können. Dazu gibt es auch einen Chat, in dem alle Hörer sich über die Sendung unterhalten können. Ich freue mich, dass meine beiden Gesprächspartner Victoria und Bernd Schiffer auch mit dabei sein werden, obwohl wir acht Zeitzonen weit auseinander wohnen! Die Sendung dauert eine Stunde, etwas später wird sie auch hier als Download und im Podcast Feed verfügbar sein.
Anschließend kann die Gesprächsreihe hier auf www.agilesproduktmanagement.de gehört und abonniert werden. Das einzige, was mir noch fehlt, ist ein passendes Logo, aber daran soll es ja nicht scheitern ;)
Ich habe das Video „Agile Product Ownership in a nutshell“ von Henrik Kniberg synchronisiert. So können deutsche Muttersprachler dieser außerordentlich guten, sehr kompakten Darstellung besser folgen. Es ist der Inhalt einer ganztägigen Schulung für Scrum Product Owner, komprimiert auf eine Viertelstunde. Es lohnt sich also, das Video mehrfach zu schauen. Ich habe beim Synchronisieren gemerkt, dass ich einige Details beim bisherigen Sehen des Videos übersehen hatte.
Ich habe für die Synchronisierung die Untertitel von Corinna Baldauf verwendet, danke Corinna!
über Eigenschaften und Fähigkeiten von Product Ownern spreche, sowie über Hintergründe, Werdegänge und Fortbildungsmöglichkeiten. Sei dabei, komm in den Chat, hilf bei den 
