APM 2 – Triagierte Zusammenfassung

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.
avatar Toby Baier Paypal Icon Amazon Wishlist Icon Bitcoin Icon
avatar Alexander Fürstenau Paypal Icon Amazon Wishlist Icon
avatar Quimoniz
avatar Mathepauker

Einführung in agile Produktentwicklung

00:04:37

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

Scrum 00:31:10

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 Toby: Value Proposition Canvas 01:01:19

Von Ralf Westbrock — Business Modelling Canvas (von Alex Osterwalder)  — Lean Canvas von Ash Maurya — Lean Startup — Fokussierung auf Kundensicht und Zielgruppe — Nicht als Erstes auf die Lösung fokussieren, sondern auf Kunden und deren Probleme.

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.

Vierte Session Alex: Kanban auf Portfolio Level

01:36:44

Kann Kanban die Zahl der Produkte/Ideen reduzieren? — Nach einer halben Stunde: Was ist eigentlich ein Portfolio? (David Joyce – How Kanban Helps us Move Beyond the Traditional PMO to 21st Century Portfolio Management) .

Podojo Sessions

01:38:35

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

O-Ton Stefan Haas 02:06:55

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.

O-Ton Alexander Benker 02:08:27

"Du bist nicht allein." (Alexander).

O-Ton Markus Hippeli 02:09:10

(Berliner PO Szene ist super!)  — "Hamburger sind auch nicht ganz dumm" (Markus).

O-Ton Michael Nordmeyer 02:09:42

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

O-Ton Lydia Grawunder 02:11:17

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

O-Ton Achim Grunwald

02:13:10

Hat Spaß gemacht, nächstes Jahr gerne wieder.

O-Ton Heike Röttgers 02:13:33

Nächstes Jahr lieber zwei Tage — Grooming ist nicht nur für Top Prios, sondern man kann auf Epics vorgreifen.

O-Ton Dirk Bartels 02:14:14

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

Ein Gedanke zu „APM 2 – Triagierte Zusammenfassung

  1. Timo

    Ich hörte gerade die erste 1/4 Stunde dieser Episode und ihr beide sprecht mir sowas von aus dem Herzen.
    Ich arbeite in der IT Abteilung eines großen Unternehmens als Teamlead und Entwickler in einem umfangreichen, lang laufenden Projekt. Unsere Kunde sind zwei große Fachbereiche. Das Projekt ist klassisch nach Wasserfall aufgesetzt. Knappe 2 Jahre wurde spezifiziert, designed, entwickelt und getestet (in dieser Reihenfolge :) ) und eine ganze Horde von Managern ist damit beschäftigt Projektpläne zu erstellen und Balken ind Gannt Diagrammen von links nach rechts zu schubsen.

    Nachdem die Software ausgerollt war, stellte der Fachbereich fest, dass man zwar grundsätzlich damit arbeiten kann, aber viele Dinge doch ganz anders gedacht waren und sehr viel fehlte. Also wird nun nach dem gleichen Vorgehensmodell kontinuierlich nachgebessert – ein irrsinniger Aufwand. Die größte Absurdität: Nachdem man Part 1 der Software immerhin an den Mann gebracht hat klopfte man sich kräftig auf die Schulter und arbeitet an Part 2 (von vieren) genau so weiter, weil man erfolgreich eine Software eingeführt hat. Auf der anderen Seite scheint genug Geld da zu sein, um so weiter zu machen.

    Ganz interessant ist die Sicht der Entwickler. Ein Entwickler der Code anfasst weiß genau, dass er ihn später wieder ändern muss, weil das, was er da tut so nicht gemeint ist. Und langsam aber sicher bröckelt damit die Motivation des Teams – mittlerweile deutlich spürbar, nur leider nicht auf Managementebene.

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *