Is't al klaar?

Wanneer is iets echt klaar?

Er was eens een klant hier heel ver vandaan. Op een dag kwam zij met een uitzonderlijk goed idee. “Als we dit idee nou eens uitwerken en ontwikkelen dan zijn we klaar!” zei de klant tegen Koek. Dus Koek zette zijn beste beentje voor en startte vol enthousiasme aan het project.

Maar nog voordat Koek het idee kon verwezenlijken had de klant alweer nieuwe inzichten die moesten worden doorgevoerd. Daardoor ontstonden er allerlei nieuwe kansen en problemen. Een nieuwe queeste voor Koek!

Alleen… deze queesten bleven maar komen! Om nog maar niet te spreken over de side-quests. En de klant bleef maar vragen wanneer zijn project nou echt klaar was. Bloed, zweet en tranen vielen neer op de grond. Uiteindelijk leerden we hier een wijze les: “ons werk is nooit klaar”.

Nu, duizenden gedachtenkronkels later, zijn wij ervan overtuigd dat continuous development wél goed werkt. We bouwen een relatie op met onze klant en eindgebruikers, werken veel samen en krijgen zo écht kennis over het product en de markt. Bij verandering van de wensen en behoeften zijn we op de hoogte en kunnen we meebewegen richting het grootste succes mogelijk.

Continuous development in de praktijk

Het begint allemaal met een wens voor een nieuwe feature op de backlog. Nice! Dit ruwe idee wordt middels refinements steeds duidelijker. Welke keuzes kunnen we het beste maken? Welke richting moeten we op werken?. Als de requirements voor de feature duidelijk genoeg zijn kunnen we gaan beginnen met ontwerpen en ontwikkelen. Een eerste versie van de feature ligt dan snel op de plank.

Tijdens de review komt er echter vaak feedback terug. Gelukkig is dat precies wat we willen. Vooraf precies bepalen wat er gemaakt moet worden en hoe we dat gaan doen is namelijk ontzettend moeilijk. En tevens gaat tegen ons design thinking principe in ;-). Pas als de feature tastbaar is kun je kwalitatieve feedback ophalen bij stakeholders en gebruikers. Deze waardevolle input wordt vervolgens gebruikt om een nieuw item op de backlog in te schieten. Zo maken we het cirkeltje rond.

Heel vaak verandert er gaandeweg ook nog iets aan een feature. Ontwikkelingen in de organisatie, trends of behoeften van gebruikers kunnen namelijk nog wel eens veranderen. Ook dan is er nog geen man overboord. Want doordat we continu blijven ontwikkelen kunnen we de koers steeds een klein beetje bijsturen naar het gewenste resultaat.

Ook voor onderhoud!

Het continu door blijven ontwikkelen van je app is niet alleen belangrijk voor nieuwe features, maar ook voor het onderhoud. Doordat we zo snel en adaptief werken moeten we soms wat shortcuts nemen. Dit kan bijvoorbeeld doordat we nog niet weten of de feature een succes gaat worden. Dan is het zonde om er al heel veel development tijd in te stoppen.

Of als er een dringende vraag vanuit de markt of klant is, bijvoorbeeld een belangrijke demo. Dan is snelheid belangrijker dan het perfect uitwerken van een feature. In dat geval is continuous development een belangrijke spelregel. Later kunnen we het namelijk wél goed doen.

Stabiliseren en refactoren

Het is belangrijk dat deze shortcuts later ‘opgeruimd’ worden, refactoren noemen we dat. Dit is van belang om het product meer toekomstbestendig te maken. Door de code wat leesbaarder of efficiënter te maken, of het product naar een hoger niveau te tillen.

Het nemen van shortcuts is een kortetermijnoplossing. Maar deze shortcuts stapelen zich op en halen je op een gegeven moment in. Het wordt namelijk steeds ietsje moeilijker om verder te werken op dezelfde code (hetzelfde geldt overigens voor UX). Des te belangrijker dus om dit onderhoud tijdig in te plannen voordat er grote problemen ontstaan.

En ze leefden nog lang en gelukkig…

Wijzelf en de wereld om ons heen zijn continu in beweging. Dus het zou raar zijn als onze producten dat niet zijn. Daarom is continuous development een manier van werken die trouw aan onze zijde blijft. Gelukkig maar, anders zou het een saaie bedoeling worden.