Scrum master: wel/niet doen?

[aaajeetee]

Bij het bedrijf waar ik nu werk wordt het development team opgesplitst in 2 (kleinere) teams. Er is al een scrum master aanwezig, deze zal 1 team op zich nemen.

Mij is gevraagd om scrum master voor het andere team te worden. Ik twijfel erg of ik dit wil of niet.

Ons bedrijf is in de opstartende scrum-fase. De afgelopen paar maanden hebben we scrum wat half-half geimplementeerd. Redenen ga ik niet al te diep op in, maar enige scrum zaken die we deden waren daily standup, retrospective en de sprint. De sprint duurde niet 2 weken, soms langer, soms korter. Kortom: niet echt scrum te noemen en een beetje chaotisch.
Binnenkort gaan we helemaal met/op scrum werken en daarbij dus alle facetten: backlog refinement, sprint planning etc. Veel dieper ga ik hier ook niet op in, maar trust me: het wordt volledig scrum.

Waarom twijfel ik?
Ik wil me eigenlijk 100% kunnen richten op programmeren en heb weinig zin om veel tijd kwijt te zijn met meetings, randzaken en overige niet-programmeer taken. Overigens snap ik dat 100% programmeren er nooit inzit; denk aan daily standup, retrospective etc.
Ik heb het idee dat een scrum master de tijd veel meer moet verdelen tussen het programmeren en de andere scrum zaken.

Misschien heb ik te weinig nog met 'echt' scrum gewerkt en is mijn beeld van een scrum master wat donkerder dan het in werkelijkheid is.

Ik heb al gegoogled, maar kom daar voornamelijk tegen dat een scrum master ervoor moet zorgen dat scrum correct wordt geïmplementeerd en dat het team goed door kan werken zonder oponthoud.

Kunnen jullie me wellicht praktijk voorbeelden geven van wat een scrum master wekelijks/per sprint doet en hoeveel tijd dit in beslag neemt?
Natuurlijk zullen er taken/zaken zijn die per branche/bedrijf verschillen. Hier zal ik dan zelf naar moeten kijken wat bij mij van toepassing is.

Ik hoop dat met deze inzichten ik voor mezelf beter de keus kan maken of ik het wel/neit wil.
Andere tips of adviezen mbt scrum (master) zijn ook welkom!

Alvast bedankt

[MarcoC]

De rol van een scrum master is veel meer faciliterend. De tijd die je kwijt bent aan de rol scrum master kan heel erg verschillen, maar je kunt er wel vanuit gaan dat je veel meer met randzaken. Ik zou mezelf wel afvragen of je deze zaken echt als randzaken moet beschouwen. Wellicht kun je vanuit jouw achtergrond juist overbodige meetings naar de achtergrond drukken en zinvolle dingen op de agenda zetten waardoor jouw team als geheel efficiënter te werk kunt gaan.

Als je echt simpelweg dolgraag wilt programmeren en verder je niet druk wilt maken om andere zaken, dan lijkt de rol van scrum master mij niet heel erg voor jou geschikt.

[Bor]

aaajeetee schreef op maandag 23 november 2015 @ 13:50:
Waarom twijfel ik?
Ik wil me eigenlijk 100% kunnen richten op programmeren en heb weinig zin om veel tijd kwijt te zijn met meetings, randzaken en overige niet-programmeer taken.

Heb je hiermee de keuze niet al gemaakt? Als daar jouw hart ligt ga je als scrumm master niet gelukkig worden.

[ Voor 9% gewijzigd door Bor op 23-11-2015 13:57 ]

[418O2]

MarcoC schreef op maandag 23 november 2015 @ 13:53:
De rol van een scrum master is veel meer faciliterend. De tijd die je kwijt bent aan de rol scrum master kan heel erg verschillen, maar je kunt er wel vanuit gaan dat je veel meer met randzaken. Ik zou mezelf wel afvragen of je deze zaken echt als randzaken moet beschouwen. Wellicht kun je vanuit jouw achtergrond juist overbodige meetings naar de achtergrond drukken en zinvolle dingen op de agenda zetten waardoor jouw team als geheel efficiënter te werk kunt gaan.

Als je echt simpelweg dolgraag wilt programmeren en verder je niet druk wilt maken om andere zaken, dan lijkt de rol van scrum master mij niet heel erg voor jou geschikt.

En je gaat dus vaak afgeleid worden. Kost bruto weinig tijd, netto wel.

[aaajeetee]

Bedankt voor de reacties tot nu toe.

MarcoC schreef op maandag 23 november 2015 @ 13:53:
[...]

ik ben het met je eens dat de 'randzaken' niet helemaal 'randzaken' zijn, de term is wellicht wat overdreven. Als ik dit zo lees dan bevestigt dat wel een beetje mijn vermoedens.

Bor schreef op maandag 23 november 2015 @ 13:57:
[...]

Heb je hiermee de keuze niet al gemaakt? Als daar jouw hart ligt ga je als scrumm master niet gelukkig worden.

Misschien wel. Echter baseer ik mijn keus dus op wat ik weet en wat ik heb kunnen vinden (tot dusver). Ik ben wel benieuwd of het in de praktijk veel/weinig tijd kost en hoeveel tijd er naast de scrum master rol nog in programmeren gestoken kan worden.
Ik heb de laatste tijd wat teveel in de niet-programmeer rol gezeten en voor een tijdje vind ik dat prima; op lange(re) termijn heb ik daar weinig zin in.

Misschien heb ik de keus al wel gemaakt om het niet te doen en ben ik nu op zoek naar argumenten/voorbeelden/adviezen om het juist wél te moeten doen... ?

Nog wat extra info: Samen met een collega zijn wij de senior developers. Het past dan wellicht wel in het straatje van een senior developer om scrum master te zijn? Daarnaast is er onlangs een nieuwe medior aangenomen die het leuk vindt om de scrum master te zijn.
Daar zit bij mij ook een beetje de tweestrijd in: er is iemand die het wel graag wil zijn, maar het wordt van mij wellicht verwacht.

[pirke]

Als je als scrum master aan de slag gaat kom je veel meer op de teamleider rol uit. Nu lees ik dat het eerst een meewerkend voorman rol is waarbij je een deel van je tijd nog mee helpt met programmeren en een deel bezig bent met planningen etc, straks zal dat alleen nog maar teamleider zijn. Doorgroeien richting een management functie noemen ze dat. Er zijn echter 2 belangrijke factoren: kun je het en wil je het? Beide moeten ja zijn anders wordt je er niet gelukkiger van.

[aaajeetee]

pirke schreef op maandag 23 november 2015 @ 14:39:
Als je als scrum master aan de slag gaat kom je veel meer op de teamleider rol uit. Nu lees ik dat het eerst een meewerkend voorman rol is waarbij je een deel van je tijd nog mee helpt met programmeren en een deel bezig bent met planningen etc, straks zal dat alleen nog maar teamleider zijn. Doorgroeien richting een management functie noemen ze dat. Er zijn echter 2 belangrijke factoren: kun je het en wil je het? Beide moeten ja zijn anders wordt je er niet gelukkiger van.

Bij mij is het antwoord op de vragen: nee en nee. Ik ben al eens manager van het team geweest (2x, waarvan onlangs interim) en dat is niet iets wat ik op lange termijn wil gaan doen.

Bedankt.

[_Erikje_]

Als het niet je ding is, doe het dan vooral niet. Daar wordt niemand gelukkiger van.

[Martin Sturm]

pirke schreef op maandag 23 november 2015 @ 14:39:
Als je als scrum master aan de slag gaat kom je veel meer op de teamleider rol uit. Nu lees ik dat het eerst een meewerkend voorman rol is waarbij je een deel van je tijd nog mee helpt met programmeren en een deel bezig bent met planningen etc, straks zal dat alleen nog maar teamleider zijn. Doorgroeien richting een management functie noemen ze dat. Er zijn echter 2 belangrijke factoren: kun je het en wil je het? Beide moeten ja zijn anders wordt je er niet gelukkiger van.

Ja, dat is precies waar het vaak fout gaat Idealiter is de scrum master niet de teamleider. In principe moet de scrum master faciliterend zijn en is dus technisch gezien geen onderdeel van het team. We hebben hier ook een tijd 1 scrum master voor meerdere teams gehad (dat kan ook prima). Als ik zou moeten kiezen zou ik dus als senior-developer, die niet de ambitie heeft scrum-master te zijn, ook geen scrum-master worden. Als er een medior-developer is die wel graag scrum-master wil zijn aanwezig is, zou ik die dus mooi scrum-master laten zijn. Het mooie is namelijk dat je als scrum-master in principe geen technisch-inhoudelijke rol hebt, en het developer-level tamelijk los staat van de kwaliteiten als scrum master. De scrum master zorgt voor het verwijderen van impediments, organiseren van retrospective, backlog planningssessies en dat soort zaken. Hij houdt zich eventueel bezig met het coachen van de product owner bij het schrijven van stories op een manier die zowel voor de technische kant alsook de niet-technische kant begrijpelijk is. Maar in principe zou een scrum master dus nooit zelf stories moeten schrijven, zich uit moeten laten over estimates en dat soort zaken. Wij hebben dan ook (toen we nog de afzonderlijke rol scrum master hadden) een development lead binnen het team die coaching gaf aan medior en junior developers en primair aanspreekpunt was vanuit de product owner voor technische zaken.
Uiteindelijk is het gebruikelijk dat een scrum master een tijdelijke rol is, omdat het team op een bepaald moment zelf in staat is de taken die de scrum master doet over te nemen.

[SiErRa]

Grotendeels met Martin eens, behalve het laatste.
Ik denk dat je altijd een Scrum master moet houden, maar dat deze gewoon steeds minder te doen heeft, naarmate het team langer samen is en de organisatie aan Scrum went.

Toen ik op mijn huidige opdracht begon als Scrum master was ik niet de lead dev, maar inmiddels wel en ik merk dat ik de scrum master rol inderdaad eigenlijk bij iemand anders kwijt wil, omdat het soms elkaar een beetje bijt.

Over hoeveel tijd het kost, dat hangt er nogal van af, hoe goed kan je PO stories schrijven? Kost het reserveren van ruimtes enzo veel tijd? Verwacht je veel impedements?

[Ankona]

Als ik jouw zo hoor zeg ik niet doen.

De scrum master is de manusje van alles die het team en zijn omgeving draaiend moet houden. Een belangrijke en moeilijke vaak fulltime taak. Maar als je hart ligt bij programmeren en niet bij het regelen en ritselen dan moet je lekker blijven programmeren en een ander de scrum master rol op zich nemen.

Scrum master is ook zeker niet het hoogst haalbare in een scrum team. Sterker nog als je kijkt naar de certificeringstrajecten dan zie je dat iedereen met twee dagen cursus scrum master kan worden. Maar certified scrum developer is voor senior developers vaak nog flink studeren. En dan vergeten we nog de belangrijke rol van product owner....

[aaajeetee]

Bedankt voor de reacties. Met name het verhaal van Martin is een goede uitleg. Onze PO zit net in deze rol en het schrijven van stories zal dus, zeker in het begin, heel erg moeten wennen. Dit is ook iets wat de medior developer waar ik het over had erg interessant vind om te doen / mee te helpen.

Ik dacht dat de scrum master een soort van 'hoogst haalbare' was (binnen een scrum-dev team), maar als ik dit zo hoor valt het dus reuze mee. Het is dus ook niet dat 'de hoogste in rang' (om het wat overdreven te zeggen) dus scrum master moet zijn

Ik denk dat ik er voor mezelf nu helemaal uit ben. Deze reacties hebben enorm geholpen, thanks!!

[Ankona]

Overigens is er niets op tegen om een scrum master training te volgen, ook als je alleen als developer wilt blijven werken.
Een van de belangrijkste en moeilijkste taken van een scrum master is het coachen van het team en de organisatie in het scrum proces. Het is dus fijn als er een aantal teamleden hier al goede kennis van hebben.

(zelf heb ik ook een scrum master training gedaan maar heb niet de ambitie om in scrum teams een andere rol dan developer op me te nemen. Wel is het handig (in mijn functie als senior developer) om gedegen proces kennis te hebben zodat ik scrum kan initieren bij klantenteams - krijgt het proces vorm, dan schuif ik graag een ander naar voren voor de scrum master rol)

[geenstijl]

@ankona
Hier precies hetzelfde.
Als senior developer de scrum master training gedaan om net wat meer feeling te krijgen met het scrum-proces, een aanrader.
Verder eens met iedereen hierboven:
een scrum-master is per definitie niet een developer in het development team, maar iemand daarbuiten.

[Hahn]

De sprint duurde niet 2 weken, soms langer, soms korter. Kortom: niet echt scrum te noemen en een beetje chaotisch.

Scrum is wat je er zelf van maakt, als jij sprints van een week wilt, dan moet je dat vooral doen. Dan ben je niet opeens 'niet echt aan het scrummen'.

Maar dat terzijde: als jij je volledig wilt wijden aan programmeren en niet afgeleid wilt worden, dan moet je je zo ver mogelijk van de taak scrum master begeven

Ik werk nu een kleine anderhalf jaar bij een bedrijf wat inmiddels ruim 100 developers heeft en al een paar mensen scrum-master-af zien worden omdat ze het niet aankonden. En onze scrum master nu heeft het ook erg druk met al het geregel en komt ook maar weinig aan echt werken toe. Zelf ben ik een paar keer vervangend scrum master geweest tijdens zijn vakanties en ik ben blij dat dat altijd maar een weekje (of 2) is, want er komt veel bij kijken.

Dus als je de ambitie (nog) niet hebt om dingen in goede banen te leiden, dan moet je het (nog) niet doen.

[rob_erwt]

Ik heb een tijdlang (toen ik nog direct bij Tweakers werkte) ook het Scrum Master gedeelte erbij gedaan, naast devver. Ik merkte daarbij echter dat het best lastig is om beide rollen te hebben. Je zou als Scrum Master neutraal in het team moeten staan, maar in de praktijk merkte ik dat ik iets neigde naar de wensen (en nukken) van de developers en niet perse naar de andere rollen in het team (zoals PO's).

Ondertussen ben ik doorgegroeid naar fulltime Scrum Master voor twee teams (bij VNU) en daar heb ik ook daadwerkelijk een fulltime baan aan! Zeker in teams die nog niet heel bedreven zijn in Scrum of waar nog veel te verbeteren valt, vult je tijd zich automatisch. Overigens was dit bij mij een bewuste keuze: ik was juist wel een beetje klaar met developen en merkte dat mijn hart toch meer uit ging naar het organisatorische vlak.

Waarmee vul ik mijn dag dan? Nou, natuurlijk het faciliteren van de meetings (standups, retrospectives, refinement session en retrospectives. Daarnaast probeer ik de nodige metrics bij te houden en daar ook nog wat zinnige conclusies aan te verbinden. Ik ben ook in de praktijk het eerste aanspreekpunt van het team bij problemen (de term impediment wordt ruim opgevat. ). En dit alles dus keer twee voor de twee teams. Overigens werken wij in sprints van 1 week wat de meeting druk ook wat hoger maakt.

Daarnaast organiseer ik met mijn mede-SM All-hands sessies (kennisdeling tussen alle developmentteams in het pand), faciliteer gilde meetings (zoals PO overleg tussen verschillende titels, zelfde voor architecten overleg) en ben ik over het algemeen betrokken bij het opvullen van vacatures (vooral in de vorm van afnemen van sollicitatie gesprekken).

Het staat of valt dus een beetje met wat voor invulling ze verwachten of die je er zelf aan wil geven, maar zelfs met 1 team kun je het al best druk hebben. Ik heb wel eens de uitspraak gehoord: 'een goede SM kan twee teams hebben, een uitstekende SM maar een.'

[koli-man]

Eigenlijk heb je in je openingspost al zelf antwoord gegeven. Je wil dit dus niet.

Momenteel heb ik ook de rol als scrum master, en het kost gewoon veel tijd. Ik merk dat ik aan het einde van een sprint en in het begin van een sprint er redelijk wat tijd gewoon mee kwijt ben. Enerzijds bereid ik de stories al voor, zodat de product owner alleen nog de prioriteiten kan geven.
Daarbij probeer ik de roadmap en release dates in de gaten te houden. Dan probeer ik om de taken al zoveel mogelijk voor te bereiden voor de stories met de hoogste prioriteit, zodat de sprintplanning zo efficient en snel mogelijk kan verlopen.

Dus ben ik eigenlijk tijdens het middengedeelte van de sprint zelf ook effectief aan het mee ontwikkelen. Ik vind persoonlijk de afwisseling prima, maar het zelf ontwikkelen blijf ik toch erg leuk vinden.

[Verwijderd]

Hahn schreef op maandag 23 november 2015 @ 20:14:
[...]
Ik werk nu een kleine anderhalf jaar bij een bedrijf wat inmiddels ruim 100 developers heeft en al een paar mensen scrum-master-af zien worden omdat ze het niet aankonden. En onze scrum master nu heeft het ook erg druk met al het geregel en komt ook maar weinig aan echt werken toe.

Wat is precies 'echt' werken? Hoe komt het toch altijd dat mensen die productiewerk doen (of dit nou in een fabriek is of software schrijven) het idee hebben dat iedereen die faciliterend werk verricht geen echt werk verricht?

[BoyGenius]

De verschillende activiteiten die bij een Scrum Master aan bod kunnen komen hebben de mensen hierboven al goed geschetst. Het is waar dat als je geen 'regelneef' bent, dat je het ook niet leuk gaat vinden.

Op dit moment ben ik SM van een team bestaande uit 8 vaste mensen, met daarom heen mensen die in verschillende teams werken (voornamelijk Ops/beheer kant). Naast mijn rol als Scrum Master ben ik ook nog tester/testautomatiseerder.

Het verschilt per omgeving en organisatie hoeveel tijd je bent aan het SM zijn. In mijn geval zijn we een nieuw team in onze 4e sprint in een organisatie die behoorlijk complex is (zowel op technisch als op politiek vlak). Het betreft hier een grote financiele instelling.

Op dit moment ben ik zo'n 60 tot 70% van mijn tijd kwijt aan het SM-schap. Uit navraag bij andere teams in de organisatie blijkt dat men uiteindelijk zo'n 50% van de tijd bezig is met het SM zijn. In een gedeelde rol (dus technische rol en SM zijn) klopt het dat je toch vaak 'gestoord' wordt en je in je technische rol niet altijd lekker door kunt werken (is ook afhankelijk van je eigen time management kwaliteiten).

Ik weet niet of jullie testers hebben in je team, maar als je kijkt, even grof geschetst, naar het 'type' mens in het geval van een ontwikkelaar en een tester is de SM rol voor een tester vaak wat prettiger, omdat deze ook veelal de spin in het web is tussen techniek en business.

Onderschat de rol van SM dus niet!

Een goed boek over Scrum en het SM zijn is het boek Essential Scrum: http://www.amazon.com/Ess...r-Signature/dp/0137043295

Veel misvattingen over het Scrum proces worden in dit boek verhelderd. Een aanrader voor elk (beginnend) Scrum team. Uiteindelijk moet je gebruiken wat je team prettig vindt en niet omdat het Scrum proces dat zegt

Simpel voorbeeld: inschatten van een story hoeft echt niet perse met een pokersessie met pokerkaartjes en ook niet iedereen hoeft mee te schatten met een story als er al bekend is dat een specifiek persoon dat op gaat pakken vanwege haar of zijn specialistische kennis (let op: dit is wat anders dan een beeld schetsen aan het team wat je verwacht dat je werkzaamheden zijn en hoeveel punten je dit gaat kosten).

Als Scrum team streef je naar voorspelbaarheid voor de business. Daarnaast zou het iteratief ontwikkelen van software er voor moeten zorgen dat je altijd een werkende situatie hebt staan. Hoe je deze voorspelbaarheid bereikt is aan het team zelf. Het Scrum proces reikt enkel handvatten aan om dit te bereiken.

Zoals het Agile Manifesto al beschrijft: 'Individuals and interactions over processes and tools'. Blijf dus pragmatisch

[ Voor 4% gewijzigd door BoyGenius op 23-11-2015 21:41 ]

[Shadowhawk00]

pirke schreef op maandag 23 november 2015 @ 14:39:
Als je als scrum master aan de slag gaat kom je veel meer op de teamleider rol uit. Nu lees ik dat het eerst een meewerkend voorman rol is waarbij je een deel van je tijd nog mee helpt met programmeren en een deel bezig bent met planningen etc, straks zal dat alleen nog maar teamleider zijn. Doorgroeien richting een management functie noemen ze dat. Er zijn echter 2 belangrijke factoren: kun je het en wil je het? Beide moeten ja zijn anders wordt je er niet gelukkiger van.

Dit hoeft helemaal niet eigenlijk. Scrum master hoeft zich helemaal niet met de planning bezig te houden.
Het enige wat je als scrum master meer moet doen is de daily standup inplannen, en de andere meetings inplannen en even voorbereiden. Bedenken hoe je ze wilt aanvliegen.
En als er problemen zijn in je team die je niet kan oplossen, specs zijn niet duidelijk, overleg met expert nodig enzo. Moet je dat beetje najagen.
Meestal komt het er dus op neer dat je dus even bij de verantwoordelijke langsloopt om te zorgen dat je gegevens krijgt.

Scrum Master = Zorgen dat niemand vastloopt op zaken die buiten het team liggen.
Product Owner = zorgen dat de juiste dingen in de sprint zitten.

Het ligt heel erg aan hoe complex de organisatie is hoeveel tijd je kwijt bent. En ook hoe goed het in de organisatie geregeld is.

[ Voor 4% gewijzigd door Shadowhawk00 op 23-11-2015 22:44 ]

[418O2]

Ik heb een (klein) project geleidt de laatste weken, maar merk wel dat je mensen inhoudelijk aan de gang moet houden en veel regelt en overlegt. Als is dat maar korte communicatie, merk ik wel dat ik in mijn rol als frontenddev daar veel last van heb. Als je een dag met een lastig probleem zit en tussendoor 5-6x kort gestoord wordt dan merk ik dat ik niet lekker in mijn 'zone' kom en dus niet zoveel gedaan krijg. Beetje hetzelfde als wat jij ervaart denk ik.

[pirke]

Als je in een grote organisatie zit dan wil de business unit toch een soort van planning hebben van de r&d mensen. Dan kun je wel scrum doen, maar uiteindelijk willen ze wel een half jaar van tevoren weten wat er wel en niet in de volgende major product release gaat zitten Deze bijten elkaar absoluut niet, want alleen maar naar de huidige en volgende sprint kijken is ook geen goede werkwijze naar mijn mening. En de roadmap (business of technisch) zit ook vol met schattingen, en ook die schattingen zijn weer ergens op gebaseerd. In mijn ervaring als je met een ontwikkelteam scrum volgt in zo'n omgeving gaat dat prima, maar de teamleider doet dan veel meer dan wat er onder de noemer scrum master valt. Het is veel uitgebreider dan puur de scrum sessies faciliteren en blokkeringen weghalen. Er moeten schattingen komen, rekening houdend met vakanties en ziektes, als er een paar sprints niet lekker gaan heeft dat weer impact op het beloofde programma, nieuwe inzichten in technische paden kunnen voor verbouwingen zorgen, overleg met andere teams en afdelingen, coaching op niet-technisch vlak, etc etc. Veel van deze zaken kun je afschermen voor je team zodat zij lekker door kunnen typen. Het scrum master deel van een meewerkend voorman wordt in mijn ervaring vaak gebruikt als opstapje naar volledig teamleiderschap met alle facetten die daar bij horen. Je gaat als teamleider steeds verder weg van de techniek, als dat je ambitie niet is dan moet je daar vooral niet aan gaan beginnen. Uiteindelijk zijn de scrum master werkzaamheden maar een klein deel vergeleken bij al het andere dat er moet gebeuren.

[ Voor 5% gewijzigd door pirke op 23-11-2015 23:01 ]

[avotar]

Vaak wordt er een senior developer genomen, omdat die net wat meer feeling met de materie moet hebbben en daardoor wellicht beter kan sparren met de Product Owner.
Ik weet niet hoe fel ze je op je huid zitten, maar probeer anders eerst de Scrum Master training te doen. En dan liever nog klassikaal dan online, om gewoon net even wat meer gevoel erbij te krijgen. Dan weet je in elk geval beter wat je niet wil gaan doen.

Want neem maar aan van iemand die in ditzelfde schuitje gezeten heeft, in een scrum implementerende organisatie ga je je eerste sprints amper tijd hebben voor development werk en zul je vooral aan het discussieren zijn.

[Blue-eagle]

Bij twijfel: niet doen.

En, met alle respect voor Scrum masters, er zit toch niets creatiefs of innovatiefs of moeilijks aan? Je gaat je dood vervelen omdat het simpelweg niet uitdagend is om die regeltjes te volgen; het is volgens mij ook een kwestie van tijd totdat Scrum-mastership wordt geautomatiseerd.
Het kan momenteel een full-time baan zijn als je het goed doet. Dat zou ik eerder overlaten aan management types.

Ik zie "Scrum master" altijd als iets wat toekomstige managers danwel team leads doen om het product en de collega's te leren kennen, en daarna doorstromen naar een functie waar wél groei in zit.

[rob_erwt]

Blue-eagle schreef op dinsdag 24 november 2015 @ 12:21:
En, met alle respect voor Scrum masters, er zit toch niets creatiefs of innovatiefs of moeilijks aan? Je gaat je dood vervelen omdat het simpelweg niet uitdagend is om die regeltjes te volgen; het is volgens mij ook een kwestie van tijd totdat Scrum-mastership wordt geautomatiseerd.
Het kan momenteel een full-time baan zijn als je het goed doet. Dat zou ik eerder overlaten aan management types.

Dan heb je niet echt door wat Scrum en agile werken beoogen. Het hele idee is nu juist dat de regels er niet zijn, alleen een framework waarin je je beweegt. En zelfs dat is tot op zekere hoogte optioneel.

Het hele idee achter Scrum is dat het team zelfsturend is/wordt. Of anders gezegd: dat ze zelf hun weg vinden en een proces opzetten waarbinnen/waarmee ze het best uit de voeten kunnen.

En als Scrum Master probeer je daarbij te helpen, handvaten te bieden en (zo min mogelijk) bij te sturen. Dat is bij uitstek mensenwerk en nauwelijks te automatiseren. Dit in tegenstelling tot dingen als Prince II die alleen maar om regeltjes draaien en dus idd prima in een bepaalde vorm te automatiseren zijn.

[avotar]

Blue-eagle schreef op dinsdag 24 november 2015 @ 12:21:
Bij twijfel: niet doen.

En, met alle respect voor Scrum masters, er zit toch niets creatiefs of innovatiefs of moeilijks aan? Je gaat je dood vervelen omdat het simpelweg niet uitdagend is om die regeltjes te volgen; het is volgens mij ook een kwestie van tijd totdat Scrum-mastership wordt geautomatiseerd.
Het kan momenteel een full-time baan zijn als je het goed doet. Dat zou ik eerder overlaten aan management types.

Ik zie "Scrum master" altijd als iets wat toekomstige managers danwel team leads doen om het product en de collega's te leren kennen, en daarna doorstromen naar een functie waar wél groei in zit.

Ik heb zo iemand als jij ook in mijn team zitten

Nee, als het eenmaal op de rit staat, kan het zijn dat het geen full-time baan meer is. Maar dat is meer hoe je je positioneert in je eigen plekje. Iedereen zijn eigen stijl, dat geldt voor zowel managers als scrum masters. Maar je bent juist geen baasje, je begeleidt en faciliteert het proces veel meer dan dat het je stuurt.

Ik denk dat je meer in de war bent met ITIL of Prince of meer van dat soort methodologiën.

[Hahn]

Verwijderd schreef op maandag 23 november 2015 @ 20:58:
[...]

Wat is precies 'echt' werken? Hoe komt het toch altijd dat mensen die productiewerk doen (of dit nou in een fabriek is of software schrijven) het idee hebben dat iedereen die faciliterend werk verricht geen echt werk verricht?

Voel je je een beetje aangevallen? Zo komt het wel over in ieder geval

Met echt werken bedoel ik waar hij voor aangenomen is: software ontwikkelen. Scrum Master is bij ons een taak die je naast je normale taken doet en geen fulltime baan.

Prima dat bij sommige bedrijven Scrum Master een fulltime baan is, maar bij ons kost het misschien een halve tot een hele dag per week, verspreid over de hele week.

[Zoijar]

Ik zou dit een keer lezen en dan jezelf de vraag stellen of je daar gelukkig van gaat worden: https://michaelochurch.wo...ially-scrum-are-terrible/

[Collaborator]

Zoijar schreef op dinsdag 24 november 2015 @ 20:45:
Ik zou dit een keer lezen en dan jezelf de vraag stellen of je daar gelukkig van gaat worden: https://michaelochurch.wo...ially-scrum-are-terrible/

Wij werken nu een jaar met Scrum/Agile en ik herken me absoluut niet in het verhaal. Het is natuurlijk ook zo dat iedereen het anders implementeert, en dat is juist de kracht (ik ben zelf geen scrummaster en zou het ook niet willen zijn).

Ons heeft het veel gebracht, onze eigen structuur binnen het team, weten waar we aan toen zijn elke week/dag, beter teamwork. Minder meetings. Beter testen. Onze product manager hoeft maar naar het 2.5 meter brede scrumboard te kijken om te weten wat er bijna klaar is om te demo'en.

Het enige probleem wat naar mijn idee bijna onoverkomelijk is dat externe partijen zich hier niet veel van aantrekken (wekelijkse sprint, dus op vaste momenten opleveren) en dus continu proberen van alles tussendoor gedaan te krijgen. Maar dat gaat na verloop van tijd ook steeds beter (product manager moet leren nee zeggen)

[Blue-eagle]

rob_erwt schreef op dinsdag 24 november 2015 @ 12:32:
[...]


Dan heb je niet echt door wat Scrum en agile werken beoogen. Het hele idee is nu juist dat de regels er niet zijn, alleen een framework waarin je je beweegt. En zelfs dat is tot op zekere hoogte optioneel.

Het hele idee achter Scrum is dat het team zelfsturend is/wordt. Of anders gezegd: dat ze zelf hun weg vinden en een proces opzetten waarbinnen/waarmee ze het best uit de voeten kunnen.

En als Scrum Master probeer je daarbij te helpen, handvaten te bieden en (zo min mogelijk) bij te sturen. Dat is bij uitstek mensenwerk en nauwelijks te automatiseren. Dit in tegenstelling tot dingen als Prince II die alleen maar om regeltjes draaien en dus idd prima in een bepaalde vorm te automatiseren zijn.

Dat klopt allemaal wel, maar is dat een full-time baan? Ik zie Scrum masters hooguit een Jira board up-to-date houden en de stickies van een retrospective uittypen. Het team zelf zorgt voor grooming, het team kan helemaal zelf de standups regelen, het team kan zelf een sprint starten en ga zo maar voort.

Misschien is het op gang krijgen van Scrum binnen een onervaren team wel veel werk. Naar mijn ervaring is Scrum in ieder geval niet zo moeilijk of ongrijpbaar dat dit van de rails afloopt als de Scrum Master niet aanwezig is.

Het is toch geen baan? Er zit voor zover ik weet helemaal niets uitdagends in wat ook maar enige creativiteit of kunde vergt. Het is toch zeker geen carrière?

Ik zie geen "junior Scrum master" of een "Lead Scrum Master" of alles daartussen. Het zijn vaak de mensen die tijd overhebben om rompslomp op zich te nemen. Er bestaat een cursus voor, en die is ook niet bepaald van het niveau waar bijvoorbeeld softwareontwikkelaars wel (vaak) aan voldoen.

avotar schreef op dinsdag 24 november 2015 @ 13:10:
[...]


Ik heb zo iemand als jij ook in mijn team zitten

Nee, als het eenmaal op de rit staat, kan het zijn dat het geen full-time baan meer is. Maar dat is meer hoe je je positioneert in je eigen plekje. Iedereen zijn eigen stijl, dat geldt voor zowel managers als scrum masters. Maar je bent juist geen baasje, je begeleidt en faciliteert het proces veel meer dan dat het je stuurt.

Ik denk dat je meer in de war bent met ITIL of Prince of meer van dat soort methodologiën.

Ik ken geen andere methodieken, misschien waterfall van vroeger

Hoe dan ook...

Dit is enkel mijn perspectief op de rol Scrum Master. Absoluut handig om te hebben in je team, maar ik zou er voor geen goud mee bezig willen zijn.

[NielsTn]

scrummaster houdt invloeden van buiten af, en laat het team in dagelijkse standup meeting elkaar sturen en helpen....
leuker lijkt me een rol als product owner, in standupmeeting luisterend naar richtingen, en waarnodig aanvullende ifnormatie verstrekken.

[Henkje.doc]

Hoe een dergelijke rol praktisch ingevuld kan worden kan een verschil maken.
Voorbeelden van sources die een team nodig heeft, maar niet toe te wijzen zijn maken dit een lastige job.

Heb verschillendd scrummasters meegemaakt. Zolang de resources in het team zitten gaat het goed anders niet en kan het erg persoonlijk worden.

Maar goed ik wijk af. Samengevat: Zou het zelf niet snel doen.