Experimenteren met lean startup methode

De laatste maanden heb ik geëxperimenteerd met de lean startup methode in een gedistribueerde omgeving. Laat het me uitleggen, want als je geen offshoring-insider bent, kan dit klinken als abracadabra.

Van de lean startup method heb je wellicht gehoord. De essentie van de methode is: als je een idee hebt voor een (software/internet/app-) product, ontwikkel dan zo snel mogelijk een minimaal haalbaar product. Dit kan een ‘alfa’ versie zijn van je software, of zelfs beter een ‘simulatie van je idee’. Een voorbeeld: je bent van plan om auto’s te verkopen via een app. Het eerste wat je wil doen is het testen van je aannames, bijvoorbeeld ‘mensen zijn bereidt om een auto te kopen via een app’ (of ‘mensen zijn bereidt een app te dowloaden die hen beloofd om een auto te kopen’).

Om dit te testen, ontwikkel je de meest denkbare eenvoudige app (en je lanceert dit op android omdat apple je het leven zuur maakt als er bugs in de app zitten). De app heeft één scherm, laat één auto zien en een ‘Bestel’ knop bijvoorbeeld. Je lanceert dit en kijkt of iemand deze app download. Zodra je de eerste bestelling krijgt, ren je naar de dichtstbijzijnde dealer en rijdt de auto naar de persoon die hem besteld heeft. Dit zal jouw hypothese/aanname bevestigen. Pas dan begin je met het ontwikkelen van de ‘echte’ applicatie en daarin test je voortdurend jouw aannames in tegenstelling tot de ‘building features’.

Het verdeelde deel is dat mensen uit verschillende landen aan de productontwikkeling werken. Typisch zijn de ontwikkelaars uit bijvoorbeeld India of Oekraïne, terwijl de persoon die eigenaar is van het product of de marketing van het product doet, in een ander land zit.

Ik ben momenteel een bullet proof methode aan het ontwikkelen om zoveel mogelijk werk te doen in ons offshorekantoor in India. Het doel is om eigen interne producten te ontwikkelen alsmede service voor klanten (startups of bestaande software bedrijven/afdelingen) door onze lean distributed startup methode. We combineren altijd het lean startup denken met elementen van scrum (dat is onze standaard software development methodologie).

Vier verschillende setups

Om de methode te ontwikkelen heb ik tot nu toe verschillende setups geprobeerd:

A. De persoon met het idee is in Nederland. Hij is de producteigenaar (de persoon die alle beslissingen neemt wat betreft de ontwikkeling en de volgende stappen). De scrum master en het ontwikkelingsteam zitten in India. De procesmanager zit in Nederland (de persoon die de communicatie faciliteert tussen de product eigenaar en het offshore team). Dit is een externe gedachte dat we opnemen in een gezamenlijke startup.

B. Er ontstaat een idee in India, in nauwe samenwerking met mezelf (ik ben in Nederland). De product eigenaar is in India, de scrum-master en het ontwikkelingsteam ook. Dit is een 100 procent intern product.

C. Een programmeur uit India komt met een idee. De product-eigenaar, scrum-master en ontwikkelaar zitten in India.

D. De product-eigenaar en de scrum-master zitten in Duitsland. Het ontwikkelingsteam zit in Oekraïne. Dit is voor ons de meeste typische opzet in het bieden van onze service aan onze klanten, waar wij als ontwikkelingspartner dienen. 

Model A:
– De product eigenaar is een atechnisch person die geen ervaring heeft in het ontwikkelen van software producten, waardoor vanaf het begin het offshore team veel autonomie krijgt in het ontwikkelen van de app.

– De proces manager kan een gebrek van vooruitgang merken van beide kanten. Doordat de product eigenaar een outsider is (en de marketing afhankelijk is van die persoon) en het team remote is, heeft hij geen volledige controle en zal hij vele blokkades op de weg moeten verwijderen. 

– De product-eigenaar kan een gebrek van vooruitgang merken, omdat hij graag zijn product uit wil brengen en niet dagelijks kan zien hoe ver de ontwikkelaars zijn op dat moment (entrepreneur zijn typisch ongeduldig). 

– Omdat het idee niet is ontstaan vanuit het ontwikkelingsteam of vanuit het eigen bedrijf, is het product niet volledig hun ‘baby’ (waarvan ik geloof dat het een belangrijk ingrediënt is voor een succesvolle startup). 

Model B:
– Omdat het een intern product is, heeft het ontwikkelingsteam volledige eigenaarschap over het product. 

– Zelfs de product eigenaar is in India, waardoor er meer dynamiek in het team ontstaat. Ze blijven ideeën uitwisselen en zijn enthousiast om te zien hoe de eerste interacties met de klant zijn. 

– Hoewel het moeilijk is om dit erin te krijgen bij een ontwikkelingsteam, de product-eigenaar en de scrum-master denken in termen van marketing en zorgen onmiddellijk voor veranderingen in het product,gebaseerd op user feedback. 

– De ‘keerzijde’ is dat ik graag zie dat de app snel wordt uitgebracht, dat er snel feedback vanuit de klanten komt, het snelle bewegen. Omdat het team ver weg zit en ik zelf niet de product-eigenaar ben (dus ik mag niet op een dagelijkse basis communiceren), zal ongeduldigheid bij mij optreden.

Model C:
– Hier heb je een technisch team die het idee hebben bedacht en zij zien graag dat het product snel uitgebracht wordt, wat erg snel gaat.

– Maar dan de marketing app, het genereren van feedback komt aan bod en hierdoor zal het product vast lopen.

–  Omdat niemand in Europa erbij is betrokken, merk ik dat er niemand is om het team aan te sporen om verder te gaan met het product.

– Deze ervaring is waarschijnlijk gebonden aan een specifiek product en we moeten meer experimenteren om tot conclusies te kunnen komen.

Model D:
– Het volledige eigenaarschap van het product is bij een van onze klanten in Duitsland, dus het gehele product is bedacht in Duitsland. 

– De scrum-masterplanning van de sprints en het plegen van de user stories is allebei bij de product-eigenaar; om volledige betrokkenheid bij het remote team te krijgen, wordt de sprint planning gedaan met behulp van Skype.

– Het helpt om nog een scrum-master te hebben in Oekraïne.

– Het team focust zich op de technologie, architectuur, functie ontwikkeling en niet op product roadmap, marketing en het genereren van feedback van gebruikers. 

Ik zal in mijn toekomstige blogs schrijven over deze lean distributed startup-methodologie. De voorlopige conclusies die ik tot nu toe heb gemaakt:

1. Voor diensten verlenen aan klanten als een offshore of een nearshore provider, zal model D het beste werken. U kunt variëren met het hebben van een remote scrum-master, maar de product eigenaar behoort onshore the zijn, dicht bij de klant (hoewel ik het kan aanraden aan de product-eigenaar om tijdens de startup periode zich te verplaatsen naar het team).
2. Dat het gehele team, inclusief de product-eigenaar in India is, zorgt voor onze interne product ontwikkeling een grote betrokkenheid en vooruitgang. Het team ‘leeft’ het product.

Ik zou graag jouw ervaringen in remote startup ontwikkeling willen horen!