Tweakers en Autotrack zoeken een scrummaster

Tweakers behoort samen met AutoTrack, Nationale Vacaturebank en Intermediair tot De Persgroep Online Services. Op dit moment heeft De Persgroep Online Services verschillende scrumteams, waaronder een voor Tweakers en een voor AutoTrack. Voor de ondersteuning van die twee scrumteams zoeken we een scrummaster.

De Persgroep Online Services

Werken bij De Persgroep Online Services betekent meewerken aan grote digitale merken, zoals Tweakers, AutoTrack, Nationale Vacaturebank en Intermediair. Een team van gepassioneerde professionals werkt binnen Online Services aan de continue groei en uitbreiding van deze merken. Gesteund door de stabiele basis van De Persgroep wordt er volop geïnnoveerd en gezocht naar nieuwe technieken, methodes, kansen en mogelijkheden.

De scrumteams werken met een variatie aan technieken en tools, die per titel verschillen. Voor Tweakers zijn dat onder andere PHP, Java, MySQL en MongoDB, en voor Autotrack kun je denken aan PHP, Scala, Angular en een Continuous Delivery pipeline, die onder meer gebruikmaakt van Jenkins, Docker, GIT en Ansible, ondersteund door Acceptance Scenarios (als onderdeel van ATDD/BDD).

Scrummaster bij De Persgroep Online Services

Als scrummaster bij Online Services ga je werken met de scrumteams van Tweakers en AutoTrack. Omdat het een overkoepelende rol is over twee merken, rapporteer je organisatorisch aan de CTO van De Persgroep Online Services en functioneel aan de Business Unit Managers van Tweakers en AutoTrack.

Het is jouw uitdaging om te ervoor zorgen dat het Agile-gedachtegoed niet alleen binnen de scrumteams, maar ook breder in de organisatie ten volle wordt uitgedragen. Wij zien de scrummaster als de olie tussen de raderen, als de persoon die het proces vloeiend laat lopen en die dus de scrumteams in staat stelt om elke dag weer op topniveau te presteren.

Wat verwachten wij van een scrummaster?

Als scrummaster ken je als geen ander de spelregels van het 'Agile' werken. Je begeleidt, coacht en ondersteunt de scrumteams van Tweakers en AutoTrack proactief bij de uitvoering van hun werkzaamheden. Zo draag je eraan bij om, vanuit het proces, projecten tot een goed einde te brengen. Daarnaast ben je dé sparringpartner voor de Product Owners en help je hen met Backlog-refinement en het prioriteren van story's. Daarnaast ondersteun je hen bij het stakeholdermanagement. Je zoekt naar kansen om naast de scrumteams ook de managementteams van Tweakers en AutoTrack te onderwijzen in het Agile-gedachtegoed en hen te begeleiden bij hun Portfolio-planning. We verwachten dus dat je breder kunt kijken dan alleen naar de eigen scrumteams.

Samen met de scrummaster van Nationale Vacaturebank en Intermediar ben je bovendien actief in de begeleiding van het managementteam van Online Services op de 'road to agility'. Met de CTO, developmentmanagers en architecten wissel je ideeën uit over de toekomst van de scrumteams.

Wat is jouw achtergrond en wat zijn jouw competenties?

We zoeken iemand die aantoonbare ervaring heeft met het werken als scrummaster. Daarbij is een PSM/CSM-certificering gewenst. Je hebt dan ook gevorderde kennis van de Agile-principes en -methoden. Kennis over de gebruikte technieken en tools is een voordeel, maar uitgebreide developmentervaring is niet vereist.

Je bent proactief, durft verantwoordelijkheid te nemen, bent besluitvaardig en vooral een sterke communicator. Daarbovenop ben je een coach en mentor, en kun je dus goed omgaan met mensen. Je spreekt en schrijft vloeiend Nederlands, maar ook Engels is jou niet vreemd.

Als bonus heb je eventueel ervaring in het werken als projectmanager of teamleider en weet je dus wat er nodig is om een team te motiveren en te stimuleren.

Wat bieden wij?

Naast uitstekende arbeidsvoorwaarden, een 38-urige werkweek en een toplocatie aan het IJ om vanuit te werken, is er veel ruimte voor persoonlijke ontwikkeling. De professionele, sociale en ondernemende collega’s zijn gewend om continu op zoek te gaan naar vernieuwende werkwijzen en producten. En successen vieren we met elkaar.

Enthousiast? Vragen?

We horen graag van je! Neem voor meer informatie over deze rol als scrummaster contact op met onze recruiter Linda Brandenburg via 06-21179809. Je kunt uiteraard ook direct solliciteren op deze vacature.

Reacties (134)

Ik denk dat ik te oud ben geworden voor deze site.... wat de fuk is een Scrummaster?

https://www.scrumalliance...certified-scrummaster-csm

Het is een redelijk zware certificering waarbij je als lead optreedt voor verschillende teams en daarmee een leidende rol kan bekleden zonder de uitkomst van het proces daadwerkelijk te beinvloeden.

Zwaar? Ik heb het certificaat en het is een online examen zonder tijd, dus als je iets niet weet kan je het zomaar opzoeken. Het certificaat stelt niets voor, iedereen met een beetje social skills en goed inzicht kan scrum master zijn.

Niet geheel waar, als je het examen gedaan hebt (wat inderdaad niet moeilijk is, heb hem zelf ook gedaan na tweedaagse training) krijg je toegang tot de online omgeving van de scrum alliance, wil je verder groeien zul je daar je ervaring moeten aantonen (Scrum Education Units (SEUs) behalen) en vervolgens vervolg certificering behalen waarbij zwaardere eisen gelden. Daarnaast vervalt je certificering voor scrum master na twee jaar tenzij je deze gaat verlengen.

Eisen vervolg scrummaster:
Be a current holder of an active CSM, CSPO, or CSD credential.
Have a minimum of 36 months of successful Agile/Scrum work experience gained within the past 5 years implementing Scrum inside organizations as team member, product owner, ScrumMaster, or "Other." (Provide details for "Other" in the "How did you use Scrum on this job" field at the bottom of the Work Experience section of your profile page. Align your experience to the basic Scrum roles as much as possible.)
Gather and submit 70 Scrum Education Units (SEUs) from the past three years. Note that SEUs earned from your CSM (up to 16 SEUs), CSD (up to 24 SEUs), and/or CSPO (up to 16 SEUs) certifications can put you well on your way. Your CSD, CSM, or CSPO training can be more than 3 years old. All other SEUs need to have been earned within the past 3 years. See our Earn SEUs for your CSP page for more details.
- See more at: https://www.scrumalliance...tion#sthash.sCJ9qHQE.dpuf

[Reactie gewijzigd door lubbertkramer op 28 januari 2016 10:41]

@homewrecker: Waar kan ik die online cursus vinden?

Ik heb een opleiding gevolgd via het werk en dan heb ik via Scrum Alliance het examen gedaan. Het kost je wel 50€ en het vervalt inderdaad na twee jaar. Pure oplichting dus want na twee jaar blijft de methodiek hetzelfde. Ze verplichten je dan om terug 50€ neer te leggen om een nieuw 'geldig' certificaat te halen.

Die andere examens zijn niet zozeer moeilijk, de trainingen zijn vrij makkelijk en bijgevolg slaag je vrij makkelijk voor de examens. Het is maar te zien wat je wil, als je scrum master wil zijn kost dit je 50€, wil je daarbovenop nog product owner, of iets anders wat ze zonet uitgevonden hebben, worden dan moet je een nieuwe training en examen doen.

Ik draai al geruime tijd mee in een paar organisaties die scrum doen en versta me niet verkeerd. Het kan een team echt hechter maken en alles goed doen draaien, maar na verloop van tijd heeft het geen zin meer om scrum te doen. De kleine problemen kan je oplossen met retrospectives maar de grote organisatorische problemen, daar kan je weinig aan doen en dat zijn meestal de problemen die overblijven na een tijd.

Hetzelfde met de filosofie van iedereen moet alles kunnen. Ik heb analisten nog niet erg veel zien programmeren, noch heb ik testers veel zien programmeren. En je kan in die zin jongleren met de functiebeschrijvingen.

Conclusie: ik was in het begin enorm fan, we hadden elke keer een goed draaiend team maar na een tijd wordt het gewoon overhead. Wat ik nu zeg ligt nogal gevoelig bij veel mensen maar ik ben ervan overtuigd dat elke werkkracht/project zijn vervaldatum heeft.

[Reactie gewijzigd door Homewrecker op 28 januari 2016 14:19]

Àh, bedankt voor de info. Wat 'grappig' wat je schrijft. Ik ben namelijk ook niet overtuigd van het werkelijke nut voor de klant maar het wordt overal gevraagd en toegepast. Ik heb het idee dat het veelal toegepast wordt om de inkomsten te garanderen/ continue te houden of te maximaliseren voor het ontwikkelbedrijf. Dus heeft weinig met de klant te maken. Gewoon niet willen investeren in een klant, de klant betaald altijd wat het resultaat ook is. Het wordt gebracht als een soort toverformule maar de klant is eigenlijk de pineut van deze werkwijze. Heb gezien dat alles wel volgens tijdschema gaat maar dan worden er wel zaken weggelaten. Dus als iemand een uitbreiding wil is dat meteen weer kassa, een nieuw project. Leuk voor de inkomsten maar of dat nu een klantvriendelijke manier is.....

[Reactie gewijzigd door codebeat op 28 januari 2016 14:47]

Mijn ervaring is compleet tegenovergesteld. Ik heb het idee dat klanten juist een veel beter product krijgen omdat ze echt onderdeel zijn van het team. Je kan veel beter gebruik maken van voortschrijdend inzicht bijvoorbeeld. Waterfall projecten eindigen veel vaker in een eindproduct wat achteraf eigenlijk niet is wat de klant nodig had. Daarnaast werkt alles vooruit specificeren in de praktijk gewoon niet goed.

En ik denk ook dat scrum veel beter aansluit bij programmeurs omdat ze meer eigen verantwoordelijkheid/ownership krijgen. Iedereen kan nuttig bijdragen en je voelt je als team verantwoordelijk voor het eindresultaat.

Er zijn vast bedrijven die het gebruiken om hun klanten geld uit de zak te kloppen maar diezelfde bedrijven zouden dat net zo goed doen met een andere methodiek. Meerwerk komt denk ik veel vaker voor bij waterfall projecten .

"Meerwerk komt denk ik veel vaker voor bij waterfall projecten ."

Niet echt. Wanneer in scrum de scope wordt bepaald, dan kan die achteraf nog gewijzigd worden. Dat is het grote verschil met waterval. Het enige probleem is, dat de looptijd van het project hetzelfde blijft, zoals bij waterval. Wat dit dan als resultaat heeft is dat er features van de backlog worden geflikkerd in ruil voor aanpassingen aan bestaande functionaliteit.

Dat is min of meer wat ik bedoel. Bij waterfall ben je als leverancier verplicht om te leveren wat is afgesproken. Ook als de klant tijdens project achterkomt dat een bepaalde feature eigenlijk minder belangrijk is dan een nieuwe feature. Het geeft de klant de vrijheid om dingen in te wisselen.

Bij waterfall resulteert voortschrijdend inzicht vrijwel altijd in meerwerk. En het is ook demotiverend voor ontwikkelaars om iets op te leveren waar de klant soms niet meer op zit te wachten.

Het kan een team echt hechter maken en alles goed doen draaien, maar na verloop van tijd heeft het geen zin meer om scrum te doen.

Ik snap wel wat je zegt, maar als je nog eens goed de gedachte achter "kaizen" erop naslaat, wil ik dit toch wel tegenspreken.

Een team is nooit klaar met verbeteren. Als een team na verloop van tijd alleen nog maar kleine dingetjes heeft, is het misschien een idee een ander soort retrospective te doen. Je kan altijd verbeteren.

Mocht je daarnaast tegen de organisatie aanlopen die niet mee wilt veranderen is dat natuurlijk weer een uitdaging op zich. Ik ben er zelf van overtuigd dat "agility" of het agile werken niet stopt bij alleen het Scrum team. De organisatie kan mee veranderen.
Maar goed - dat is natuurlijk in theorie wel leuk; ik kan me voorstellen dat in jouw specifieke geval daar ook redenen zijn dat er geen beweging in zit.

Grappig dat je het een methodiek noemt. Het is een framework, geen methode. Dat zou jij, als scrummaster, goed moeten weten. Tevens moet binnen SCRUM niet iedereen alles kunnen, juist niet. Uit je hele reactie maak ik op, dat je SCRUM niet goed begrijpt.

Zelf heb ik ook het certificaat, evenals veel collega's. Het certificaat halen is inderdaad echter niet zo moeilijk. De moeilijkheid, en tevens de kracht van het framework, is het toepassen ervan. Het bijbehorende denkproces is voor veel mensen erg lastig en daarom heb je een goede scrummaster nodig die snapt hoe het werkt om te coachen en de processen te bewaken.

Dat SCRUM voor extra inkomsten zorgt is ook niet waar, het zorgt voor een goed eindproduct en een klant die het gevoel van voortgang behoud. Mocht er tijdens het traject bijgesteld worden, dan zullen hier gegronde redenen voor zijn, en een goed projectteam / projectmanager kan de klant dan ook overtuigen van de noodzaak om aanpassingen te doen aan het project in opvolgende sprints.

[Reactie gewijzigd door OriginalFlyingdutchman op 28 januari 2016 16:47]

Hoe kan ik dan via ScrumAlliance een examen volgen voor 50 euro, waarmee ik een Scrum certificaat kan behalen?

Ik heb het indertijd via een tussenpartij gedaan, die hebben toen gezorgd dat ik het certificaat kon halen. Na twee jaar was het vervallen en zou ik terug 50€ moeten betalen om het te verlengen. Pure afzetterij dus.

Ik ben wel geïnteresseerd in een certificaat. Kun je mij vertellen hoe ik dat kan aanpakken zonder dat ik een dure tussenpartij moet inschakelen?

Je moet sowieso een cursus volgen, dat kan je overal doen. Als je die cursus hebt gevolgd, dan kan je online het examen doen.

Dat snap ik. Maar hoe pak ik dat aan, zonder dat ik een dure tussenpartij moet inschakelen? Als ik erop Google, dan kom ik telkens bij een duur tussenpersoon terecht. Ik zou gewoon direct een online cursus + examen willen volgen voor certificaat.

Dat weet ik eerlijk gezegd niet.

Zwaar? Kom op.
Als je de juiste mindset hebt krijg je alleen maar meer energie van een Scrum Master training.
De Scrum Master training van Scrum.org duurt (meestal, ligt aan de opleider) 2 dagen, en daarna kun je online certificeren.
Ja, je moet wel wat inzicht ontwikkeld hebben met die training wil je slagen voor het examen, maar moeilijk is het niet echt.

Het is juist enorm fun om met teams te werken die zelfsturend zijn, eigen verantwoordelijkheid hebben, waar je als Scrum Master voor mag zorgen dat zij hun werk kunnen doen door impediments weg te nemen.
Natuurlijk kom je allerlei problemen tegen: traditionele projectleiders die op hun manier grip willen houden, afhankelijkheden waar je soms niet omheen kunt en meer, maar ik verwacht die bij zo'n vacature als deze nauwelijks: Tweakers is op en top Agile

Scrum / Agile werken sluit naadloos aan bij mensen die van lean werken houden: continu bezig zijn met verbeteren.
Voor mij was het geweldig toen ik er in 2010 mee te maken kreeg.
Inmiddels ben ik met enkele collega's kartrekker van onze Agile Community bij Enexis (ACE).
Gisteren hadden we weer een maandelijkse Lunchmeet die we organiseren, dit keer met de Belastingdienst als gastspreker, echt onwijs tof dat we dat kunnen doen.

Overigens valt er veel meer Agile op te pakken: zoals requirements, daarvoor heb ik enkele maanden geleden ook een training gevolgd met methoden die ervoor zorgen dat je met grote groepen belanghebbenden - Product Owners (zoals bij een ketenproject dat door meerdere afdelingen heenloopt) toch in zeer korte tijd een flinke set aan features / User Stories op papier weet te krijgen, iets dat met waterval aanpakt gewoon niet meer mogelijk is (te complex is).

We gaan bij ons nu ook aan de slag met SAFe (check scaledagileframework.com), waarmee we onze organisatie nog meer Agile gaan maken.

Ik heb wel eens tegen een team gezegd dat het onvermijdelijk is, Agile werken, tijdens een conflict over ingrijpen in een Scrum team door projectleiders die zeiden dat niet alles Agile zal gaan lopen. Ben toen het team uitgekickt, maar gelukkig zie ik die mannen nu ook aanschuiven bij onze Agile Lunchmeets en trainingen (die ik nu ook zelf geef).

Nee, ik ga niet solliciteren

Je weet wel waar je over praat, ik dacht even dat dit een moderne sollicitatiebrief was

De Professional SCRUM Master 1 certificering is inderdaad heel eenvoudig. Deze certificering dekt dan ook alleen de kennis van het toepassen van de SCRUM-regels. De PSM 2 certificering is een stuk zwaarder en alleen voor SCRUM-masters met veel praktijk ervaring, waarschijnlijk vergelijkbaar met de 2de certificering van scrumalliance (zie hierboven).

Mijn vrouw is Scrum Master (niet in de ICT) en we hebben de organisatie van onze huwelijksdag gescrumd, gewoon op het witeboard in de keuken. Het maakte de voorbereidingen veel leuker en de dag zelf liep uiteindelijk fantastisch!!

Ik heb sterk mijn bedenkingen bij SAFE. Heb het nog nergens zien werken.
Het loopt meestal de mist in wanneer management agile probeert te werken...

Je kunt een organisatie creëren op basis van SAFe.
Maar management zal inderdaad eerst overtuigd moeten zijn van Agile werken voordat ze dat aandurven.

In ieder geval is het onontbeerlijk voor veel organisaties gezien de complexiteit waar ze mee kampen: Agile werken is daar de oplossing voor.

De organisatie moet sowieso agile werken omarmen wil je dat het goed gaat. SAFe is echter een must als je met veel scrum teams aan een portfolio of een product werkt. Ik ken een paar bedrijven die SAFe toepassen en waar het goed werkt. In het begin is het lastig maar na een poosje word het steeds beter

Als ik me niet vergis is iedereen in een SCRUM team gelijk, een scrum master beïnvloed dus ook niets. Scrum master is er uiteindelijk om de SCRUM processen te bewaken en impediments weg te halen zodat het team verder kan.

Zit er stiekum over na te denken om zelf richting scrum master te gaan, maar weet niet of ik de software ontwikkeling vaarwel wil zeggen.. beetje jammer van mijn master SE anders

Dat hoeft toch ook niet? als Scrummaster zit je toch ook gewoon in het development team?

EDIT:
Het is me inmiddels duidelijik dat dit meestal niet het geval is, iets wat dus anders is bij mijn huidige stage.

[Reactie gewijzigd door StefanJanssen op 28 januari 2016 18:09]

Wellicht dat je bij kleine projecten als scrummaster mee kan ontwikkelen, maar bij grotere projecten krijg je daar echt de tijd niet voor.

Ah, ben nu bezig met mn eerste project met agile dus heb er niet zoveel verstand van

Volgens de vacature niet: development ervaring is niet nodig.

Bij elk team is het anders. Er zijn Scrum teams waarbij ze de Scrum Master rol beleggen bij een van de developers. Dus ja, dan zal je meeprogrammeren.

Er zijn ook bedrijven (zoals de Persgroep) die de Scrum Master rol als losse FTE (vol tijd functie) willen inzetten.

Het is een beetje eeuwige discussie of de Scrum Master moet kunnen programmeren of niet. Mijn persoonlijke mening is dat het niet noodzakelijk is om zelf applicaties te kunnen schrijven, maar dat het wel handig is om te snappen wat de basics inhouden. Dit is iets wat ook met training on the job kan.

Ik kan zelf geen software schrijven, maar dat heeft mij de afgelopen periode als Scrum Master bij Tweakers (naar mijn mening) niet in de weg gestaan.

Op zich niet, de scrummaster maakt onderdeel uit van het scrum team, dit bestaat naast de scrummaster uit een product owner en het development team.

Nope, mij werd verteld door de oude scrum master dat hij scrum master was over verschille de teams, en dat ze hij zelft niet hoeft te ontwikkelen.
De taak vd scrum master is ook om te zorgen dat het team ongestoord aan het werk kan.
Hier hebben ze er dus voor gekozen om de scrum master op deze manier in te zetten.
Met grote en meerdere projecten ben je al druk genoeg als scrum master met het organizeren

Het is maar net hoe ver je het trekt . Ik ken scrum teams die goed lopen en waar de scrum master (die eerst wel veel werk deed) zijn scrum master taken heeft overgedragen aan een lid van het development team. En dat lid had ook een scrum master certificaat.

Een scrum master is een facilitator; hij zorgt ervoor dat de rest van het team optimaal kan werken. Hij lost onduidelijkheden op en gaat achter missende informatie aan. Als je in hiërarchische termen denkt zit de scrum master tussen de product owner (=klant) en het development team in. Als je met een extern scrum team werkt is de scrum master vaak in dienst bij de leverancier en de product owner bij de klant (al kan een account manager of iemand anders ook de rol van product owner vervullen eventueel).

Scrum master is bijvoorbeeld ook verantwoordelijk voor het organiseren van de standups/poker sessions/retrospectives.

Scrum master rol kan ook gecombineerd worden met andere rol in het team (met uitzondering van product owner denk ik). Dus een scrum master kan ook prima een tester of developer zijn, zolang diegene maar beschikbaar is voor het team.

Methode om een project in goede banen te leiden. Scrum is iets van de laatste jaren wat erg veel wordt gebruikt en erg goed werkt. Tevens is het vrij makkelijk te leren

Meer info: https://nl.wikipedia.org/...softwareontwikkelmethode)

Incorrect. Een project in goede banen leiden doet een projectmanager met bijvoorbeeld een methode als PRINCE2.

SCRUM is geen methode, het zegt je niet hoe je moet werken. SCRUM geeft grenzen aan (framework), en door het respecteren van die grenzen, en het leren werken binnen die grenzen zorg je ervoor dat je op een effectieve manier voortgang houdt in je werkzaamheden. Het team moet bijvoorbeeld een sprint review houden, maar de manier waarop dat gebeurt, mag het team zelf invullen.

Als SCRUM master zorg je ervoor dat je team als een geoliede machine werkt. Je faciliteert alle mogelijke benodigdheden en zorgt dat iedereen in dezelfde "spirit" blijft werken. Jouw team bepaalt wat kan of wat niet kan binnen een sprint. De methodes die het team verder gebruikt, dat is aan hen, zij zijn de professionals met de benodigde kennis.

Bijvoorbeeld als een projectleider komt klagen dat iets niet snel genoeg gaat o.i.d. Dan zul jij als SCRUM master ervoor zorgen dat die druk niet bij je SCRUM team komt te liggen, daarbij zul je het belang van SCRUM uitleggen aan de projectleider. De taak van de projectleider is vervolgens de klant duidelijk maken dat andere keuzes gevolgen hebben, zodat deze een goed afgewogen beslissing kan nemen.

Het grote voordeel van dit alles is dat je team op een efficiënte manier samenwerkt en er niet op 20 verschillende plekken getrokken wordt aan dit team. Behoudens de vaste momenten bepaald in het SCRUM framework, kunnen ze voor de volle 100% focussen op het daadwerkelijk "werk".

En alles wat je nu zegt is in jou ogen niet iets in goede banen leiden

"SCRUM is geen methode, het zegt je niet hoe je moet werken"

SCRUM stelt dat je daily standups dien te hebben, retrospectives, dat je user stories schrijft, een backlog beheerd, velocity beheerd, sprint planningen doet....en jij beweerd vervolgens dat SCRUM zich niet bemoeid met het HOE?

Leestip: 'De Kracht van Scrum'. Goed leesbaar en zeer inspirerend.

Ik vind dit ook een heel erg inspirerend filmpje over scrum/agile.
https://vimeo.com/110554082
Code god: Erik Meijer

Niet werkzaam binnen de IT zo te zien. Scrum is al enige jaren een veel gebruikte projectmanagement methode binnen de IT.

@wimdebok hieronder
Niet vreemd, maar logisch. Scrum is zoals ik hierboven zeg een projectmanagement methode. Het is geen antwoord op technische uitdagingen, maar op organisatorische uitdagingen.

[Reactie gewijzigd door FreqAmsterdam op 28 januari 2016 11:19]

Zoals gezegd geen methode. Het grote probleem met SCRUM is dat mensen het verwarren met een methode en daardoor de meerwaarde niet meer zien. SCRUM kan daarentegen heel goed gebruikt worden binnen een project waar bijvoorbeeld PRINCE2 als methode gebruikt wordt.

Zo lang PRINCE2 geen invloed heeft op het scrum process. Voor projectmanagers die PRINCE2 altijd gebruiken is het heel moeilijk om de controle los te laten en het team zelfsturend te laten zijn.

Ik denk dat ik te oud ben geworden voor deze site.... wat de fuk is een Scrummaster?

Veel software development teams werken tegenwoordig via agile methodieken waarvan Scrum er 1 is. In die Scrum methode is er een rol weggelegd voor de Scrum Master. Wat doet hij dan?? Lees de vacature

Bij SCRUM gaat het er ook om dat elk teamlid veel kennis heeft van zaken en er niet 1 verantwoordelijke is. Iedereen is verantwoordelijk. In principe houdt je elke ochtend een korte meeting wat er vandaag gedaan gaat worden en werk je in (korte) sprints om zaken op te leveren. Best een fijne methode

Niet persé 100% scrum, maar de essentie wordt wel erg duidelijk met deze twee video's over agile werken bij Spotify:
https://www.youtube.com/watch?v=Mpsn3WaI_4k
en
https://www.youtube.com/watch?v=X3rGdmoTjDc

Zelf vind ik ze erg inspirerend.

verschrikkelijk Engels woord ja... roept niet direct associaties op met een professioneel beroep. Zowaar is scrum nog een echt woord ook:
an ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side. The ball is thrown into the scrum and the players try to gain possession of it by kicking it backward toward their own side.

agile scrum lean mvp
back to common sense please
https://lukehalliwell.wor.../11/16/the-agile-disease/
2008 mind you..

Voor de mensen die geinteresseerd zijn is er een gratis webinar op http://www.netvlies.nl/scrum-voor-beginners/

een soort werkvoorbereider (ofzo) voor projectteams

Alles behalve juist... De product owner is meer een werkvoorbereider voor het Scrum team, aangezien hij de persoon is die het werk ("items op een Backlog") ordent en klaarzet.

De Scrum Master is dan meer een dienende leider

"Scrummaster" geeft de leiding aan "The Scrum's" in sidequest voor D&D. Opzich heeft hij zelf geen goeie stats en zijn damage is maar 1d10 met 20HP. het grote gevaar zit hem in de grote groepen die vaak om hem heen lopen. deze side quest start in het oosten van "Nerath" bij de grensovergang van "Vailindor" naar "Barony of Brandil."
Goed te doen als je groep ongeveer level 6 is en je dungeonmaster niet te hardcore gaat.

ontopic: echt geen flauw idee

Deze vergelijking: Opzich heeft hij zelf geen goeie stats en zijn damage is maar 1d10 met 20HP. het grote gevaar zit hem in de grote groepen die vaak om hem heen lopen.

Is eigenlijk veeeel meer kloppend en juist dan je zelf doorhebt denk ik... hahah ik ga hem in ieder geval wel vaker gebruiken!!

IT lingo voor regelneef/regelnicht.

Dit is wat ik letterlijk hardop zei bij het lezen van dit artikel. Gelukkig ben ik dus niet de enige

Grappige discussie die hier ontstaat. Ik ben zo afgeknapt op de implementatie van Agile in de meeste bedrijven dat ik het als een nadeel zie niet als een voordeel als men claimt met Agile te werken. Iedere dag een half uur weggooien met een daily standup die uiteraard zittend gedaan wordt omdat niemand zo lang kan staan. Waarbij 80% van wat de mensen me vertellen zo weer het andere oor uit gaat omdat het niks te maken heeft met wat ik doe, of gewoon niet uitgelegd wordt wat het voor mij zou kunnen betekenen.

Dan nog het gemekker met story points die uiteraard niet bindend zijn maar wel overal gebruikt worden om je performance te tracken en die performance is natuurlijk weer wel van toepassing op je salaris. Altijd een kant-en-klaar design wat op een vast ingestelde datum af moet zijn en natuurlijk schaven we het vooraf bedachte idee niet achteraf bij want dat zou betekenen dat iemand's ego wel eens geknakt zou kunnen worden.

Maar we doen Agile hoor. Kijk maar: daily standups, Jira, story points, (bi)weekly sprints, scrum master in plaats van een team lead.

Nee dan liever dat ene bedrijf waar je gewoon per week je prioriteiten bijstelt, al van te voren weet dat je eerst snel iets neer zet en daarna gaat verfijnen en iedereen die je nodig hebt binnen een uur reageert. En het woord Agile nog nooit gevallen is.

[Reactie gewijzigd door BikkelZ op 28 januari 2016 19:02]

Het feit dat je zegt dat de stand-ups een half uur duren is al voldoende signaal dat jullie dus nooit de methode op juiste wijze hebben ingezet.

Storypoints van invloed op je salaris?!?

Het is jammer dat veel mensen door een slechte implementatie van Scrum (of andere Agile methode) afknappen op iets wat aantoonbaar werkt.

Ik weet niet wie bij jullie verantwoordelijk was voor het Agile werken maar zoals ik het zo lees snap ik dat je het bagger vond..

Heb het bij veel bedrijven gezien. Harde deadlines met vast verankerde features zijn dingen waar sommige bedrijven nou eenmaal echt aan vast zitten. Bij Apple moet alles ook weer presenteerbaar zijn op de WWDC. Sommige bedrijven deden dan toch "Agile" terwijl er helemaal niks flexibel was (behalve mijn werkuren natuurlijk!).

Agile werkt maar bij een beperkte groep projecten en dan nog moet je kijken wat er echt werkt binnen je team en wat niet.

Heb het bij veel bedrijven gezien. Harde deadlines met vast verankerde features zijn dingen waar sommige bedrijven nou eenmaal echt aan vast zitten.

Eens; dit heb ik zelf ook meegemaakt hoor... Een CEO die graag Agile wilt zijn en daar zegt z'n best voor te willen doen maar vervolgens precies dit wat jij zegt aanhoud.

Een juiste implementatie vergt ook van management een commitment om dingen anders te doen. Anders om te gaan met deadlines en harde features.

Past het altijd, overal, op elk moment? Nee, niet volgens de harde regels van Scrum miss; maar je kan wel altijd een modus vinden waarin je meer lean je product ontwikkeld.

Agile als methodiek adopteren is i.m.h.o. de theorie doorgronden en ook die van:
- Vriend Edward Yourdon
- Watervalmodel
- IAD
- RAD
- (R)UP
- XP
- Prince 2 (Dat is uiteraard een grapje; wie dat ooit verzonnen heeft, heeft enkel in de schoenen van een "bewaker" gestaan en heeft nooit als onderdeel van een ontwikkelteam gewerkt)
- En vele anderen

Het is met de methodieken en "theoriën" meer een conventie "kneden" naar wat het project(team) nodig heeft en met z'n allen weten "how deep to go down the rabbit hole" om een product op maat en naar wens te krijgen.
Je niet laten "verzinken" in de code en de code modulair genoeg maken om het ook gemakkelijk te kunnen hergebruiken.

Regels in deze methodieken zijn er om te "buigen" naar de behoeften van allen. Als je met 10 man in een stand-up staat zal deze met inhoud gemakkelijk over de 10 min. uit komen en is het de vraag of je niet in kleinere groepen stand-ups moet doen. Tenzij je chronisch rugpatient bent blijf je staan en vermeld je wat er "boeiend" is; blockers, afsluitingen, en de items die je die dag gaat aanpakken.
In detail treed je op afspraak later met elkaar en/of met de scrummaster.

De score kaarten / het planningpoker is iets dat je met name doet om te merken wie wat goed en snel "pretendeert te kunnen" om vervolgens door de werkelijkheid te worden ingehaald en in een next run een betere schatting (lees realistischere schatting) te kunnen maken.
Je werkt als team en zal dus geregeld de koppen bij elkaar moeten steken.

Het grootste belang is dat je communiceert; iets dat voor menig (soms ietwat introvert) IT-er lastig kan zijn, zeker als je al wat jaartjes in een ivoren torentje zit en in je uppie het werk hebt gedaan.
Maar je maakt elkaar beter en het team efficiënter door deze aanpak.

Een scrum-master is onderdeel van het team en mediator tussen business en het team en staat boven de project materie, maar niet boven het project in hierarchie, ook al draag hij verantwoording en hakt hij met regelmaat knopen door. Daarmee is een "arrogante" scrum-master is zoals iedere arrogante IT-er; een puist in een team.

Regels in deze methodieken zijn er om te "buigen" naar de behoeften van allen. Als je met 10 man in een stand-up staat zal deze met inhoud gemakkelijk over de 10 min. uit komen en is het de vraag of je niet in kleinere groepen stand-ups moet doen. Tenzij je chronisch rugpatient bent blijf je staan en vermeld je wat er "boeiend" is; blockers, afsluitingen, en de items die je die dag gaat aanpakken.
In detail treed je op afspraak later met elkaar en/of met de scrummaster.

Volgens scrum is 10 al te groot voor een dev team. 9 is echt de absolute max (7 als je scrumprinciples volgt en niet scrumguide).

Een scrum-master is onderdeel van het team en mediator tussen business en het team en staat boven de project materie, maar niet boven het project in hierarchie, ook al draag hij verantwoording en hakt hij met regelmaat knopen door. Daarmee is een "arrogante" scrum-master is zoals iedere arrogante IT-er; een puist in een team.

Ik weet niet welke verantwoording je hier bedoelt maar de scrum master is alleen verantwoordelijk om te zorgen dat scrum goed word toegepast. Hij hakt dus helemaal geen knopen door op dingen die daar niet mee te maken heeft. De PO is verantwoordelijk voor het eindelijke product en het dev team van de implementatie daarvan en ook de keuzes die worden gemaakt. Juist omdat het dev team zelf de verantwoording draagt voelt men zich meer betrokken en denken ze ook beter na over keuzes.

Enigzins herkenbaar. Dergelijke implementaties van SCRUM gaan voorbij aan de 2 kernwaarden van het Agile manifesto:

1. Klanten weten pas tijdens ontwikkeling wat ze nu echt willen
2. Ontwikkelaars komen pas tijdens de ontwikkeling erachter hoe ze iets gaan implementeren

Bedrijven die niet met die feitelijke waarheden om kunnen gaan bouwen schijnzekerheden in. Daarmee verbergen ze in feite bovenstaande waarheden, maar deze komt er toch wel uit.

Dergelijke implementaties van SCRUM gaan voorbij aan de 2 kernwaarden van het Agile manifesto:

1. Klanten weten pas tijdens ontwikkeling wat ze nu echt willen

Misschien snap ik niet wat je bedoeld maar Scrum faciliteert juist dit punt... Omdat je in korte sprints werkt ben je in staat elke keer de richting van je product aan te passen.

Als voorbeeld hebben we ooit in Sprint 1 een basis van een product opgeleverd aan een klant. Toen ze zagen hoe het werkten kwamen ze toch met aardig wat aanpassingen. Geen probleem; in sprint 2 over een andere boeg gegooid en zo had de klant na 4 weken al precies wat ze in gedachten hadden.

Dat lijkt mij toch snel kunnen inspelen op de veranderende wensen van de klant?

Dat bedoel ik dus: SCRUM een reactie op die 2 waarheden. We zijn het dus eens.

Eens! Al heeft Agile voor ons ook duidelijk voordelen. Wij zijn na een tijdje over gegaan op maandelijkse sprints (wekelijks ging simpelweg te snel omdat wij niet fulltime aan een project werken) en doen wekelijks een standup, al is het eigenlijk gewoon een bespreking. Die punten laten we achterwege, maar we bekijken wel welke onderdelen lastig kunnen zijn en welke onderdelen we de komende sprint gaan oppakken. Jira en Fisheye voor reviews vind ik erg prettig. Zeker omdat je code die je commit naar de SVN direct terugziet bij source changes. Vraag een review aan en anderen kunnen overzichtelijk feedback geven. Hoewel ik het volledig met je eens ben dat de situatie die je schetst het werkproces niet beter maakt, moet ik toch bekennen dat veel onderdelen van Scrum erg handig zijn. Sprints om in stappen een werkend product op te leveren, standups om inzicht te krijgen in moeilijkheden en problemen, Jira om te zien waar aan gewerkt wordt en met name de backlog om zicht te houden op het project. Zo slecht is het nog niet, maar bedrijven moeten niet overdrijven en Agile willen werken omdat het hip is.

Je moet werken op de manier die het beste past bij het team, de klant en het project. En niet overal een Agile saus over heen gooien alsof het HeLa curry is.

Ken weinig marathon lopers die dat volhouden .. de hele marathon sprinten ..
Ja maar met agile hebben hebben we die marathon toch opgedeeld in behapbare "sprints" ...
Erhhmmm ja .. maar je moet blijven sprinten .. enige verdeling van krachten .. enige reflectie .. ach waar hebben we het voor nodig.
Nou mag het alleen maar een "naampje" zijn, maar vaak is de naamgeving toch een aardige indicatie van hoe het uitgevoerd wordt.

Toch vreemd dat er aan de Scrummaster geen enkele ICT inhoudelijke eisen gesteld worden. Ik zou toch denken dat de Scrummaster uitgebreide ervaring moet hebben met: PHP, Java, MySQL en MongoDB, , Scala, Angular, Continuous Delivery, Jenkins, Docker, GIT, Ansible en uiteraard Acceptance Scenarios. Zou een technische baas niet slimmer zijn en dat hele scrum gewoon aan de kant gooien? En je dan echt met de inhoud bezig houden.

Een scrum master zorgt er louter voor dat programmeurs als team werken in samenwerking met de cliënt. Een voetbalcoach hoeft ook geen prof voetballer te zijn om goed te kunnen coachen.

Overigens, ironisch dat tweakers mensen wil die de 'regels' van agile kennen en vervolgens wil dat ze vanuit het proces gaan werken... So much for people over processes

Ik blijf het vreemd vinden dat rollen die zo belangrijk zijn in het scrum proces geen inhoudelijke achtergrond vragen. Je moet wel enige kennis hebben om een goede inhoudelijke dialoog met je mede collega's op te zetten. Het mag duidelijk zijn, ik moet er helemaal niets hebben van het gescrum, het gaat over procesbegeleiding en gaat niet over de ICT inhoud. Scrum gaat over controle om over die kinderachtige rituelen maar te zwijgen. Want uiteindelijk draait het uit op de vraag, is wat wij ware scrum of niet. Een verkeerde discussie naar mijn mening. Kwakzalver iCT.

Maar waarom is het de taak van een scrummaster om uberhaupt zo'n inhoudelijke dialoog aan te gaan? Dat is juist het gene waarvan je toch wel mag hopen dat de developers (+ eventuele lead developers en architecten) en productowners daar goed in zijn?
Juist de andere aspecten van scrum zouden bij ons onderbelicht raken als we niet iemand hebben die in de eerste plaats goed het team kan begeleiden. Daar is inhoudelijke kennis uiteraard welkom bij, maar niet hetgene waar we hoge eisen aan stellen.

Anders gezegd; de scrummaster is belangrijk voor het scrumproces, niet voor de technische inhoud van de resultaten.

Je moet wel enige kennis hebben om een goede inhoudelijke dialoog met je mede collega's op te zetten.

Technisch inhoudelijk? Absoluut niet nodig.
Coaching skills (denk aan, goed luisteren, de juiste vragen kunnen stellen)? Hard nodig.

Ik heb vaak tijdens standup een developer een technisch inhoudelijk verhaal horen afsteken waar de rest van het team niet op inging. Toen ik vroeg wat zijn volgende stap was en hij door praatte, ging het team opeens reageren dat ze het er niet mee eens waren --> luisteren en vragen stellen

Scrum gaat over controle om over die kinderachtige rituelen maar te zwijgen.

Dit klinkt mij meer in de oren als iemand die ooit een slechte ervaring met Scrum (of andere agile methodiek) heeft gehad en er nu op afgeeft.
Wat veel mensen vergeten:
De regels van Scrum zijn aardig simpel, om het goed toe te passen is extreem lastig.

Die zin heb ik met name geschreven om aan te geven dat het niet zozeer aan de Scrum Master is om vanuit de (product) inhoud te sturen/coachen/begeleiden, maar meer vanuit het proces (het moet toch ergens gebeuren).

Het klopt wat je zegt: people and interactions over process. Dat probeer ik dan ook in mijn rol altijd toe te passen binnen Tweakers en een beetje Scrum Master (of anders bekende met de rol) zal dat denk ik ook wel snappen.

Erg leuke uitdaging. Als er wat minder "uitdagende" projecten zouden zijn had ik graag gesolliciteerd zou zonde vinden om nu uit te stappen.

De positie om als scrummaster tussen twee bedrijven in te zitten is een lastige.
(De hele stelling eigenlijk al)
Zeker als je er maar 1 (klein) devteam onder hebt.
Beste benadering is gewoon de programmeertijd per partij "halveren" of per 4 weken switchen van "backlog"
8 man of meer met "gelijke competenties" dan twee teams van 4.

D'r wordt niet echt ingegaan op het devteam dat er achter zit, wat misschien een mooie aanvulling is voor de vacature. Met elkaar zal je het immers moeten doen.
Wordt "meneer Cure" ook onderdeel van het devteam? (Groetjes van @@D!; ex- IQ-er Eric)

Wel ff wat typo's in de vacature opschonen, hoor Arjen:
"Pergroep"
"verwoordelijkiheid"

Er zijn juist twee geheel losse teams (dus eigen devvers, eigen productmensen, eigen backlog, e.a.) voor Tweakers en voor AutoTrack. Maar de scrummaster-functie wordt bij ons ook weer niet zo zwaar geacht dat ieder van die losse teams een eigen, fulltime scrummaster nodig heeft. Vandaar dat we hem willen delen tussen de twee bedrijven.

[Reactie gewijzigd door ACM op 28 januari 2016 10:39]

Als de backlog items niet als paddestoelen uit de grond schieten en de commitment van de scrum-master ook weinig architectuur behelst moet dat goed te doen zijn.
Ten behoeve van de sprints zou 't voor de scrum master wel lekker zijn om a-synchrone cycli aan te houden voor de urgentiespreiding en commitment van de scrum-master richting de business.

Inhoudelijk dan even:
AutoTrack werkt met sprints van 2 weken en Tweakers met iteraties van 3 weken (vandaar ook elke 3 weken een nieuwe .Plan over wat er is opgeleverd).
Dat is dus prima te doen.

Verder is alles zoals ACM al zei gescheiden, dus had ik als SM een mooie mix tussen 2 toffe bedrijven.

1:3 kans dat er wat livegang enigszins samen valt; klinkt inderdaad als prima te doen.

Ja het komt in de praktijk idd wel eens boor dat ik een sessie met de
Teams dubbel geboekt heb staan, maar is in de praktijk nooit echt problematisch geweest

Yep, ik ben uiteraard ook onderdeel van het devteam wat bij deze vacature hoort... maar momenteel nog op vakantie in Costa Rica

Costa Rica? Lekker!!!
Enjoy nog maar eventjes zonder 'stand-ups'

Scrum is een afgeleide versie van projectmanagement. Bij scrum word veel waarde gehecht aan direct contact en in korte periodes veel bereiken. Ook wel sprints genoemd. Scrum is ideaal voor software ontwikkeling omdat in korte periode veel software geschreven kan worden en als er in de eerste versie fouten zitten kan deze in de tweede versie er vaak uitgehaald worden en desnoods helemaal opnieuw geschreven worden. Wat ontbreekt aan Scrum is de kwaliteitscontrole en de administratie. Dit maakt Scrum ook sterk tegelijk. Geen onnodig werk en in korte tijd zoveel mogelijk bereiken.
Scrum teams bestaan vaak uit een kleine groepen mensen met één taak. Deze teams worden geleid door een scrummaster die het proces begeleid en het doel in ogen houd. Dan heb je ook nog een productowner. Die is de eigenaar van het project en stelt de eisen van het product op. Dan zijn er ook nog de software ontwikkelaars die het werk uiteindelijk doen.

Scrum is eigenlijk een verkorte versie van Prince2. Ideaal voor software ontwikkeling maar niet geschikt om grote organisatorisch problemen op te lossen. Vaak ontbreekt het ook aan registratie.
Scrum werkt maar gebruik het alleen waar het echt is voor bedoeld.

Wat ontbreekt aan Scrum is de kwaliteitscontrole en de administratie

Dat is incorrect. Testers zijn ook gewoon onderdeel van het scrum team. En welke administratie bedoel je? Het is juist enorm duidelijk waar de tijd aan wordt besteed.

"Wat ontbreekt aan Scrum is de kwaliteitscontrole en de administratie"

Dat is onjuist. SCRUM pleit voor een "definition of done" voor iedere user story op de backlog. Dat kan inhouden testen, een code review, een kennisoverdracht, net wat van toepassing is. Daarbovenop komt de demo aan de product owner is, die stories accepteerd danwel afwijst, wat ook een kwaliteitscontrole is.

'road to agility'

Ah, we willen wendbaar zijn, maar wel graag de weg volgen als het even kan

Het bedrijf heeft nog een hoop te leren ja, maar een beetje Scrum Master ziet daar juist de uitdaging in

Dat is voornamelijk omdat onze vorige scrummaster nogal passief was

Mag ik vragen wat er gebeurd is met jullie vorige scrummaster?

Tuurlijk, al kan hij dat zelf waarschijnlijk veel beter uitleggen CaptRondo was onze ScrumMaster maar heeft een welbekende "Offer you can't refuse" gekregen. Wat dat exact inhoud mag hij zelf uit de doeken doen mocht hij daar behoefte aan hebben. Vandaar dat hij zijn skills elders ten uitvoer gaat brengen. Het is dus allemaal op goede voet gegaan en we zullen hem in de toekomst vast nog eens zien voor een biertje.

Goed om te weten.. Kom vaker bedrijven tegen die personeel op straat zetten als iets niet bevalt. Jouw reactie gaf het gevoel dat hij vervangen werd omdat hij te passief was. Als je solliciteert is het toch prettig om te weten in welke bedrijfscultuur je terecht komt

Beetje wat Inspector zegt idd.
Ik had/heb het erg goed naar mijn zin bij Tweakers (en AutoTrack), maar kreeg een kans aangeboden die op dit moment nog beter aansluit bij mijn wensen en mogelijkheden.

In het openbaar de ex-werknemer afbranden als "passief"... Leuk voor die ex-werknemer dan.

Nog mensen die hier willen werken?

Ja het is ook best een slechte werkomgeving... ik werd vaak beledigd en gekleineerd.. maar daar leer je mee om gaan...

Zie hier ook een mooie uitdaging aan de Scrum Master om te kunnen dealen met dit type developers

In feite maakt die certificering dus geen klap uit en heb je net zoveel aan een goede projectleider als aan een "great scrum master".

Ik heb verder totaal geen verstand van dat hele gescrum (dus ik kan het zomaar mishebben) maar als ik het zo lees lijkt het mij alleen maar weer een zoveelste manier om ergens geld aan te verdienen, interessant te doen met een enorme berg nikszeggende engelse termen en afkortingen, en om maar weer een soort verkapte managementlaag in een organisatie te proppen.

Grappig om te horen dat je wel een oordeel hebt over iets waar je geen verstand van zegt te hebben.

Los daarvan denk ik dat je op een aantal vlakken best gelijk hebt en deel ik zelfs wat meningen;
Certificering maakt geen klap uit om als goede projectleider op te treden. In de regel is dat één van de taken die een scrum-master vervult.
Sterker nog, ik denk dat ervaring bij projectbeheersing boven de theorie gaat.

Ze hebben zeker allemaal hippe termen bedacht voor weer een methodiek (Agile / Scrum) die neer komt op "meer met elkaar communiceren" (Stand-up), "laten we de actiepunten wegen met het belangrijkste beginnen" (Planningpoker & Backlog) en "how to eat an elephant; piece by piece" (Sprint).

Wanneer iets alleen serieuze vormen aan begint te nemen en meer dan 2 ontwikkelaars betrokken worden (er kan er immers 1 onder te tram komen of opstappen, je kan meer capaciteit nodig hebben of meer projecten parallel willen laten lopen en je wil je als bedrijf daar niet op vertraging toeleggen en continuiteit hebben), kan het overzicht kwijt raken en o.a. de communicatie naar de "aanvrager" van features "verwateren".

Juist dat soort dingen regelt een scrum master en hij bemiddelt zodat developers kunnen doen waar ze goed in zijn, beter worden en elkaar aanmoedigen op vlakken waar ze moeite hebben en vooral niet teveel van de hak op de tak bezig zijn.
Ook zorgt hij dat incidenten / problemen niet per definitie op het bord van de oorspronkelijke ontwikkelaar belanden maar dat deze worden opgevangen door een team dat de incidenten classificeerd en zich in eerste instantie toelegt op de nazorg. (Functioneel beheer)

Iedereen wil betaald worden voor het steken van energie in het bedrijf waar hij bij werkt dus het lijkt mij geen zonde om te worden betaald als je je werk naar behoren doet.
Sceptisch zijn is belangrijk want het kan de dialoog openen en daarmee inzichten geven aan alle partijen. Inzicht geeft begrip.

Zonder er al te diep of ongenuanceerd op in te gaan; de "verkapte managementlaag" moet je zien als een brug tussen mensen uit het bedrijf die in de regel de primaire bedrijfsbehoefte vervullen en de ondersteunende dienst. (IT).

Een goede scrum-master moet voor ieder development team met veel werk of waar veel verwachtingen op rusten een steunpilaar en een welkome toevoeging zijn.
Als het enkel iemand is die naar cijfers en opleversnelheid kijkt zit hij als je 't mij vraagt op de verkeerde plek.

Ik mag er dan geen verstand van hebben maar ik kan wel lezen.

Als ik dan dus op die scrumwebsite kijk word ik doodgegooid met "interessante" engelse termen en de standaard vage beschrijvingen die je werkelijk overal ziet. En zo is ook vrijwel deze hele vacature hier op tnet.

Het is al jaren zo dat er (engelse) termen gebruikt (en de meeste vreemde termen verzonnen) worden om het maar interessant en poepstatig te laten lijken. Wat vroeger gewoon de chef was heet nu ineens de shop manager. Je bent niet meer vooruitdenkend maar proactief. En zo gaat het werkelijk overal mee. Je bent niet meer dom maar mentaal uitgedaagd. Je bent geen schoonmaker maar interieurverzorger. En ga zo maar door.

Ik krijg altijd jeuk van dat soort dingen en bij het lezen van dat hele scrumgebeuren kreeg ik heel erg veel jeuk

Iedereen wil betaald worden voor het steken van energie in het bedrijf waar hij bij werkt dus het lijkt mij geen zonde om te worden betaald als je je werk naar behoren doet.

Ik doelde hierbij meer op de "bedenkers" en "aanbieders" van deze methodiek. Trainingen hier en trainingen daar die uiteraard flink veel geld kosten.

Zo krijg ik ook altijd jeuk van termen als "teamplayer" e.d. Het doet mij ook heel erg denken aan de teambuildingcursussen die tegenwoordig zo in trek zijn. Een soort geforceerd vriendjes worden met je collega's ofzo.

Het is het hele pakket van verschijnselen waar ik jeuk van krijg en ik vind het lastig om duidelijk samenhangend uit te leggen hoe dat zo komt.

Ik vraag me ook serieus af of dergelijk methodieken/functies er ook daadwerkelijk voor zorgen dat er betere producten gemaakt worden. Als ik zo kijk wat er in het algemeen geproduceerd en aan diensten geleverd wordt neig ik te denken van niet namelijk. Dat is waarschijnlijk ook een reden waarom ik van dit soort dingen jeuk krijg.

Maar ook dat is natuurlijk sterk afhankelijk van het perspectief waarvan uit je kijkt ...

Verder heb ik steeds meer afkeer van de dronification (als we dan toch bezig zijn met mooie termen ) van de hele maatschappij. En ook hier krijg ik dat gevoel bij. Het gaat er niet meer om dat je een groep werknemers hebt (o nee, een "team" natuurlijk ) die gewoon goed samenwerkt (iets met elkaar liggen en aanvullen op een natuurlijke manier) en gestuurd wordt door een eventuele chef maar meer dat iedereen het liefst zoveel mogelijk in zijn eigen kleine hokje gaat zitten doen waar hij/zij in gespecialiseerd is.

De zogenaamde smeerolie die vanzelf zou moeten voortvloeien uit die "klik" en uit de gaven van een chef (want in principe word je niet voor niks chef) wordt nu toegewezen aan weer een aparte "drone".

Het is het "geforceerde" en "kunstmatige" waar ik een probleem mee heb.

Uiteraard heb je (zeker als het hele grote bedrijven betreft met grote projecten) wel een zekere methode nodig om de hele boel een beetje soepel te laten verlopen maar ik ben er van overtuigd dat mensen niet geschikt zijn om (tot op microniveau) te functioneren als een bijenkolonie. Als je begrijpt wat ik bedoel.

Ghehehe ik kan je goed volgen.

Een team met programmeurs is echt niet zoals een computergrid.
Iets dat je met de juiste "methodiek" kan sturen naar je hand.

De ene persoon is "georganiseerder" dan de ander. Mijn ervaring is dat het duidelijk schetsen van de doelstellingen mijzelf (en andere) programmeurs helpt in het simplificeren van een vraagstuk. Ook het ondervangen van mogelijke "ruis" (telefoontjes / mailtjes e.d.)
Het tijdig de gedachten losweken van iets dat geen oplossing lijkt te kennen is met een team efficienter te benaderen. (Met elkaar er over denken of spontaan twee personen van taak laten ruilen)
Je leert van elkaar en elkaars fouten.

Het zijn en blijven mensen en het bereiken van een doel is iets waarmee sommige teamleden echt begeleiding nodig hebben en anderen komt het natuurlijk aangewaaid.
Ik vind het de truuk om het samenspel als een sport / spel te zien en niet te serieus te zijn. Als je met een stok in je r33t het team probeert z'n werk te laten doen loop je gewoon tegen personen aan die dit niet accepteren.
Daarbij is dat niet de meest sociale benadering.

Het kunnen en durven toegeven van je fouten is iets dat binnen een team gewaardeerd wordt. Nobody's perfect en af en toe jezelf "afzeiken" mag ook best als je in een versioning system oude designs / code tegen komt waar geen hout van klopt.

Och scrum..

Op mijn hogeschool worden we ermee doodgegooid en moeten onze projecten via scrum methodology gemaakt worden
Scrum is een techniek die gebruikt word om bepaalde projecten uit te voeren, blijkt heel effectief te zijn. Beter dan de oude waterfall method.

Ik ben benieuwd hoe dat gaat op school dan. Zoals ik ergens anders hierboven (of beneden) ook al schreef:
De regels van Scrum zijn zeer eenvoudig te begrijpen, maar het goed implementeren en uitvoeren is zeer lastig.

Ik hoop in ieder geval dat door de wijze waarop het op je school wordt toegepast je niet te negatief komt te staan in het proces an sich

Ja gezien scrum voor langere periodes zijn bedoelt en projecten duren vaak maar 3 weken maximaal. Dus dat loopt vaak een beetje stroef en gebruiken we ¨stiekempjes¨ soms waterfall methode. Maar wat we moeten doen bijv. zijn de standups met wat we hebben gedaan en wat we deze dag gaan doen binnen de scrum sprint.

(Het is niet heel super geïmplementeerd maar het gaat om het idee en dat je weet hoe het gaat denk ik.)

De projecten hoeven niet "maar" 3 weken te zijn.
Doel is alle features op te splitsen en een schatting te maken van een selectie die je verwacht binnen dit tijdbestek op te leveren.
Dat kan soms meer en soms minder zijn.

Niet gerealiseerde doelen vallen weer terug naar de backlog en met de tijd zal dat aantal minder worden omdat je schatting van realisatie beter wordt.

Je doorloopt in de regel een OTAP straat (Ontwikkeling, Test, Acceptatie, Productie) en zal dus eigenlijk mondjesmaat de features opleveren.
Één enkele sprint kent eigenlijk geen iteratie en zou je als een waterfall aanpak kunnen beschouwen. (Ookal zullen er veel mensen het niet met mij eens zijn)

Net als iedere methodiek geeft het wat handvatten; een rode draad en een beetje sturing. Het maakt niet het project; het helpt alleen in het opleveren en werken als team.

Een "project" van 3 weken wordt in geen enkele methode uberhaupt erkend als een project. Bijna iedere methodiek is in dat geval overkill.

Scrum is in de game wereld ook heel hot.
Games worden uitgebracht en de rest van de content wordt in scrums komt later als DLC.

Koen Kuijpers en een tafeltennistafel. Betere arbeidsvoorwaarden zijn er volgens mij niet te vinden.

Vergeet de Airhockey, Arcade kast, Mario Kart en tafelvoetbaltafel niet! Ook allemaal met Koen erbij. Voor iedereen, gewoon solliciteren dus

[Reactie gewijzigd door Inspector op 28 januari 2016 10:54]

Even wat tegenwicht voor alle Scrum-liefhebbers hier

Maar even zonder dollen. Ik heb zeer ruime ervaring als software engineer in diverse settings, en de beste resultaten komen in mijn ervaring steevast van teams die geen Agile doen, maar zich focussen op waar ze goed in zijn: het bouwen van software. Geen enorm ceremoniele processen (want dat is wat Scrum wat mij betreft is), maar het werkelijk uitbaten van de expertise van developers en het omarmen van de hacker culture en de werkelijke flexibiliteit die daarmee gepaard gaat.
Het lijkt er op - zeker als ik alle verhalen over enorme certificeringstrajecten lees in de comments hier - dat Agile het nieuwe Waterval wordt, met een ongezonde dosis Prince2 om het nog ineffectiever te maken. Erik Meijer ageert hier al een tijdje tegen, en als je langs zijn schuimbekken heen kijkt, zit er veel wijsheid in. Een opvatting waar ik me in kan vinden is dat Agile vaak een mechaniek is om mediocriteit van developers te maskeren. Zoals Meijer het zegt:

processes, such as Scrum or Agile, are really a way to take “low educated employees” under control so their product is still average quality. The hacker way, on the opposite, privileges experienced programmers that know how to build stuff and do not really need a process.

Dit zal ongetwijfeld een controversiele mening blijken, maar ik kan niet anders zeggen dan dat ik het zo ervaren heb. Scrum is soms nodig als je met minder goede developers werkt. Werk je met top developers, dan zit het alleen maar in de weg. En laten we eerlijk zijn, als bedrijf zou je altijd moeten streven naar het inhuren van top personeel toch?

[Reactie gewijzigd door Kajel op 29 januari 2016 01:34]

Even wat tegenwicht voor alle Scrum-liefhebbers hier

Maar even zonder dollen. Ik heb zeer ruime ervaring als software engineer in diverse settings, en de beste resultaten komen in mijn ervaring steevast van teams die geen Agile doen, maar zich focussen op waar ze goed in zijn: het bouwen van software. Geen enorm ceremoniele processen (want dat is wat Scrum wat mij betreft is), maar het werkelijk uitbaten van de expertise van developers en het omarmen van de hacker culture en de werkelijke flexibiliteit die daarmee gepaard gaat.

Het vervelende is alleen dat de 'hacker mindset' van zelf onderzoeken en het laten varen van een strakke projectorganisatie heel moelijk in een commerciëel bedrijfsproces in te passen zijn. Managers willen resultaten zien en kunnen kwantificeren hoeveel hun developers precies voor het bedrijf opleveren zodat ze die uren ook naar de afdeling Financiën kunnen verantwoorden.

Waar je alleen mee zit is dat een creatief denkproces niet in keiharde euro's of produktiviteit uit te drukken is. Het is niet zo dat een uurtje langer denken precies 10% meer product oplevert, terwijl het bovenliggende management wel dat soort cijfers wil zien.

Voor zover ik het weet zijn technieken zoals Aglile en Scrum vooral bedoeld om de "zelforganiserende" hackergedachte in te kunnen passen in grotere bedrijfskundige processen en grote projecten met veel ontwikkelaars, maar het wordt vaak slecht geïmplementeerd en door een manager naar binnen gehaald als "de nieuwe productiviteitstool". Daardoor worden ze geen middel meer om meer gedaan te krijgen, maar een doel op zich.

Dat het hele proces een beetje overdreven doorspekt is met managers-jargon helpt niet altijd mee.

Als scrummaster ken je als geen ander de spelregels van het 'Agile' werken. Je begeleidt, coacht en ondersteunt de scrumteams van Tweakers en AutoTrack proactief bij de uitvoering van hun werkzaamheden. Zo draag je eraan bij om, vanuit het proces, projecten tot een goed einde te brengen. Daarnaast ben je dé sparringpartner voor de Product Owners en help je hen met Backlog-refinement en het prioriteren van story's. Daarnaast ondersteun je hen bij het stakeholdermanagement. Je zoekt naar kansen om naast de scrumteams ook de managementteams van Tweakers en AutoTrack te onderwijzen in het Agile-gedachtegoed en hen te begeleiden bij hun Portfolio-planning. We verwachten dus dat je breder kunt kijken dan alleen naar de eigen scrumteams.

Dit is denk ik het meest wollige, lege, pretentieuze stukje vacature dat ik ooit gelezen heb? Agile, coacht, scrumteams, sparringpartner, product owners, backlog-refinement, story's (stories??), stakeholdermanagement, managementteams, enz.

Hier zat iemand te tikken die denkt dat het intelligenter lijkt wanneer je veel Engelse woorden en scrum-specifieke termen gebruikt?

En dan:

...maar uitgebreide developmentervaring is niet vereist.

[Reactie gewijzigd door GeoBeo op 28 januari 2016 10:58]

Het is natuurlijk op zich wel logisch om scrum-specifieke termen te gebruiken bij een extreem scrum-specifieke vacature zoals scrummaster. Of heb ik dat verkeerd?

Naar mijn ervaring zijn methodes voor project begeleiders en managers ervoor om de zaken voor iedereen simpeler en overzichtelijker te maken, niet ingewikkelder.

Scrum lijkt mij zo'n methode die bedacht is om zichzelf in stand te houden door o.a. nodeloos ingewikkelde termen te gebruiken. Waarom een Engelse methode gebruiken met Engelse terminologie binnen een (blijkbaar) Nederlandse omgeving?

Het voelt als een typisch middle-management mode-dingetje waar organisaties prima zonder kunnen. Maar goed, dat is mijn mening als outsider.

Dat is nou eenmaal vrij gebruikelijk in de IT... Er zijn zoveel woorden uit het engels die we hebben overgenomen, denk aan: server, database, development, deployment, browser, compiler, website en nog vele meer.
Het concept scrum en de rol scrummaster is nou eenmaal 'ingeburgerd' via de Engelse terminologie. Dan kan je wel al die termen proberen te vertalen, maar ik betwijfel of het daar nou zoveel duidelijker van wordt. Op deze manier weten in ieder geval ook niet-nederlandstalige collega's (en collega's die wel nederlandstalig zijn maar niet onze vertaling gebruiken) ook waar je het over hebt.

Ik denk zelfs dat als je het wel vertaald; dat je het dan juist onnodig moeilijker maakt, al is het alleen maar omdat iedereen dan eigen vertalingen gaat proberen te verzinnen

Scrum is verder op zich niet ingewikkeld; hoewel je het natuurlijk zo moeilijk of makkelijk kan maken als je wil. De rol van scrummaster is zelfs niet per se iets dat overal in een los persoon moet worden opgepakt. Hoewel wij wel van mening zijn dat dat meerwaarde heeft, zeker omdat deze persoon daardoor een zekere onafhankelijkheid kan krijgen. Bovendien hoeven we dan ook niet te zoeken naar iemand die zowel deze rol goed kan vullen als de vereiste inhoudelijke kennis heeft voor het overige van de taken (want er zijn dan geen overige taken).

Het 'probleem' is dat we wel mensen zoeken die die tekst juist kunnen interpreteren, want het zijn veel woorden die je vaak bij je dagelijkse werkzaamheden zal gebruiken. Dat kunnen we dan wel vertalen naar een simpele nederlandse woorden maar dan heb je kans dat een potentiele kandidaat de vacature niet meer als interesant ziet want hij komt 'zijn' terminology nergens tegen.

Natuurlijk is het een tikkeltje aangedikt en kan het ook anders opgeschreven worden, maar dan is het voornamelijk de ene 'lege' term door een andere 'lege' term vervangen.

Valt wel mee toch , er zijn er zijn nog veel meer van die begrippen http://www.scrum.nl/site/Scrum-Begrippen-agile-scrum. Deze hebben wij overigens niet zelf verzonnen, het zijn vaste begrippen uit de scrummethode, we kunnen ze wel naar het nederlands vertalen, maar ik het is nog een hele uitdaging om bijvoorbeeld 'Scrum Master' een goede Nederlandse vertaling te geven.

Thanks voor de feedback in ieder geval! Zoals al gezegd heb ik een aantal woorden expliciet gebruikt om ook een bepaalde doelgroep aan te spreken.

De vergelijking tussen mijn tekst en dan development ervaring niet vereist snap ik niet...
wat zegt het een over het ander?

IT vacatures zijn vaak zo wollig en/of vol met IT vaktaal wat vrij normaal is binnen de IT.
En veel vacatures worden door managers opgesteld die soms zelf niet eens goed weten wat al die buzzwords nou precies beteken.

Je krijgt de duimen naar beneden maar het is wel degelijk waar wat je zegt. Je leest soms zulke rare ICT vacatures met ook nog een onwaarschijnlijke lijst van competenties. En dan zit je er eenmaal blijkt het heel anders in elkaar te steken. Ik ken ze, tig programmeertalen, framework, libs die je zou moeten kennen. Het is toch altijd, wat je niet weet google je er wel bij?