Scrum is ooit begonnen als een alternatieve manier om met name ICT projecten beter te organiseren. Tegelijk met Scrum was er – ook in ICT kringen – de ontwikkeling van extreme programming en nog een andere agile methodes die allemaal een ICT grondslag hebben. Met het succes van Scrum (en de andere agile methodes) wordt er steeds meer gekeken of deze methoden ook buiten ICT projecten zin hebben.
Wat is Scrum eigenlijk?
Voor diegenen die nog onbekend is met Scrum: de aanpak van een scrum project verschilt met die van een ’traditioneel’ project door niet van te voren alles proberen vast te leggen in een projectplan. Het projectresultaat wordt wel omschreven, maar min of meer. Vervolgens wordt er door een team in een aantal iteraties (korte periodes van een week of een paar weken ook wel ‘sprints’ genoemd) naar het resultaat toegewerkt. Na elke iteratie (‘sprint’) is er overleg met de opdrachtgever en wordt het project bijgestuurd. Hierdoor is er beter contact tussen opdrachtgever en team en kan er veel beter (en sneller) bijgestuurd worden door het uitvoerend team. Dit is vooral handig als men het projectresultaat nog niet helemaal voor ogen heeft (en zeg nu eerlijk in welk project weet men echt helemaal precies wat men wil aan het begin). Misschien denkt men het te weten, maar in de praktijk verandert er meestal een hoop gedurende het project). Tot zover een hele korte introductie op Scrum (en in feite ook op de andere agile methodes).
Lees ook: Wat is Scrum?
Scrum als je geen softwareontwikkeling doet?
Binnen ICT organisaties is massaal Scrum omarmd. De vraag is nu heeft scrum zin binnen een bedrijf dat geen IT projecten doet? En dan bedoel ik niet een ander voornamelijk technisch of wetenschappelijk bedrijf waar men nieuwe producten ontwikkelt of te maken heeft met veel innovatie. Daar is Scrum zeker nuttig vanwege de hoge mate van onzekerheid. De vraag is hier: heeft Scrum zin in bijvoorbeeld een administratieve organisatie, bij een communicatiebureau of een redactie van een website, in een museum of in de zorg? Organisaties waar projecten gedaan worden die niet zo technisch complex zijn als software ontwikkeling of onderzoek naar een nieuwe energietechnologie maar waar men toch te maken heeft met enige mate van chaos die bij projecten hoort. Bijvoorbeeld:
- hoge werkdruk en moeite om alle door elkaar lopende projecten en projectjes te managen
- gebrek aan overzicht over het werk
- te weinig contact met opdrachtgevers
- opdrachtgevers die vaak van mening wijzigen (creatieve organisaties?)
- projecten die half technisch zijn, bijvoorbeeld een tekstbureau dat met content management systemen werkt op het web
- creatief werk dat lastig in te schatten is qua urenbelasting
- organisaties waar veel ‘ff’ snel tussendoor moet
- organisaties waar er in (wisselende) teams gewerkt wordt
- projecten die te klein zijn om er een heel projectplan voor te schrijven, maar waarvoor toch een en ander georganiseerd moet worden.
Uiteraard heeft traditioneel projectmanagement antwoorden op bovenstaande punten, die in feite neerkomt op het aanbrengen van een aantal structuren en de discipline van eerst denken (plannen) en dan doen. Maar Scrum heeft ook antwoorden op bovenstaande veelvoorkomende problemen bij projectorganisaties. Bijvoorbeeld door dagelijks te beginnen met een kort groepsoverleg en het werk te bespreken kan men een hoop van bovenstaande zaken beter regelen. Zeker als er een kanban bord bij gebruikt wordt waar het werk op verdeeld wordt.
Scrum termen voor niet programmeurs
Scrum is bedacht door programmeurs en de termen die ze erbij toepassen zijn voor mensen buiten de ICT wereld soms nogal abstract. Een “product backlog” met “user stories” is in feite een lijst met wensen (“user stories”) die de nieuw te ontwikkelen software moet kunnen (een ‘klanten-wensen-lijst’ dus). Een “product owner” is de persoon die praat tussen de mensen die een projectresultaat wensen en het uitvoerend team. Hij of zij is ook de persoon die uiteindelijk bepaalt welke dingen van de wensenlijst als eerste gemaakt gaan worden. Een scrum master is in feite een coach die het team helpt met de scrum discipline (zoals elke ochtend starten met een kort overleg). Als je gaat werken met Scrum met niet ICT-ers is het verstandig om de lijst te vertalen naar herkenbare termen bijvoorbeeld:
| User Story | Wens |
| Product Backlog | Wensenlijst |
| Sprint | Cyclus, iteratie, periode |
| Sprint Backlog | Todo lijst |
| Product Owner | Taakverdeler |
| Scrum Master | Coach, begeleider |
| Storypoints | Werkhoeveelheid, complexiteit |
| Definition of done | Afspraak wanneer goed genoeg |
(maar andere termen zijn ook mogelijk).
Is Scrum dan ook een oplossing voor alle organisaties?
Een van de krachtigste elementen van Scrum is dat een team niet boven zijn capaciteit gaat werken. Het heeft (op de wat langere termijn) gewoon geen zin om een groep mensen structureel te overbelasten. Bovendien komen mensen die in een scrum team zitten meer in de flow en is er door de nauwere samenwerking in de regel sneller en beter resultaat. Al is het maar door het intensievere contact tussen klant (opdrachtgever) en uitvoerenden.
Scrum gaat uit van teams tussen de 6 en 9 mensen en van ingewikkelde en moeilijk te plannen (onzekere) projecten. Agile heeft ook een aantal elementen die je niet kan toepassen in een niet technische omgeving (unit test, refactoring, pair programming) of zult moeten ‘vertalen’ naar een niet-technisch equivalent (bv. de definition of done). Werkt Scrum dan bijvoorbeeld bij een marketingbureau waar teksten geschreven moeten worden en onderzoeken moeten worden gedaan door een team van 3 tot 5 mensen? Wat als het gaat om veel kleine projectjes die veelal door elkaar gedaan moeten gebeuren? Mogelijk helpen scrum principes hier, al is het maar om de workflow en capaciteit van dit (kleine) team of de berg aan projectjes beter te regelen. Je hoeft Scrum ook niet in zijn geheel te adopteren. De implementatie van een kanban bord en dat elke ochtend met elkaar bijwerken is mogelijk al voldoende om de werkdruk te beperken en als groep in de flow te komen.
