Scrum bij Kennisnet

Interview: Jeroen Veldkamp

Kennisnet is de publieke ICT-partner voor het onderwijs. Naast onafhankelijk en gratis advies aan basisonderwijs, voortgezet onderwijs en middelbaar beroepsonderwijs, biedt Kennisnet onlineplatformen waarop digitaal leermateriaal centraal toegankelijk is. Bij de ontwikkeling van deze platformen past Kennisnet sinds een aantal jaar een agile werkwijze toe waarbij volgens Scrum wordt gewerkt. Phil van Dulm, projectmanager bij Kennisnet, vertelt ons hoe Kennisnet het agile werken heeft ingevuld en waar voor de organisatie voordelen liggen.

Zou je willen omschrijven hoe bij jullie het agile werken is ingericht?

Kennisnet heeft voor het ontwikkelen van onze platformen een aantal mantelpartijen geselecteerd waar we gebruik van maken bij onze ontwikkeltrajecten. Wij zijn niet continu aan de platformen aan het ontwikkelen, maar we werken met verschillende ontwikkeltrajecten per jaar. Dit is voor ons een voordeel, omdat we de ontwikkelbehoefte als het ware kunnen opsparen.

Tijdens een ontwikkeltraject werken we in zes à zeven sprints met een sterk gefocust team aan de verbetering en de vernieuwing van een van onze onlineplatformen. Het team bestaat meestal uit twee ontwikkelaars, een parttime tester en een projectmanager van Kennisnet in de rol van Scrum-master. De technisch productmanager van het platform waaraan wordt gewerkt is de product owner.

Er wordt altijd gewerkt in sprints van twee weken en het team voert alle benodigde sprintactiviteiten uit. Op de eerste dag van de sprint is er een sprintreview, een retrospective en de sprintplanning. Dagelijks wordt er in de ochtend een stand-up gehouden en één keer per week wordt er een paar uur gewerkt aan de backlog tijdens de backlog refinement. Na het voltooien van een sprint wordt er uitgerold op de acceptatieomgeving, zodat wij indien nodig feedback van onze stakeholders kunnen verzamelen.

Wat zien jullie als de belangrijkste voordelen van agile werken?

Doordat er veel oplevermomenten zijn, is het team sterk gefocust en tonen de teamleden veel commitment. Dit komt doordat er elke twee weken een deadline is die moet worden gehaald en het team aan het begin van de sprint gezamenlijk het doel heeft bepaald. Als het lukt om een dedicated team te krijgen, voel je de focus binnen het team en deze focus geeft veel rendement.

Een ander voordeel is het werken met user stories, omdat het een fijne methode is voor het opdelen van werk. Hierdoor wordt het werk overzichtelijker en ben je beter in staat door complexere materie heen te bijten.

Hiernaast stelt het iteratief werken ons in staat snel feedback te verzamelen over wat er wordt gebouwd. In plaats van lang nadenken over wat er potentieel gebouwd kan worden, wordt er juist snel iets tastbaars gemaakt waar men een mening over kan vormen.

Tot slot is het erg waardevol dat we continu bezig zijn met het optimaliseren van het proces, het team en de samenwerking. Er zit veel kracht in het continu blijven nadenken over hoe het beter en sneller kan.

Wat is voor jullie lastig bij het agile werken?

Het is een uitdaging om een regressietest binnen een sprint uit te voeren, omdat dit vaak veel tijd kost. Het gedeeltelijk automatiseren van de regressietests biedt hierbij wel perspectief. Hiernaast is het faciliteren van automatische deployments tussen verschillende omgevingen soms lastig, terwijl dit juist voorwaardelijk is voor de continuïteit van het project. Verder heb je te maken met exotische expertises die je niet fulltime nodig hebt in het sprintteam, waarbij het een uitdaging is om de inzet van deze experts goed in het team in te passen.

Houden jullie kerngetallen bij? Meten jullie? Zo ja, wat?

Tijdens een ontwikkeltraject meten we de velocity per sprint en deze velocity vergelijken we tussen sprints. De gemiddeld behaalde velocity is vaak de basis voor het inplannen van het aantal user stories dat we in de volgende sprint willen realiseren.

Hoe voeren jullie testen uit?

Van een ontwikkelaar wordt verwacht dat hij of zij het werk van een andere ontwikkelaar test en valideert dat het voldoet aan de acceptatiecriteria. Als de testende ontwikkelaar vindt dat het werk voldoet aan de criteria, dan wordt de user story ter verificatie klaargezet voor de tester. De tester is parttime bij het team betrokken en is uiteindelijk verantwoordelijk voor het testen van de user stories die tijdens de sprint worden opgeleverd.

Voordat een release op productie wordt uitgerold, voert de tester een volledige regressietest uit op de acceptatieomgeving. Het uitvoeren van een volledige regressietest wordt niet na elke sprint gedaan, omdat dit te veel tijd kost. We zijn wel bezig met testautomatisering, zodat een deel van de regressietest automatisch uitgevoerd kan worden.

We betrekken in een aantal ontwikkeltrajecten ook eindgebruikers bij het testen. Hierbij wordt een demonstratie gegeven op Skype voor een selectie van eindgebruikers. Vervolgens worden deze gebruikers uitgenodigd om zelfstandig op de acceptatieserver te gaan testen.

Hoe gaan jullie om met continue verbetering binnen/over de teams?

Elke sprint houden we met het team een retrospective waarbij we terugkijken op de laatste sprint. We kijken dan hoe we als team kunnen verbeteren, maar staan ook stil bij waar we juist mee door moeten gaan. Aan het einde van de retrospective kiezen we gezamenlijk één of twee verbeterpunten en die pakken we tijdens de volgende sprint op.

Heb je nog een goede tip voor andere organisaties?

Organisaties die overwegen om met Scrum te gaan werken, zou ik adviseren om een keer Scrum te gaan ervaren. Verzamel een aantal stakeholders, zoals directieleden, projectmanagers en ontwikkelaars, en neem ze mee in een tweedaagse Scrum-training om het te ervaren. Zoek na deze training een project met veel verbeterpotentieel en pas juist daar eens twee weken Scrum toe. Het is daarnaast ook altijd een goed idee om bij andere bedrijven te informeren hoe zij met Scrum werken.