Mooi artikel. Scrum in een nutshell... Echter, volgens de Scrum Guide:

- bestaat een Scrum team uit een Product Owner; een Scrum Master en een ontwikkelteam. (Een Scrum team kan natuurlijk geen Scrum team in zichzelf hebben. Dat lijkt mij niet logisch en zeer verwarrend);

- bestaat een ontwikkelteam team uit 3 tot 9 leden (de Product Owner en de Scrum Master niet meegerekend). Dus niet zoals hier vermeld: eerst "maximaal 7" en vervolgens "vier tot maximaal negen" en

- is het ontwikkelteam niet alleen zelf-organiserend maar ook cross-functioneel. De leden hebben dezelfde skills en kunnen elkaars werk overnemen. Dit is zeer wezenlijk voor Scrum.

Goed dat er een artikel over Scrum op managementsite staat, en goed dat er gezocht wordt naar manieren om dit buiten IT toe te passen! Mooie samenvatting ook.

Zelf werk ik al een aantal jaar als Scrum Master en geef ook regelmatig trainingen aan organisaties die in de IT-sector opereren maar ook daarbuiten. Vanuit die achtergrond heb ik een aantal toevoegingen op het artikel.

Ten eerste mis ik de term 'business value' in het artikel. Een belangrijk uitgangspunt van Scrum is dat teams elke sprint (business) waarde genereren door de taken die in de sprint voltooid worden. (Business) waarde kan zijn: het genereren van omzet, het verhogen van klanttevredenheid, het verminderen van supportcalls, het verminderen van waste in het proces, enzovoorts. De Product Owner is de persoon in het team die kan bepalen wat de (business) waarde is van elk item op de backlog en op basis hiervan beslissingen neemt en prioriteert.

Ik benadruk het belang van (business) waarde omdat je perfect kunt Scrummen zonder waarde te genereren voor de organisatie. Dat gebeurt helaas heel vaak. Het is tenslotte ook moeilijk om te bepalen wat de waarde is van punten op de backlog. Maar als je dit niet doet, dan ga je tijd verspillen aan niet-relevante zaken en introduceer je veel verspilling in je proces.

Ten tweede worden veel technieken genoemd die niet noodzakelijk of nodig zijn binnen Scrum. Planning poker is weliswaar nuttig, maar niet nodig. Ditzelfde geldt voor het schrijven van user stories. Dit is geenszins noodzakelijk, en werkt vaak juist tegen als het verplicht wordt gemaakt. Uiteindelijk gaat het er om dat een backlog bestaat uit afgekaderde brokken werk die (zoveel mogelijk) individueel (business) waarde realiseren als ze voltooid zijn en die zodanig zijn opgeschreven dat iedereen in het Scrum Team er kaas van kan maken.

Ten derde mis ik het concept van timeboxing. Binnen Scrum is het belangrijk dat alle 'events' (sprint planning, sprint review, retrospective) qua tijd duidelijk gekaderd zijn. Zo voorkom je eindeloos gepraat. Het voorkomt ook de observatie van de auteur dat het samenvoegen van de retrospective en de sprint planning problemen geeft. Ik merk dit probleem zelf niet zo vaak. Vaak combineer ik de sprint review, retrospective en planning zelfs op 1 dag. De retrospective is dan vaak juist het moment waarop een team op ontspannen wijze stoom af kan blazen. Hier zijn ook leuke werkvormen voor.

Ten vierde zou ik het gebruik van electronische middelen beperken. Het probleem met 'tools' is dat mensen denken dat de tool al het werk wel doet. Scrum is vooral een menselijk proces. Als je een grote monitor in de kamer zet met een backlog, dan slaat de energie vaak volledig dood. Iedereen zit te wachten tot de persoon die het keyboard heeft klaar is met tikken. Gebruik liever een paar whiteboards en postits. Eventueel kun je het na de sprint planning overnemen in een tool.

Tenslotte mis ik een belangrijk punt in de filosofie achter Scrum; complexiteit is niet beheersbaar. Ondanks al onze pogingen om te proberen van tevoren te voorspellen wat de loop gaat zijn van een project, gaat dit vrijwel altijd mis. De praktijk leert dat je beter kunt 'denken door te doen' in plaats van 'denken voordat je doet'. Bij Scrum is het idee vaak dat je maar beter kunt beginnen, maar dat je zeer regelmatig kritisch kijkt of je nog business waarde aan het genereren bent. Zo niet, dan moet je bijsturen.

Om nog terug te komen op het begin; je ziet in alles direct of indirect terugkomen dat het al dan niet genereren van business waarde de drijvende motor is achter een Scrum Team. In de praktijk blijkt dit super belangrijk, maar super moeilijk.

Het kopje kennisdelen deed mij gelijk triggeren om dit artikel te lezen.
Wat ik niet begrijp hoe je corporate information en successes kunt delen.
Vooral doordat grotere bedrijven niet van elkaar dingen weten.
Zoals ik het lees is scrum bedoeld om tijdens een project fase met leden informatie te kunnen delen door de scrum aanpak.
Is dat correct?

Vriendelijke groet,
Luuk Mooibroek

Luuk, ik denk dat Scrum in die context vooral nuttig is omdat kennis wordt gedeeld binnen een team in plaats van dat de focus ligt op het vastleggen van kennis. Binnen Scrum is het inderdaad belangrijk dat wordt gedacht in termen van een 'team mind'. Die kan meer onthouden dan de individueen, en is bovendien ook minder gevoelig voor het wegvallen daarvan. Kennis in een team, zo is de gedachte, is beter geborgd dan kennis in een systeem. Dan is het slechts informatie.

Doordat je binnen Scrum alles als team doet, en er geen sterke specialisaties meer zijn, is kennisdeling optimaler. Ik denk dat je het zo op moet vatten.

Helaas veel overbodige Engelse termen ('agile', 'retrospective', 'stand-up' enz.), wat voor de acceptatie van deze methode niet bevorderlijk is.