Produktmanagement Lesetipps: Scrum an den Boss verkaufen, Make-or-Buy, ROTI, Tage der Entscheidungen

glassesEine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um die Bewerbung von Scrum beim Vorgesetzten, Make-or-Buy-or-Partner-Entscheidungen, Feedback für Meetings mittels ROTI und um „Tage der Entscheidungen“. Viel Spaß beim Lesen!

  • Schon häufiger habe ich es erlebt, dass Mitarbeiter die Einführung von Scrum in ihrem Unternehmen vorantreiben wollten und sich überlegt haben, wie Sie der Führungsebene die Vorteile vermitteln können. Robert Karlsson hat in dem Artikel „Key Arguments to Sell Scrum to Your Boss“ einige Empfehlungen zusammengetragen, wie vorgegangen werden kann.
  • Building Your Own Product – Isn’t Always the Best Strategy„, diesen Reminder gibt uns das Blog onproductmanagement. Es sollte in Betracht gezogen werden, dass der Kauf einer bestehenden Lösung oder auch eine Partnerschaft der bessere Weg sein könnten.
  • Im Blog von //SEIBERT/MEDIA wird ein Verfahren vorgestellt, mit dem schnell Feedback zu Besprechungen und Workshops eingeholt werden kann: ROTI: Schnelles Feedback bei jeder Gelegenheit. Es wird auch gleich eine Druckvorlage mitgeliefert, mit dem die kurze Abfrage bei den Teilnehmern durchgeführt werden kann.
  • 3 Fragen sollten sich Unternehmen und Organisationen regelmäßig stellen, empfehlen Förster & Kreuz in ihrem aktuellen Artikel „Tage der Entscheidungen„: 1. Wo liegen die größten Chancen, auf die wir uns konzentrieren sollten? 2. Welche Fähigkeiten brauchen wir, um von diesen Chancen profitieren zu können? 3. Womit vergeuden wir heute Zeit und wofür sollten wir diese besser verwenden? Sie selbst möchten sich diese Frage fortan vier Mal pro Jahr stellen.

Foto: 0xMatheus

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder denRSS-Feed.

Erste Expertenvorträge der Tools4AgileTeams bekanntgegeben

Die ersten Expertenvorträge der Tools4AgileTeams wurden kürzlich bekanntgegeben.
Die Tools4AgileTeams ist eine Konferenz über den Einsatz von Werkzeugen bei agilen Entwicklungsteams, die am 8. November in Wiesbaden im Hotel Oranien stattfinden wird.

Der Ablauf der Konferenz sieht Expertenvorträge am Vormittag vor, spezifische Fragestellungen werden am Nachmittag im Rahmen eines Open Space behandelt. Damit soll erreicht werden, dass jeder Teilnehmer konkrete, anwendbare Learnings für sein/ihr Unternehmen mitnimmt.

Die folgenden Expertenvorträge können bei der Tools4AgileTeams unter anderem erwartet werden:

Wir befinden uns im Gespräch mit weiteren möglichen Referenten. Diese werden dann auf der Konferenz-Website bekannt gegeben.

Am Nachmittag des Konferenztages folgt dann das Open Space. Die konkreten Sessions für das Open Space werden vor Ort selbst vorgestellt und besprochen. Im Vorfeld möchten wir jedoch schon einmal Themen beispielhaft aufgreifen, die Bestandteil des Open Space werden könnten:

  • Erfahrungsaustausch zur rein analogen Arbeit
  • Möglichkeiten für den Abgleich von virtuellem Backlogpflege-Tool und analogem Taskboard
  • Erfahrungsbericht zum Einsatz von kunagi in Scrum-Teams
  • Vorstellung der Software-Systeme von Atlassian und von Target Process
  • Tool-Unterstützung in verteilten Teams
  • Kundenintegration durch den Tooleinsatz

Anmeldung zur Tools4AgileTeams

Die Anmeldung für die Veranstaltung über die Eventseite ist geöffnet. Für Leser dieses Blogs besteht die Möglichkeit, mit dem Rabattcode „ProduktmanagerInternet“ eine Vergünstigung in Höhe von 15% zu erhalten.

Sponsoring

Mit der Bekanntgabe der ersten Expertenvorträge wurde auch ein Sponsoring-Paket für interessierte Unternehmen auf der Eventseite online gestellt. Bei Interesse bitte Kontakt über pherwarth@seibert-media.net aufnehmen.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Produktmanagement Lesetipps: Product Owner-Rolle, Kunden- und Anwenderbefragungen, Bereitschaft zu Fehlern, Pretotyping

Nach längerer Pause gibt es wieder einige Leseempfehlungen aus meinem RSS-Reader zu verschiedenen Themen, die für Produktmanager von Bedeutung sind.

Die Rolle des Product Owners

Roman Pichler stellt zwei typische Varianten gegenüber, wie die Product Owner-Rolle besetzt wird: Die Besetzung durch den Kunden selbst sowie eine Besetzung mit einem Proxy. Er schlägt aber auch vor, bei einem größeren Projektportfolio die beiden Varianten zu nutzen, je nachdem, ob nur für einen Kunden oder für eine Vielzahl von Kunden entwickelt wird: „Two common ways to apply the product owner role„.

Hilfreiche Tipps für Kunden- und Anwenderbefragungen

Egal ob Customer Development, Lean Startup oder agile Softwareentwicklung – sie alle empfehlen die aktive Einbeziehung von Kunden und Anwendern. Ein Mittel hierfür ist die Durchführung von Kunden- und Anwenderbefragungen. Zur Durchführung solcher Befragungen gibt es hier zahlreiche Tipps von einem erfahrenen Produktmanager: „How do I set up customer interviews?

Keine Angst vor Fehlern

Im hervorragenden Blog von HackFwd, dem Pre-Seed Investor von Lars Hinrichs, wird die Bedeutung des Scheiterns und des Fehler machen betont. Für die Realisierung von neuen Produkten ist es wichtig, die Bereitschaft aufzubringen, Fehler zu machen und aus ihnen zu lernen: „Fail better„.

Minimale Feedbackschleifen – Pretotyping

Wie kann so schnell wie möglich Feedback vom Markt eingeholt werden, um sicherzustellen, dass nur wirklich Nutzen schaffende Produkte und Features realisiert werden? Der Begriff des Prototyping ist bekannt. Doch auch für so manchen Prototypen wird noch Wochen und Monate gearbeitet.
Alberto Savoia empfielt: „Pretotype it!„. Und stellt auch gleich ein kostenfreies E-Book bereit, in dem er erklärt, wie hierfür vorzugehen ist.

Weitere Ausgaben der Produktmanagement Lesetipps:

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Sprint-Review: Konstruktives Feedback geben, wenn es einmal schlecht läuft

Review / Demo / Sprint-Review / Scrum ReviewDer Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das Scrum-Team in den letzten Wochen geleistet hat und erreichen konnte. Der Product Owner ist gefordert, „seinem“ Team Feedback dazu zu geben, wie er mit den Arbeitsergebnissen zufrieden ist.

Doch wie sollte er damit umgehen, wenn es einmal wirklich schlecht gelaufen ist und das Team bei weitem nicht die Fortschritte erreichen konnte, die gemeinsam geplant wurden?

Dem Team zuhören

Zunächst einmal ist es wichtig, dem Team die Chance zu geben, aufgetretene Hindernisse im Sprint-Verlauf darzulegen. Womöglich waren sie durch größere Ereignisse im Live-Betrieb von der Arbeit am Sprint-Ziel verhindert, haben aber ihr bestes gegeben, das System am laufen zu halten. Dies kann z.B. der Fall sein, wenn ein ungewöhnlich starkes Nutzerwachstum aufgetreten ist, dass sich nicht vorhersehen ließ. Dadurch ändert sich nicht die Situation, dass das Sprintziel nicht erreicht wurde, es ist aber doch ein Unterschied, ob das Team alles gegeben hat und es trotzdem nicht geklappt hat, oder ob die Verfehlung des gemeinsamen Ziels andere Gründe hatte. Womöglich teilt das Team dabei auch wichtige Informationen mit, die dem Product Owner und dem ScrumMaster die Möglichkeit bieten, das Team bei der Erreichung zukünftiger Zielsetzungen zu unterstützen. Damit es dazu kommen kann, muss dem Team aber die Möglichkeit gegeben werden, eine Selbsteinschätzung zu geben.

Die eigene Perspektive erklären

Das Feedback des Product Owners sollte klar und verständlich zum Ausdruck kommen. Das sollte allerdings jederzeit sachlich und konstruktiv erfolgen. Wurde nicht nach den vereinbarten Prioritäten gearbeitet, kann noch einmal herausgestellt werden, warum sie so festgelegt wurden. Wurde einem Stakeholder gegenüber in Abstimmung mit dem Team eine Zusage gemacht, die nun nicht eingehalten werden kann, sollte das auch noch einmal betont werden. Die Konsequenzen des schlechten Sprintverlaufs sollten dargestellt werden. Da der Product Owner die wirtschaftliche Verantwortung für das Projekt trägt, sollte er gerade auch die betriebswirtschaftliche Sicht mit einbringen und die Interessen der Stakeholder vertreten.

Das Ziel nicht aus den Augen verlieren

Ein schlechter Sprint tut weh. Er tut dem Product Owner weh, der die wirtschaftliche Verantwortung für das Projekt trägt. Er tut dem Team weh, das seine selbst gesteckten Ziele nicht erreicht hat. Und auch dem ScrumMaster tut er weh, da ihm eine Menge Arbeit bei der Aufarbeitung bevorsteht.
Aus dieser schmerzlichen Situation heraus sollte das Ziel des Product Owners nicht sein, dass das Team sich noch schlechter fühlt. I.d.R. können sich die Teams auch selbst gut einschätzen und sind selbst unzufrieden, wenn das Sprintziel nicht erreicht wurde. Dennoch sollte er klar darstellen, wie die Erwartungshaltung war und wie das gelieferte Ergebnis sich dazu verhält. Es kann auch anhand eines Release-Burndown-Chart ermittelt werden, wie die Auswirkungen auf den Releasetermin (wenn der Umfang fixiert, das Datum variabel) oder den Releaseumfang (wenn der Umfang variabel, das Datum fixiert ist).

Gemeinsam nach Lösungen suchen

In der Retrospektive besteht noch einmal ausführlich die Möglichkeit, den zurückliegenden Sprint aufzuarbeiten und Verbesserungsmaßnahmen zu erarbeiten. Persönlich habe ich gute Erfahrungen damit gemacht, als Product Owner bei den Retrospektiven des Teams dabei zu sein. Das machen wir allerdings nur, wenn das Team dem zustimmt. Denn für einen offenen Umgang mit Kritik ist eine situative Ermöglichung der Kritik erforderlich. Die Teammitglieder müssen das Gefühl haben, dass sie Fehler offen ansprechen dürfen. Das ist meist eine Frage des Vertrauens.

Fazit

Gerade ein schlechter Sprint zeigt, ob das Team wirklich ein Team ist. Der Product Owner sollte seine Erwartungen und die Erwartungen des Stakeholder klar vertreten. Vertrauen ist die Basis für ein erfolgreiches Team.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: psd

Gastbeitrag bei deutsche-startups: Wie Start-ups Nutzer zu aktivem Feedback motivieren können

NutzerintegrationFür Startups ist das Feedback der Nutzer unheimlich wichtig für die Produktentwicklung. Aber wie motiviert man die Nutzer dazu, auch wirklich Feedback zu geben? Zu dieser Fragestellung ist heute ein Gastbeitrag von mir bei deutsche-startups erschienen. Er basiert (wie auch mein letzter Gastbeitrag bei Gründerszene) auf unseren Erfahrungen aus der Entwicklung von TwentyFeet.

Zum Artikel bei deutsche-startups

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: Von hikingartist

%d Bloggern gefällt das: