Produktmanagement Lesetipps: Next Feature Fallacy, Erfolgreich Pitchen, Werthaltige Innovation, Software-Architektur, Daily Standup

glasses

Die Lesetipps von heute fassen mal wieder ganz kompakt ein paar Blogartikel über wesentliche Themen des Produktmanagements von Internetanwendungen zusammen, deren Lektüre lohnenswert ist.

 

 

  • „Next Feature Fallacy“: Das kommende Feature wird die Leute dazu bringen, das Produkt zu nutzen? Nein! Häufig ist das nicht der Fall und es ist wichtig, sich darauf zu fokussieren, dass das Grund-Produkt einen guten Value liefert, schreibt Andrew Chen. Den Reiz von neuen Features kenne ich aus der eigenen Backlog-Priorisierung heraus auch sehr gut. Ein guter Reminder, noch einmal die Grundfeste des Produkts zu überprüfen und nicht auf die Zugkraft von neuen Features zu hoffen.
  • Die eigene Idee zu pitchen, ob gegenüber Investoren oder potentiellen Kunden, gehört gerade in der Anfangsphase der Produktentwicklung häufig zum täglichen Brot eines Produktverantwortlichen. Worauf bei einem Pitch geachtet werden sollte, könnt Ihr aus Investorensicht bei Matt Bolton (Bolt Capital) lesen. Sehr schön insbesondere noch einmal der Hinweis, einen relevanten Use-Case vorzuweisen, anstatt lange über Features und Spezifikationen zu sprechen. Am Ende ist es der Nutzen für den Kunden und die Anwender, der entscheidend ist.
  • Bei Innovation geht es um Problemlösung und nicht darum, Ideen zu haben. Und Autor Aaron Shapiro liefert in seinem Beitrag auch gleich noch ein paar Anregungen, wie sich echte Probleme finden lassen.
  • Ein ProductOwner spezifiziert, was und wie es gebaut wird. Kann er auch die Software-Architektur vorgeben? Mike Cohn bejaht diese Frage und schildert Fälle, in denen es auf jeden Fall auch sinnvoll sein kann, dass der ProductOwner entsprechenden Einfluss nimmt.
  • Das Daily Scrum / Daily Standup ist zu viel Zeitverschwendung und sollte automatisiert werden? Mark Levison erläutert, warum weder der erste, noch der zweite Teil zutreffend sind. Die Ziele des „Daily“ sind nur in einem persönlichen Austausch wirklich erreichbar, dafür sollten dann aber auch 15 Minuten ausreichend sein.

 

 

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

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: „Ist das Daily Standup für Teammitglieder zwingend?“
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung „daily scrum“ verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit „Strafen“, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

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

Warum alle Scrum-Meetings wertvoll sind

PDCA-Zyklus oder Demingkreis Ist es denn wirklich erforderlich, alle in Scrum vorgesehenen Meetings durchzuführen? In einem aktuellen Beitrag im Blog von //SEIBERT/MEDIA unter dem Namen „Die Scrum-Meetings und ihre Bedeutung“ habe ich dargelegt, warum alle Meetings, die durch den Scrum-Zyklus vorgegeben werden, sinnvoll sind. Denn erst durch die Ausführung von Sprint-Planungsmeeting, die Daily Scrums, Sprint-Review und Sprint-Retrospektive wird der Demingkreis der kontinuierlichen Verbesserung geschlossen. Eine Vorstellung dieser Meetings und ihrer Bedeutung für den Demingkreis erfolgt in diesem Artikel:

Zum Artikel im //SEIBERT/MEDIA Blog

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

Scrum = Scrum, sagt Ken Schwaber

Immer wieder gibt es Diskussionen darüber, ob Scrum als „reine Lehre“ genommen werden sollte, oder ob auch Modifikationen von Scrum sinnvoll sein können. Da Scrum so häufig nicht vollständig implementiert wird, hat sich mittlerweile der Begriff ScrumBut eingebürgert. Diese Bezeichnung kommt von der Aussage: „Wir nutzen Scrum, aber…“.

Bis zu welchem Maße Modifikationen an Scrum sinnvoll und sogar notwendig sind, ab wann sie aber nicht erwünscht sind, dazu hat Ken Schwaber, einer der Begründer von Scrum, jetzt in seinem Blog Stellung bezogen.

Mehr von diesem Beitrag lesen

Wie reagieren, wenn Scrum als unnötiger Overhead kritisiert wird?

Scrum = Gedränge Wenn für die Entwicklung einer Internetanwendung das Vorgehensmodell Scrum (zu deutsch: Gedränge) zum Einsatz kommt, sind damit im Entwicklungszyklus gewisse Teamaktivitäten verbunden. Gerade für Personen, die bisher keine Erfahrungen mit Scrum-Projekten gemacht haben, können die täglichen Stand-up-Meetings („daily scrum“) und die zum Start von jeder Iteration fälligen Sprint-Planungsmeetings, die zwischen einem halben Tag und einem Tag dauern, zunächst als ein Überfluss an face-to-face-Kommunikation wahrgenommen werden. Dies kann in der Praxis zu einer ernsthaften Kritik an diesem Vorgehensmodell heranwachsen, die den ganzen Projekterfolg gefährdet.

Mike Cohen, Gründungsmitglied der Scrum Alliance und Autor von Agile Estimating and Planning und User Stories Applied: For Agile Software Development, stellt im Blog der Scrum Alliance einige mögliche Gründe für eine solche Kritik dar.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: