Bij Recras zijn we continu bezig om ons product nog beter te maken. Maar hoe bepalen waar we aan werken? Sinds kort werken wij met een nieuw ontwikkelproces, en in deze blogpost lichten we dit toe.

De helft van het team van Recras bestaat uit programmeurs, waardoor we veel tijd besteden aan software-ontwikkeling. Naast het bouwen van nieuwe dingen wordt er ook altijd gewerkt aan het repareren van bugs en het doen van onderhoud. Maar hoe bepalen we dan aan welke dingen er gewerkt wordt?

Er zijn altijd ontzettend veel ideeën om Recras nog beter te maken! Veel hiervan komen binnen via onze gebruikers, die erg betrokken zijn. En zelf hebben we natuurlijk ook veel plannen, dus aan input geen gebrek.

Ons proces

We werken in periodes van 5 weken, gevolgd door 1 ‘tussenweek’. In deze 5 weken werken we aan 2 tot 3 projecten. In de 6e week evalueren we de afgelopen periode, pakken we losse klusjes op, en plannen we de volgende periode.

Laten we beginnen bij het begin: de projectselectie. Deze doen we altijd voordat een periode begint. De projectselectie is een overleg (van 2 uur) waarbij het hele team aanwezig mag zijn en invloed kan uitoefenen. Potentiële projecten worden hier gepitched: een pitch wordt altijd van te voren in Google Docs uitgewerkt, en mag tijdens de projectselectie nog 5 minuten worden toegelicht.

Meestal zijn er wel 6 tot 10 pitches, wat betekent dat we harde keuzes moeten maken! Sommige pitches worden redelijk vlot afgewezen: bijvoorbeeld omdat maar een klein deel van de gebruikers er iets aan zou hebben, of omdat de pitch nog niet goed genoeg uitgewerkt is (dan moet deze terug naar de tekentafel, en kan in een latere periode eventueel opnieuw ingediend worden).

Vaak blijven er dan alsnog te veel goede projecten over. Er volgt dan een ronde van overleg: is een bepaald project belangrijker dan een ander project? Is er een goede reden om een project uit te stellen, of is het juist handig als het voor een bepaalde datum af is? Zijn we er dan nog niet uit, dan wordt er gestemd.

De projecten die het niet hebben gehaald gaan naar het archief. Dit is bijvoorbeeld gebeurd bij een pitch voor het “maken van statistieken over gebruik van kortingscodes”. We vonden het allemaal een goed idee, maar andere projecten in die periode waren nog belangrijker.

Pitches uit het archief worden soms opnieuw ingediend. Daarnaast worden alle goede ideeën uit het archief benoemd in onze enquête, zodat gebruikers van Recras daar kunnen laten weten welke projecten zij het belangrijkst vinden.

Per project dat we gaan doen wordt een team samengesteld. Vaak bestaat zo’n team uit 2 personen: 1 programmeur, en 1 niet-programmeur. Een van de projecten die we op deze manier hebben ontwikkeld is het “digitaal akkoord geven op een boekingsvoorstel”. Dit is een project waar we al lange tijd aan wilden werken, maar waar we op deze manier echt tijd voor hebben vrijgemaakt.

Overkoepelend over alle projecten wordt een “periodecaptain” aangesteld. Deze ziet er onder andere op toe dat de projecten niet stil komen te liggen.

Dan begint de periode zelf in week 1. Tijdens deze 5 weken werken we aan de gekozen projecten. Hierbij proberen we zo snel mogelijk eventuele problemen te vinden, zodat we daar hopelijk nog iets aan kunnen doen. Daarnaast proberen we onze projecten flexibel te maken: valt het project tegen, kunnen we het dan kleiner maken? Valt het mee, kunnen we dan iets extra’s doen? Hiermee proberen we er voor te zorgen dat er uiteindelijk altijd iets op te leveren valt.
Bugs die tijdens de periode worden ontdekt pakken we altijd zo snel mogelijk op, wat ook voor een stukje variatie in het werk zorgt. Zodra iets is opgelost, wordt het teruggekoppeld naar de gebruiker die het heeft aangedragen. 

In week 6 begint onze ‘tussenweek’, en is het als eerste tijd voor de evaluatie. Dit is weer een overleg (van 1 uur) voor het hele team, waar we bespreken hoe projecten gegaan zijn. Viel een project tegen? Dan proberen we er achter te komen waar dit door kwam, en hoe we dit in de toekomst kunnen vermijden. Als een project niet (helemaal) gelukt is, bespreken we hier ook wat we er verder mee gaan doen. 

Verder wordt deze week gebruikt voor wat losse taken. Bijvoorbeeld het repareren van bugs die een lage prioriteit hebben, het doorvoeren van technische verbeteringen, of wijzigingen waardoor de programmeurs hun werk beter kunnen uitvoeren. En we eindigen weer waar we begonnen: met de projectselectie voor de volgende periode.

Hoe we hier zijn gekomen

We hebben niet altijd op deze manier gewerkt, we hebben nu 4 periodes (ongeveer 5,5 maand) volgens deze manier gewerkt. Hiervoor werkten we met een veel losser proces. Iedere maandagochtend hadden we een kort overleg (een half uur) met het hele team, waarin we de week bespraken. Hier bespraken we al het programmeerwerk dat in de afgelopen week gedaan was, het werk dat nog bezig was, en het werk dat nog ‘open’ stond. In principe werd al het openstaande werk stilzwijgend doorgeschoven naar de volgende week, tenzij we op dat moment besloten om iets niet meer te doen.

Nieuwe projecten werden toen op allerlei momenten gemaakt. Bijvoorbeeld omdat een gebruiker van Recras belde met een belangrijk en urgent idee. Dit werd dan vaak nog even overlegd met Harrie of Tijmen.

We liepen hierbij tegen een aantal zaken aan. Ten eerste merkten we dat projecten die belangrijk zijn maar geen urgentie hebben vaak niet opgepakt werden. Er is altijd wel iets dat op dat moment urgent is (maar op de lange termijn misschien niet zo belangrijk), de “waan van de dag”. We zijn toen op zoek gegaan naar meer gestructureerde werkmethode, die goed bij onze identiteit past. We hebben ons hierdoor sterk laten beïnvloeden door andere softwarebedrijven, zoals bijvoorbeeld Basecamp en Moneybird

Wat de toekomst ons brengt

Op dit moment hebben we 4 periodes gewerkt volgens onze nieuwe structuur, en we zijn er ontzettend enthousiast over! Het kiezen tussen verschillende goede pitches is lastig, maar deze discussie zorgt er voor dat onze prioriteiten duidelijker in beeld krijgen. We hebben hierdoor al een aantal projecten opgepakt, waarvan we denken we ze vroeger misschien nog wel een keer hadden uitgesteld. Ook zorgt het overleg met het hele team voor een hoop duidelijkheid. Daarnaast zorgen relatief korte periodes ervoor dat onze projecten erg concreet moeten zijn, en dat we niet blijven door-emmeren. Omdat ons hele team projecten kan aandragen, merken we dat er ook veel input vanuit support uitgewerkt wordt. Op deze manier komen veel ideeën van gebruikers van Recras bij ons terecht. Door deze projecten met het hele team te bespreken bewaken we ook de langetermijnvisie van Recras.

Natuurlijk zitten er ook nadelen aan onze methode, niks is perfect. Tijdens de zomervakantie merkten we bijvoorbeeld dat het toch best lastig is wanneer een aantal teamleden niet aanwezig kunnen zijn bij de projectselectie. Verder zijn projecten die niet worden afgerond in een periode lastig: wat doe je ermee? Helemaal stoppen, en al het werk voor niks; of meenemen naar de volgende periode (en daar dus minder andere dingen kunnen doen), lastig! Daarnaast willen we bugs die binnenkomen graag zo snel mogelijk oplossen, maar dit gaat natuurlijk wel ten koste van tijd die we aan projecten kunnen werken. Is er ineens een periode met veel bugs, dan wordt het lastig om alles aan het einde af te krijgen.

Tijdens onze evaluatie van een periode bespreken we voor- en nadelen ook elke keer. Het proces dat we hanteren staat ook niet voor altijd vast, elke periode worden er wel wat kleine aanpassingen gedaan. Bijvoorbeeld over hoe pitches ingediend moeten worden, wie een overleg voorzit, etc. Tijdens de laatste evaluatie hebben we nog eens kritisch gekeken naar de lengte van een periode, in sommige gevallen (bv rondom de zomervakantie) denken we dat het handig kan zijn om een periode met 1 tot 2 weken te verlengen. Ongetwijfeld ziet het proces er over een jaar weer anders uit, en dat is alleen maar goed!

Heb je naar aanleiding van deze blogpost vragen, of heb je een suggestie voor ons proces? Laat het ons dan even weten.