Scaled Agile, is het Spotify Model een goed idee ?

[Groeneg2]

Scrum Agile ken ik, echter wat te doen als je 10 scrum teams hebt van elk 7 man? Hoe ga je dit opschalen?

Vraag:
1. Met welke methoden van Scaled Agile hebben jullie ervaring? Wat werkte goed en minder goed?
2. Kennen jullie het Spotify model van Henrik Kniberg & Anders Ivarsson? Wat is jullie ervaring? Werkt dat goed met die Tribes etc. Zie plaatje.

[spijkerhoofd]

Bij de ING en Rabobank gebruiken ze het zelfde principe en daar werkt het goed! Je ziet daar dat devs en ops gescheiden is omdat beide erg complex zijn om in een functie te doen. Veel scrum methodiek zijn overigens gewoon overgenomen zoals sprints, planning en refindmend meetings. Ik weet echter niet of ze precies Spotify’s gekopieerd of dat ze er een eigen draai aan gegeven hebben.

Bedenk wel dat het agile manifest geen methodes voorschrijft maar meer een soort geboden zoals de mens boven procedures!

[ValHallASW]

Welk probleem probeer je op te lossen? Zonder helder te hebben welke problemen je als organisatie tegenaan loopt heeft het weinig zin om naar oplossingen als het Spotify-model (dat overigens nooit als zodanig bij Spotify heeft bestaan) te kijken.

[The Eagle]

De grootste open deur is natuurlijk SAFe, Scaled Agile Framework
Let wel: het is een framework, en zoals met alle frameworks pak je de dingen die je nodig hebt. En zo zijn er meer, zie https://www.nimblework.co...d-agile-frameworks/?amp=1 (leesvoer).

Wat heel veel mensen vergeten is dat scrum / agile in welke vorm dan ook een productie proces is. Het zegt helemaal niks over de personele verantwoordelijkheid / direct reports van managers etc. Daar gaat het ook vaak op mis: managers of projectleiders die PO worden en dan menen dat ze ook de verantwoordelijkheid en leiding over het team hebben

[Groeneg2]

ValHallASW schreef op dinsdag 18 april 2023 @ 19:32:
Welk probleem probeer je op te lossen? Zonder helder te hebben welke problemen je als organisatie tegenaan loopt heeft het weinig zin om naar oplossingen als het Spotify-model (dat overigens nooit als zodanig bij Spotify heeft bestaan) te kijken.

Probleem dat je met meerdere scrumsteams aan het werken bent, hoe coördineer je dat?

[Groeneg2]

The Eagle schreef op dinsdag 18 april 2023 @ 19:48:
En zo zijn er meer, zie https://www.nimblework.co...d-agile-frameworks/?amp=1 (leesvoer).

Vrolijk dat aan het einde deze meneer Spotify buiten spel zet, dat is een persoonlijke mening en doet niets af aan het feit dat het Spotify model terdege wordt gezien als model te gebruiken in een scaled agile situatie.

[NiGeLaToR]

Groeneg2 schreef op donderdag 20 april 2023 @ 17:29:
[...]

Vrolijk dat aan het einde deze meneer Spotify buiten spel zet, dat is een persoonlijke meening en doiet niets af aan het feit dat het Spotify terdege wordt gezien als model te gebruiken in een scaled agile situatie.

Ik vind het zelf ook een heel interessant model, maar begrijp ook dat het model op zichzelf meer mythisch is dan dat het echt in gebruik is bij Spotify.

Wat inmiddels volgens mij een goed raamwerk is, is het SAFe Scaled Agile framework waarin je in principe het spotify model als uitwerking in terug ziet - zoals met elk model is de crux niet het kiezen van het juiste model maar het kiezen van een implementatie die voor jouw organisatie werkt.

De organisaties die zoiets invoerden met als doel het invoeren van zoiets hebben niet zo'n grote kans op succes, als het via zo'n filosofie werken onderdeel van je bedrijfscultuur wordt heeft het volgens mij een grotere kans van slagen.

[The Eagle]

De tribes, guilds en chapters zijn niks anders dan een methode om mensen met een zelfde focus of aandachtsgebied te (kunnen) groeperen, met als doel de onderlinge samenwerking door de organisatie te borgen en van iedereen te kunnen leren.
Zie ook https://achardypm.medium....s-and-guilds-80932ace0fdc wat het wel redelijk uitlegt imho.

Spotify is daarmee begonnen en in de volksmond heet dat het Spotify model, maar eigenlijk is het gewoon een manier om interactie tussen mensen te bevorderen. Doet niks af aan de productie methode (scrum agile) of de rollen / functies van de mensen.

[The Eagle]

Groeneg2 schreef op donderdag 20 april 2023 @ 17:27:
[...]

Probleem dat je met meerdere scrumsteams aan het werken bent, hoe coördineer je dat?

Nogmaals, lees je eens in in SAFe. Als hints: Er zitten meerdere scrum teams met een gelijk aandachtsgebied in een ART, en de scrum master van een ART heet een RTE (release train engineer). De rest mag je zelf lezen

[The Eagle]

Groeneg2 schreef op donderdag 20 april 2023 @ 17:29:
[...]

Vrolijk dat aan het einde deze meneer Spotify buiten spel zet, dat is een persoonlijke mening en doet niets af aan het feit dat het Spotify model terdege wordt gezien als model te gebruiken in een scaled agile situatie.

Wat wil je nou eigenlijk zeggen hier? Je stelt de vraag hoe je scrum kunt opschalen, maar vervolgens stel je dat je het Spotify model zou kunnen gebruiken. Heb je daar dan niet het antwoord op je impliciete vraag?
Als je de bevestiging wilt: nee, die krijg je niet. Zie eerdere opmerkingen: het zijn frameworks, geen modellen die je 1 op 1 overal toepast. Wat Spotify gedaan heeft is simpelweg mensen in groepen indelen, meer niet. Hoe zij agile werken is bij mijn weten een mix van bestaande frameworks en dat wat voor henzelf werkt
Maar knikker dat 1 op 1 bij zeg de NS, een willekeurig ministerie of een reus als Unilever neer en het werkt niet, want andere organisatie.

[Falcon]

@Groeneg2 Zou je ons wat meer kunnen vertellen waarom je deze vraag hier plaatst?

- Is dit van toepassing op je werk?
- Ben je in opleiding?
- Algemene interesse?

Modellen zijn mijn inziens altijd gekaderd en afhankelijk van commitment en menselijke skills/cultuur.

Op basis van de theorie zeg ik volmondig ja, in de praktijk is het afhankelijk van veel factoren. Net zoals met Scrum model, DevOps model etcetra.

Ook ben ik van mening dat de architectuur en implementatie het model moet kunnen ondersteunen. Denk aan CD/CT/CI in het opleverproces en platform ondersteuning.
Maar ook, heb je te maken met een monoliet of super moderne micro-services op een k8s cluster.

Ik vind op dit moment jouw vraagstelling te algemeen.

[ValHallASW]

Groeneg2 schreef op donderdag 20 april 2023 @ 17:27:
Probleem dat je met meerdere scrumsteams aan het werken bent, hoe coördineer je dat?

Dat is nog steeds geen probleemstelling.

Als je tien teams hebt die aan tien verschillende producten werken dan hoef je niet te coördineren.

Als je tien teams hebt die niet met elkaar praten dan gaat een Spotify-model dat niet voor je oplossen (en Safe/LeSS/etc ook niet).

Als het om een organisatie van 100 mensen gaat dan is je antwoord vermoedelijk anders dan in een organisatie van 10000 mensen.

Verschillende organisatiemodellen lossen verschillende problemen op, en zolang je niet zelf helder hebt welke problemen je op probeert te lossen wordt het puur cargo culten.

[ZieMaar!]

Inderdaad, als die scrumteams aan hetzelfde product of waardestroom werken wil je schalen en dan ligt
SAFe wel voor de hand. De po op het totaal is dan een pm, de sm een rte en er zijn manieren voor prioritering ed uitgewerkt. Ik heb veel ervaring met dit model, maar specifieke vragen helpen dan wel .

[Shivs]

Vanuit wat ervaring binnen de overheid kan ik zeggen dat SAFe daar populair is voor het schalen van Scrum. Echter heeft mij dat ook direct geleerd dat je SAFe vaak ziet als een vlucht terug naar het oude. Waar organisaties (in mijn ervaring overheid) moeite mee hebben is dat bij Agile ontwikkeling ze minder vat hebben op wat, wanneer af is. Door SAFe te implementeren proberen ze dat dan weer terug te krijgen, want een bepaalde feature zit in een PI dus kan je er een datum aan hangen.

Als het probleem dat je probeert op te lossen komt vanuit deze hoek, dan zou ik niet beginnen aan een scaled Agile framewerk. Voornamelijk omdat je dan het stuk Agile los laat en alleen in naam nog zo werkt. De sturing van bovenaf is dan je eigenlijke probleem dat opgelost moet worden.

[The Eagle]

Naja,l SAFe en Agile (en scum ook ) in het algemeen gaan uit van een mentaliteit van relentless improvement enzo. Oftewel de intrinsieke drive bij de teams om steeds maar beter te worden. Nofi, maar dat is nou niet de mentaliteit die je bij een gemiddelde ambtenaar verwacht

Daarbij, nogmaals: SAFe en andere Scrum / Agile frameworks gaan over een productieproces, niet over de aansturing van de mensen. Het legt een laag op de organisatie. Een bepaalde rol in het productieproces kan door iedereen vervuld worden, zonder dat ze daarbij mensen aan hoeven te sturen cq personele verantwoordelijkheid hebben. Maar dat gaat er ook bij heel veel mensen niet in, die zijn directe aansturing / verantwoordelijkheid gewend. terwijl het framework juist uitgaat van zoveel mogelijk verantwoordelijkheid zo laag mogelijk leggen (dus bij de teams).