Product Owner – Projekt Manager – Produkt Manager – Business Analyst: Was macht eigentlich ein PO?
Im August 2020 began Bens TNG Kollege Lars Bonnes ein Experiment: Er nahm inzwischen 7 Podcasts zu fokussierten Fragestelllungen aus dem Arbeitsalltag von TNG Kolleg*innen jeweils in einer kleinen Interviewrunde auf. In der ersten Folge war Ben zu Gast und es ging um das Thema PO – Product Owner.
Freundlicherweise hat Lars diesen Podcast für die Gedenkseite zur Verfügung gestellt.
Diesen Vortrag zum Thema Agile Promotion hat Benjamin gemeinsam mit einigen Kollegen von TNG vorbereitet. Er wurde mehrfach vor e-fellows Studenten gehalten.
Bastian Beskers, Maria Langbeckers und Arved Reising, die den Vortrag gemeinsam mit Benjamin erarbeitet haben, waren so freundlich eine leicht abgewandelte Version davon zur Veröffentlichung vorzubereiten.
Bens TNG-interner Blogpost Meetings, die vom Ziel abdriften
9. Dezember 2019 (editiert von Mathias Arens)
Vor kurzem hatte ich ein Refinement-Meeting mit etwa 10 Personen (Entwickler zweier Teams, UX Team, QA, Agilist, Team Lead)
Ziel des Meetings war es,
3 verschiedene Optionen zu refinen,
deren Aufwand zu schätzen (in Form von Punkten für Team 1 und T-shirt Size für Team 2, aber dieses Konstrukt ist ein Thema für sich)
und damit eine Entscheidungsgrundlage für das Gespräch mit den Stakeholdern zu liefern,
das aufgrund knapper Zeitlage (Weihnachtsgeschäft) am nächsten Tag geplant wurde
Für das Meeting hatten wir 1 Stunde eingeplant.
Nach 50 Minuten befand ich mich in der Situation, dass zwar alle Optionen vorgestellt worden waren (eigentlich waren sie das schon vor dem Meeting) und im Detail diskutiert worden waren – wir aber noch weit weg davon waren, eine Einschätzung zum Aufwand zu finden.
Das Meeting driftete dagegen ab in eine generelle Diskussion zu den Themen:
Was ist die Rolle von UX
Darf ein PO […] mit Stakeholdern alleine entscheiden, welcher Vorschlag gebaut werden soll oder hat UX ein Veto-Recht?
Was ist, wenn UX ein Feature in schön möchte, PO und Stakeholder […] aber ein Release in diesem Jahr für „wertvoller“ hält?
Welche von den 3 Varianten favorisiert XY
Was ist bei dem Feature bereits alles schief gelaufen in der Kommunikation […].
Frage an euch:
Wie hättet ihr in dieser Situation als PO reagiert?
Wie hättet ihr in dieser Situation als Agilist (Scrummaster) reagiert?
Später gibt es dann die „Auflösung“
was habe ich als PO getan?
wie ging es weiter?
was würde ich nach einigen Tagen Nachdenken (anders) formulieren?
Auflösung:
Was habe ich als PO getan?
zwei Mal die Frage gestellt „What prevents us from doing an estimation?“ – was wiederum 2x in eine Rollendiskussion abdriftete
Nach 50 Minuten hatte ich dann wirklich „Die Schnauze voll“ ? Dann kam der Ausspruch (auf den ich nicht stolz bin): „Either, we are now going to estimate the 3 options or I am ending the meeting“
Wie ging es weiter?
Daraufhin gab es Stille im Raum und jemand fragte in etwa „What’s blocking you guys from providing an estimation?“
Innerhalb von 10 Minuten wurden dann alle 3 Optionen geschätzt
am Ende wurde sich auf die mittlere Option geeinigt, nachdem klar wurde, dass keine der 3 Optionen noch dieses Jahr released werden kann, und die favorisierte Version von UX mehrere Risiken beinhaltet
Stakeholder […] waren nicht happy, haben es aber hingenommen
danach folgten längere persönliche Gespräche mit verschiedenen Teilnehmern des Meetings.
ein Action-Item ist, dass wir per Feature (insbesondere mit mehreren Releases) Feature-Retros durchführen.
Mit einem anderenTeilnehmer hab ich bis heute keinen Austausch zum Meeting gehabt. Dafür hat der Techlead mit ihm geredet. Ich hoffe mal, dass er bald Zeit für mich findet.
Das Thema Rollenverständnis UX ? PO wird inzwischen Team-übergreifend diskutiert.
Was würde ich nach einigen Tagen Nachdenken (anders) formulieren?
Ich glaube schon, dass es in der Situation wichtig und richtig war, die Karten auf den Tisch zu legen. Eine Vermeidung des Konfliktes oder ein „Ich nehme die komplette Frustration auf mich“ wäre nicht sinnvoll gewesen.
Gleichzeitig ärgere ich mich über die viel zu kurze und unsaubere Formulierung. Viel besser wäre etwa folgende Kette gewesen:
„We have 10 minutes left and I know that we cannot prolong the meeting today. Let me ask you straight: Is there something that really blocks us to give an estimation for the talks with the Stakeholders? If not, let’s estimate now. If there are, then let’s end the meeting here and discuss in a smaller round“
Als Notiz am Rande:
Es ist nicht so leicht greifbar, wie viel ein Remote Setup kostet. Schätzungen anderer Consulting-Unternehmen sprechen von 30% Produktivitäts-Verlust, wenn eine Person nicht am gleichen Ort ist.
Hier in dem Beispiel bin ich zu 100% sicher, dass die lausige Verbindungs-Qualität dazu beigetragen hat, die Emotionen hochzuschaukeln und verkürzende Sätze provoziert.
Bens TNG-interner Blogpost The Clean Coder – and why I don‘t like it
26. August 2018 (editiert von Martina Schäfer)
Robert C. Martin as an author is probably most known for “Clean Code“ […].
His book “The Clean Coder: A Code of Conduct for Professional Programmers” from 2011 looks at another perspective of today’s coding and tries to teach “what it means to behave as a true software craftsman”. In my own words: the social aspects of the daily work of a programmer.
What I like about the book
The real life stories of Martin reaching back into the 70s give a view into what it was like to be a programmer in those times – and how much more manual work it involved. Furthermore, he is open about how he failed and why.
I like the general idea of the chapters “Saying No” and “Saying Yes”. This is something important to learn. However, the examples are very artificial and hard to generalize…
Why I don’t like the book
Basically, I have 3 main complaint points about this book. Please be aware that they are my subjective opinion and bound to my everyday situations and experience as a Product Owner.
I think the author sees Agile as a process to improve development and developers, not a way to change companies into a more human-centric and successful place. In particular, the book does not even go into the direction of Scrum mechanisms to cope with typical situations between stakeholders and development teams. This surprises as the book is from 2011 and Agile practices are widely accepted in the world of software.
the examples for talks between “management” and “coders” are so extreme that I would rather change the project than recommending any technique to deal with these kind of unrealistic expectations.
the book does not teach any techniques of reflection, how to give feedback, how to deal with conflicts, how to communicate, not even a slight bit of psychology. For me, this is a main aspect that every developer should look into. Personally, I benefited the most from learning about these.
Summary
To be honest, I think the whole learning point of this book could be brought down to 2 blog posts of maybe 10 pages with lots of links to people who explained the details much better than Martin. And 2 statements to keep in mind.
[…]
Blog Post 1
These are the 10 things you should think and read about as a professional software developer
Blog Post 2
Why I failed in my professional software developers life and what I learned from it
Statement 1
Say NO when you would like to say maybe
Statement 2
Usually, a YES comes with a set of conditions. Make them transparent.
Zugegeben, als ich die Idee präsentiert bekam, an einem Volkshochschulkurs zur Weiterentwicklung meiner Persönlichkeit teilzunehmen, kamen in mir erstmal die üblichen Klischees auf:
was für Hausfrauen über 50
unterbezahlte Trainer, die sonst keine Arbeit finden
Kurse wie Qi Cong oder die Feldenkrais-Methode
Aber erstens kommt es anders, und zweitens als man denkt.
So stand ich an einem Freitag Abend 19:30 Uhr in einer Gruppe voller Kommunikationstrainer, Marketingverantwortlicher, Unternehmensberater, Jobcoaches, Projektleiter (12 Personen) und einem Trainer namens Carsten Schleuß [1], der Schauspieler, Fotograf, Einzelshandelskaufmann und irgendwie auch ein bisschen Überlebenskünstler war und ist.
Ein bisschen Background zum Thema
Albert Mehrabian führte 1971 mit ca. 50 Versuchsteilnehmern Kommunikationsexperimente durch, bei dem er die gleichen Wörter immer wieder mit verschiedenen Stimmen und Optik sagen ließ. Grob vereinfacht, kam er zu dem Schluss, dass die Wirkung der Person durch
Optik: 55 %
Stimme 38 %
Inhalt 7 %
( Am Telefon : Stimme: 87 % / Inhalt: 13 % )
bestimmt wurde. Dass diese Ergebnisse auch oft falsch oder zu extrem interpretiert werden, kann man unter [2] nachlesen.
Ingesamt kennt bestimmt jeder Mensch die typische Situationen:
Wieso habe ich mir diesen (Handy)-Vertrag aufschwatzen lassen?
Wieso glaube/traue/wähle ich diesen Politiker, obwohl ich seine Kompetenzen doch überhaupt nicht einschätzen kann (ich nenne das etwas abfällig den Guttenberg-Effekt)?
Warum sind die erfolgreichsten Professoren nicht die, die die herausragendsten Ergebnisse finden, sondern die, die sie auch einem allgemeinen Publikum zugänglich machen können?
Das war und ist immer wieder Anlass für mich, sich mit den nicht-inhaltlichen Themen der Kommunikation und des Auftretens zu beschäftigen.
Ablauf des Seminars
Nach der üblichen kurzen Vorstellung des Trainers und der auch bei TNG-Workshops inzwischen üblichen „Was wünsche ich mir vom Workshop“-Runde stiegen wir direkt in eine erste Spielerunde ein. Mal im Kreis, mal zu zweit, mal in der ganzen Gruppe übten wir Einzelaspekte des persönlichen Auftritts
wie halte ich Blickkontakt?
wie stehe ich sicher?
wie gehe ich mit Situationen um, in denen ich nicht weiß, was ich sagen/antworten soll?
wie komme ich zur Ruhe und entspanne trotz Stress?
wie wirke ich präsent vor einer Gruppe?
wie werde ich in Diskussionen gehört?
Im Folgenden gebe ich ein bisschen Einblick in die einzelnen Übungen
Die erste Übung – Assoziieren
Eigentlich ganz simpel:
Die Gruppe steht im Kreis
Person A sagt ein Wort und gibt es an Person B weiter (Blickkontakt, Gestik, …)
Person B wiederholt das Wort und nennt nachfolgend ein weiteres Wort, das sie mit dem ersten Wort assoziiert. Sie gibt dieses Wort an Person C weiter (Blickkontakt, Gestik)
usw.
Was wird geübt?
Den Blickkontakt und die Präsenz in der Gruppe auch dann zu halten, wenn einem nicht sofort ein neues Wort einfällt
man neigt doch schnell dazu, aus seiner Haltung zu fallen, wenn man nachdenkt Mit dem Abwenden des Blickes und des Körpers verliert man die Präsenz
Durch die Wiederholung des Wortes der vorherigen Person verschafft man sich Zeit zum Nachdenken
eines der Lieblingsmittel im Vertrieb: „Verstehe ich sie richtig, dass sie sich folgendes wünschen/fordern/sehen…?“
Kernidee: Die Pause des Nachdenkens mit Inhalt füllen.
Weiter atmen lernen
Für den Alltag
Versucht mal, beim Bäcker, an der Käsetheke, im Restaurant Blickkontakt mit der Bedienung zu halten – das gesamte Gespräch über.
Die härteste Übung für mich – Mein Auftritt
Wieder ganz simpel:
Die Gruppe sitzt in einer Reihe
Einer aus der Gruppe geht hinter eine Pinnwand und sammelt sich
Er tritt hervor, sucht sich einen sicheren Standpunkt in dem für ihn passenden Abstand
Ohne zu reden, steht man da, Blickkontakt zum Auditorium suchend
Nach einer Weile (ca. 20 Sekunden, die viel länger wirken) gibt der Moderator ein Zeichen
Daraufhin begrüßt man die Gruppe und stellt sich vor: „Guten Tag, meine Name ist …“
Was wird geübt?
Weiter Atmen
Richtige Wirkung
guter Blickkontakt, der allen Anwesenden das Gefühl gibt, beteiligt zu sein
eine Begrüßung und seinen Namen sauber und verständlich wiederzugeben, in einer Weise, die zum körperlichen Auftreten passt
Ruhe bewahren vor ungewohnten Situation (bei mir: ordentlicher Herzschlag )
Für den Alltag
Versucht mal, darauf zu achten, wie ihr euren eigenen (vollen) Namen aussprecht und wie das beim anderen ankommt. Kann man da was verbessern?
Meine Lieblingsübung – Sich durchsetzen in einer Gruppe
Und wieder simpel:
Alle sitzen in einem Stuhlkreis, als fiktive Mitarbeiter einer Firma
Jeder wählt ein gewünschtes Ausflugsziel für den Firmenausflug – aber jeder ein anderes
Man versucht, sein Ausflugsziel in der Gruppe durchzusetzen
Alle rhetorischen Mittel sind erlaubt
Was wird geübt?
Die erste Runde war das absolute Chaos:
Fiese Tricks unter der Gürtellinie
lautes Überstimmen und Durcheinander rufen
einige Teilnehmer, die sich schnell aufgaben
kein Konsens
Danach gibt der Moderator einige Tipps und man probiert das Ganze nochmal. Einige Tricks:
Suche Konsens und Koalitionen mit einigen Personen
Äußere Wunsch/Bitte (das bekannte „Jetzt lassen sie mich doch mal ausreden“)
Blickkontakt erzwingen und damit Aufmerksamkeit einer Person bekommen
und vor allem auch: Seine Rede durchziehen und nicht stoppen (gegebenenfalls lauter)
Für den Alltag
Talkshows, Talkshows, Talkshows. Immer wieder spannend zu sehen – welche Mittel nutzen insbesondere Politiker, um in einer Runde zu Wort zu kommen? Was kommt gut an, was schlecht? Was ist fair, was ist unfair?
Bens TNG-interner Blogpost E-Mail parsen und verarbeiten mit Zapier
30. Dezember 2015 (editiert von Martina Schäfer)
Zwischen Weihnachten und Silvester habe ich mich mal mit einem Problem beschäftigt, dass mich immer wieder Zeit kostet. An einem Beispiel möchte ich euch erklären, wie man mit Zapier und seinem E-Mail Parser relativ komplexe automatische Handlungen aus wiederkehrenden, gleich strukturierten E-Mails vornehmen kann. Natürlich kann man das auch per Regex und sed oder ähnlichem lösen
Ausgangslage:
1-2 Mail im Monat erhalte ich 3-10 E-Mails im gleichen Format mit Ansetzungen als Basketball-Schiedsrichter, die enthalten
Ort, Zeit, Kollege, Halle mit Adresse, …
leider kein ICS-Anhang, um sie direkt in den Kalender zu übertragen.
Ziel
generiere aus diesen E-Mails automatisch Kalender-Einträge
generiere mir eine Vorlage für eine E-Mail, die ich 2-3 Tage vorher an den Schiedsrichter-Kollegen schicke, wo ich nochmal die Grunddaten checke und ihm mitteile, wann ich in der Halle bin.
Umsetzung:
Schritt 1:
Mails parsen. Mit dem Mail-Parser von Zapier (1), der komplett kostenlos ist, lassen sich E-Mails, die einer gleichen Grundstruktur gehorchen, parsen.
Am Ende dieses Schrittes hat man eine Mailbox mit all seinen E-Mails und dem geparsten Text in Listenform:
So sah die Mail vorher aus:
Und das ist der Output
Schritt 2:
Nun wollte ich natürlich die Information auch anhand von Regeln (im Sinne von „If this, then that“) verarbeiten. Dazu nutze ich das Tool Zapier (2). Leider ist Zapier nur kostenlos bis 100 ausgeführte Tasks pro Monat und bis zu 5 ausgeführten Zaps (angelegte Regeln). Danach wird es schnell teuer (20 Dollar pro Monat für Stufe 1). Als kostenlose Alternative bietet sich IFTTT (3) an. Leider gibt es zu IFTTT keinen eigenen Mail Parser, man müsste ihn sich vermutlich in irgendeiner Weise selbst schreiben, siehe (4), oder einen anderen Mail-Parser finden, der IFTTT in geeigneter Weise anspricht.
Mit Zapier verbinde ich nun den Zapier Mail-Parser mit meinem Google Kalender. Der automatische Flow ist dann wie folgt
Leite eingegangene Mail (automatisch) an Mail-Parser Inbox weiter
Mail-Parser erstellt den passenden Output
Zapier triggert die Erstellung eines Google Kalender Eintrags
Für 3. muss man bei der Erstellung des Zaps nur die entsprechenden Tags, die der Mail-Parser auswirft, den passenden Feldern im Google Kalender Event zuordnen. Bei mir sieht das in etwa so aus:
Weiterhin verbinde ich mit einem zweiten Zap den Mail-Parser mit meinem Google Mail Konto und lasse mir einen Mail-Entwurf mit den wichtigsten Daten der Schiedsrichter-Ansetzung und immer gleich bleibendem Text schicken. Fertig!
Nebenbemerkung: Vergleich Zapier und IFTTT
Das kostenlose IFTTT ist sicher vom Funktionsumfang und von der Anzahl der Apps und Tools, die man automatisieren kann, deutlich schwächer als Zapier. Aber trotzdem, man kann coole Sachen damit anstellen:
a) Ich lasse mir morgens und abends eine Mail mit dem Wetterbericht schicken, die auch als Benachrichtigung auf meiner Pebble Smartwatch erscheint. So werde ich nochmal gewarnt, falls Regen angesagt ist und ich mich als Fahrradfahrer entsprechend vorbereiten sollte
b) Hätte ich ein Android Smartphone, würde ich Folgendes nutzen: Starte google maps mit der Verbindung nach Hause/zur Arbeit, wenn man das Haus verlässt.
c) IFTTT arbeitet auch mit Android Wear und damit mit nahezu jeder Smartwatch zusammen. Benachrichtigungen aller Art sind möglich.
d) Heimautomatisierungs-Freunde finden diverse Möglichkeiten: So lässt sich die Lampe Philips Hue per Tageszeit, Wetterbericht, oder beim Siegder NBA-Lieblingsmannschaft einschalten. Oder das Licht und die Heizung geht an, wenn man das Haus betritt.
e) und für die Atlassian-Freunde: JIRA ist auch dabei.
f) eine meiner Lieblingsapps ist Pushbullet, das schnell zum Text- und Datenaustausch zwischen mobilen Geräten und Desktop-PCs genutzt werden kann. Die Pro-Version bietet sogar ein Universal Clipboard, also eine Zwischenablage, die zwischen den Geräten synchronisiert wird. IFTTT bietet auch eine Pushbullet-Integration…
Zusammenfassung
Der Haken der meisten Automatisierungen ist ja oft, dass die Umsetzung zu lange dauert, dass es sich für kleine, private wiederholende Tasks nicht lohnt. Mit Zapier und dem Mail-Parser habe ich gelernt, dass es a) Spaß macht und b) auch privat in kleinem Kreise Sinn machen kann, E-Mails automatisch abzuhandeln. Beide Tools, Zapier und IFTTT, bieten Unmengen an Möglichkeiten, die jeder für sich selbst entdecken kann.
Bens TNG-interner Blogpost Die Product Owner User Story Check List
24. February 2017 (editiert von Martina Schäfer)
Vermutlich alle bzw. viele von euch kennen die folgenden Check Lists:
Definition of Done
Wann ist ein Task fertig? Wann ist eine Story fertig?
Implementation, Code Review, Story Review, Sprint Review
User Story Checklist
Haben wir alles beachtet? Woran müssen wir noch denken?
Planning 2
Definition of Ready
Sind alle Fragen geklärt, sodass wir mit der Entwicklung starten können?
Grooming/Backlog Refinement und Planning 1
[….]
Product Owner User Story Check List
Da wir inzwischen beim Kundenmehrere POs sind, haben wir uns gefragt, ob es nicht auch Sinn macht, eine ähnliche Checkliste mit Projektbezug auch für die Arbeit der Product Owner zu erstellen. Man stellt sich im Prinzip die Frage:
Welche Dinge muss ich alle bedenken, um eine Story „Ready for Estimation“ zu machen und zu versuchen, mit den Akzeptanzkriterien möglichst viele Punkte bereits abzudecken?
Herausgekommen ist dabei der unten stehende Entwurf, der natürlich ein Work in Progress ist.
Fragen an euch, speziell die Product Owner/Business Analysten:
Habt ihr ähnliche Listen für euch selbst oder gar im Team?
Haltet ihr sie für sinnvoll?
Welche Punkte findet ihr sinnvoll/wenig sinnvoll?
Die Liste: Questions to ask when preparing stories
Concerning Pre Development
Which departments/people have to deliver data/designs/information for the Development?
Customer Care/Communication: Did we inform Person 1 and Person 2 and got their opinion on the story?
Concerning In Development
Which departments/people are involved in the Development?
Whose expectations (departments/people) need to be managed?
Concerning Post Development
Are we expected to roll this out to a specific audience only?
Countries
Languages
Specific Customers
Which departments/people are affected by the Development?
What implications does the story might have on those?
Who is to be informed of the changes and when?
Is it enough to inform with the release mail or sprint review?
How do we measure the impact and success of the Story (after its release)?
Can/Should we use Tracking/Reporting for/by
Tool 1
Tool 2
Tool 3
Which parts of the Story should be configurable/changeable without a release?
schicken. Fertig!
Aber denkt an den Datenschutz… 