Scrum Master / Product Owner --> doorgroei?

[praet0rian]

Hi,

Ik zit met een dilemma / luxeprobleem.

Momenteel ben ik werkzaam binnen een operationele afdeling van een bedrijf, als manager van een team binnen de klantendienst.

Ik heb aangegeven dat ik eerder binnen de IT-afdeling verder wil, en men heeft mij de functie van Product Owner (van materie waar ik nu reeds in zit) of Scrum Master aangeboden.

Het gaat om horizontale doorgroei, dus behoud van salaris en dergelijke.

Ik ken de verschillen tussen beide functies, maar ik kan voorlopig nog geen keuze maken.

Bij PO kan ik mijn technische kennis meenemen en gebruiken, maar dan zit ik in een heel technisch/uitvoerende rol. Vandaag als manager sta ik hier wat verder vanaf en zit minder in het uitvoerende.

Bij SM kan ik mijn coachende & faciliterende kwaliteiten gebruiken, maar sta ik ver van het inhoudelijke.

Voor zij die er al bekend mee zijn, kunnen jullie zeggen welke functie het meeste (verticale) doorgroei kent?

De eindbeslissing zal ik uiteindelijk moeten maken :-).

[Phyrozi]

Product Owner. Meer stakeholdermanagement tussen product, team en business. Meer verticale exposure en eindverantwoordelijk. SM's moeten vaak nog door PO heen om verticaal te groeien.

Dat gezegd hebbende, SM is een relatief lichte rol.

[Piet_Piraat7]

Ik denk dat dat sterk verschilt per bedrijf. Bij ons bedrijf is SM vaak een doorgroei rol richting teammanager / RTE.

[SmurfLink]

Het is meer wat je zelf graag wil doen. Zoals je al zegt, PO heb je meer met je kennis maar minder faciliteren, je gaat meer op de inhoud van de materie in. SM gaat meer in op de inhoud van het team en de onderlinge interacties. Ligt jouw interesse meer bij de techniek of bij het proces?

[Freeaqingme]

Is het echt een full time keuze? In ervaren zelfstandige teams is de rol van Scrum Master vaak een parttime rol. Daarnaast is mijn ervaring dat ook als sm je echt wel je technische kennis kan inzetten, bijvoorbeeld als een dev meldt dat X zwaar uit gaat lopen om dan ook mee te sparren wat voor technische oplossingen er allemaal te bedenken zijn om de planning te redden zonder al te veel af te doen aan de scope, etc.

Qua doorgroei hangt het heel erg af van het bedrijf waar je zit. In de bedrijven waar ik actief geweest ben maakt het allemaal niet zo veel uit, en kan je met alles altijd nog alle kanten op. Ik kan me daarbij wel voorstellen dat als product owner je wat meer in de producthoek blijft hangen terwijl je als scrum master wat meer de manager kant op gaat. In sommige (grotere) bedrijven is dat laatste op lange termijn vaak lucratiever, vrees ik.

[Tylen]

SM is toch een bijrolletje? Niet echt een functie wat je als doorgroei moet zien. Meer een downgrade.

[Azer]

Tylen schreef op zaterdag 13 mei 2023 @ 14:35:
SM is toch een bijrolletje? Niet echt een functie wat je als doorgroei moet zien. Meer een downgrade.

Dat verschilt heel erg per bedrijf en ligt aan het team of de teams waarin je terecht komt. Bij sommige bedrijven neemt één van de developers in he team de rol van Scrum master. Bij andere bedrijven is er een dedicated Scrum master voor één of meerdere Scrum teams.

Doorgroeimogelijkheden zijn voor een product owner vaak beter dan voor een Scrum master. Van de positie van product owner is het een stuk makkelijker om door te groeien naar een functie met meer verantwoordelijkheid.

[Hydra]

Ik zou absoluut afraden voor een 'scrum master' functie te gaan. In de meeste gevallen is het bestaan van full time scrum master rollen een indicatie dat het bedrijf weinig van agile snapt. Als een bedrijf agile 'goed' gaat doen, gaat er steeds minder werk zijn voor een scrum master.

Als PO heb je nog doorgroei mogelijkheden naar product manager (die staat itt tot PO boven meerdere teams), 'head of product' en soortgelijke rollen mogelijk zijn.

[Voor 11% gewijzigd door Hydra op 13-05-2023 15:34]

[Hydra]

Tylen schreef op zaterdag 13 mei 2023 @ 14:35:
SM is toch een bijrolletje?

Als het goed is wel. In veel gevallen roterend, of iets dat door een vrij junior persoon wordt gedaan. Full time SM rollen zie je eigenlijk alleen bij bedrijven waar agile 'niet goed' gaat.

[Hahn]

Tylen schreef op zaterdag 13 mei 2023 @ 14:35:
SM is toch een bijrolletje? Niet echt een functie wat je als doorgroei moet zien. Meer een downgrade.

Hydra schreef op zaterdag 13 mei 2023 @ 15:34:
[...]

Als het goed is wel. In veel gevallen roterend, of iets dat door een vrij junior persoon wordt gedaan. Full time SM rollen zie je eigenlijk alleen bij bedrijven waar agile 'niet goed' gaat.

Deze reacties zijn op het trollende af

Als je een Scrum Master nodig hebt die voor 1 team 40 uur per week werkt, dan heb je inderdaad een probleem. En in mijn ervaring kan een goedlopend team prima werken met een teamlid die de SM-taak als bijrol neemt.

Maar Scrum Masters hebben die enkel en alleen Scrum Master zijn, maar dan voor meerdere teams, heeft wat mij betreft sterk de voorkeur ten opzichte van 1 teamlid z'n aandacht te laten verdelen.

Dat gezegd hebbende, de doorgroeipotentie van een Product Owner is volgens mij vele malen groter dan die van een Scrum Master. Mede door deze 'ach joh, SM laat je gewoon iemand even erbij doen'-insteek die veel mensen hebben.

[Furion2000]

@Phyrozi Zegt het eigenlijk al, die exposure van een PO is vele male groter en je leert skills die bruikbaarder zijn voor management rollen.

Dat gezegd hebbende, SM is vaak ook een tussenstap voor management rollen. Als je die rol goed vervult kun je in de juiste situatie ook goed doorgroeien.

Als SM heb je zoals je al kunt lezen, aardig te maken met wat geringschattende meningen. Ik was zo ook, ik ben SM en denk er nog steeds zo over. De scrum SM taken doe ik heel weinig en zoals @Hydra dat zegt moet dat ook weinig tijd kosten, want anders doe je iets niet goed. Wat ik er wel van mee pak en wat ik stiekem wel erg leuk vind is de leiding nemen bij meetings, aanspreekpunt zijn voor problemen en die delegeren of direct oppakken en toch wel een vinger in de pap hebben op een iets hoger niveau (e.g. nieuwe medewerkers, weten wat er speelt). Vooral dat stukje leiding geven is heel gek, waar je normaal feedback kreeg op elke beslissing en wat vaker complimenten, maak je nu keuzes en lijkt het alsof je geen feedback krijgt. Af en toe voelt het als een of andere dictator.

Anderszijds wringt het soms wel dat ik mijn werk niet af krijg als er weer iets bruins tegen die ventilator aan vliegt

PO dus...

[Tylen]

Hahn schreef op zaterdag 13 mei 2023 @ 15:43:
[...]


[...]

Deze reacties zijn op het trollende af

Als je een Scrum Master nodig hebt die voor 1 team 40 uur per week werkt, dan heb je inderdaad een probleem. En in mijn ervaring kan een goedlopend team prima werken met een teamlid die de SM-taak als bijrol neemt.

Maar Scrum Masters hebben die enkel en alleen Scrum Master zijn, maar dan voor meerdere teams, heeft wat mij betreft sterk de voorkeur ten opzichte van 1 teamlid z'n aandacht te laten verdelen.

Dat gezegd hebbende, de doorgroeipotentie van een Product Owner is volgens mij vele malen groter dan die van een Scrum Master. Mede door deze 'ach joh, SM laat je gewoon iemand even erbij doen'-insteek die veel mensen hebben.

Nope niets trollends. Maar eigenlijk zeg jij hetzelfde toch . Alleen iets genuanceerder.

[retoohs]

praet0rian schreef op zaterdag 13 mei 2023 @ 01:36:
Bij PO kan ik mijn technische kennis meenemen en gebruiken, maar dan zit ik in een heel technisch/uitvoerende rol. Vandaag als manager sta ik hier wat verder vanaf en zit minder in het uitvoerende.

Een PO rol zou ik echt niet technisch uitvoerend noemen. Je hebt wel kennis nodig van het product en de context maar de gemiddelde PO snapt de ballen van de technische details. Logisch want het is ook niet nodig in die rol.

[Hahn]

Tylen schreef op zaterdag 13 mei 2023 @ 16:56:
[...]

Nope niets trollends. Maar eigenlijk zeg jij hetzelfde toch . Alleen iets genuanceerder.

Een flink grote en belangrijke nuance. Wat jij zei is een beetje alsof je zegt dat je niet fulltime een schoonmaker kan zijn, omdat je na X uur één huis wel helemaal schoon hebt, en je dan geen werk meer hebt.

[pingkiller]

De term Product Owner wordt tegenwoordig voor zo'n beetje alle functies gebruikt waar inhoudelijke verantwoordelijkheid wordt gedragen. Soms is het zo erg dat ze de term manager gewoon vervangen hebben door product owner, vermoedelijk omdat ze denken dat het hipper klinkt.

Daarom is het wat lastig hier een gesprek over te voeren, iedereen heeft misschien weer een ander beeld bij PO.

[rob_erwt]

Scrummaster met technische achtergrond hier.

Doorgroeimogelijkheden voor een PO die ik vaak zie is een beetje het volgende rijtje:

• PO: verantwoordelijk voor een (deel)product/feature, meestal 1 development team
• Senior PO / Product Manager: verantwoordelijk voor een groter product of productlijn, meestal meerdere development teams
• Head of Product: verantwoordelijk voor het gehele product pakket van de organisatie en/of afdeling, vaak ook lijnmanagement van de PO's
• (doorgroei naar VP of CXO- achtige functies)

Voor een Scrummaster is het verticaal idd wat magerder:

• SM: verantwoordelijk voor 1 of 2 teams
• Senior SM: verantwoordelijk voor 2 a 3 teams en vaak coachende rol richting andere SM's

Daarna hangt het af van je eigen ambities omdat ik meestal twee richtingen zie:

• Meer proces gerelateerd: Agile Coach. Dus meer op strategisch niveau bezig zijn met de processen. Endgame zou beetje in de COO hoek zitten.
• Meer techniek gerelateerd: Technisch coach of tech-lead. Dan ben je meer bezig met de technische aspecten. Endgame hier zit uiteindelijk meer in de CTO hoek.

Ik zal ook een beetje in gaan op de percepties van de rol/functie van scrummaster hier. Allereerst: SM is geen entry-level positie. Een goede SM heeft simpelweg ervaring nodig om haar/zijn werk goed te doen. Dat kan technische ervaring zijn (wat ik persoonlijk denk dat het beste is), maar kan ook meer algemene ervaring zijn. Zolang je maar een goed gevoel hebt bij hoe mensen werken, wat processen voor invloed hebben op het werk en de nodige organisatie sensitiviteit hebben.

Als je de rol van scrummaster alleen ziet als de secretaris van het team (beetje meetings plannen, voorzittertje spelen en de metrics bijhouden) dan is het idd geen fulltime rol en doe je sowieso geen recht aan de mogelijkheden die de rol kunnen bieden. Een korte opsmming van ik zoal die binnen mijn functie. Onze afdeling bestaat uit 35 man, waaronder rond de 18 developers verdeelt over 4 development teams. De hele organisatie bestaat uit ongeveer 1000 mensen.

• Scrummaster voor 4 teams (ja, dat is teveel, maar budget...)
• In de gaten houden of belangrijkste meetings gehouden worden (eventueel zelf organiseren)
• Het belang van metrics onder de aandacht brengen en helpen hier ook wat mee te doen
• Coach/mentor zijn op het gebied van agile processen (Scrum natuurlijk, maar eventueel ook Kanban, DevOps, etc)
• Op hoofdlijnen up to date blijven over de ontwikkelingen in het vakgebied (ook qua development) zodat ik op het juiste moment dingen kan aandragen in de teams
• Zorgen dat inter-team communicatie op gang blijft
• (Coachende) gesprekken met de developers (niet qua persoonlijke ontwikkeling of lijnmanagement, daar hebben we de Teamlead voor)
• Met de Teamlead sparren over wat er speelt en waar we eventueel op in moeten springen
• Klankbord en coach voor de PO's zijn
• Onderdeel van het afdelings MT met als aandachtspunt de processen (duh...)
• Mede-organiseren van hackatons en kwartaalupdates of andere grotere events

Heb ik hier een dagtaak aan? Ja, ruim... Dat is mede omdat het 4 development teams betreft, maar ook met 2 of 3 teams zou dat ruim lukken. Op dit moment laat ik de rest van de organisatie nog liggen terwijl daar ook wel het nodige zendelingen werk op agile gebied plaats zou kunnen vinden.

Misschien dat ik meer als een Agile Coach ofzo opereer, maar op mijn loonstrook staat toch echt Scrummaster. En dat is ook gelijk een mooie afsluiter: iedere bedrijf beschouwt de functie van PO of SM op een eigen manier. Het is dus altijd goede zaak om helder te hebben wat men van je verwacht in die functie. De titel op zich zegt wel iets, maar vertelt niet het hele verhaal.

[Tylen]

Nouja mijn ervaring met een sm (bij enterprises, denk aan +100K werknemers) is dat ze alleen maar de daily standup leiden en geen technische kennis hebben. Zelfsturende groepen ftw.

[Hydra]

Hahn schreef op zaterdag 13 mei 2023 @ 15:43:
Maar Scrum Masters hebben die enkel en alleen Scrum Master zijn, maar dan voor meerdere teams, heeft wat mij betreft sterk de voorkeur ten opzichte van 1 teamlid z'n aandacht te laten verdelen.

Dat is ruk. Dan heb je als teams meteen niet de flexibiliteit wat betreft het plannen van meetings omdat je rekening moet houden met de andere teams van de scrum master.

Het kost een teamlid echt nauwelijks tijd als een organisatie goed werkt. In m'n huidige team hebben we nieteens een SM rol. Guess what; alle retro's e.d. worden toch georganiseerd. Als je een SM nodig hebt om mensen achter de broek aan te zitten zegt dat veel over je organisatie.

Ik heb meerdere malen in teams gewerkt met wel full time scrum masters en die gingen meestal hard op zoek naar 'extra' werk omdat ze, ook met bijv. 2 teams, eigenlijk weinig te doen hadden. En meer dan 2 teams werkt eigenlijk niet, want dan kom je hard in de problemen met je meeting tijden.

[Hydra]

rob_erwt schreef op zondag 14 mei 2023 @ 10:17:
Scrummaster voor 4 teams (ja, dat is teveel, maar budget...)

Om dit maar even aan te halen; dan ben je als scrum master dus al compleet verkeerd bezig. Er is no way dat je vooral in teambelang handelt als je 4 teams hebt. Alleen het gedoe met het plannen van de stand-ups e.d. is al een mega pain in the ass.

Ik vind je "het belang van metrics" overigens iets dat je wel uit mag leggen want oh wee als je aankomt met dat die burndown graph relevant is

[Voor 15% gewijzigd door Hydra op 15-05-2023 09:02]

[Hydra]

Tylen schreef op zondag 14 mei 2023 @ 13:14:
Nouja mijn ervaring met een sm (bij enterprises, denk aan +100K werknemers) is dat ze alleen maar de daily standup leiden en geen technische kennis hebben. Zelfsturende groepen ftw.

In de basis faciliteer je de scrum ceremonies. Stand-up, retro, etc. Maar daar gaat in een mature team echt nauwelijks tijd inzitten. Vaak zie je dat full time scrum masters daarom maar allerhande andere zaken erbij gaan zoeken om toch wat te doen te hebben. Want eens in de twee weken bedenken welk retro format we gebruiken kost niet zoveel tijd.

Ik werk nu al meer dan 10 jaar in verschillende organisaties in verschillende scrum verhoudingen (voordeel als 'externe' is dat je veel bedrijven van binnen ziet) en full time scrum masters is wat mij betreft een rode vlag dat er iets mis is in de organisatie.

Niks ten nadele van mensen die dit werk doen natuurlijk; het is niet hun schuld dat veel bedrijven het niet snappen.

[Hydra]

Hahn schreef op zaterdag 13 mei 2023 @ 17:36:
Een flink grote en belangrijke nuance. Wat jij zei is een beetje alsof je zegt dat je niet fulltime een schoonmaker kan zijn, omdat je na X uur één huis wel helemaal schoon hebt, en je dan geen werk meer hebt.

Een schoonmaker is geen onderdeel van een team waarbij hij dan moet zeggen "sorry team C, de stand-up kan niet naar 9:30 omdat ik van 9 tot 11 al meetings heb met team A en B". Die vergelijking gaat volkomen mank.

[Hydra]

Furion2000 schreef op zaterdag 13 mei 2023 @ 16:35:
Wat ik er wel van mee pak en wat ik stiekem wel erg leuk vind is de leiding nemen bij meetings, aanspreekpunt zijn voor problemen en die delegeren of direct oppakken en toch wel een vinger in de pap hebben op een iets hoger niveau (e.g. nieuwe medewerkers, weten wat er speelt).

En dat is dus het gevaar; je ziet dat veel SMs dit soort dingen gaan proberen. De 'leiding' nemen in dingen. Terwijl dat niks met de scrum master rol te maken heeft; dat is echt puur een faciliterende rol. Dit is niet aan jou gericht (ik weet niet hoe je je werk doet) maar ik heb dit zien gebeuren bij niet-technische full time scrum masters. En dat werkt echt niet in een software team. Ten eerste snappen ze te weinig van de materie, ten tweede zijn ze niet de business 'owner' (dat is de PO) en ten derde conflicteert dat met het feit dat je als SM een 'peer' bent en niet iemand's manager.

Het heeft daarom meerdere voordelen een SM rol bij een junior te leggen. Ze zijn minder duur, ze hebben minder de neiging om een 'delegerende' rol op zich te nemen die niet bij de SM rol hoort, en het is bovendien een mooie learning experience omdat ze verantwoordelijkheden krijgen.

[JMfx]

Hydra schreef op maandag 15 mei 2023 @ 09:01:
[...]


In de basis faliciteer je de scrum ceremonies. Stand-up, retro, etc. Maar daar gaat in een mature team echt nauwelijks tijd inzitten. Vaak zie je dat full time scrum masters daarom maar allerhande andere zaken erbij gaan zoeken om toch wat te doen te hebben. Want eens in de twee weken bedenken welk retro format we gebruiken kost niet zoveel tijd.

Ik werk nu al meer dan 10 jaar in verschillende organisaties in verschillende scrum verhoudingen (voordeel als 'externe' is dat je veel bedrijven van binnen ziet) en full time scrum masters is wat mij betreft een rode vlag dat er iets mis is in de organisatie.

Niks ten nadele van mensen die dit werk doen natuurlijk; het is niet hun schuld dat veel bedrijven het niet snappen.

Dit is echt niet wat een scrum master hoort te doen (leiden van scrum ceremonies). Dat kan het team prima zelf. Ook telkens weer een nieuw format voor de retro verzinnen is niet nodig, als je er 3 hebt die je wisselt is het prima.

De rol van een Scrum Master is het team beter Scrum te laten werken:
- Bv. Het sprint doel wordt telkens niet gehaald, hoe kunnen we dat oplossen?
- Bv. Het team releast niet minimaal elke 2 weken naar productie, hoe kunnen we dat oplossen? En hoe dagelijks?
- Bv. Impediments blijven lang liggen, welke werkwijze implementeren om dit te gaan verbeteren?

Als je echt een goede scrum master hebt houdt die zich bezig met dat soort zaken. Het vraagt er om dat je het team in beweging kan brengen, het team spiegel kan voorhouden. Het staat heel ver af van het werkveld van een developer-profiel (techniek), het is niet verstandig om die functies te combineren.

Je hebt wel gelijk met je ervaring dat de meeste bedrijven niet zo werken

[Voor 3% gewijzigd door JMfx op 15-05-2023 09:12]

[Hydra]

JMfx schreef op maandag 15 mei 2023 @ 09:10:
Dit is echt niet wat een scrum master hoort te doen (leiden van scrum ceremonies). Dat kan het team prima zelf. Ook telkens weer een nieuw format voor de retro verzinnen is niet nodig, als je er 3 hebt die je wisselt is het prima.

Ik zei faciliteren En mijn voorkeur heeft gewoon 1 format.

De rol van een Scrum Master is het team beter Scrum te laten werken:
- Bv. Het sprint doel wordt telkens niet gehaald, hoe kunnen we dat oplossen?
- Bv. Het team releast niet minimaal elke 2 weken naar productie, hoe kunnen we dat oplossen?
- Bv. Impediments blijven lang liggen, welke werkwijze implementeren om dit te gaan verbeteren?

Dit zijn dingen die developers onderling moeten kunnen regelen. Daar heb je als het goed is geen scrum master voor nodig. Waarom zou je zitten te wachten op iemand die alleen dingen kan benoemen die 'ie niet zelf op kan lossen.

Ik zit zelf meestal in lead dev rollen en vooral de eerste twee zijn gewoon issues die het team zelf op moet lossen. De derde is vaak iets dat buiten het team ligt. Anticiperen aan de ene kant, en zorgen dat je ander werk op kan pakken aan de andere kant, is in de regel hoe je hiermee omgaat. Ik zie niet hoe je je met het stellen van deze drie vragen je jezelf full time bezig kan houden.

Nogmaals; ik werk al tien jaar met scrum en als externe heb ik in een hoop teams gezeten met zowel SM rollen (meestal bij een junior dev) en full time scrum masters. Dat laatste was meestal een indicatie dat of het bedrijf een lage graad van maturity had, of het team zelf. Vaak beiden; het is vaak een indicatie dat management weinig van software snapt.

De grootste rode vlag; SAFe.

[rob_erwt]

Hydra schreef op maandag 15 mei 2023 @ 08:58:
[...]


Om dit maar even aan te halen; dan ben je als scrum master dus al compleet verkeerd bezig. Er is no way dat je vooral in teambelang handelt als je 4 teams hebt. Alleen het gedoe met het plannen van de stand-ups e.d. is al een mega pain in the ass.

Je hebt helemaal gelijk. Simpel as that. Het plannen van de meetings gaat overigens verbazingwwekkend goed omdat ieder team een ander dag ritme heeft en het daarbinnen gelukkig prima past. Maar agenda-management is lastig af en toe. Overigens maak ik dat mijn probleem, niet die van de teams. Ik heb hierbij het geluk dat het relatief volwassen teams zijn en ze mij lang niet bij elke meeting nodig hebben.

Ik pleit bij onze organisatie voor een extra SM, maar gezien we een publieke organisatie zijn, doen we het met publiek geld en vooralsnog hebben de brave belastingbetalers van Nederland niet meer geld over voor onze diensten...

Ik vind je "het belang van metrics" overigens iets dat je wel uit mag leggen want oh wee als je aankomt met dat die burndown graph relevant is

Ik heb al in geen tijden meer een burndown gezien en dat wil ik graag zo houden. Ik kijk liever naar metrics als doorlooptijd, release frequency, aantal defects/bugs na een release en of we onze sprintdoelen halen. Iedereen die begint over burndowns en velocity krijgt een lesje vanity metrics van mij.

[rob_erwt]

Hydra schreef op maandag 15 mei 2023 @ 09:18:

Dit zijn dingen die developers onderling moeten kunnen regelen. Daar heb je als het goed is geen scrum master voor nodig. Waarom zou je zitten te wachten op iemand die alleen dingen kan benoemen die 'ie niet zelf op kan lossen.

Ik zit zelf meestal in lead dev rollen en vooral de eerste twee zijn gewoon issues die het team zelf op moet lossen. De derde is vaak iets dat buiten het team ligt. Anticiperen aan de ene kant, en zorgen dat je ander werk op kan pakken aan de andere kant, is in de regel hoe je hiermee omgaat. Ik zie niet hoe je je met het stellen van deze drie vragen je jezelf full time bezig kan houden.

Ik ben met je eens dat de meeste problemen door het team zelf opgelost moeten worden, maar een boel teams vinden dat lastig of zijn daar nog niet volwassen genoeg in. Dan is een goede SM (bij voorkeur met enige technische expertise) een goede manier om die teams op weg te helpen. Niet door de problemen op te lossen, maar wel om de pijnpunten te benoemen en (tot op zekere hoogte) te adviseren hoe je die problemen zou kunnen aanvliegen.

Op termijn maakt dat wellicht de rol overbodig, maar zeker bij grotere organisaties is er altijd wel weer een (nieuw) team die die hulp kan gebruiken.

De grootste rode vlag; SAFe.

Daar zijn we het sowieso over eens!

[Hydra]

rob_erwt schreef op maandag 15 mei 2023 @ 09:20:
Ik heb al in geen tijden meer een burndown gezien en dat wil ik graag zo houden. Ik kijk liever naar metrics als doorlooptijd, release frequency, aantal defects/bugs na een release en of we onze sprintdoelen halen. Iedereen die begint over burndowns en velocity krijgt een lesje vanity metrics van mij.

Klinkt alsof je meer in een agile coach dan een scrum master rol zit, en daarvan denk ik zeker dat je een hoop waarde toevoegt Ook omdat je zelf niet bij elke meeting bent, wat een scrum master als teamlid wel hoort te zijn.

En ik geloof zeker dat een hoop bedrijven dit soort agile coaches hard nodig hebben

[JMfx]

Hydra schreef op maandag 15 mei 2023 @ 09:18:
[...]


Ik zei faciliteren En mijn voorkeur heeft gewoon 1 format.


[...]


Dit zijn dingen die developers onderling moeten kunnen regelen. Daar heb je als het goed is geen scrum master voor nodig. Waarom zou je zitten te wachten op iemand die alleen dingen kan benoemen die 'ie niet zelf op kan lossen.

Ik zit zelf meestal in lead dev rollen en vooral de eerste twee zijn gewoon issues die het team zelf op moet lossen. De derde is vaak iets dat buiten het team ligt. Anticiperen aan de ene kant, en zorgen dat je ander werk op kan pakken aan de andere kant, is in de regel hoe je hiermee omgaat. Ik zie niet hoe je je met het stellen van deze drie vragen je jezelf full time bezig kan houden.

Nogmaals; ik werk al tien jaar met scrum en als externe heb ik in een hoop teams gezeten met zowel SM rollen (meestal bij een junior dev) en full time scrum masters. Dat laatste was meestal een indicatie dat of het bedrijf een lage graad van maturity had, of het team zelf. Vaak beiden; het is vaak een indicatie dat management weinig van software snapt.

De grootste rode vlag; SAFe.

Uiteindelijk moeten developers het natuurlijk zelf doen, het is immers zelforganisatie. Echter, écht Agile werken is niet makkelijk voor veel IT-ers; er zijn ingesleten patronen, spanningslijnen waardoor teams niet functioneren, oude techstacks waardoor frequent releasen niet gaat, IT-ers met autisme ... mensen die al 30 jaar hetzelfde doen (of mijn favoriet: Agile IT-teams binnen een projecten gestuurde organisatie).

Als je dan de SM rol belegt bij een developer in het team, dan krijg je gewoon geen verandering.
Het is juist de rol van de Scrummaster om deze verbeteringen te signaleren, het team een spiegel voor te houden (door échte metrics te presenteren), en met het team verbeterideeën uit te werken (let wel: SM is ook een teamlid, en neemt dus zelf actief deel aan de retro).

Als het team extreem volwassen functioneert prima dat SM een bijrol is.
Echter werk ik ook als externe, en ken ik geen organisatie waar Scrum/Agile écht goed werkt (en dan bedoel ik niet één of andere hippe startup, maar midden en groot bedrijf).

[JMfx]

Hydra schreef op maandag 15 mei 2023 @ 09:59:
[...]


Klinkt alsof je meer in een agile coach dan een scrum master rol zit, en daarvan denk ik zeker dat je een hoop waarde toevoegt Ook omdat je zelf niet bij elke meeting bent, wat een scrum master als teamlid wel hoort te zijn.

En ik geloof zeker dat een hoop bedrijven dit soort agile coaches hard nodig hebben

Agile coach is een niet bestaande rol in Agile/Scrum

Doet me denken aan Arjen Lubach, dat 50% Nederland coach wil zijn. Wat daarboven wordt beschreven is wat een goede Scrummaster moet doen. Alleen in de praktijk helaas bijna niet doet, waardoor functie-inflatie ontstaat en mensen zich Agile coach gaan noemen. Scrum Master is echter een hands-on rol, waarbij deze het team helpt concrete verbeteringen door te voeren naar beter Agile/Scrum werken.

[CVTTPD2DQ]

JMfx schreef op dinsdag 16 mei 2023 @ 01:33:
Echter werk ik ook als externe, en ken ik geen organisatie waar Scrum/Agile écht goed werkt (en dan bedoel ik niet één of andere hippe startup, maar midden en groot bedrijf).

Ja, bekend verhaal. Agile is al twintig jaar de revolutionaire oplossing. Als Agile niet werkt komt dat omdat de medewerkers, die andere afdeling, of de klant niet echt geloven in Agile. Of door saboteurs gestuurd uit het imperialisische Westen.

Blijf vooral de revolutie verkondigen, broeders. Ik mag hopen dat de TS genoeg gezien heeft om te begrijpen dat het Agile wereldje qua ideologische starheid nog het meeste weg heeft van een RAF-cel ergens eind jaren '70.

[mannowlahn]

Hydra schreef op maandag 15 mei 2023 @ 08:56:
[...]


Dat is ruk. Dan heb je als teams meteen niet de flexibiliteit wat betreft het plannen van meetings omdat je rekening moet houden met de andere teams van de scrum master.

Het kost een teamlid echt nauwelijks tijd als een organisatie goed werkt. In m'n huidige team hebben we nieteens een SM rol. Guess what; alle retro's e.d. worden toch georganiseerd. Als je een SM nodig hebt om mensen achter de broek aan te zitten zegt dat veel over je organisatie.

Ik heb meerdere malen in teams gewerkt met wel full time scrum masters en die gingen meestal hard op zoek naar 'extra' werk omdat ze, ook met bijv. 2 teams, eigenlijk weinig te doen hadden. En meer dan 2 teams werkt eigenlijk niet, want dan kom je hard in de problemen met je meeting tijden.

Ik ben dezelfde mening toebedeeld. De SM rol is iets wat ik vaak in een development team zelf belegd zag worden. Of iedereen voldeed gewoon aan scrum en had geen persoon nodig die hen dat vertelde of iemand uit het team pikte die rol per sprint op.

Dat ging prima. Zodra scrum goed geïmplementeerd is behoren de teamleden de scrum processen zelf te kunnen hanteren. Iemand lult te lang in standup, je roept Mand, teveel taken op een naam in progress? Waarom niet geëscaleerd, velocity loopt uit de pas? Waarom niet geëscaleerd of als team geholpen. Oplevering aan PO, dat is zelf individueel een verantwoordelijkheid, review en retro kent iedereen toch het format inmiddels wel. Refinement is met de PO.

Dus tja de rol van scrum master snap ik nooit zo erg als aparte rol, tenzij je als organisatie net met scrum begint of iedereen maar wat doet.

[mannowlahn]

JMfx schreef op maandag 15 mei 2023 @ 09:10:
[...]


Dit is echt niet wat een scrum master hoort te doen (leiden van scrum ceremonies). Dat kan het team prima zelf. Ook telkens weer een nieuw format voor de retro verzinnen is niet nodig, als je er 3 hebt die je wisselt is het prima.

De rol van een Scrum Master is het team beter Scrum te laten werken:
- Bv. Het sprint doel wordt telkens niet gehaald, hoe kunnen we dat oplossen?
- Bv. Het team releast niet minimaal elke 2 weken naar productie, hoe kunnen we dat oplossen? En hoe dagelijks?
- Bv. Impediments blijven lang liggen, welke werkwijze implementeren om dit te gaan verbeteren?

Als je echt een goede scrum master hebt houdt die zich bezig met dat soort zaken. Het vraagt er om dat je het team in beweging kan brengen, het team spiegel kan voorhouden. Het staat heel ver af van het werkveld van een developer-profiel (techniek), het is niet verstandig om die functies te combineren.

Je hebt wel gelijk met je ervaring dat de meeste bedrijven niet zo werken

Die vragen behoren teams zelf te kunnen beantwoorden na bv de retro. Als je signaleerde dat je niet kon voldoen aan je sprint doel dan is dat prima in kaart te brengen. Zie je een patroon na X aantal sprints dan weet je of het incidenteel is.

De rol van scrum master is niet een coach op hetgeen van wat er opgeleverd wordt. Naar mijn mening heb je hier al senioren of een lead die die rol vervult.

Maar wel interessant hoe iedereen zelf tegen scrum aankijkt. Dat is dan ook de reden dat als je ergens komt werken dat je soms je ogen uitkijkt. Om de twee sprints een retro, openstaande stories zonder vragen door schuiven, sprint doelen ter grootte van een boekwerk, nooit wat te demoen. Je komt de raarste dingen tegen, vaak wel een zeer goede indicatie waarom men niet goed iteratief en volgens planning kan werken.

[ZieMaar!]

In dit topic zie ik vooral vooroordelen over beiden rollen voorbij komen en, op zich in lijn met de vraag van de ts, inzichten over doorgroeien ed.

In mijn ogen zijn de rollen echt zo verschillend, dat je een fundamentele keus moet maken op basis van je voorkeur. Ben je meer van het wat? Dan PO. Meer het hoe? Dan Scrummaster (en later bijv rte en/of teamleider).

Ik heb het geluk om we goed werkende implementaties van SAFe gezien te hebben en daar waren scrummasters echt niet de mensen all een meetings plande. Ook was het overigens altijd een combinatie rol. Ik zou ts echt sterk willen aanraden om te bedenken wat hem echt trekt en daar vol voor te gaan. Groei komt sneller als je je baan echt leuk vindt.

[Tylen]

@praet0rian en weet je het al?

[FirePuma142]

Oneerbiedig gezegd zie ik in de praktijk dat de functie Agile Coach een beetje een afvoerputje geworden is. Echt waarde toevoegen zie ik maar heel, heel zelden gebeuren.

[Hydra]

ZieMaar! schreef op dinsdag 16 mei 2023 @ 07:38:
In dit topic zie ik vooral vooroordelen over beiden rollen voorbij komen

Beetje raar om decennia aan totale ervaring van mensen als 'vooroordelen' weg te zetten.

[RagingPenguin]

JMfx schreef op maandag 15 mei 2023 @ 09:10:
[...]


Dit is echt niet wat een scrum master hoort te doen (leiden van scrum ceremonies). Dat kan het team prima zelf. Ook telkens weer een nieuw format voor de retro verzinnen is niet nodig, als je er 3 hebt die je wisselt is het prima.

De rol van een Scrum Master is het team beter Scrum te laten werken:
- Bv. Het sprint doel wordt telkens niet gehaald, hoe kunnen we dat oplossen?
- Bv. Het team releast niet minimaal elke 2 weken naar productie, hoe kunnen we dat oplossen? En hoe dagelijks?
- Bv. Impediments blijven lang liggen, welke werkwijze implementeren om dit te gaan verbeteren?

Als je echt een goede scrum master hebt houdt die zich bezig met dat soort zaken. Het vraagt er om dat je het team in beweging kan brengen, het team spiegel kan voorhouden. Het staat heel ver af van het werkveld van een developer-profiel (techniek), het is niet verstandig om die functies te combineren.

Je hebt wel gelijk met je ervaring dat de meeste bedrijven niet zo werken

Dat is een traditionele project manager, niet een scrum master... Een full-time, niet-technische scrum master die ook nog eens z'n tijd moet verdelen over meerdere teams is een bodemloze put aan meetings om zaken te bespreken die voor iedereen al lang duidelijk zijn maar nog wel versimpeld uitgelegd moeten worden aan de 'manager'. En daarmee zijn we dan ironisch genoeg weer full-circle naar een van de grootste problemen met waterval development.

[RagingPenguin]

CVTTPD2DQ schreef op dinsdag 16 mei 2023 @ 07:10:
[...]


Ja, bekend verhaal. Agile is al twintig jaar de revolutionaire oplossing. Als Agile niet werkt komt dat omdat de medewerkers, die andere afdeling, of de klant niet echt geloven in Agile. Of door saboteurs gestuurd uit het imperialisische Westen.

Blijf vooral de revolutie verkondigen, broeders. Ik mag hopen dat de TS genoeg gezien heeft om te begrijpen dat het Agile wereldje qua ideologische starheid nog het meeste weg heeft van een RAF-cel ergens eind jaren '70.

Wel, ik denk dat je hier twee groepen moet onderscheiden: mensen die gebakken lucht verkopen (agile coaches ed) en mensen die daadwerkelijk werk verzetten in een agile omgeving. Die eerste groep is vaak ontzettend star op alle formaliteiten en hebben een groot belang bij problemen vinden, de tweede groep is vaak een stuk losser (en daarmee een stuk meer agile). Agile werkt het beste als je er gewoon niet zo druk om maakt en enkel problemen oplost die daarwerklijk in de teams bestaan.

[CVTTPD2DQ]

RagingPenguin schreef op dinsdag 16 mei 2023 @ 10:26:
Wel, ik denk dat je hier twee groepen moet onderscheiden: mensen die gebakken lucht verkopen (agile coaches ed) en mensen die daadwerkelijk werk verzetten in een agile omgeving.

En die vroeger werk verzetten ondanks hun PRINCE2, (D)SDM, weet-ik-wat-voor ongein omgeving.

Men lijkt een beetje te zijn vergeten dat de grote theoretische ontdekkingen in de informatica, het internet, en de besturingssytemen die we vandaag de dag nog steeds gebruiken al ontwikkeld waren lang voordat de 17 apostelen hun stenen tablet ontvingen, en gingen verkondigen dat het ontwikkelen van een gefaald payroll systeem eigenlijk nog het meest leek op het bouwen van een experimentele kernreactor.

[ZieMaar!]

Hydra schreef op dinsdag 16 mei 2023 @ 10:01:
[...]


Beetje raar om decennia aan totale ervaring van mensen als 'vooroordelen' weg te zetten.

Fair enough; ik doelde vooral op het deel van de reacties die de SM vooral als facilitator van meetings zien.

[Oogje]

CVTTPD2DQ schreef op dinsdag 16 mei 2023 @ 12:43:
[...]


En die vroeger werk verzetten ondanks hun PRINCE2, (D)SDM, weet-ik-wat-voor ongein omgeving.

Oftewel, mensen die schijt hebben aan allerlei frameworks omdat die (ondanks alle waarschuwingen) leidend gemaakt worden voor de werkprocessen ipv ondersteunend zijn.

[Furion2000]

Hydra schreef op maandag 15 mei 2023 @ 09:09:
[...]


En dat is dus het gevaar; je ziet dat veel SMs dit soort dingen gaan proberen. De 'leiding' nemen in dingen. Terwijl dat niks met de scrum master rol te maken heeft; dat is echt puur een faciliterende rol. Dit is niet aan jou gericht (ik weet niet hoe je je werk doet) maar ik heb dit zien gebeuren bij niet-technische full time scrum masters. En dat werkt echt niet in een software team. Ten eerste snappen ze te weinig van de materie, ten tweede zijn ze niet de business 'owner' (dat is de PO) en ten derde conflicteert dat met het feit dat je als SM een 'peer' bent en niet iemand's manager.

Het heeft daarom meerdere voordelen een SM rol bij een junior te leggen. Ze zijn minder duur, ze hebben minder de neiging om een 'delegerende' rol op zich te nemen die niet bij de SM rol hoort, en het is bovendien een mooie learning experience omdat ze verantwoordelijkheden krijgen.

Het zet mij wel aan het denken en lijkt er inderdaad op dat ik ook aardig wat lead taken aan het pakken ben. Ik spotte al een tijdje dat deze taken er lagen, maar was van mening dat ik software dev was en dan een punt (choose your battles). Nu als SM besteedt ik, zoals ik al zei, weinig tijd aan de SM taken maar het titeltje zorgt automatisch dat ik het team wil verbeteren en dus die andere taken ook oppak zonder na te denken. Vind team efficiëntie gewoon razend interessant en neem dus de leiding om dat samen te doen.

Het voelt dus voor mij nu niet als conflicterend en ik zie dat het zijn vruchten afwerpt (netwerk, kansen, groei), dus ik ga er zo mee door. Het is alleen wel goed om te realiseren welke taken bij wat hoort en dat je ze kunt afstoten zodra je het voor jan met de korte achternaam doet.

Denk wel dat we veel over een ideale situatie kunnen praten zoals we op de werkvloer ook al veel doen, maar ik word ook wel een beetje allergisch voor die ideale situatie praatjes. We hebben de theorie, maar het komt er altijd op neer dat je in een situatie terecht komt en daar ook alleen incrementeel kunt groeien, al het andere is gedoemd om te falen. (edit: m.a.w. wat @Oogje zegt )

[praet0rian]

Tylen schreef op dinsdag 16 mei 2023 @ 08:06:
@praet0rian en weet je het al?

Ik heb nu pas alle reacties kunnen lezen 😅.

Ik ga meevolgen met een PO bij ons om eens te kijken hoe het bij ons loopt.

Ik wil coördineren, overleggen, overtuigen en beslissen.

Ik wil niet 80% van de tijd bezig zijn met het uitschrijven van stories of requirements.

I'll keep you guys posted, thanks alvast voor de vele nuttige inzichten!

[Hahn]

praet0rian schreef op dinsdag 16 mei 2023 @ 23:41:
[...]


Ik heb nu pas alle reacties kunnen lezen 😅.

Ik ga meevolgen met een PO bij ons om eens te kijken hoe het bij ons loopt.

Ik wil coördineren, overleggen, overtuigen en beslissen.

Ik wil niet 80% van de tijd bezig zijn met het uitschrijven van stories of requirements.

I'll keep you guys posted, thanks alvast voor de vele nuttige inzichten!

Een Scrum Master zal geen 80% van z'n tijd bezig zijn met het uitschrijven van stories of requirements. Maar als je wilt overtuigen en beslissen, dan zal PO veel meer zijn wat je zoekt dan Scrum Master.

[Tylen]

praet0rian schreef op dinsdag 16 mei 2023 @ 23:41:
[...]


Ik heb nu pas alle reacties kunnen lezen 😅.

Ik ga meevolgen met een PO bij ons om eens te kijken hoe het bij ons loopt.

Ik wil coördineren, overleggen, overtuigen en beslissen.

Ik wil niet 80% van de tijd bezig zijn met het uitschrijven van stories of requirements.

I'll keep you guys posted, thanks alvast voor de vele nuttige inzichten!

PO dus. verstandig

[rob_erwt]

praet0rian schreef op dinsdag 16 mei 2023 @ 23:41:
[...]

Ik wil niet 80% van de tijd bezig zijn met het uitschrijven van stories of requirements.

Dat is nu juist (deels) het werk van een PO... Niet 80% van de tijd en je kan theoretisch delegeren naar anderen, maar als PO ben je juist verantwoordelijk voor stories en requirements (lees: toekomst en staat van het product)...

[Hydra]

Furion2000 schreef op dinsdag 16 mei 2023 @ 21:08:
Het zet mij wel aan het denken en lijkt er inderdaad op dat ik ook aardig wat lead taken aan het pakken ben. Ik spotte al een tijdje dat deze taken er lagen, maar was van mening dat ik software dev was en dan een punt (choose your battles). Nu als SM besteedt ik, zoals ik al zei, weinig tijd aan de SM taken maar het titeltje zorgt automatisch dat ik het team wil verbeteren en dus die andere taken ook oppak zonder na te denken. Vind team efficiëntie gewoon razend interessant en neem dus de leiding om dat samen te doen.

Voor mij geldt hetzelfde maar ik vind het juist belangrijk om als 'peer' (lead developer) dat op mij te nemen. Een blije developer is een productieve developer over het algemeen. Dus ik zie het als een sterk onderdeel van mijn rol om te kijken of ik dat kan fixen. Ik wil zelf absoluut niet de 'scrum master' titel omdat die titel meestal gebruikt wordt door niet-technische mensen. Dus zelfs als ik de SM rol zou vervullen, dan zou ik absoluut niet de titel willen. Sommigen zien het als promotie. Ik zelf eerder als demotie

Ik heb overigens bij m'n vorige klant met een ijzersterke scrum master gewerkt, maar die was 90% van haar tijd bezig om agile te 'leren' aan de organisatie. Grappig genoeg zie je dat vaak bij een scrum master terecht komen, terwijl dat eigenlijk geen onderdeel van de rol is. In sommige gevallen werkt dit prima als de SM ook echt agile goed snapt. Maar ik zie het regelmatig gebeuren dat iemand voor een SM rol op een Scrum™ training gestuurd wordt en dan, puur op basis van een cursusje, aan mensen gaat 'vertellen' hoe Scrum™ 'moet'. En dan meestal ook aan de mensen die het werk doen, want tegen je manager vertellen dat 'ie z'n gedrag moet veranderen durven ze meestal niet.

Nou, die SM waar ik het over had durfde dat absoluut dus wel. En kreeg daar vanuit een nogal ouderwetse organisatie enorm veel pushback op. En nu werkt ze daar dus ook niet meer

[rob_erwt]

Hydra schreef op woensdag 17 mei 2023 @ 13:29:
[...]

Ik heb overigens bij m'n vorige klant met een ijzersterke scrum master gewerkt, maar die was 90% van haar tijd bezig om agile te 'leren' aan de organisatie. Grappig genoeg zie je dat vaak bij een scrum master terecht komen, terwijl dat eigenlijk geen onderdeel van de rol is.

Laat dat nu juist WEL een van de taken van een scrum master zijn...

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

_{Aldus https://scrumguides.org/scrum-guide.html#scrum-master.}

Daar hebben ze het dan specifiek over het scrum framework, maar er is geen enkele reden om dat niet breder op te vatten en alle vormen van agile werken mee te nemen.

[Gropah]

Het is inderdaad wel onderdeel van de rol, maar... dat zou vooral in het begin van scrum bij een organisatie veel tijd moeten kosten. Als je hele organisatie al op een scrum manier werkt, zou het trainen van de organisatie niet meer 90% van je tijd moeten kosten. Al helemaal niet als je een klein leger aan scrum masters hebt. Dan voelt het weer als een red flag.

[Hydra]

rob_erwt schreef op woensdag 17 mei 2023 @ 15:14:
Laat dat nu juist WEL een van de taken van een scrum master zijn...

An sich, maar oorspronkelijk (begin '00) was de focus van de SM vooral op het team en dus te zorgen dat het team efficient kon werken. Dus de SM ging vooral de organisatie in om het team te kunnen unblocken.

Dit is vrij recent veranderd omdat Scrum.org graag trainingen wil verkopen en nu de scrum master rol twee petten opheeft. Nu zie je dus full time scrum masters die 90% van hun tijd niet bij hun team zijn. Dat deel is nu compleet onderbelicht en een van de redenen waarom ik niks heb met de 'volgens het Scrum.org boekje' scrum masters omdat het oorspronkelijke doel compleet kwijt is. Dan heb je scrum masters die maar bij de helft van je scrum ceremonies is, niet met het team luncht, geen idee heeft wat het team precies doet en vooral met 'management' in meetings zit.

Dan kun je het beter compleet lostrekken en gewoon het 'SM' deel door een teamlid laten doen en alle 'de organisatie is ruk en snapt agile niet' shit door een 'agile coach' laten doen.

En ja, Scrum.org kent geen agile coach maar gelukkig bepaalt scrum.org niet wat agile is.

Daar hebben ze het dan specifiek over het scrum framework, maar er is geen enkele reden om dat niet breder op te vatten en alle vormen van agile werken mee te nemen.

Mijn ervaring is dat de team rol niet te verenigen is met de agile coach rol. Ik zie eigenlijk altijd scrum masters met meerdere teams volledig de focus op het team kwijtraken. Als je niet bij elke stand-up aanwezig bent, zoals de rest van het team wel is, ben je geen onderdeel van het team en dus niet de 'scrum master'. Dan ben je dus per definitie extern en is je rol anders. Als we je hulp nodig hebben ben je welkom, maar in de basis ben je dan niet bij meetings.

[Voor 20% gewijzigd door Hydra op 18-05-2023 09:52]

[ocf81]

Ik heb toch wel een paar opmerkingen:

Hydra schreef op maandag 15 mei 2023 @ 09:18:
[...]


Ik zei faciliteren En mijn voorkeur heeft gewoon 1 format.

Het format moet passen bij het doel van de retro. Vaak zal inderdaad een standaard format wel oké zijn, maar soms zie je als SM ook dat bepaalde dingen niet goed lopen en dan is het soms nodig om een ander format te gebruiken voor die week.

Hydra schreef op maandag 15 mei 2023 @ 09:18:

[...]


Dit zijn dingen die developers onderling moeten kunnen regelen. Daar heb je als het goed is geen scrum master voor nodig. Waarom zou je zitten te wachten op iemand die alleen dingen kan benoemen die 'ie niet zelf op kan lossen.

Als dingen blijven liggen is dat meestal een teken dat het team erop gewezen moet worden. De onderliggende problemen moeten dan worden ontdekt. Meestal zijn het sociale zaken en geen technische zaken die dan moeten worden besproken. Dat gaat dan echt niet vanzelf. (helemaal niet bij stugge developers)

Hydra schreef op maandag 15 mei 2023 @ 09:18:
Ik zit zelf meestal in lead dev rollen en vooral de eerste twee zijn gewoon issues die het team zelf op moet lossen. De derde is vaak iets dat buiten het team ligt. Anticiperen aan de ene kant, en zorgen dat je ander werk op kan pakken aan de andere kant, is in de regel hoe je hiermee omgaat. Ik zie niet hoe je je met het stellen van deze drie vragen je jezelf full time bezig kan houden.

Impediments zijn vaak organisatorisch van aard. Middelen die niet worden toegekend en dat soort zaken. Dan is wel fijn als een SM binnen de organisatie daar voor op kan komen. Dat is denk in niet zo zeer een rol van een developer.

Maar je vult er inderdaad geen hele dagen mee zonder ook iets anders te doen.

[ocf81]

praet0rian schreef op dinsdag 16 mei 2023 @ 23:41:
[...]

Ik wil niet 80% van de tijd bezig zijn met het uitschrijven van stories of requirements.

Een SM schrijft geen stories. Een PO is daarentegen wel degene die in de lead is om dit voor elkaar te krijgen, maar zal die, als het goed geregeld is, vaak in samenwerking met het dev team vormgeven en vooral aansturen op een werkbaar resultaat voor het dev team zonder daar 80% van de tijd mee bezig te zijn.

[Voor 4% gewijzigd door ocf81 op 18-05-2023 14:26]

[Bossie]

Hydra schreef op donderdag 18 mei 2023 @ 09:46:
[...]

En ja, Scrum.org kent geen agile coach maar gelukkig bepaalt scrum.org niet wat agile is.

Die zijn er toch alleen om geld te verdienen aan de agile hype?

[Craven]

Imo stel je de verkeerde vraag. Doorgroeimogelijkheden zijn vaak niet afhankelijk van de rol maar meer van het bedrijf en of jij je werk goed doet.

Daarmee bedoel ik dat een bedrijfscultuur en of het bedrijf groeiende is veel meer invloed heeft op doorgroeimogelijkheden. Een bedrijf met verziekte cultuur wil je überhaupt niet werken maar daar is doorgroeien vrij moeilijk. Een bedrijf dat krimpt of stil staat qua groei ga je ook niet of nauwelijks doorgroeimogelijkheden zien omdat er weinig plekken vrij komen.

Daarnaast is het veel belangrijker dat jij de rol leuk vind. Dat zie je namelijk in hoe je je werk doet. Dat valt op binnen het bedrijf waardoor je ook weer meer droogroeimogelijkhedeb creëert. Hetzij verticaal maar ook horizontaal als je samen werkt met andere afdelingen.

Dat gaat allemaal vele malen meer invloed hebben op je carrière dan de rol die je kiest.

Note: ik heb in het verleden de scrum master rol erbij gedaan en ben inmiddels een jaar of 6 product owner/manager. Scrum master ligt mij niet zo, zeker niet full time. Maar als ik kijk naar wat mij in dank werd afgenomen dan zijn dat de product owner taken.

[Voor 12% gewijzigd door Craven op 18-05-2023 16:56]

[Mog]

Het is inderdaad een dilemma, maar toch een belangrijke keuze @praet0rian!

In beide rollen kun je groeien, maar de aard van de groei is anders.

Als Product Owner kun je je verder ontwikkelen in de technische en business-aspecten van de producten die je beheert. Je krijgt meer invloed op de strategische richting van het product en, naarmate je meer ervaring opdoet, kun je doorgroeien naar rollen zoals Product Manager of zelfs Director of Product. Deze rollen hebben over het algemeen meer strategische verantwoordelijkheden en kunnen betrokken zijn bij de grotere bedrijfsstrategie.

Als Scrum Master ligt de focus meer op het verbeteren van processen, coachen en begeleiden van teams, en het faciliteren van een effectieve samenwerking. De verticale groei als SM kan leiden tot rollen zoals Agile Coach, waarbij je meerdere teams of zelfs een heel bedrijf kunt begeleiden bij de implementatie en verbetering van agile processen, of naar een positie van Project of Program Manager.

Uiteindelijk hangt het van je persoonlijke voorkeur en carrièredoelen af. Als je meer geïnteresseerd bent in het werken met technologie, strategie en producten, zou de PO-rol een goede keuze kunnen zijn. Als je meer interesse hebt in teamdynamiek, procesverbetering en coaching, dan zou de SM-rol een betere keuze zijn.

[Hydra]

ocf81 schreef op donderdag 18 mei 2023 @ 14:15:
Het format moet passen bij het doel van de retro. Vaak zal inderdaad een standaard format wel oké zijn, maar soms zie je als SM ook dat bepaalde dingen niet goed lopen en dan is het soms nodig om een ander format te gebruiken voor die week.

Dat was ook min of meer wat ik bedoel. Ik vind het niet erg van een format af te wijken als dat een doel heeft. Alleen heb ik bij veel overenthusiaste SMs juist het tegenovergestelde ervaren; dat er elke week een ander format moest en dat of het format ook aansluit bij de behoefte uit het oog werd verloren.

Als dingen blijven liggen is dat meestal een teken dat het team erop gewezen moet worden. De onderliggende problemen moeten dan worden ontdekt. Meestal zijn het sociale zaken en geen technische zaken die dan moeten worden besproken. Dat gaat dan echt niet vanzelf. (helemaal niet bij stugge developers)

Dit is meer een team coaching ding en ik ben het er helemaal mee eens dat dat vaak nodig kan zijn. Alleen ik vind het best wel apart dat een scrum master nu opeens ook een soort psycholoog begint te worden, aangezien veruit de meeste daar helemaal de achtergrond niet voor hebben.

Ik ken echt wel scrum masters die dit ook echt heel goed kunnen. Alleen deze zijn zwaar in de minderheid en ik vind deze groeiende verantwoordelijkheid die toegewezen wordt aan 'de scrummaster' best wel gevaarlijk.

[K0L3N]

Hydra schreef op donderdag 18 mei 2023 @ 09:46:
[...]


An sich, maar oorspronkelijk (begin '00) was de focus van de SM vooral op het team en dus te zorgen dat het team efficient kon werken. Dus de SM ging vooral de organisatie in om het team te kunnen unblocken.

Dit is vrij recent veranderd omdat Scrum.org graag trainingen wil verkopen en nu de scrum master rol twee petten opheeft. Nu zie je dus full time scrum masters die 90% van hun tijd niet bij hun team zijn. Dat deel is nu compleet onderbelicht en een van de redenen waarom ik niks heb met de 'volgens het Scrum.org boekje' scrum masters omdat het oorspronkelijke doel compleet kwijt is. Dan heb je scrum masters die maar bij de helft van je scrum ceremonies is, niet met het team luncht, geen idee heeft wat het team precies doet en vooral met 'management' in meetings zit.

Dan kun je het beter compleet lostrekken en gewoon het 'SM' deel door een teamlid laten doen en alle 'de organisatie is ruk en snapt agile niet' shit door een 'agile coach' laten doen.

En ja, Scrum.org kent geen agile coach maar gelukkig bepaalt scrum.org niet wat agile is.


[...]


Mijn ervaring is dat de team rol niet te verenigen is met de agile coach rol. Ik zie eigenlijk altijd scrum masters met meerdere teams volledig de focus op het team kwijtraken. Als je niet bij elke stand-up aanwezig bent, zoals de rest van het team wel is, ben je geen onderdeel van het team en dus niet de 'scrum master'. Dan ben je dus per definitie extern en is je rol anders. Als we je hulp nodig hebben ben je welkom, maar in de basis ben je dan niet bij meetings.

Ben ik het niet mee eens, het coachen van de organisatie doe ik voornamelijk door de punten die mijn team onnodig veel tijd en energie kost op te lossen op dat niveau. Dus ik kijk heel goed naar het proces van mijn team, ik bespreek dat met de andere scrum masters in de organisatie, en samen proberen we de impediments die we zien in de organisatie waar mogelijk op te lossen, maar vaker te mitigeren en af te vangen met workarounds.
Dat is ook wat ik leuk vind aan mijn rol, want anders zou ik mijn hardwerkende team continu op de vingers moeten kijken of er misschien nog wat te verbeteren valt.