Das Problem der jungen Generation:
Als ich ins Berufsleben eintrat (2008, also noch nicht solange her), da gab es noch das Mantra: Love it, Change it, Leave it: Du magst etwas oder findest dich zumindest damit ab, du veränderst es oder du verlässt das Unternhemen. Change it ist heute bei der jüngeren Generation völlig verschwunden. "Weil man es eh nicht ändern kann".
Das habe ich so oft von frustrierten Frührentnern gehört, die dann irgendwann mürrisch etwas von "glücklichen Zufällen" reden mussten, als es doch geklappt hat, etwas zu verändern. Nicht gleich aufgeben!
Wegen deiner Lage: Trau dich mehr! Der Scope eines Sprints soll nicht verändert werden. Nutze einfach deinen Gestaltungsspielraum, du hast mehr davon als du denkst,
Der Sprint ist Sache des Sprintteams, da haben Stakeholder und Product Owner nichts mit am Hut. Versucht die Sprintdauer klein zu halten, vor allem zu Beginn ist kürzer einfach besser. Ich empfehle gerne eine Woche, maximal zwei Wochen. Je öfter ein Team den Sprintzyklus durchläuft umso eingespielter wird es.
Deine Aufgabe als Product Owner ist das Backlog. Das gehört dir. Nicht dem Sprint Team, dem Scrum Master oder den Stakeholdern. Es ist dein Baby :)
Wenn jetzt ein Stakeholder kommt und Anforderungen an dein Produkt stellt ist das sein gutes Recht. Deine Aufgabe ist es die Anforderung aufzunehmen und abzuklären. Das musst du immer machen.
Der knifflige Schritt ist der nächste: Die Entscheidung ob die Anforderung aufgenommen wird und wenn ja, wie sie priorisiert wird. In der Theorie auch deine Aufgabe, in der Praxis wirst du dich da abstimmen müssen. Je nach deinem Standing und der politischen Lage kannst du autonomer reagieren oder eben nicht. Das ist natürlich ein Dilemma, aber weißt du wie man das nennt? Führungskraft!
Kennt jeder im mittleren Management nur zu gut.
Den Tipp mit den 10% Sprintzeit für adhoc-Änderungen halte ich für schädlich. Der Sprint gehört dem Entwicklungsteam und nicht dir. Von vorneherein Zeit freizuhalten sendet auch gleich das komplett falsche Signale: Der Sprintscope ist nicht fix und timeboxing wird auch nicht gelebt.
Den zweiten Tipp mit den Workshops mit relevanten Stakeholdern halte ich für wesentlich besser. Nimm einfach die Anforderungen auf, hinterfrage sie und schätze sie ein. In einem regelmäßigen Meeting kannst du dann allen Stakeholdern die Änderungen bzw. das aktualisierte Backlog vorstellen und darüber diskutieren.
Am Ende hat aber jede Führungskraft (mit wenigen Ausnahmen wie manche CEOs oder Alleineigentümer) das Problem, dass sie nicht autonom entscheiden kann, sondern von allen Seiten Anweisungen/Forderungen bekommt und für einen Interessenausgleich sorgen muss. Das ist vielleicht die wesentliche Aufgabe einer Führungskraft.
antworten