LeSS zwingt den Product Owner, seinen Fokus auf die Priorisierung zu legen und die Klärung von Details zu delegieren! Noch klarer bringt es unser Gast Eike Gehler auf den Punkt: “Prioritization over clarification”. Eike ist erfahrener Agile Coach und langjähriger Scrum Master – v.a. bringt er aber sehr viel Erfahrung in sehr großen und skalierten Kontexten mit ins Gespräch ein.
Er mag keine Blaupausen und mag am Liebsten zusammen mit den Organisationen die er begleitet herausfinden, welcher Skalierungsansatz im jeweiligen Kontext der geeignete ist. Dabei bedient er sich aufgrund seiner Erfahrung gerne im “Baukasten” verschiedener Skalierungs-Frameworks und -Modelle. Dennoch hat er einen Favoriten: das Framework LeSS – kurz für “Large-Scale Scrum”. Dennoch betont Eike Gehler, dass die entscheidende Frage der Produkt-Kontext sei, in dem das Skalierungsvorhaben stattfindet.
Tim beleuchtet zusammen mit Eike zunächst dessen eigene Weg in die Agilität sowie seine aktuellen Wirkungskreise in oft großen Organisationen. Zusammen rätseln die beiden, warum das sogenannte “Spotify”-Modell (oder zumindest die dort genannten organisatorischen Formate) derzeit so viele Nachahmer hat. Warum muss jetzt plötzlich alles Squad, Tribe, Gilde usw. heißen? Warum legen Organisationen soviel Hoffnung in diese Organisationsmuster, obwohl dies von Henrik Kniberg und Anders Ivarsson, die damals bei Spotify die Transformation begleiteten, nie als Skalierungs-Framework gemeint war. Tim stellt die These auf, dass “Spotify” derzeit sogar SAFe den Rang abläuft.
Tiefer geht es dann um das LeSS-Framework. Hier wird vieles reduziert: für bis zu sieben Feature-Teams ist dort nur EIN Product Owner und nur EIN Product Backlog (innerhalb einer Area) vorgesehen. Eike erklärt zunächst den Begriff des Feature-Teams und wie schwer es oft ist, für diese Idee in großen, bislang silo-artig organisierten Unternehmen Befürworter zu finden. Aber wenn es nur einen Product Owner in LeSS gibt – wie verhält es sich dann mit den Scrum Mastern? Wie viele Scrum Master sind z.B. in einer Area mit fünf Feature Teams sinnvoll?
Im letzten Teil geht es nach dieser Herleitung dann ganz konkret um diese Product Owner Rolle in LeSS und welche Herausforderungen sie mit sich bringt. Eike Gehler gibt in diesem Zuge auch noch wertvolle Tipps für Menschen, die als Product Owner in LeSS arbeiten.
Quellen zum sog. “Spotify-Model” und LeSS
Im Gespräch beziehen wir uns auf die folgenden Quellen:
- Die damalige Beschreibung von Henrik Kniberg und Anders Ivarsson der Skalierung bei Spotify… die dann als “das Spotify-Model” (miss)verstanden wurde.
- Spotify Engineering Culture, dieses Video wird üblicherweise als Video über das “Spotify-Model” referenziert
- Henrik Kniberg: No, I didn’t invent the Spotify model
- Heutige Sicht von Henrik Kniberg auf Scrum@Scale im Vergleich zum “Spotify-Model”
- Die offizielle Beschreibung von LeSS mit allen Details, die ihr über das (De)Skalierungs-Framework LeSS wissen müsst
Wenn ihr mit Eike in Kontakt treten wollt, freut er sich über eure Nachricht auf folgenden Kanälen:
Eike GehlerMail : eike@aykey.de, LinkedIn oder Web
Telefon: 089 208044440
Im Zusammenhang mit dieser Episode ist auch die Folge 41 rund um Skalierung empfehlenswert:
- Product Owner im skalierten Umfeld mit Björn Schotte
Welche Herausforderungen erlebt ihr selbst als Product Owner in LeSS oder Ansätzen die sich an das Spotify-Model anlehnen? Wir freuen uns, wenn du deine eigenen Erfahrungen mit uns in einem Kommentar teilst, entweder hier oder auf unserer Produktwerker LinkedIn-Seite.
