zx
Die forensische Produkt-Backlog-Analyse: Eine 60-minütige Teamübung um Ihr Produkt-Backlog zu fixen. Identifizieren Sie, was kaputt ist, finden Sie heraus, warum, und einigen Sie sich auf praktische Lösungen – alles in fünf schnellen Schritten. Ohne Schnickschnack, nur Ergebnisse.
Sie wollen technische Exzellenz leben und Kundenprobleme lösen? Beginnen Sie mit einem soliden Produkt-Backlog.
Das Schicksal der Feature Factory ist nicht unausweichlich. Es gibt Hoffnung, um zu verhindern, dass Sie nur ein Rädchen im Getriebe werden. Erfahren Sie wie!
In vielen großen Unternehmen geraten Scrum-Teams in die “Feature Factory”-Falle und konzentrieren sich mehr auf die Produktion von Funktionen als auf die Schaffung echter Werte. Schade, dass diese Entwicklung agile Prinzipien untergräbt und den langfristigen Erfolg und die Innovation gefährdet. Lassen Sie daher uns erörtern, wie und warum dies geschieht und was wir tun können, um die Fesseln der Feature Factory zu sprengen.
Einige Product Owner glauben, dass ein umfassendes Produkt-Backlog der beste Weg ist, um das Produktziel zu erreichen und gleichzeitig völlig transparent zu sein – und keine möglicherweise wertvolle Idee ungenutzt zu lassen. Ein umfassendes Backlog kann jedoch schnell zu einem kompletten Produkt-Backlog mit unbeabsichtigten Nebeneffekten werden.
Erfahren Sie mehr über die negativen Auswirkungen eines kompletten Produkt-Backlogs auf Innovation, die Fähigkeit Ihres Scrum-Teams, Werte zu schaffen, und Ihre Beziehung zu den Stakeholdern.
In Scrum planen wir viel: Es gibt einen täglichen Plan, wenn die Entwickler während des Daily Scrum darüber nachdenken, wie sie heute dem Sprint-Ziel näher kommen können. Natürlich spiegelt das Sprint-Ziel selbst ein größeres Etappenziel wider, das das Scrum-Team für wertvoll hält, um die Probleme seiner Kunden zu lösen. Außerdem gibt es das noch Produkt-Ziel, ein mittel- oder langfristiges Ziel des Scrum-Teams.
Das Problem ist, dass Scrum-Teams, die das Konzept des Sprint-Ziels noch nicht verinnerlicht haben — zuerst einigt sich das Team auf das Sprint-Ziel, dann wählen die Entwickler die Arbeit aus, die sie als notwendig erachten, um dieses Ziel zu erreichen — höchstwahrscheinlich auch mit geeigneten Produkt-Zielen kämpfen werden.
Schauen wir uns drei kritische Probleme an, die Scrum-Teams mit Produkt-Zielen haben, und ein praktisches Tool, das Ihnen hilft, das Durcheinander zu vermeiden.
Als taktisches Framework ist Scrum gut geeignet, um Inkremente in die Hände der Kunden zu übergeben. Da wir in Iterationen arbeiten, tun wir das wahrscheinlich mehrmals im Monat und mindern das Risiko, indem wir Feedbackschleifen schließen. Dennoch gibt es eine potenziell gefährliche Lücke im Framework, die erfolgreiche Scrum-Teams schon früh zu schließen beginnen: Die Frage, wie man herausfindet, was es wert ist, überhaupt gebaut zu werden oder: Produktentdeckung. Infolgedessen ist die Wertschöpfung in Scrum nicht so einfach, wie Sie vielleicht gedacht haben.
Entgegen der landläufigen Meinung hat der Product Owner keine diktatorischen Befugnisse, was die Zusammensetzung und Reihenfolge des Produkt-Backlogs angeht. Stattdessen basiert Scrum auf einem ausgeklügelten System von Checks & Balances, Zusammenarbeit und gemeinsamer Entscheidungsfindung, um das Risiko zu mindern, dass sich der Product Owner in seine Lösung verliebt und nicht in das Problem des Kunden. Erfahren Sie mehr über die wichtigsten Produkt-Backlog Prinzipien: Von der Größe und dem Wachstum des Produkt-Backlogs bis hin zur Frage, ob ein Produkt-Backlog überhaupt notwendig ist. (Einige Lean-Experten bestreiten, dass dessen Existenz gerechtfertigt ist.)
Es gibt ein Produkt, einen Product Owner, ein Product Backlog – eine einfache Regel. Wie soll das skalieren, könnte man fragen, wird der Product Owner dadurch nicht zum Engpass des Scrum-Teams, der die Wertschöpfung behindert, statt sie anzuführen? Nun, Cargo-Cult-Scrum könnte in der Tat in dieser Sackgasse enden. Der Trick, um dieses Schicksal zu vermeiden, besteht darin, das Entwicklungsteam so früh wie möglich in das Product Backlog Management einzubeziehen, um die Produktdenkweise zu fördern.
Erfahren Sie mehr darüber, wie Sie diesen Prozess mit einem einführenden eintägigen Workshop über die Produktdenkweise für Ihr Scrum-Team anstoßen können.
Ein großartiger Scrum Master dient nur einem Scrum Team – das ist zumindest eine beliebte Wahrnehmung in der Scrum-Gemeinde. Dennoch gibt es auch Stimmen, die an dieser Interpretation der Scrum Master Aufgaben zweifelt: Was würde man den ganzen Tag tun – mit einem einzigen Scrum Team? Sollte das Team sich mit der Zeit nicht selbst organisieren? Und wenn ja, braucht das Scrum-Team dann rund um die Uhr einen Scrum Master?
Da ich jahrelang als Product Owner in Scrum Teams ohne einen dedizierten Scrum Master gearbeitet habe, was gut funktionierte, war ich neugierig, ein Antwort auf diese Frage zu finden. Deshalb habe ich von Ende Juni bis Anfang Juli 2018 eine Umfrage durchgeführt, deren Ergebnisse hier vorgestellt werden.
Insgesamt nahmen in den zwei Wochen vor dem 5. Juli 2018 261 Scrum Masters an dieser nicht repräsentativen Umfrage teil. 19 Teilnehmer der Umfrage beschlossen, der Verarbeitung ihrer Daten durch Google nicht zuzustimmen. Daher wurden ihre Beiträge gelöscht, was zu einer Stichprobengröße von 242 Antworten führte.
