Stel, je hebt een nieuwe website, portal, DLWO (digitale leer- en werkomgeving) of een ander systeem nodig. Het bureau waar je mee samenwerkt, stelt voor om te gaan Scrummen – oftewel Agile te gaan ontwikkelen. Je hebt er al eens vaker van gehoord. Het bureau belooft dat je met deze moderne methode veel sneller resultaat ziet, binnen budget blijft en ook nog eens precíes krijgt wat je nodig hebt. Daar word je natuurlijk razend enthousiast van. Maar is Scrum wel geschikt voor jouw project? En is je organisatie er wel klaar voor?
Als je tegenwoordig niet Agile ontwikkelt, ben je hopeloos verouderd. Dat is althans wat veel mensen denken. Deels hebben ze daar ook gelijk in. Scrummen zorgt er inderdaad voor dat je in korte sprints snel functionaliteiten oplevert, alleen ontwikkelt wat echt nodig is en makkelijker binnen het budget blijft. Maar dat is alleen het geval wanneer zowel de it-leverancier als de organisatie er klaar voor zijn. En hoe weet je eigenlijk of je klaar bent voor een Scrum-project? Als je op alle onderstaande vragen volmondig ‘ja’ kunt antwoorden, dan komt het helemaal goed.
1. Ben je bereid om zeer intensief samen te werken?
Het sleutelwoord bij Agile-ontwikkelen is samenwerken. En dat klinkt makkelijker dan het is. Bij een traditioneel traject heb je als opdrachtgever in het begin veel contact met je it-bureau en de ontwikkelaars. Je bespreekt precies wat je wil hebben, maakt een lijst met functionele wensen en gaat akkoord met een functioneel ontwerp. Daarna gaat het ontwikkelteam vrij zelfstandig aan de slag. Natuurlijk heb je tussendoor contact over de voortgang, maar de afstand tussen jou en de ontwikkelaars is relatief groot.
Bij een Scrum-project is dat wel anders. Daar moeten de ontwikkelaars en de opdrachtgever – jij dus – heel intensief met elkaar samenwerken en continu met elkaar communiceren. Het liefst een aantal dagen per week bij elkaar in één ruimte zijn. Scrum betekent dat er ten minste één persoon binnen je organisatie full time bezig moet zijn met het project. Die persoon hoeft niet altijd op locatie te zijn, maar wel altijd snel telefonisch antwoord kunnen geven op vragen. Als je daar geen tijd of capaciteit voor hebt, of de voordelen er niet van in ziet, dan kun je er beter niet aan beginnen.
2. Heb je een goede product owner in huis?
Een Scrum-project heeft een goede product owner nodig; iemand die full-time beschikbaar is voor het project. Hij of zij is de schakel tussen het ontwikkelteam en de organisatie. Het is dus ontzettend belangrijk dat deze persoon de business als geen ander kent. Hij of zij moet weten wie de stakeholders zijn, wat hun wensen zijn en wat de business values zijn. Hij of zij moet goed kunnen inschatten welke functionaliteiten echt essentieel zijn en welke niet. En hij of zij moet precies begrijpen hoe de eindgebruiker met het product gaat werken en bereid zijn dat herhaaldelijk tot in detail aan de ontwikkelaars uit te leggen.
De product owner moet bovendien niet alleen de tijd hebben om al zijn aandacht op het project te richten, maar ook het mandaat om beslissingen te mogen nemen. Daarnaast is hij of zij de persoon die beslissingen moet kunnen uitleggen aan de stakeholders in de organisatie en daar buiten. En dat geldt ook voor de gevolgen van Agile-ontwikkelen. Waar je bij een traditioneel traject vooraf exact weet wat je krijgt, ontstaat het eindproduct bij een scrum-traject organisch. Elke zoveel weken krijg je een bouwblokje te zien en pas op het einde heeft het systeem echt vorm gekregen. Dat moet je als product owner ook aan je stakeholders kunnen uitleggen.
3. Wordt er actief en snel gecommuniceerd binnen je organisatie?
Een Scrum-project valt of staat met communicatie. Agile-werken is eigenlijk heel veel praten en relatief weinig bouwen. Maar uiteindelijk bouw je wel exact wat nodig is. Ik heb wel eens twintig minuten over een user story gepraat met de klant, om er uiteindelijk achter te komen dat men een heel andere functionaliteit wilde dan eerst gedacht werd. Die bereidheid om veel en intensief te communiceren, en alles continu tot op de bodem uit te pluizen, is essentieel.
De product owner moet zoals gezegd het mandaat hebben om zelfstandig beslissingen te kunnen nemen. Maar hij weet natuurlijk ook niet alles. Hij moet kunnen overleggen en input kunnen vragen bij stakeholders in de organisatie. Korte lijntjes en de bereidheid om snel feedback te geven zijn daarbij essentieel. Als je scrumt dan lever je elke twee, drie weken iets op. En als je met meerdere ontwikkelteams werkt, dan worden er elke twee, drie weken meerdere functionaliteiten opgeleverd. Dat is de kracht van Agile-werken.
Maar als de communicatie niet snel gaat, dan kun je ook niet ‘sprinten’, zoals dat heet. Ik heb wel eens in een project gezeten voor een gemeente, waarbij de product owner elke technische beslissing moest voorleggen aan een bestuursgroep die maar eens in de drie weken bij elkaar kwam. Dan ligt een deel van je project dus regelmatig drie weken stil. Dat werkt natuurlijk echt niet.
4. Ben je bereid om veel te testen?
Eén van de pijlers van Scrum is dat je na elke sprint een product oplevert dat uitgebreid kan worden getest door de stakeholders. Dat betekent dat je als opdrachtgever bereid moet zijn en de tijd moet hebben om elke twee, drie weken te testen en inhoudelijke feedback te geven. Dat testen moet door verschillende partijen gebeuren. Door een eindgebruiker, iemand die over security & privacy gaat, en ga zo maar door. Als je geen mogelijkheid hebt om de juiste mensen regelmatig vrij te maken voor het geven van kwalitatieve feedback en het doen van acceptatietests, dan kun je beter niet gaan scrummen.
5. Vind je het niet erg om klein te beginnen?
Als opdrachtgever heb je een plaatje in je hoofd van hoe het eindproduct eruit moet zien. Je wil het liefste alles hebben, binnen een bepaald budget. Maar negen van de tien keer wordt van een systeem slechts 20 procent van de gebouwde functionaliteiten echt intensief gebruikt. Het principe van Scrum is dat je functionaliteiten oplevert in iteraties. Elke sprint kijk je opnieuw welke functionaliteit de meest waardevolle toevoeging is aan het systeem. Je focust je op die 20 procent en bouwt dus niet alle must haves in één keer. Je begint klein en start met de functionaliteiten die de meeste toegevoegde waarde hebben.
Je kunt ook niet oneindig blijven sprinten. Het einddoel moet behapbaar zijn, het moet in iemands hoofd passen. Als je drie jaar ontwikkeltijd nodig hebt om een compleet systeem te bouwen, dan moet je het in kleine projecten opdelen. Op den duur wordt het ontwikkelteam moe en is de fitheid eruit. Na een sprint of tien heb je gewoon even pauze nodig, moet je de tijd nemen om te analyseren wat je gemaakt hebt en waar je naar toe wil.
Doe je dat goed? Dan heb je in the end een combinatie van functionaliteiten waar je gebruikers ook echt wat aan hebben. Binnen budget én binnen de deadline. Maar vind je het moeilijk om stapje voor stapje te ontwikkelen, wil je in één keer een compleet product opleveren en wil je liever niet klein beginnen? Dan is Scrum waarschijnlijk niets voor jouw organisatie.
6. Zijn je andere it-leveranciers in staat om snel te schakelen?
Als je een systeem gaat bouwen waarbij ook andere systemen betrokken zijn, denk aan back-officeapplicaties, dan is het noodzakelijk dat de leveranciers van die systemen ook snel kunnen leveren en schakelen. Onderzoek dus, voordat je gaat Scrummen, wat voor partnership je precies hebt met je andere leveranciers. Hoe snel wordt er gehandeld? Hoe is de support? Hoe snel kun je veranderingen doorvoeren op het systeem?
Stel je voor, je bouwt een inlogsysteem waarmee je gebruikers straks in één keer op al je back-officeapplicaties kunnen inloggen. Als de leverancier van zo’n back-officesysteem pas na drie maanden iets kan opleveren, dan zal de concrete werking van de software lang onduidelijk blijven. In zo’n geval moet je tijdens het ontwikkelen bepaalde aannames doen, en de kans is groot dat die niet kloppen. Dat betekent dat je tijd en geld kwijt bent aan het herbouwen van je inlogsysteem.
Investering meer dan waard
Scrummen gaat dus absoluut niet vanzelf. Het is hard werken en een kwestie van heel veel praten, testen, praten en testen. Als je Agile ontwikkelt, dan ga je een langetermijnrelatie met je it-bureau aan. Het is een intensief partnerschap, waarin beide partijen evenveel tijd en energie investeren. Maar al die moeite, al die tijd en al dat communiceren is het absoluut meer dan waard. Je krijgt een product waarmee je verwachtingen worden waargemaakt. Bovendien levert het je een product op waar je écht wat aan hebt en waar je gebruikers heel erg blij van worden.
Martijn van der Maas, software engineer bij Finalist
linken naar artikel over user stories
