Wat zijn de succesfactoren in een low-code project?
Niet elk low-code-project loopt goed vanaf de start. Waar gaat het soms mis en wat kun je daaraan doen? Jeroen de Smedt, een van onze developers, neemt je mee in deze blog.
Belangrijke aandachtspunten
Veel bedrijven die met een low-code-platform aan de slag gaan, beginnen zonder eerst goed te hebben nagedacht over de rol en succesfactoren van low-code. Ze komen in een ongewenste situatie terecht en dat is vaak het moment waarop wij worden ingeschakeld. In deze blog delen wij onze ervaringen zodat jij deze fout niet snel maakt.
1. De business wordt vergeten
Wij zien nogal eens dat de betrokkenheid van de business wordt vergeten. Dat terwijl het uiteindelijk de business is die weet wat de software moet gaan doen.
2. Er is onvoldoende voorbereiding
Agile werken gaat in sprints en de software worden iteratief opgeleverd. Ook dan – of juist dan – is een goede voorbereiding cruciaal. Daar wordt vaak veel te weinig tijd ingestoken. Hoe beter de voorbereiding, hoe beter het hele project of programma verloopt. Wat zijn de requirements, wat zijn de verschillende milestones, wat zijn goede validatiemomenten, en wanneer ga je evalueren en bijsturen? Dat soort vragen moet je beantwoorden voor je een project start.
3. Er is een gebrek aan de juiste expertise op de juiste plaats
Bij elk project zijn verschillende disciplines betrokken. Architecten, senior developers, junior developers, ze hebben allemaal een rol, maar vaak zien we dat de juiste expertise niet op het juiste moment op de juiste plaats wordt ingezet. Dat er junior ontwikkelaars worden ingezet, is uit kostenoverwegingen een logische keuze. Zorg dan wel dat voor het project doorgaat naar een volgende fase, alles wat wordt afgeleverd is gevalideerd door iemand met een senior rol. Als je bugs op tijd ontdekt, kun je eenvoudig en snel bijsturen, maar als fouten pas in een later stadium worden ontdekt, zullen de kosten exponentieel stijgen.
4. Er wordt te weinig getest
Als software iteratief wordt opgeleverd, moet er ook iteratief worden getest. Dit ligt een beetje in het verlengde van het vorige punt: als je doorbouwt op software die niet goed is getest, kun je aan het eind van de rit weleens voor vervelende verrassingen komen te staan. Wat hier ook nog weleens fout gaat, is dat software alleen door de ontwikkelaars zelf wordt getest. Zij kijken met andere ogen naar software dan mensen uit de business. Iets kan functioneel prima werken, maar dat wil niet per se zeggen dat het in de praktijk ook lekker werkt.
5 tips om lowcode te doen slagen
Nu we weten waar het vaak mis gaat, hierbij vijf tips voor een succesvol adoptie en executie van lowcode projecten in jouw organisatie.
1. Neem de business mee
Een low-code-platform is de ideale omgeving om de kloof tussen IT en de business te overbruggen. Dan mag je natuurlijk niet vergeten om de business ook daadwerkelijk te betrekken bij het ontwikkelproces. Door met de business in gesprek te gaan over de benodigde functionaliteiten en de gewenste performance komen we tot een oplossing komen waar iedereen blij mee is. Ook gedurende het project zorgen we dat mensen uit de business tijd reserveren om in alle stadia van het project de applicatie te testen. Zij zijn immers de inhoudelijke experts, niet de ontwikkelaars.
2. Neem tijd voor sprint 0
Neem de tijd voor een gedegen en gestructureerde voorbereiding. Wij noemen dat Sprint 0. Wie agile werkt, werkt in sprints en hoe beter de voorbereiding, hoe beter ook de rest van het project gaat. Wij stoppen relatief veel tijd in Sprint 0, maar dat betaalt zich dubbel en dwars terug tijdens het project. Allereerst analyseren we de requirements die de klant heeft aangeleverd. Zijn ze duidelijk, zijn ze voldoende uitgewerkt en hebben wij nog vragen? Zodra alles helder is, vertalen we dit in user stories die we weer voorleggen aan de business. Zodra alle partijen tevreden zijn met wat er voorligt, dan pas maken we een kostenraming en een eerste planning.
3. Zet de juiste expertise in op de juiste plaats
In ons team hebben we mensen van verschillende niveaus, van heel junior tot zeer ervaren senior. Omwille van de doorloopsnelheid, maar ook omwille van het budget, zetten we de juiste expert in op de juiste plek, op het juiste moment. De junior waar het kan, de senior waar het nodig is. Behalve met ontwikkelaars en mensen uit de business, hebben we ook te maken met externe partijen, bijvoorbeeld partners die in integraties moeten voorzien. Ook met hen gaan we op het juiste moment het gesprek aan: wat hebben we van elkaar nodig, hoeveel tijd gaat daarmee gepaard en wanneer zijn benodigde resources beschikbaar?
4. Kies voor een gestandaardiseerde manier van werken
Wij werken altijd volgens bepaalde standaard ‘ways of working’. Die definiëren we voor we bij een klant aan de slag gaan. Ongeacht het aantal projecten of het aantal verschillende medewerkers dat gedurende het traject meewerkt, iedereen weet wat de bedoeling is. Dat zorgt niet alleen voor transparantie, het maakt ook de inwerktijd beperkter. Onnodig te zeggen dat testen – door zowel ontwikkelaars als mensen uit de business – onderdeel is van deze standaard werkmethode.
5. Communiceer
Wij zijn geen fan van zinloze meetings, maar we houden wel van heldere communicatie en daarvoor zijn bijeenkomsten soms noodzakelijk. Zo houden we iedereen betrokken bij elkaar en kunnen we actiepunten correct opvolgen. Door goed met alle partijen te communiceren voorkomen we mogelijke spanningen, die een project nooit ten goede komen.
Daag ons uit!
Benieuwd hoe onze manier van samenwerken eruitziet? Daag ons uit met een use-case. Samen met jouw collega’s bedenken en bouwen we in slechts één dag een proof-of-concept-applicatie.