Lessons learned bij het bouwen van een Minimum Viable Product

Summit heeft al 25 jaar ervaring met in goede banen leiden van grote evenementen. Denk hierbij aan beurzen waar duizenden bezoekers komen of aan onderwijsinstellingen die een open dag organiseren over meerdere locaties. Voor die laatste klantengroep zijn we al een tijdje bezig met ontwikkelen en collega Dennis schreef er eerder een technische blog over.

Voor Infi lag in deze periode de focus op het systeem dat onderwijsklanten gebruiken en dat sloot goed aan bij de situatie ontstaan door de COVID-pandemie: grote evenementen en beurzen konden geruime tijd niet of nauwelijks plaatsvinden. Nu de maatschappij zijn draai weer heeft gevonden, is er ook ruimte bij klanten van Summit om vooruit te kijken, en dat kwam tot uiting in een klantvraag.

Zelf je eigen zaken beheren als beurs of exposant

Een beursorganisator wil exposanten uitnodigen voor zijn evenement en wil deze in staat stellen het verzamelen van leads op zo’n evenement zelf te regelen. De exposant moet daarbij op een intuïtieve manier vragenlijsten beheren en de verzamelde antwoorden makkelijk kunnen exporteren. Summit had al systemen die bezoekers van evenementen kon koppelen aan exposanten, maar dit vergde veel handmatig configuratiewerk: bijvoorbeeld het invoeren van vragenlijsten en het koppelen van die lijsten aan de juiste exposanten. Dit stukje functionaliteit stroomlijnen, waarvan we al wisten dat het waarde had voor Summit en haar klanten, werd het uitgangspunt voor Summit Events.

Agile approach: Minimum Viable Product én pragmatisch te werk gaan

Daarom kozen we -onder leiding van de kersverse Summit technical lead Bouke- voor een andere aanpak dan bij het onderwijsgerichte project, waar een complete rewrite het uitgangspunt is. Het idee was om een sterk gekaderd stukje functionaliteit te pakken van het systeem zoals het er stond, en dat ten behoeve van de klantvraag opnieuw vorm te geven. De focus lag daarbij op het opleveren van een Minimum Viable Product (MVP) in een kort tijdsframe.

Vanzelfsprekend werd gekozen voor eenzelfde tech-stack als het onderwijsproject, bestaande uit een .NET Core backendapplicatie en een Vue.js frontendapplicatie, en werden snel meters gemaakt. Door met adapterstructuren herziene businessentiteiten vorm te geven, konden we gemakkelijk inhaken op het bestaande systeem binnen Summit en kon direct met bestaande data worden gewerkt zonder dat we daarbij vast zaten aan het “oude” databasemodel.

Daarnaast hebben we alle applicaties binnen één repository gehouden. Dat heeft veel voordelen, bijvoorbeeld dat je een feature van voor tot eind kan implementeren en in één pull request ter review kan aanbieden. Maar ook zodat we eenvoudig gebruik maken van tooling zoals nSwag en met code generatie de frontend en backend gemakkelijk aan elkaar konden knopen.

Ook op procesgebied kozen we voor een andere werkwijze: in plaats van Scrum met sprints, kozen we voor Kanban en hebben we in hele kleine iteraties (1 week!) steeds het systeem uitgebouwd totdat de MVP af was. Verder was de business nog meer betrokken bij het uitschrijven van de features en kregen we sneller helder wat we gingen bouwen.

Conclusie: leer van iedere kans die je krijgt

Het kan vervelend zijn om halverwege een project (tijdelijk) ergens anders tijd aan te spenderen: het domein is anders en je maakt tijdelijk minder meters in het hoofdproject. Maar het heeft ook veel voordelen: je doet kennis op die je anders nooit hebt opgedaan én kan deze direct toepassen in je andere project.

Het eindresultaat: het beoogde minimum viable product staat er en de lessons learned worden toegepast binnen het onderwijs project.