Cases / Onderwijs

Agile Transitie in het hoger onderwijs

20-05-2021 5 minuten

SaNS is een samenwerkingsverband tussen de Universiteit van Amsterdam, de Hogeschool van Amsterdam en Universiteit Leiden rondom het Studenteninformatiesysteem (SIS). Zij worden hierbij ondersteunt door het SaNS Expertise Centrum. Deze vier partijen zorgen samen voor een solide SIS, door in te spelen op de vragen uit de business én proactief nieuwe functionaliteiten aan te dragen. Het proces en de onderlinge samenwerking waren hier voorheen niet optimaal voor ingericht. Morgens heeft de transitie naar een nieuwe, Agile werkwijze begeleid.

De vraag

SaNS had hulp nodig bij het sneller implementeren van innovaties en updates van het studenteninformatiesysteem (SIS).

De uitdagingen van SaNS op een rijtje:

  • Er werden slechts twee keer per jaar nieuwe wijzigingen aan het systeem uitgebracht;
  • De doorlooptijd van aanvraag tot uitvoering was daardoor erg lang (+ 9 maanden);
  • De klanttevredenheid liep terug;
  • Piekbelasting bij medewerkers was twee keer per jaar extreem hoog.

Om innovaties en updates sneller te kunnen doorvoeren, is het aantal uitgaves van nieuwe updates in 2019 al verhoogd van 2 naar 10. De manier van werken veranderde echter niet mee, waardoor de piekbelasting onverminderd hoog bleef. Ook was er zowel binnen als tussen de teams sprake van rolonduidelijkheid: het was onduidelijk wie waarvoor verantwoordelijk was en teamleden durfden niet altijd zelfstandig beslissingen te nemen. Dit kwam de onderlinge samenwerking niet ten goede.

Morgens is gevraagd om samen met de instellingen en het SaNS Expertise Centrum (EC) een nieuwe werkwijze te ontwikkelen die een betere onderlinge samenwerking tot doel had, evenals het sneller en vaker doorvoeren van wijzigingen aan het SIS.

SaNS: Samenwerking Nieuw SIS

Het SaNS Expertisecentrum beheert en vernieuwt het studenteninformatiesysteem (SIS) van de Universiteit van Amsterdam, de Hogeschool van Amsterdam en Universiteit Leiden. Deze samenwerking zorgt voor kostenbesparing en vergemakkelijkt kennisdeling. Ruim 100.000 studenten en bijna 10.000 docenten en andere medewerkers maken gebruik van dit SIS.

De aanpak

Onze aanpak voor dit project is een drietrapsraket:

  1. Exploreren
  2. Adapteren
  3. Implementeren

1. Exploreren

We zijn gestart met het afnemen van interviews om de context en problematiek goed te doorgronden. Van elke instelling hebben we de verantwoordelijke managers en 4 tot 5 medewerkers gesproken. Op basis van deze gesprekken hebben we een analyse gemaakt van belangrijkste thema’s. Dit vormde de basis voor het vervolg.

Vervolgens zijn we tijdens twee ‘leiderschapsdagen’ in gesprek gegaan met de managers van de verschillende instellingen. Als we van medewerkers verwachten dat zij goed samenwerken, dan moeten managers dat ook. Zonder leiderschap immers geen verandering!

Tijdens deze dagen hebben de managers elkaar beter leren kennen door hun persoonlijke drijfveren met elkaar te delen, in gesprek te gaan over de analyse van de interviews en onderlinge samenwerking. Vervolgens hebben we een ‘True North’ voor het SIS opgesteld. Dit is een beknopte en visuele weergave van de ambities en kernwaarden voor de samenwerking aan het SIS. Ook hebben we een eerste verkenning gedaan van verschillende ontwikkelmethoden en wat passend zou kunnen zijn voor het samenwerkingsverband. Tot slot hebben we een roadmap opgesteld voor het vervolg.

De resultaten van deze eerste stappen:

  • De managers kennen elkaars drijfveren en ambities;
  • Een gezamenlijke visie op het SIS;
  • Een roadmap voor het vervolg.

Het Transitieteam

Na een kick-off met alle betrokkenen van de instellingen in Amsterdam hebben we een Transitieteam gevormd. Hierin zaten tien afgevaardigden van het SaNS EC, Universiteit Leiden, Universiteit van Amsterdam en Hogeschool van Amsterdam. Zij waren de linking pin tussen de verandering en de eigen organisaties.

Na elke bijeenkomst met het Transitieteam brachten de vertegenwoordigers verslag uit aan hun eigen teams, zodat collega’s van het proces en de veranderingen op de hoogte waren. Daarnaast konden zij zo vragen en opmerkingen van hun collega’s meenemen naar het Transitieteam. Op die manier ontstond een wisselwerking en werden andere collega’s niet verrast door het uiteindelijke resultaat.

Best passende ontwikkelmethode

Allereerst heeft het team doelen voor de transitie opgesteld. Op die manier was voor iedereen helder wat we met de transitie wilden bereiken en hadden we een meetlat waarlangs we de nieuwe werkwijze konden leggen. Daarna hebben we een verkenning gedaan naar de best passende ontwikkelmethode voor het wijzigingsproces. Hierbij keken we naar de Watervalmethode, Agile, Kanban en Extreme Programming.

Scrum

Op basis van de verkenning bleek dat Agile het beste bij onze wensen en uitgangspunten past. Binnen het Agile framework zijn meer dan 40 verschillende ontwikkelmethoden te onderscheiden. Het Transitieteam koos uiteindelijk voor de Scrum methodiek, omdat deze het best is uitgewerkt en goed past in de context van SaNS. Daarnaast zijn enkele teams binnen het SaNS EC en de UvA/HvA al bekend met Scrum.

2.  Adapteren

In de tweede fase hebben we het oude proces in kaart gebracht en vervolgens een nieuw proces ontworpen op basis van het Scrum Framework. Dit nieuwe proces, inclusief taken, rollen en verantwoordelijkheden hebben we vervolgens uitvoerig besproken en beschreven (zie afbeeldingen met post-its en uitvoeringsfase details). In het kader van “practice what you preach” gebruikten we in deze fase een aantal hulpmiddelen uit de Scrum methodiek, zoals een Product Backlog voor de transitie en wekelijkse stand-ups met het Transitieteam om acties te verdelen en de voortgang en hulpvragen te bespreken.

We onderscheiden twee processen in de nieuwe werkwijze:

1  Voorbereiding: Twee werkgroepen bereiden de sprints voor. Zij zijn verantwoordelijk voor het verzamelen en beoordelen van de wijzigingsverzoeken vanuit de faculteiten. Alle wijzigingsverzoeken (WV’s), inclusief technische wijzigingen en bugfixes, komen samen op één gezamenlijke Product Backlog en vallen onder verantwoordelijkheid van twee Product Owners. De WV’s worden geprioriteerd door de werkgroep en de Product Owner samen. Het aanvraagproces heeft een doorlooptijd van 4 weken.

2  Sprint: Rondom elk wijzigingsverzoek wordt een ontwikkelteam gevormd met een vertegenwoordiger van de business, een ontwikkelaar, een tester en een code-reviewer. Gedurende de Sprint van 4 weken zijn er verschillende overlegmomenten (startbijeenkomst, feedback bijeenkomst, evaluatie). Dit voorkomt onduidelijkheid en herstelwerk. Aan het eind van de Sprint is er een gezamenlijke evaluatie (Retrospective) en worden verbeteracties voor de volgende Sprint opgesteld.

Covid-19 helpt een handje

Eén van de wensen van vrijwel alle betrokkenen was nauwere samenwerking. In het verleden was het gebruikelijk dat er gezamenlijk, op één locatie werd getest. Dit was gedurende de jaren verwatert, mede doordat de reistijd als struikelblok werd gezien. Er is daarom veel discussie geweest over de vraag hoe dit op te lossen. Op afstand testen vond men niet ideaal, hoe konden we dit oplossen? Bijvoorbeeld door afwisselend in Utrecht, Amsterdam of Leiden samen te komen? Ook dat leek niet de ideale oplossing.

Het antwoord kwam uit onverwachte hoek: de wereldwijde Covid pandemie. Dit heeft wereldwijd tot een thuiswerk revolutie geleid. Met behulp van MS Teams werd het mogelijk om gemakkelijk vanuit huis te vergaderen en samen te werken. Dit loste ook in één klap dit vraagstuk op. De ervaring die we tijdens de pandemie met thuiswerken hebben opgedaan, heeft ertoe geleid dat gezamenlijk testen op 1 locatie geen issue meer is.

3.  Implementeren

Op een gegeven moment kwamen we op een punt dat we het praten over de theorie moe waren. We wilden wel eens aan de slag! We besloten een pilot te starten.

Het Transitieteam heeft een klein aantal wijzigingsverzoeken volgens de nieuwe werkwijze geprioriteerd en ontwikkeld. Na een evaluatie en wat aanpassingen aan het proces, is een brede pilot opgezet. Hierin deden ook collega’s van buiten het Transitieteam mee. Deze pilot is succesvol verlopen.

Succesfactoren van het nieuwe proces waren:

  • Kortere doorlooptijd;
  • Minder rework nodig;
  • Verbeterde (meer) communicatie;
  • Verbeterde samenwerking;
  • Heldere taak- en rolverdeling.

Op basis van de bevindingen van deze pilot is besloten om de Scrum-methode te implementeren.

Het resultaat

Voorspelbaar proces, nauwe samenwerking en minder herstelwerk

De nieuwe werkwijze heeft allereerst voor voorspelbaarheid gezorgd. De repeterende scrum cyclus van vier weken zorgt ervoor dat men meer dan voorheen weet waar ze aan toe zijn.

Daarnaast worden betrokkenen door de scrum methodiek gedwongen nauwer samen te werken. Doordat aan de voorkant beter wordt afgestemd wat precies moet worden opgeleverd, is hierdoor minder herstelwerk nodig. De tussentijdse feedbackbijeenkomst helpt hierbij. Hierin laat de ontwikkelaar zien wat hij of zij heeft ontwikkeld en heeft de vertegenwoordiger van de business de mogelijkheid om feedback te geven.

Tegelijkertijd is de nieuwe werkwijze ook uitdagend: de nieuwe manier van werken heet met recht ‘sprinten’. We zijn naar 10 uitleveringen per jaar gegaan, elke vier weken één (met uitzondering van een aantal weken). Dat lijkt tot meer werk te leiden dan in de oude situatie. Blijven evalueren, bijsturen en leren is dan ook een must, zodat de som der delen niet substantieel meer is dan voorheen. Op dit moment wordt dit nog wel zo ervaren. Gelukkig is adaptatie één van de pijlers van Scrum, zodat het proces continu aangepast kan worden.

Meer weten?

Wil je meer weten over deze case, of ben je benieuwd naar de mogelijkheden voor een Agile-transitie binnen jouw organisatie? Neem contact op met Maarten van der Molen.