Tipps zu Präsentationen werden auch in diesem Jahr Thema dieses Blogs sein. Es gibt einfach zu viele schlechte Präsentationen und zu wenige gute Redner. Hier ein lustiges Beispiel, wie wir es alle kennen, aber nicht mehr sehen wollen…

via www.blogpiloten.de

Weitere Artikel zu diesem Thema

• Steve Jobs 1955-2011
• Präsentationen für das Management sind andersPresentation to the Management are different
• Das Geheimnis exzellenter Präsentationen Das Geheimnis exzellenter Präsentationen
• Let’s meet
• Präsentationschamäleons
• 10 Schlüssel für Erfolg im Leben
• Tipps für die Gestaltung ihrer nächsten Präsentation

Den ersten Artikel des Jahres widmen wir Niklas Sum, der momentan als Product Owner bei www.betterplace.org tätig ist. Nach seinem Studium der Betriebswissenschaft arbeitete er bis 2009 bei SportScheck in München. Seit Januar 2010 unterstützt er das Produktmanagement bei betterplace.org in Berlin. Privat ist der Umweltschutz eines der zentralen Anliegen von Nicklas, der unter anderem das Projekt www.energie-ohne-zukunft.de auf die Beine gestellt hat. Als Product Owner ist er dort für die Weiterentwicklung der Website zuständig, an der täglich mit einem Scrum Team gearbeitet wird. Niklas beschreibt im Interview, wie sein Tagesgeschäft bei betterplace.org aussieht, welche Herausforderungen auf ihn warten und gibt hilfreiche Tipps, die für die Arbeit in der Rolle als Product Owner hilfreich sind.

Steckbrief

• Name: Niklas Sum
• Alter: 25
• Angestellt als: Produktmanager
• Product Owner Rolle seit: 2011
• Berufserfahrung gesamt: 2,5 Jahre
• Branche: Internet, e-Commerce
• Produkt Thema: betterplace.org – Spendenplattform und Marktplatz für soziales Engagement

Was ist deines Erachtens das Schwierigste bei der Erfüllung der Product Owner Rolle?

Das Schwierigste ist häufig das Setzen von Prioritäten. Auf der einen Seite stehen die Stakeholder mit sehr vielen guten Ideen, auf der anderen Seite ein relativ kleines Entwicklerteam. Hier die richtige Entscheidung zu treffen, was auf die Product Roadmap kommt, in der “Icebox” landet oder auf die ganz lange Bank geschoben wird, ist essentiell.

Was sind deiner Meinung nach die wichtigsten Fähigkeiten eines Product Owners?

Die Markt- und Wettbewerbssituation sollte man abstrahieren und die gewonnen Informationen auf das Produkt anwenden können. Man muss in angebrachtem Maße eine Liebe zum Detail haben, darf dabei aber nicht den Gesamtüberblick verlieren.

Welche Softskills sollten bei einem Product Owner besonders ausgeprägt sein?

Ein Product Owner muss sehr kommunikationsstark sein, denn er ist Bindeglied zwischen allen Stakeholdern. Er muss mit allen auf einer Augenhöhe kommunizieren können und so viel Empathie besitzen, sich auf die unterschiedlichsten Menschen einzulassen. Er muss nicht nur in Meetings überzeugen können, sondern immer ein offenes Ohr für Jedermann im gesamten Team zu haben: Welche Bedürfnisse, Probleme oder Wünsche gibt es?

Welche Rolle spielt das Entwicklungsteam bei der Erfüllung deiner Aufgaben?

Meine Aufgabe ist es, Produkte und Anforderungen zu liefern, die valuable, feasible und usable sind. Das geht nur in enger Zusammenarbeit mit dem Entwicklungsteam. Scrum stellt das Team vor die Herausforderung, dass es keine seitenlangen Spezifikationen gibt, die es abzuarbeiten gilt, sondern sehr viel der Konzeptions- und Spezifikationsarbeit in der direkten Kommunikation erledigt wird. Darauf müssen sich alle  im Scrum Team einlassen, um erfolgreich zusammenarbeiten zu können.

Wie grenzt sich deine Arbeit von der des Scrum Masters ab?

Wir arbeiten bei betterplace seit 1,5 Jahren ohne einen dedizierten Scrum Master und hatten lediglich zur Einführung des Scrum-Prozesses den Luxus eines Vollzeit-Scrum Masters. Daher sind bei uns die Grenzen ein wenig fließend. Wir alle (PO und Entwicklungsteam) schauen gemeinsam darauf, dass der Prozess eingehalten wird, hauen uns gegenseitig auf die Finger und beseitigen Impediments gemeinsam. Geholfen hat uns hier u.a. die Einführung eines „Artefakts”. Zum Beispiel wird einer der Entwickler während des Stand-ups in die Rolle des Scrum Masters befördert. Mit solchen Hilfsmitteln und einem erfahrenen und eingespielten Team ist Scrum meiner Meinung nach auch ohne dedizierten Scrum Master machbar.

Wie organisierst du deine Arbeit, um die fortlaufende Erstellung von Backlog Items aufrecht erhalten zu können?

Zu Beginn eines neuen Backlog Items steht meistens ein Gespräch mit einem Stakeholder oder eine E-Mail. Mehr als eine User Story ist es dann meistens noch nicht. Je näher die Story dann in Richtung Umsetzung kommt, desto konkreter und ausführlicher wird sie beschrieben. Hilfreich sind hier die fest eingeplanten Estimations und Plannings, da hier immer mehr Informationen benötigt werden, um die Story konkreter zu machen.

Scrum stellt hohe Ansprüche an die Rolle des Product Owners. Sind diese deiner Meinung nach zu erfüllen bzw. wo liegen die Herausforderungen?

Ich denke durchaus, dass die Ansprüche zu erfüllen sind. Klar sollte sein, dass es kein 9to5-Job ist, sondern man das Produkt leben und lieben sollte, um erfolgreich zu sein. Eine Herausforderung ist sicherlich, den Wald vor lauter Bäumen nicht mehr zu sehen: viele Meetings, Stories für die immer laufenden 2-wöchigen Sprintzyklen vorbereiten und das Entwicklerteam betreuen.

Welche Unterstützung hilft dir am meisten bei der Erledigung deiner Aufgaben?

Zuerst natürlich das Entwicklerteam, mit dem eine sehr gute Zusammenarbeit erforderlich ist. Tools die ich zur Organisation meiner Aufgaben verwende sind hauptsächlich Pivotaltracker und Things.

Um Product Owner zu werden, lassen sich viele zertifizieren. Ist es deiner Meinung nach damit getan? Was hat dir geholfen, die Rolle auszufüllen?

Ich habe ebenfalls eine zertifizierte Scrum-Schulung besucht. Nicht, um das Zertifikat zu bekommen, sondern vielmehr, um mehr über die Rolle des Product Owner zu erfahren und zu lernen. Damit ist es allerdings auf keinen Fall getan, es hilft aber andere Product Owner kennenzulernen und über mögliche Probleme zu sprechen und Lösungswege zu diskutieren.

Du kennst die Praxis am Besten – Was sind die 3 schlimmsten Fehler, die man als Product Owner machen kann?

1. Selber keine Ahnung haben, was die Anforderungen sind oder unvorbereitet in ein Planning/Estimation gehen.
2. Die Meinung des Anwenders ignorieren – Stichwort Usertesting.
3. Die Meinung des Entwicklerteams nicht respektieren.

Kann aus deiner Sicht jeder die Rolle des Product Owners besetzen? Wenn nein, warum nicht?

Man muss auf jeden Fall Druck aushalten können und bereit sein, viel Verantwortung zu übernehmen. Man steht 100 Prozent für den Erfolg des Produkts. Trotzdem muss man in der Lage sein, sich unterordnen zu können. Hilfreich ist außerdem, technisches Wissen zu haben, um bei Bedarf Diskussionen im Entwicklerteam über mögliche technische Lösungen mitgestalten zu können.

Backlog Grooming ist ein essentieller Bestandteil von Scrum. Was sind deine Erfolgsfaktoren für die richtige Anwendung?

Das Backlog Grooming ist fester Bestandteil des Terminkalenders und geschieht in ruhiger Stunde vor den Estimation Meetings. Die Sortierung entsteht dabei grob anhand der Roadmap und des Business Values. Erst wenn eine erste Sortierung steht, neue Bugs eingetragen und andere Stories rausgeflogen sind, werden die Items mit dem gesamten Team in Estimation Meetings besprochen und geschätzt.

Was waren die größten Herausforderungen nach dem Wechsel zu Scrum und der Übernahme der Rolle als Product Owner?

Scrum und die Organisation unter einen Hut zu bringen und zum Laufen zu bringen, war sicherlich die größte Herausforderung für unsere Organisation. Die Rolle als Product Owner habe ich übernommen, nachdem ich schon ein Jahr Teil des Entwicklungsteams war. Probleme, das Standing sich erst noch erarbeiten zu müssen, hatte ich Dank meiner tollen Kollegen nicht.

Erzähl doch bitte aus deiner Praxis – Wie gestaltet sich ein normaler Arbeitstag für dich?

Der Tag beginnt mit Emails lesen, Termine und Aufgaben überfliegen, KPI’s checken sowie Küchengesprächen. Danach folgt um 9.30 Uhr das tägliche Stand-up mit dem Entwicklungsteam. Das war’s dann aber auch schon mit der Gleichförmigkeit. Danach folgen unterschiedliche Termine mit Stakeholdern über laufende und zukünftige Projekte oder innerhalb des Produktteams zu Themen wie bspw. Konzept oder Design. Gleichzeitig steht die Tür zu den Entwicklern fast immer offen – bereit für etwaige Rückfragen.

Was ist deine Empfehlung für diejenigen die mit dem Gedanken spielen die Rolle zu übernehmen bzw. die ihre ersten Schritte in der Rolle als Product Owner machen?

Wichtig ist die Entscheidung, ob man bereit ist, so viel Verantwortung zu übernehmen. Darüber hinaus sollte man sich so sehr mit dem Produkt identifizieren können, dass man es in allen Belangen gerne repräsentiert. Wichtige Grundeigenschaften wie Kommunikationsstärke und Belastbarkeit habe ich ja schon im ersten Teil des Interviews herausgestellt. Für die ersten Schritte ist der Kontakt zu anderen (erfahreneren) Product Ownern ratsam, um auftauchende Probleme zu besprechen.

Weitere Artikel zu diesem Thema

• Product Owner im Potrait – Interview Heike Funk
• Product Owner im Portrait: Interview Björn Waide
• Agile Projekte mit Scrum, XP und Kanban
• Product Owner im Portrait: Interview Petra Wille
• 10 deutschsprachige Buch-Neuerscheinungen zum Thema Agile Softwareentwicklung10 deutschsprachige Buch-Neuerscheinungen zum Thema Agile Softwareentwicklung
• Story Maps – Selbsterklärende Product BacklogsStory Maps – Let your product explain itself
• Sprint Zero – Die Null muss stehenSprint Zero – Fasten your seatbelt

Der Gewinner des Gewinnspiels aus letzter Woche wurde ermittelt  und von mir kontaktiert. Er darf sich über ein handsigniertes Buch “Management 3.0” von Jurgen Apello freuen. Herzlichen Glückwunsch!

An dieser Stelle möchte ich die Gelegenheit nutzen Sven Röpstorff, Susanne Reppin, Katja Roth und Ralf Wirdemann für Ihre Mitarbeit und Fachbeiträge recht herzlich zu danken. Mein Dank gilt auch allen Interviewpartnern für die aufschlussreichen Einblicke in ihren Arbeitsalltag.

Vielen Dank allen neuen und treuen Lesern, die auch in 2012 interessante Beiträge erwarten können.

Ich wünsche eine frohe Weihnacht und einen Guten Rutsch in das Neue Jahr!

Weitere Artikel zu diesem Thema

• Herzlichen Glückwunsch – der glückliche Gewinner ist gefunden
• Nutzen Sie Ihre Chance und nehmen Sie jetzt noch am Gewinnspiel teil
• Jahresrückblick 2011 plus Gewinnchance
• Agile Projekte mit Scrum, XP und Kanban
• 7 interessante Antworten von Katja Roth7 interesting answers from Katja Roth
• ATDD – Akzeptanztest-getriebene Entwicklung ATDD – acceptance test-driven development
• Neuauflage: Scrum mit User StoriesNew edition: Scrum with User Stories

Kaum kommt man aus dem lang ersehnten Jahresurlaub zurück, da neigt sich das Jahr auch schon dem Ende zu. Für mich war es ein sehr arbeitsreiches Jahr, welches zügigen Schrittes auf das Jahresende zugegangen ist. Ich habe viel meiner privaten Zeit der Fortführung des Blogs gewidmet, neue Dinge ausprobiert und an weiteren Ideen gearbeitet. Die Arbeit mit meinen Teams hat mir auch in diesem Jahr viel Freude bereitet und ich konnte allerhand dazu lernen. Ich freue mich auf 2012, mit seinen neuen persönlichen, fachlichen und menschlichen Herausforderungen. Nachfolgend einige Zahlen, wie sich projekt-log.de in 2011 weiterentwickelt hat, inklusive Weihnachtsgewinnspiel.

Projekt-log.de im Jahresrückblick:

• Dieses Jahr wurden 60 Artikel zu den verschiedensten Fachthemen verfasst, also im Schnitt 1 Artikel pro Woche.
• Knapp 23.000 Besucher (2010: 14.500) haben an die 36.700 Seitenaufrufe (2010: 27.100) getätigt.
• Am 8.11.2011 war der meistbesuchte Tag mit 248 Besuchern.
• Die meisten Besucher kommen aus Deutschland, gefolgt von der Schweiz, Österreich sowie den USA.
• Katja Roth ist im April als neue Autorin gestartet.
• projekt-log.de ist im Mai zwei Jahre alt geworden.
• Im Laufe des Jahres haben wir auf Zweisprachigkeit umgestellt und bieten seit diesem Zeitpunkt viele Artikel auch in Englischer Sprache an.
• tools.projekt-log.de erblickte das Licht der Welt und wird im kommenden Jahr weiter ausgebaut.
• Das persönliche Engagement, Zeit und Energie der Autoren: unbezahlbar.

Die Top 5 Artikel aus 2011:

1. Estimation – Bewahre die Magie
2. Product Owner im Potrait – Eine Rolle, viele Herausforderungen
3. Lieber Sprint ich hasse dich
4. Team Estimation Game mit verteilten Teams
5. Agile & Lean Konferenzen 2011

Das Beste zum Schluß

Ich verlose ein handsigniertes Exemplar des Buches Management 3.0 von Jurgen Appelo.

So einfach gehts: Jeder der ab heute den “Gefällt-mir“-Button auf Facebook drückt oder @projekt_log auf Twitter folgt, ist bei der Verlosung des Buches dabei. Der Gewinnspielzeitraum endet mit Ablauf des 21.12.2011. Am 22.12. werde ich die Auslosung vornehmen und den Gewinner kontaktieren. Der Gewinn sollte dann noch rechtzeitig zum Weihnachtsfest eintreffen. Viel Glück!

Weitere Artikel zu diesem Thema

• 70 Links zu Autorenwebsiten die über agile Themen berichten
• Frohe Weihnachten
• 7 interessante Antworten von Katja Roth7 interesting answers from Katja Roth
• Agile & Lean Konferenzen Europa 2011Agile & Lean Conferences Europe 2011
• Lieber Sprint, ich hasse Dich …Dear sprint, I hate you …
• 7 interessante Antworten von Josh Nankivel7 interesting answers from Josh Nankivel
• Top 5 Beiträge aus 2010

Weitere Artikel zu diesem Thema

• “… saying we´ve done something wonderful…that´s what matters to me.” [Steve Jobs]
• Der schlimmste Weg, den man wählen kann, ist der, keinen zu wählen. [Unbekannt]Der schlimmste Weg, den man wählen kann, ist der, keinen zu wählen. [Unbekannt]
• Your decisions about allocating your personal time, energy, and talent ultimately shape your life’s strategy. [Clay Christensen]Your decisions about allocating your personal time, energy, and talent ultimately shape your life’s strategy. [Clay Christensen]
• “So much of what we call management consists in making it difficult for people to work.” [Peter F. Drucker]“So much of what we call management consists in making it difficult for people to work.” [Peter F. Drucker]
• “Den größten Fehler, den man im Leben machen kann…”“Den größten Fehler, den man im Leben machen kann…”
• “Wenn dir alles gelingt, was du versuchst, dann versuchst du nicht genug.” [Gordon Moore]“Wenn dir alles gelingt, was du versuchst, dann versuchst du nicht genug.” [Gordon Moore]
• Lebenssituationen

In den meisten Firmen findet man nach Business Value priorisierte Product Backlogs vor, wie Scrum es uns ja auch seit vielen Jahren gelehrt hat. Der aktuelle Scrum Guide vom Juli 2011 hat diese Anforderung etwas gelockert und spricht nun von Product Backlogs, die “oft nach Wert, Risiko, Priotität oder Notwendigkeit geordnet” sind. Wie auch immer, in beiden Fällen steht man vor der Herausforderung, komplexe Funktionalitäten in kleinere Einheiten herunterzubrechen und sie in einer eindimensionalen Liste anzuordnen. Zu einem bestimmten Epic gehörige User Stories bilden in der Regel keinen Block im Backlog, sondern sind weit verteilt und mit User Stories anderer Epics vermischt. Wie kann man seinen Stakeholdern ein rundes Bild des Produktes lediglich mit dem Product Backlog vermitteln? Oder es ihnen sogar einfach nur zum Lesen geben? Vor einiger Zeit hat sich Jeff Patton dieses Problems angenommen und die Idee der Story Maps hervorgebracht. Mit Story Maps kann man des ganze Produkt in einer kompakten Ansicht darstellen und es damit einfacher erklärbar und diskutierbar machen. Dieser Artikel stellt das Konzept der Story Maps vor.

Man braucht

• eine große freie Fläche (Wand oder Fußboden)
• Post-its wie man sie oft sowieso für User Stories benutzt

Erster Schritt

Zunächst zerlegt man sein Produkt in Epics. Sie werden auf Post-its geschrieben und in einer Reihe von links nach rechts an die Wand geklebt. Je weiter links ein Epic steht, desto eher sollte es implementiert werden. Es ist hilfreich, wenn man bei der Anordnung an den groben Workflow denkt, dem der spätere Benutzer des Produkts folgt.

Zweiter Schritt

Nun werden die Epics in User Stories heruntergebrochen. Die Stories werden einzeln auf Post-its geschrieben, die sich farblich von den Epics unterscheiden. Zu diesem Zeitpunkt sollte man nicht an Releases oder zu gruppierende Features denken, sondern sich einfach das finale Produkt mit all seinen Komfortfunktionen vorstellen, die möglicherweise implementiert werden sollen. Danach sollte die Wand in etwa so aussehen wie die Grafik rechts.

Jeff Patton vergleicht das resultierende Bild mit einer Wirbelsäule (“backbone”) und daraus hervorstehenden Rippen, daher hat sich für die Reihe mit den Epics der Begriff “Product Backbone” eingebürgert.

Dritter Schritt

Wenn alle Epics in User Stories zerlegt wurden, beginnt man mit der Priorisierung der Stories pro Epic. Dazu folgt man am besten dem MuSCoW-Prinzip (Must haves, Should haves, Could haves, Won’t haves) und ordnet die wichtigsten Stories am weitesten oben an. Für die Must haves sollte man eine andere Farbe der Post-Its wählen, da diese das sogenannte “Walking Skeleton” beschreiben. Dieser Begriff wurde von Alistair Cockburn geprägt, der ihn folgendermaßen definiert:

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”

Mit dieser zweidimensionalen Story Map bekommt man einen Überblick über das gesamte Produkt. Sie bildet eine idele Ausgangsbasis für Diskussionen sowohl mit den Stakeholdern über den Umfang und die Business-Anforderungen als auch mit dem Team über technische Abhängigkeiten. Man überblickt das gesamte Produkt auf einen Blick und erkennt sofort, welche Funktionalitäten als erstes geliefert werden.

Wie jedes gute Product Backlog sollte auch die Story Map öffentlich sichtbar sein. Auf diese Weise wird man eine Menge Feedback bekommen und viele wertvolle Diskussionen werden vor der Wand stattfinden. 

Um das “Big Picture” nicht zu verlieren, werden Stories, die es in einen Sprint geschafft haben, nicht aus der Story Map entfernt, sondern in das Sprint Backlog dupliziert und in der Map markiert. Fertiggestellte Stories werden entsprechend als erledigt markiert.

Vor etwa anderthalb Jahren habe ich mit einer Gruppe von Product Owner gearbeitet und erstaunlicherweise sind wir auf eine ähnliche Idee gekommen wie Jeff mit den Story Maps. Niemand von uns kannte Story Maps, wir sind lediglich unserem Bauchgefühl gefolgt. Das Produkt war ziemlich komplex und wir haben sehr gutes Feedback sowohl vom Team als auch von den Stakeholdern bekommen, die eine derartig übersichtliche Darstellung sehr begrüßt haben.

Was habt Ihr für Erfahrungen damit, euer Produkt Leuten vorzustellen, die nicht täglich damit beschäftigt sind? Habt Ihr schon Story Maps benutzt? Kennt Ihr andere Methoden? Ich freue mich über Kommentare.

Weitere Artikel zu diesem Thema

• Komplexität in den Griff kriegen – Die TTM-MatrixGet a grip on complexity – the TTM-matrix
• Die Struktur des Heiligen Grals
• Sprint Zero – Die Null muss stehenSprint Zero – Fasten your seatbelt
• Team Estimation Game mit verteilten TeamsTeam Estimation Game with distributed teams
• 200 Links zu Agilität, Projektmanagement, Lean Management & GTD200 links about Agile, Project Management, Lean Management & GTD
• User Stories für das Product Backlog (Teil 2|2)
• User Stories für das Product Backlog (Teil 1|2)

Auf der AgileEE 2011 Conference in Kiew hatte ich das Vergnügen, einen Workshop über Schätzmethoden auszurichten. Die Teilnehmer waren begeistert, da der größte Teil bisher nur Planning Poker kannte und es trotz aller Einschränkungen benutzte. Wir haben Planning Poker mit dem Team Estimation Game verglichen, das ich hier im Blog bereits vor einiger Zeit beschrieben habe (weitere Links unten) und außerdem mit Magic Estimation. Während das Team Estimation Game in letzter Zeit mehr und mehr Anhänger gefunden und Variationen wie Silent Grouping entwickelt hat, ist Magic Estimation noch nicht so bekannt.

Ich werde in diesem Beitrag Magic Estimation erklären, so dass Ihr Eurem Schätzungsportfolio eine weitere Methode hinzufügen könnt.

Die ursprüngliche Idee für Magic Estimation stammt von Lowell Lindstrom, der 2008 “Affinity Estimation” vorgeschlagen hat. Boris Gloger hat Lowell’s Idee aufgegriffen und zu Magic Estimation weiterentwickelt.Verglichen mit Planning Poker bekommt man mit Magic Estimation ein sehr gutes Schätzergebis in kurzer Zeit.

Vorbereitungen

Alle User Stories müssen auf einzelnen Karten vorliegen. Man benötigt einen Tisch, der idealerweise von allen Seiten zugänglich ist. Auf dem Tisch werden Karten mit T-Shirt-Größen ausgelegt (XS, S, M, L, XL, XXL, jeweils eine). Anschließend versammelt sich das ganze Team um den Tisch und die User Stories werden zufällig und gleichmäßig unter den Teilnehmern aufgeteilt..

Durchführung

Erste Runde

Wichtig: Diese Runde ist eine stille Runde! Es gibt keine Diskussionen!
Alle Teilnehmer schätzen gleichzeitig. Sie lesen die ihnen zugeteilten User Stories und ordnen sie den T-Shirt-Karten zu. Der Product Owner ist verfügbar und darf zu inhaltlichen Themen befragt werden, falls notwendig.

Sobald die ersten Karten auf dem Tisch liegen, entwickelt sich implizit eine Art Skala und die Teilnehmer können sich an den bereits auf dem Tisch liegenden Stories orientieren.

Die Runde ist vorbei, wenn alle User Stories auf dem Tisch liegen. Abhängig von der Anzahl der zu schätzenden Stories dauert dies in der Regel nicht länger als ein paar Minuten.

Zweite Runde

Das gesamte Team verteilt sich um den Tisch herum und betrachtet das Ergebnis. Falls jemand eine Karte einer anderen T-Shirt-Größe zuordnen möchte, darf er das tun, muss aber dem Team kurz erklären, warum er dieser Meinung ist. Auch in dieser Runde kann der Product Owner um Erläuterung gebeten werden. Sollte sich das Team bezüglich einer Karte nicht einigen können, wird sie zwecks späterer Klärung aus der Schätzung genommen.

Die zweite Runde ist vorbei, sobald niemand mehr eine Karte verschieben möchte.

Im letzten Schritt werden die T-Shirt-Größen mit der Scrum-Fibonacci-Sequenz ersetzt.

• XS – 1
• S – 2
• M – 3
• L – 5
• XL- 8
• XXL – 13

Boris Gloger benutzt die Fibonacci-Sequenz von Beginn an. Ich verzichte darauf, weil ich möchte, dass das Team sich komplett vom Denken in Zahlen löst. Zahlen werden unbewusst immer wieder miteinander, mit Tagen, Stunden oder Sonstigem verglichen. Ich möchte, dass sich das Team auf “größer, gleich, kleiner” konzentriert und die Stories nur relativ zueinander schätzt. Meiner Erfahrung nach reichen Einschätzungen bis 13 Story Points völlig aus, daher die Einschränkung auf sechs Kategorien. Alles was darüber liegt, ist in der Regel zu groß, um es sinnvoll zu schätzen oder in einem Sprint daran zu arbeiten.

Vorteile

Wie auch mit dem Team Estimation Game bekommt man mit Magic Estimation sehr schnell ein gutes Ergebnis, da die initiale Schäzung einer Story nicht ausdiskutiert wird, sondern von einer einzelnen Person vorgenommen wird. Die möglicherweise abweichenden Perspektiven der anderen Teilnehmer bekommt man in der zweiten Runde.

Verglichen mit dem (ohnehin schon schnellen) Team Estimation Game ist Magic Estimation noch einmal eine Spur schneller, da man nun nicht mehr sequentiell, sondern parallel schätzt..

Nachteile

Manchmal höre ich, dass das die “Weisheit der Vielen” (wisdom of crowds) mit dieser Methode verlorengeht. Das sehe ich nicht so, denn in der zweiten Runde bespricht das gesamte Team das Ergebnis und nimmt Anpassungen vor. Die Weisheit der Vielen geht also nicht verloren, sondern wird erst später im Prozess genutzt.

Erfahrungen

Während ich mit Planning Poker manchmal nach 10 Minuten die Schätzung abbrechen musste, weil sich keine Einigung abzeichnete, beträgt die durschschnittliche Schätzzeit pro User Story mit Magic Estimation etwa 30 Sekunden. Stellt Euch die Schätzung eines 100 Stories starken Product Backlogs mit Planning Poker vor. Bekommt man da nicht Alpträume? Mit Magic Estimation hat man innerhalb einer Stunde ein brauchbares Ergebnis vorliegen, das dem Planning-Poker-Ergebnis in nichts nachsteht.

Für unerfahrene Teams oder Teams, die sich mit dem Produkt noch nicht auskennen, würde ich eher das Team Estimation Game einsetzen als Magic Estimation. Durch die Parallelisierung ist man zwar enorm schnell, aber die sequentuelle Schätzung beim Team Estimation Game bietet eine Menge Information und Einblicke, die für unerfahrene Teams wichtig sein können, da jede Story und ihre Schätzung kurz besprochen wird.

Weiterführende Links

• Slideshare: Workshop über Team Estimation Game und Magic Estimation von der AgileEE 2011 in Kiew
• Projekt-Log: Team Estimation Game
• Projekt-Log: Bye, bye Planning Poker (Erfahrungen mit dem Team Estimation Game)
• Projekt-Log: Team Estimation Game mit verteilten Teams
• Video: Boris Gloger erklärt Magic Estimation (Englisch)

Weitere Artikel zu diesem Thema

• Die magische Schätzmethode
• Agile Schätzung & PlanungAgile Estimation & Planning
• Team Estimation Game
• Team Estimation Game mit verteilten TeamsTeam Estimation Game with distributed teams
• Bye bye, Planning Poker?
• Präsentationen zum Thema Agile Softwareentwicklung
• Erbsenschätzerei reloaded

Das it-camp fand vor wenigen Tagen am 28.10.2011 in Hamburg statt. Da mich die Unkonferenz bei den letzten Besuchen immer begeistert hat, war auch dieser Termin eine Pflichtveranstaltung für mich. Bevor ich zum diesjährigen it-camp komme, möchte ich kurz meine Erfahrungen aus den vergangenen Veranstaltungen teilen:

• Die Themen sind für mich bisher immer interessant und hilfreich gewesen.
• Die Atmosphäre im überschaubaren Rahmen von Menschen macht intensive Arbeit möglich.
• Bernd Österreich hat es bisher immer wieder geschafft neue und erprobte Methoden, Vorgehensweisen und Ideen zum „Wie?“ zu kombinieren, so dass ich bezüglich Methodik bei Workshops immer wieder etwas lerne.
• Die Teilnehmer sind aus einem ähnlichen Holz geschnitzt: haben „agil“ bereits inhaliert, sind sehr offene Köpfe voller Ideen und auch Nöten.

Das Thema auf dem letzten it-camp
Letztes Mal war das Thema „Theorie U – Führen von der Zukunft her“. Klingt spannend und war es auch. Dieses Mal hatte sich Bernd für ein Moderationsteam entschieden. Das Trio (Bernd Oesterreich, Katrin Goecke und Axel Palzer) ergänzten sich wundervoll und waren jeder für sich faszinierend. Hans Wetzer half bei der Vorbereitung und konnte leider nicht dabei sein.

Mein Erleben auf dem letzten it-camp
Zur Vorbereitung habe ich mir den kurzen Film von Bernd Österreich angeschaut und war danach noch mehr gespannt. Ich war also unvorbereitet. Die Einführung, oder sollte ich besser sagen „Einfühlung“ war ungewöhnlich und dadurch perfekt für mich. Geführt wurde von der Theorie, über die Philosophie bis hin zum Fühlen und Erleben. Am Ende galt es das Ziel „die Öffnung des Willens“ zu erreichen. Dazu verhalfen Vorträge, Erzählungen, Beispiele, Übungen sowie ein kleiner Film.

Das Ziel des it-camps war es das „U“ zu durchlaufen und zu erleben. Was das „U“ ausmacht? Vielerlei Aspekte wie bspw. Teams, Gruppen,  Gesellschaft, “das eigene Ich”, Unternehmen oder Organisationen wurden berührt. Je nachdem in welche Kleingruppe man sich begab, konnte man das eine oder andere intensiver erleben. Wenn ich mich also in die Zukunft, in das „weite Feld“ hineinfühle und dabei das Ziel kenne, dann bedeutet „die Öffnung des Willens“, genau das Richtige, für mich Authentische zu tun. Ok, das klingt abgehoben, fremd und bedeutet nichts anderes, als dass unser Handeln und die Ideenfindung aus einer weiteren Sicht heraus entsteht – authentisches Handeln.

Mein Fazit
Die Theorie ist nichts sensationell Neues, sondern eine wissenschaftlich fundierte Vereinigung von bekanntem Wissen zum „U“, welche in dieser Weise sehr interessant ist, praktisch anwendbar und neue Welten eröffnet.

Alle Buchempfehlungen, Bilder, Details und sonstige Verweise zur Vertiefung sind auf der Seite des it-camps zu finden: www.it-camp.de.

Ich werde beim nächsten it-camp wieder dabei sein.

Weitere Artikel zu diesem Thema

• Die Seacon 2011Seacon 2011 Impressions
• Unkonferenz für Software- und Systementwicklung
• Seacon 2011 – der Norden rocktSeacon 2011 – der Norden rockt
• SEACON 2010: Hanseatisch – Sympathisch
• PM-Camp 2011
• Agile & Lean Konferenzen Europa 2011Agile & Lean Conferences Europe 2011
• 7 interessante Antworten von Patrick Fritz

Im heutigen Interview steht Björn Waide (@waide) meinen Fragen Rede und Antwort. Björn bekleidet die Rolle als Product Owner seit geraumer Zeit und blickt auf einen reichen Erfahrungsschatz in der Arbeit mit diversen Scrum Teams zurück. Nach dem Studium der Informatik startet Björn als Software-Entwickler in das Berufsleben und ist mittlerweile sechs Jahre als Produktmanager tätig. Durch die Arbeit in einem agilen Arbeitsumfeld verantwortete er in den letzten drei Jahren verschiedene Produkt-Initiativen in der Rolle des Product Owners. Erfahren sie im Interview mehr über seine Erfahrungen, Herausforderungen und Tipps.

Steckbrief

• Name: Björn Waide
• Alter: 32
• Angestellt als: Director Product Management
• Product Owner Rolle seit: 2009
• Berufserfahrung gesamt: 6 Jahre
• Branche: Internet, Dienstleistung
• Produkt Thema: Social Network

Was ist deines Erachtens das Schwierigste bei der Erfüllung der Product Owner Rolle?

Die Product Owner Rolle stellt hohe Anforderungen aus allen möglichen Teilgebieten an den, der sie ausfüllen soll. Man muss sich in Details auskennen und doch immer das große Ganze sehen. Muss mit Entwicklern über technische Machbarkeit diskutieren oder mit dem Marketing über Produkteinführungsstrategien. Es gibt wohl kaum jemanden, der alle Anforderungen aus allen Teilgebieten gleich gut abdeckt. Für jeden wird also die Schwierigkeit an einer anderen Stelle liegen. Es ist wichtig, sich selbst zu reflektieren und an den Punkten, an denen Wissen oder Erfahrung fehlt, Hilfe von Kollegen oder Fachspezialisten einzuholen.

Was sind deiner Meinung nach die wichtigsten Fähigkeiten eines Product Owners?

Es klingt vielleicht abgedroschen, aber für mich trifft es gerade für den Product Owner immer noch folgendes Zitat von Antoine de Saint-Exupéry: „Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten, endlosen Meer.“ Man kann alleine als Product Owner nichts erreichen. Daher ist es in meinen Augen das Wichtigste, sein Team für die Sache zu begeistern, sie zu infizieren mit einer Idee. Dann läuft ganz viel auch ohne weiteres Zutun, auch wenn Fehler gemacht werden, Akzeptanzkriterien fehlen oder Termine eingehalten werden müssen.

Welche Softskills sollten bei einem Product Owner besonders ausgeprägt sein?

Vielleicht sollte man fragen, auf welche Faktoren man am ehesten verzichten könnte. Als Schnittstellenfunktion und Führungskraft ohne disziplinarische Verantwortung für seine Teammitglieder sind es gerade diese Softskills, die ein Team erfolgreich machen, oder auch nicht. Von Kommunikations- und Teamfähigkeit über Präsentations- und Problemlösungskompetenzen sowie Zeitmanagement bis hin zu Motivationsvermögen, zählen diese „soften Faktoren“ häufig mehr als all mein im Studium oder anderswo erworbenes Wissen.

Welche Rolle spielt das Entwicklungsteam bei der Erfüllung deiner Aufgaben?

Wir bauen gemeinsam als Team ein hoffentlich großartiges Produkt. Das funktioniert nur mit Menschen, die sich nicht als reine Programmierer verstehen, sondern als Produktentwickler. Es gibt in Scrum keine Spezifikation im eigentlichen Sinne, vieles basiert auf dem Versprechen, miteinander zu kommunizieren. Das stellt auch hohe Anforderungen an die Mitglieder des Entwicklungsteams, die selbständiger arbeiten und mehr kommunizieren müssen als bei der Entwicklung nach Wasserfall.

Wie grenzt sich deine Arbeit von der des Scrum Masters ab?

Meine Aufgabe ist vor allem die fachliche Arbeit mit dem Produkt, die Erstellung und Vermittlung einer gemeinsamen Vision und der Produktstrategie, Kenntnisse über die Nutzer zu sammeln und ein Backlog zur Verfügung zu stellen. Der Scrum Master schafft die zur effizienten Umsetzung notwendigen Voraussetzungen, arbeitet ganz eng mit dem Team und formt es zu einer Einheit, zeigt Verbesserungsmöglichkeiten auf und hält allen Beteiligten in der Retrospektive immer wieder den Spiegel vor.

Wie organisierst du deine Arbeit, um die fortlaufende Erstellung von Backlog Items aufrecht erhalten zu können?

Da das Stakeholder-Management oft viel Zeit frisst und man am Product Backlog besser einige Zeit am Stück sitzt, als immer mal wieder 15 Minuten, helfen mir regelmäßige Blockertermine im Kalender, um sich mit dem Team die Zeit zu nehmen.

Scrum stellt hohe Ansprüche an die Rolle des Product Owners. Sind diese deiner Meinung nach zu erfüllen bzw. wo liegen die Herausforderungen?

Product Owner sein ist mehr als nur ein Job. Wenn man die notwendige Begeisterung und Leidenschaft für sein Produkt und die anfangs beschriebenen Fähigkeiten mitbringt und ausbaut, dann sind die meisten anderen Dinge und das nötige Handwerkszeug erlernbar.

Welche Unterstützung hilft dir am meisten bei der Erledigung deiner Aufgaben?

Die Zusammenarbeit mit dem Scrum Team. Wenn das Team sich nicht als “Abarbeiter” von Backlog Items sieht, sondern als Mitgestalter, dann übernimmt es quasi automatisch Aufgaben, die andernfalls beim PO liegen. Dann wird nicht über jedes Akzeptanzkriterium gefeilscht, sondern pro-aktiv Entscheidungen vom Team getroffen, da sie involviert sind oder den Nutzer aus den User Tests kennen, eigene Ideen einbringen o.a.

Um Product Owner zu werden, lassen sich viele zertifizieren. Ist es deiner Meinung nach damit getan? Was hat dir geholfen, die Rolle auszufüllen?

Die in den Zertifizierungskursen vermittelten Inhalte sind hilfreiche Grundlagen. Mir hat allerdings mehr geholfen, die ersten Schritte als PO in einem erfahrenen Scrum Team gemacht zu haben. Der Scrum Master und das Team wussten genau, was sie von mir erwarteten und haben mir dabei geholfen, mich auf die wichtigsten Dinge zu konzentrieren. Meine damalige Teamleiterin, die selbst erfolgreich als Product Owner gearbeitet hat, hat das Übrige dazu beigetragen.

Es wird sehr schwer werden, wenn Scrum für alle eine neue Erfahrung ist. Für die ersten Schritte sollte man zumindest einen sehr erfahrenen Scrum Master haben, bei Bedarf einen Externen.

Du kennst die Praxis am Besten – Was sind die 3 schlimmsten Fehler, die man als Product Owner machen kann?

• Nicht der Experte seines Produktes zu sein.
• Keine Vorstellung davon zu haben, wo die Reise hingehen soll.
• Zu glauben, man sei der Boss.

Kann aus deiner Sicht jeder die Rolle des Product Owners besetzen? Wenn nein, warum nicht?

Das Handwerkszeug des Product Owners ist wie die meisten anderen Dinge im Leben erlernbar und ehrlich gesagt auch kein Hexenwerk. Wie schon an anderer Stelle erwähnt sind allerdings für den Erfolg des Produktes, und damit des Teams, maßgeblich andere Dinge verantwortlich. Insbesondere die Leidenschaft für das Produkt und die Fähigkeit andere mit der eigenen Leidenschaft anzustecken. Wer leidenschaftslos agiert, Management, Stakeholder, Nutzer und Team auf der Strecke lässt, wird es schwer haben.

Backlog Grooming ist ein essentieller Bestandteil von Scrum. Was sind deine Erfolgsfaktoren für die richtige Anwendung?

Wichtig ist erst einmal, dass das Team versteht, welchen wichtigen Beitrag sie selbst zu einem guten Backlog beitragen können. Dann ist eine Einbeziehung des Teams in ganz frühe Entstehungsphasen wichtig, damit das Team bei jedem Backlog Item schon weiß, um was es grundsätzlich geht.

Dann hilft es, mit Backlog Items bereits in sehr frühem Stadium ins Estimation Meeting zu gehen. Aus den Diskussionen und den Schätzungen des Teams ergeben sich die ersten Hinweise für die nächste Iteration der Backlog Items: Schneiden, wenn die Backlog Items zu groß sind, präziser werden, Abhängigkeiten klären, Server bestellen etc. Je nach Aufstellung des Teams, helfen Arbeitssessions vor dem Planning Meeting mit Teammitgliedern wie dem Tester oder Entwickler, um dem Product Backlog den letzten Schliff geben.

Was waren die größten Herausforderungen nach dem Wechsel zu Scrum und der Übernahme der Rolle als Product Owner?

Da ich in eine etablierte Scrum Umgebung meine ersten Schritte als Product Owner machen konnte, fiel mir der Einstieg deutlich leichter als für viele andere, die Scrum oft selbst erst einführen oder etablieren möchten. Die Übernahme der PO-Rolle war trotzdem eine Herausforderung. Als ehemaliger Entwickler war meine größte Herausforderung, den Perspektivenwechsel zu vollziehen und nicht mehr in erster Linie über technische Machbarkeit nachzudenken oder eine technisch ästhetische Umsetzung, sondern über den Nutzer, seine Probleme und wie mein Produkt diese lösen kann. Aber genau hier liegt auch der große Reiz der Rolle.

Erzähl doch bitte aus deiner Praxis – Wie gestaltet sich ein normaler Arbeitstag für dich?

Als Product Owner ist der Arbeitstag geprägt vom Rhythmus der Scrum-Iterationen; neben den täglichen Stand-ups die Vorbereitung auf das nächste Estimation, Planning oder Review Meeting. Da man als PO viele Stakeholder Meetings hat, habe ich immer versucht, zumindest eine Tageshälfte am Arbeitsplatz zu sein, um dem Team für Fragen zur Verfügung zu stehen. Einen Großteil der übrigen Zeit nimmt die Pflege des Product Backlogs und die Erarbeitung neuer Produktideen ein.

Was ist deine Empfehlung für diejenigen die mit dem Gedanken spielen die Rolle zu übernehmen bzw. die ihre ersten Schritte in der Rolle als Product Owner machen?

Ganz viel mit anderen erfahrenen Product Ownern sprechen! Product Owner ist kein Ausbildungsberuf, man kann es nicht studieren und es gibt auch nicht das eine Buch, in dem einem alles Wichtige vermittelt wird. Der regelmäßige Austausch mit Kollegen hilft oft mehr als alle Theorie. Wer gerade keine Kollegen mit Erfahrung bei der Hand hat, kann sich auch virtuell, zum Beispiel in unserer jüngst gegründeten Online Product Management Gruppe austauschen.

Weitere Artikel zu diesem Thema

• Product Owner im Potrait – Interview Heike Funk
• User Stories für das Product Backlog (Teil 2|2)
• User Stories für das Product Backlog (Teil 1|2)
• Product Owner im Potrait – Eine Rolle, viele Herausforderungen
• Agile Schätzung & PlanungAgile Estimation & Planning
• Sag mir, wie Du heisst …
• Story Maps – Selbsterklärende Product BacklogsStory Maps – Let your product explain itself

Vor einigen Tagen ist das Buch “Agile Projekte mit Scrum, XP, Kanban im Unternehmen durchführen: Erfahrungsberichte aus der Praxis” bei mir in der Post gelandet. Ich habe mich schon darauf gefreut, da ich die Texte für Susanne und Sven vorab lesen und reviewen durfte. Henning Wolf, bekannt durch viele Veröffentlichungen zum Thema Agile Softwareentwicklung, hat sich 13 Fachleute zusammengesucht und diese Erfahrungsberichte im Buch gebündelt wiedergegeben. Eine schöne Idee.

Ich habe bis dato einige Erfahrungsberichte gelesen und finde vieles durch den starken Praxisbezug sehr interessant. Besonders gefallen mir die unterschiedliche Herangehensweisen bei der Umsetzung und die Blickwinkel der Autoren, Lernkurven sowie Lösungsansätze. Im Buch kann man sich zu folgenden Schwerpunkten informieren:

• Scrum-Einführung in einem klassischen Organisationsumfeld
• Kanban für Serviceteams
• Agilität in einem Großunternehmen
• Vom Micromanagement zu Scrum
• Agilität unter Festpreisbedingungen
• Kanban für Systemadministratoren
• Agilität bei der Unternehmensgründung
• Agile Werte und Transparenz bei Veränderungsprojekten
• Kanban in Vertrieb und Verwaltung

Sehr gut finde ich die Idee, nach jedem Kapitel eine Auflistung der agilen Werte als Zusammenfassung zu liefern. Es werden hier Aspekte des Projekts anhand einer Skala eingestuft und zusammenfassende Eräuterungen des jeweiligen Autors vorgenommen.

Für alle diejenigen, die etwas über die Praxis agiler Projekte erfahren möchten, die bereits Vorkenntnisse haben und die oben genannten Themenschwerpunkte interessant finden, sollten nicht zögern einen Blick in das Buch zu werfen. “Agile Projekte mit Scrum, XP und Kanban” gibt es ab morgen im Buchhandel zu erwerben.

Update zur Verlosung des Buches “Agile Projekte mit Scrum, XP und Kanban”.

Der Gewinner ist in einem komplizierten und kostenintensiven Losverfahren (Danke Björn) ermittelt worden und kann sich schon bald über das Buch freuen. Herzlichen Glückwunsch! Vielen Dank an die Teilnehmer, deren Vorschläge ich mir zu Herzen nehmen werde. 

Weitere Artikel zu diesem Thema

• Product Owner im Portrait: Interview Petra Wille
• 10 deutschsprachige Buch-Neuerscheinungen zum Thema Agile Softwareentwicklung10 deutschsprachige Buch-Neuerscheinungen zum Thema Agile Softwareentwicklung
• 200 Links zu Agilität, Projektmanagement, Lean Management & GTD200 links about Agile, Project Management, Lean Management & GTD
• 10 Prezi Präsentationen zu Agilen Prinzipien aus 201010 Prezi Presentations about Agile Principles from 2010
• Sag mir, wie Du heisst …
• Top 10 Tipps für agile Coaches
• Product Owner im Potrait: Niklas Sum