’Scrum’ is een ‘agile’ methodiek die oorspronkelijk is bedacht voor het ontwikkelen en in gebruik nemen van software. Op een gegeven moment is men deze aanpak ook gaan toepassen bij andere projecten, en ook als werkwijze om met lerenden aan projecten te werken. Kun je deze aanpak ook gebruiken voor de invoering van ICT voor het versterken van opleiden, onderwijs en leren?
#/media/File:Scrum_process.svg)
De Scrum-methodiek is ontwikkeld als antwoord op de zogenaamde watervalmethode waarbij eerst lang werd nagedacht over functionele eisen van een ICT-systeem. Vervolgens maanden werd besteed aan de ontwikkeling ervan, waarna gebruikers werden geconfronteerd met een ICT-oplossing die toch niet aan de wensen bleek te voldoen.
Bij Scrum ontwikkel je een ICT -oplossing in kleine stappen, waarbij je zeer snel de gebruiker laat werken met een product dat op zich werkt, maar nog verder zal worden uitgebreid. Je maakt dus intensief gebruik van gebruikerservaringen om het systeem door te ontwikkelen.
Ik heb bij de Open Universiteit bijna vijf jaar gelden kennis gemaakt met Scrum bij de ontwikkeling van OpenU, en daarna van yOUlearn. Ik heb daarbij gefungeerd als product owner en projectleider implementatie (nu projectleider functionaliteit).
De product owner is eindverantwoordelijk voor het product, en bepaalt welke wensen door een ontwikkelteam moeten worden opgepakt. De product owner heeft daartoe overleg met eindgebruikers. Dat valt niet altijd mee. Er worden honderden wensen geuit, waarvan maar een deel kan worden opgepakt. Deze wensen worden op een zogenaamde back log geplaatst. De product owner gebruikt die back log om prioriteiten te stellen. Hiervoor wordt software gebruikt zoals Jira of Trello.
Wensen worden met name geformuleerd in de vorm van zogenaamde user stories. Dat zijn beknopte verhalen hoe gebruiker een functionaliteit met een bepaalde reden wil gebruiken.
Als (gebruiker), wil ik (feature), zodat ik (reden waarom/achterliggende behoefte).
Voorbeeld: Als medewerker wil ik samen met collega’s een document kunnen aanmaken zodat we tijd- en plaatsonafhankelijk aan procedures kunnen werken.
Een valkuil hierbij is dat een gebruiker geen user stories formuleert, maar oplossingen of zich bemoeit met het interaction design (ik wil linksboven een knop…).
In zogenaamde ’sprints’ van 2 of 3 weken wordt vervolgens aan user stories gewerkt. Die verhalen worden dan uitgewerkt in taken die door ontwikkelaars worden opgepakt. Elke dag bespreken de ontwikkelaars kort de stand van zaken en de werkzaamheden die men gaat uitvoeren. Vervolgens worden de nieuwe functionaliteiten getest en daarna in productie genomen (ontwikkelomgeving, testomgeving, acceptatieomgeving, productieomgeving). Verder wordt er veel geëvalueerd (proces en product).
Deze aanpak werkt goed. Volgens Anton Vanhoucke zijn er echter belangrijke beperkingen, die vooral te maken hebben met de aard van een organisatie:
- De product owner heeft onvoldoende mandaat om beslissingen te nemen.
- De product owner heeft onvoldoende tijd om mee te werken (bijvoorbeeld besprekingen voeren over user stories).
- De teamleden beschikken over onvoldoende kwaliteit en onvoldoende senioriteit.
- De opdrachtgever heeft moeite met het nemen van beslissingen.
- De cultuur van de organisatie is zeer formeel.
Bij de OU had ik ook relatief weinig tijd om intensief contact te hebben met de ontwikkelaars. We beschikken bij de OU echter over zeer ‘seniore’ ontwikkelaars die niet alleen uitvoeren, maar ook meedenken over concepten. Zij werken pro-actief. Dat werkt(e) goed, al is het niet helemaal in lijn met de Scrum-aanpak.
Verder werkt het bij Scrum volgens Vanhoucke niet goed als een project veel denkwerk en bewustwording nodig heeft. Wat mij betreft kun je dit ondervangen door de tijd te nemen voor ontwerpsessies en door een ‘roadmap’ te maken waarin de grote lijn van de ontwikkeling is beschreven. Ik heb ook meegemaakt dat veranderende inzichten rond een onderwijsmodel er toe kunnen leiden dat ontwikkelde functionaliteiten opnieuw gemaakt moesten worden. Dat gaat inderdaad ten koste van een snelle ontwikkeling. Zorgvuldigheid is echter belangrijker dan snelheid.
Daarnaast heb ik gemerkt dat gebruikers het heel lastig vinden om te werken met een systeem dat permanent in ontwikkeling is. Vanaf het begin beschikken zij niet over alle functionaliteiten die zij wensen. Dit kun je wel ondervangen door pas echt met een systeem te gaan werken als het over voldoende basisfunctionaliteiten beschikt. Hiervoor hebben we bij de Open Universiteit bijvoorbeeld acceptatietests uitgevoerd. Tenslotte blijkt communicatie met de eindgebruikers een belangrijk aandachtspunt te zijn. Het is lastig om efficiënt en begrijpelijk over de ontwikkeling te communiceren.
De vraag is of deze aanpak ook gebruikt kan worden bij de invoering van ‘technology enhanced learning’. Daarbij hanteren we bijvoorbeeld vaak een plateauplanning. Deze kent normaliter echter geen sprints van 2-3 weken.
Bij de Open Universiteit is het systeem yOUlearn zelf bijvoorbeeld via Scrum ontwikkeld. De invoering ervan vond echter plaats via een beperkt aantal plateaus waarin het systeem binnen een jaar is ingevoerd voor de vernieuwde masteropleidingen (en nu voor de vernieuwde bacheloropleidingen die volgend jaar worden aangeboden). De andere werkzaamheden, zoals het ontwikkelen van ondersteuningsmaterialen, het invoeren van cursussen of het verzorgen van workshops, zijn niet via sprints opgepakt.
Dat is natuurlijk wel mogelijk. Je kunt ook op het gebied van
- Machtsverhoudingen en belangen
- Leiderschap en strategie
- Curriculum
- Mensen en cultuur
- Processen en organisatie
- Infrastructuur en systemen (anders dan de digitale leer- en werkomgeving)
user stories en taken formuleren die in een periode van 2 tot 3 weken kunnen worden uitgevoerd, waarbij je leert van gebruikerservaringen en veel kort overleg voort over de voortgang.
Een user story kan bijvoorbeeld zijn:
Ik wil als auteur van een cursus in staat zijn om binnen yOUlearn een ontwikkelde structuur van een cursus in te voeren, zodat mijn studenten een duidelijk overzicht hebben van de opbouw van de cursus van 12 weken.
Deze user story heeft met name te maken met professionalisering. Via een andere user story wordt de functionaliteit ontwikkeld, terwijl de structuur zelf via een derde user story wordt gemaakt (curriculum).
De invoering van ‘technology enhanced learning’ is eerder een programma, dat uit meerdere projecten bestaat, dan een enkelvoudig project. Voor de overzichtelijkheid is het wellicht daarom aan te raden om voor de afzonderlijke projecten een aparte backlog te hanteren, of in ieder geval deze stories duidelijk te scheiden van die op het gebied van het betreffende ICT-systeem.
This content is published under the Attribution 3.0 Unported license.
Interessant;) binnen Agora in Roermond hebben we Agile toegepast om persoonlijke leerroutes te laten onstaan. Binnen mijn PhD ga ik onderzoek doen naar het inzetten van Agile in het onderwijs. Samen met Target Process heb ik een digitale educatieve versie gemaakt waarbij de docent overzichten krijgt van de ontwikkelingen van de leerlingen. De leerlingen hebben hun eigen overzichten. Ik denk dat dit een zekere meerwaarde voor het onderwijs heeft.
Guido
Beste Wilfred,
De kanttekeningen die jij plaatst bij Scrum voor e-learning ontwikkeling zijn herkenbaar. Zoals je weet is Scrum een van de aanpakken binnen Agile. Wat ik mis bij het model van Scrum is de fase waarin je het denkwerk doet in de aanloopfase naar het project. Dus nog voordat je user cases formuleert.
Naar mijn idee is het belangrijk vooraf een aantal vragen te stellen die je over het hoofd zou kunnen zien bij de aanpak zoals Scrum die voorstaat. Ik denk dan bijvoorbeeld aan: wat is hier precies de vraag? Gaat het wel over een opleiding of is er een andere interventie nodig? Wie is precies de opdrachtgever en wat is zijn mandaat?
De volgende stap – wanneer is vastgesteld dat een leerinterventie inderdaad op zijn plaats is – zou dan volgens mij moeten zijn om eerst te beoordelen wat er op hoofdlijnen moet komen. Noem het een macro-ontwerp. Daarbij is het van belang te bepalen of de oplossing maakbaar en betaalbaar is. In deze fase stem je met de opdrachtgever op hoofdlijnen af wat er moet komen. Daarna pas komen de gewenste oplossingen op basis van de user cases.
Deze aanpak heb ik gebaseerd op het DSDM-model (zie http://www.dsdm.org). Ook dit is een variant van Agile maar met meer structuur vooraf. Bovendien is onderdeel van dit model dat je vooraf bepaalt welke functionaliteiten je minimaal wil hebben, wat je nog maakt als je tijd en budget over hebt en wat je niet in deze fase van het project doet (MoSCoW met de W van Will not have this time). De afgesproken tijd en kwaliteit staan centraal en het wisselgeld zit in met name in de could-haves, die je met de opdrachtgever vooraf zo hebt benoemd.
Volgens mij voorkom je met een dergelijke aanpak dat je weliswaar op tijd oplevert wat is afgesproken maar dat je inlevert op kwaliteit. De planning moet volgens deze aanpak namelijk gebaseerd zijn op maximaal 60% Must haves. De rest is Should en Could.
Om te voorkomen dat gebruikers een onaf product testen, bepaal je ook in welke fase van het project je deelproducten live zet. Dat hoeft dus niet per se na elke timebox/sprint. Overigens lever je wel na elke timebox een gereed product op dat je binnen het ontwikkelteam test.
Op mijn website heb ik deze aanpak op hoofdlijnen beschreven voor de niche waarop ik mij richt.
Ik ben benieuwd naar je reactie.
Met hartelijke groet,
Mark
Dag Mark,
Volgens mij is het erg belangrijk om vooraf na te denken over het grotere kader, en staat dat niet haaks op Scrum. Wat verder ook helpt is dat je eerst epics formuleert waar meerdere user stories en vervolgens taken onder vallen. Binnen projecten kun je ook eerst ‘ontwerptickets’ hanteren, waarbij je afspreekt dat je eerst uitgebreider stil staat bij het ontwerp van een user story.