Bloggers

Kun je via Scrum ‘technology enhanced learning’ invoeren?

’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?

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.

Zoals gezegd wordt ’Scrum’ ook binnen andere typen projecten gebruikt, en ook om met lerenden aan projecten te werken. Daarbij wordt software als Trello gebruikt om overzicht over taken te houden. Bij Agora Roermond hebben ze bijvoorbeeld de applicatie Target Process voor onderwijsgebruik laten aanpassen.

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.

Lees het hele artikel