Jutta Eckstein berät seit 1998 vor allem große Firmen und begleitet sie auf ihrem Weg zu mehr Agilität. Während des Retrospective Facilitatörs Gathering 2016 in Sagres habe ich ein Gespräch mit ihr aufgezeichnet.

Ein Ausflug der agilen Produktentwickler in die Welt der Philosophie, nicht anderes kann man erwarten, wenn Patrick Breitenbach vom Soziopod zu Gast ist im Agilen Produktmanagement. Anlass war ein Treffen beim Soziopod Live Event in Hamburg, bei dem mir bewusst geworden ist, wie gut Poppers kritischer Rationalismus auf agile (oder "lean") Produktentwicklung passt. Diese Episode ist also als Einwurf zu verstehen, oder wie gesagt als Ausflug, nicht aber ohne konkrete Hilfestellungen im Alltag des Product Owners zu entwickeln.

Corinna Baldauf ist zu Gast. Sie ist bekannt durch den Retromaten, ein Tool zur leichteren Gestaltung von Retrospektiven, und hat alle Rollen der agilen Welt durchlebt. Gemeinsam betrachten wir, was eine agile Transition ist, warum der Begriff "Transition" eigentlich irreführend ist, und was dies für den Product Owner bedeutet.

Bernd Schiffer hat noch ein paar weitere Ansätze, wie agile Skalierung (Scaling Agile) in Unternehmen funktionieren kann, die im ersten Teil nicht drangekommen sind. Das schließen wir heute ab. Spannend am Ende die Frage: für wen ist Scaling Agile eigentlich eine Herausforderung? Denn: sobald man bei diesem Problem angekommen ist, sollten vorher eine ganze Reihe anderer Probleme (allgemeiner Entwicklungs-Workflow, Agil im Kleinen) gelöst sein, so dass die Skalierung gar nicht mehr so schwierig sein sollte.

Die meisten Veröffentlichungen zu Scrum, Kanban und anderen agilen Methoden konzentrieren sich auf die Situation mit genau einem Team. Dabei ist der Übergang zu agilen Methoden mit mehreren Teams alles andere als trivial, gerade für den oder die Product Owner. In dieser Episode erklärt Bernd Schiffer, was man hierzu alles machen kann. Bitte beachtet die Shownotes für Links und weitere Informationen. Wenn genügend Wünsche eintrudeln, dass wir die wegen Audio-Breakdown übersprungenen weiteren unstrukturierten sowie ganz neuen Modelle auch noch besprechen, machen wir einfach eine weitere Episode.

In dieser Episode geht es um elektronische und physische Taskboards (nicht etwa physikalische, wie ein verwirrter Podcaster behauptet). Was macht man mit Boards, wie viele Spalten braucht man, und was ist dieser Schneepflug?

In dieser Episode geht es um das Thema "Schätzen". Projektbeteiligte, vor allem die Auftraggeber, haben immer ein berechtigtes Interesse daran zu erfahren, wann etwas bestimmtes "fertig" ist. Dabei ist es wirklich nicht leicht in die Zukunft zu schauen, um das Fertigstellungsdatum eines Features oder gar eines ganzen Produktes zu schätzen. Also was tun? Die agile Welt schätzt Story Points, aber warum? Dazu einiges zum Einstieg in dieser Episode, dessen Fazit ist: erstellt nur solche Schätzungen, anhand derer Ihr auch wirklich Entscheidungen trefft.

Heute geht es endlich um das, was wir schon so oft erwähnt haben: das Backlog in all seinen Ausprägungen und die User Stories, die sich häufig darin befinden. Das von mir gewählte Beispiel der Schiebetür am Auto ist zwar etwas spontan und albern, abstrahiert aber vielleicht gut genug davon, was wir ITler so im täglichen Job erleben.

Das erste non-essential in der Reihe Scrum Essentials: das Backlog Grooming gehört nicht wirklich zu den Pflicht-Meetings im Scrum Zyklus. Dennoch ist es ein sehr wertvolles Mittel, um das Product Backlog zu pflegen. In dieser Episode erklären wir, was das für ein Meeting ist, wie man es durchführt, was die Ziele sind, und was schiefgehen kann.

In Scrum gehört nach jedem Sprint eine Retrospektive in den Zeitplan. In diesem Meeting wird reflektiert, wie der vergangene Sprint gelaufen ist, was gut war, was verbessert werden kann, wie Stärken gestärkt und Schwächen ausgebügelt werden können. Natürlich ist diese Methode weder eine Erfindung von Scrum, noch auf Scrum beschränkt. Wie man es machen kann, warum man es tut, was der Product Owner dabei zu tun hat, und nicht zuletzt was alles schiefgehen kann hört Ihr in dieser Episode.

Nach dem Sprint ist vor dem Sprint. Im Sprint Review Meeting stellt das Team das Sprint Ergebnis vor. Der Product Owner überprüft das Ergebnis und entscheidet, welche Stories fertig sind, wobei das Team optimalerweise bereits vorher weiß, was Sache ist. Dann können die Stake Holder Stellung beziehen, Feedback geben und Fragen stellen. Gemeinsam wird am Ende geprüft, ob der aktuelle Plan noch richtig und gut ist.