In 2018 sprak Rieks tijdens MageTitans Groningen, een conferentie voor developers georganiseerd door Elgentos, MediaCT en Space48. Zijn presentatie werd goed ontvangen door zijn collega’s, en hij besloot zijn verhaal op papier te zetten voor het MediaCT blog. Zijn visie over het lanceren van een webshop in slechts één sprint zette veel mensen aan het denken. Lees snel verder!

agile-rieks.jpg

Het lanceren van een nieuwe webshop is vaak een groot en complex project. Er wordt een nieuw design uitgewerkt en functionaliteiten uit de bestaande webshop worden nagebouwd. Nieuw ontwikkelde features gaan de klant een verbeterde shopervaring geven. Met bloed, zweet en tranen wordt er maanden of zelfs jaren aan het project gewerkt. Maar, na een spannende en regelmatig stressvolle tijd komt die ultiem spannende dag, het moment van de waarheid: de nieuwe shop gaat live! Gaat de nieuwe shop net zo converteren? Brengt het design de verwachte verbeteringen; hoe en waar precies? Kan de site de pieken in verkeer aan? Gaan de nieuwe features meer orders opleveren? Begrijpen de gebruikers de nieuwe configuratiewizard? Alles gaat zich nu bewijzen!

Spannend zeg, zo’n waterval!

De bovenstaande aanpak zul je waarschijnlijk herkennen. Veel projecten worden op een dergelijke, plan-gedreven, ‘waterval’ manier uitgevoerd. Hoewel het bijna leest als een spannend boek, komt het aan het eind niet altijd goed. ‘Spannend’ is hier een mooi woord voor stress- en risicovol. Wanneer het om grote projecten en veel geld gaat, heeft ‘stabiel’ en ’voorspelbaar’ toch de voorkeur. En als software-ontwikkeling iets veelal niet is, dan is het wel voorspelbaar. De waterval-aanpak leent zich goed voor herhalende, voorspelbare processen. Voor creatieve, complexe uitdagingen in een continu veranderende markt, is het minder geschikt. Net als bij een echte waterval, heeft het afdalen van een projectwaterval de nodige gevaren:

Validatie van alle gemaakte keuzes is pas aan het eind. Kosten en risico lopen op, en daarmee spanning en stress. Als klant, en als ontwikkelende partij leren we onderweg nog niks over de beslissingen die gemaakt worden.

  • Doordat er niet met echte eindgebruikers wordt getest tot de livegang, is het waarschijnlijk dat de functionaliteit niet volledig aansluit bij hun behoeften. Zelf een feature testen is toch heel anders dan wanneer een echte gebruiker er mee aan de slag gaat. Voortbordurend daarop: tot de livegang staat het project op een afgeschermde veilige omgeving, bijvoorbeeld een staging- of acceptatie-server. Door deze veiligheid wordt er minder goed getest. Wanneer een livegang nog maanden verwijderd is, kijkt men lang niet zo kritisch als wanneer de feature nog diezelfde week gereleased wordt.

  • Priorititering is lastig. Doordat de deadline ver weg is, maakt de volgorde in feature-ontwikkeling ogenschijnlijk niet uit. Of, er wordt aan drie features tegelijk gewerkt, maar geen van allen is echt af. Ook worden features vaak in delen opgeleverd. “Deze sprint wordt de styling van de feature opgeleverd”. De back-end logica komt over 2 sprints. De feature valt niet te testen, zou niet gereleased kunnen worden, en heeft dus geen waarde. Maar, het is op een afgeschermde omgeving, dus, geen probleem!

Geen probleem... totdat we twee weken voor de deadline zijn. Een van de meest treffende vragen tijdens een software project is: “als we dit nu lanceren, wat gaat er dan écht mis?”. Dát zijn de zaken die als eerste aangepakt moeten worden. Helaas stellen we deze vraag bij waterval pas helemaal aan het eind, met het gevolg dat vlak voor lancering de deadline verschoven moet worden.

 
Agile waterfall plan versus reality
 

Over naar Agile vaarwater

Dat de waterval gevaarlijk is weten we al decennia. In de jaren 90 ontstonden daarom meerdere lichtgewicht projectmethoden met een andere visie, zoals Scrum, DSDM en Xtreme Programming. De grondleggers daarvan stelden, samen met andere invloedrijke IT gurus, in 2001 het ‘Agile Manifesto’ op. Deze beschrijft de essentie van deze nieuwe methoden; een verklaring van de kernwaarden waar zij gezamenlijk achter staan. De essentie: samenwerken met klant (opdrachtgever) en eindgebruiker, doorlopend werkende software opleveren in korte cyclussen, om daarmee continue feedback en verandering te omarmen.

 
© Rieks Visser

© Rieks Visser

 

Ok, goed verhaal! Maar wat gaan we nu doen dan?

Dat is een terechte vraag. De vertaling van de Agile ideologie naar de praktijk kan best lastig zijn. Scrum is een methode die hierbij helpt, met regels en rollen die “garanderen” dat je Agile bezig bent. Maar, ook Scrum vertelt uit zichzelf niet precies ‘waarom’ en het ‘hoe’ binnen een real-life context. Dit is omdat je dit juist zelf moet ontdekken, je eigen lessen leren. Ieder bedrijf en project is anders, je moet ontdekken wat voor jou werkt. Wat voor Spotify, Apple of je concurrent werkt, werkt niet per se voor iemand anders.

Omdat we hier binnen MediaCT al jaren mee bezig zijn, kunnen we wel onze geleerde lessen delen. De aanpak die wij in de context ‘Magento projecten’ ontdekt hebben, en hoe we de gevaren van de waterval ontwijken.

Spijkers met koppen

Dus, “down to business”! Zoals gezegd draait alles om korte cyclussen, samen met de opdrachtgever software maken en feedback zo vroeg mogelijk inbouwen. Gelukkig biedt Magento ons werkende software vanaf dag 1. Alles wat je nodig hebt om orders van klanten te kunnen ontvangen, zit er in. Met dit kant en klare ‘Minimum Viable Product’, kunnen we klanten laten bestellen en betalen. In de eerste sprint nemen we daarom de volgende stappen:

  • Een Magento-shop zonder wijzigingen wordt op een ‘live’ server gezet. Deze shop is te bezoeken via een domeinnaam.

  • Het logo en twee huisstijlkleuren worden toegevoegd aan het design.

  • Bezoekers moeten kunnen betalen, al is het via bankoverschrijving. Een kant-en-klare extensie voor iDeal of Paypal is nog mooier.

  • Opdrachtgever en developers stellen samen basale Analytics in.

  • Medewerkers van de opdrachtgever voegen de eerste producten toe; basisinformatie en een foto. Minimaal één product, liever twintig a dertig.

  • Medewerkers van de opdrachtgever voegen de essentiële CMS pagina’s toe. Denk aan: algemene voorwaarden, FAQ’s, contact, de homepagina.

That’s it! Er is nu een volledig werkende live webshop waar klanten kunnen bestellen. We krijgen feedback doordat de webshop werkt, orders geplaatst kunnen worden, en statistieken uit Analytics ons vertellen hoe de shop presteert. In sprint 2 gaan we direct aan de slag met de eerste verbeteringen en het uitbouwen van de eerste aanvullende functionaliteiten zodat we direct meer feedback krijgen.

 
Henrik Kniberg ( source )

Henrik Kniberg (source)

 

Leren van Agile

De stappen hierboven zijn het resultaat van de lessen die we op ons Agile pad geleerd hebben. Op deze wijze werken heeft ons en onze klanten veel voordelen gebracht:

  • De webshop is altijd klaar voor release. Door de werkende software per sprint uit te bouwen, veranderen we de mindset van ‘is het af?’ naar ‘hoe kunnen we dit nog beter maken’?

  • Goed prioriteren en testen is ingebouwd. De shop staat ‘live’, we moeten bouwen wat nu voor klanten het belangrijkst is en het moet gewoon werken. Geen veiligheid achter gesloten deuren. In plaats daarvan, een stok achter de deur.

  • Samenwerking tussen de klant (opdrachtgever) en de ontwikkelende partij vanaf de eerste sprint. De klant werkt mee en is onderdeel van het resultaat van de sprints. Er wordt actief geëvalueerd en gepland, telkens kijkend naar wat het belangrijkste is voor de webshop.

  • Er is echte feedback vanaf de eerste sprint. Stakeholders, medewerkers en klanten kunnen allemaal vanaf de eerste sprint input leveren. Op basis hiervan kunnen prioriteiten worden gesteld en bouwen we functionaliteit waarvan we bewijs hebben dat gebruikers ze nodig hebben.

  • Budget wordt optimaal besteed. We bouwen niet wat we niet nodig hebben. Op ieder moment kunnen we besluiten dat de shop goed genoeg is.

Beren op de weg en olifanten in de kamer

Zeggen we nu écht dat we in één sprint een webshop ‘live’ gaan zetten? Basic Magento, met slechts een ander logo en wat kleurtjes? Jazeker! Dat kan natuurlijk wat twijfels oproepen. Klanten hebben verwachtingen vanuit de bestaande webshop, de merkervaring van de klant is gekoppeld aan hoe de shop er uit ziet, en de plannen voor een nieuw design, hoe doen we dat? Die vragen horen we vaker, en we hebben hier dan ook strategieën voor ontwikkeld, hieronder lees je een aantal voorbeelden.

1. Niche shop voor het nieuwe project

We creëren een nieuwe shop, voor een bepaalde niche. Denk aan een productcategorie of een pilot voor een nieuw type product, land, doelgroep, enzovoorts. Hiervoor komt een apart domein en Magento storeview. (Een storeview is een manier om de inhoud en/of producten van de webshop weer te kunnen geven. Denk hierbij aan verschillende talen, verschillende shops met hun eigen focus of simpelweg een andere url.) Deze storeview gaat direct live, en wordt doorontwikkeld. Tegelijkertijd wordt een tweede storeview voor de ‘echte’ store aangemaakt. Deze is nog niet open voor het publiek. Doordat Magento storeviews van elkaars functionaliteit gebruik kunnen maken, komt er weinig extra werk bij kijken. De ontwikkeling van niche en toekomstige shop, gaat gelijk op. Wanneer de functionaliteiten op de niche shop goed genoeg zijn en zich bewezen hebben, kan de ‘echte’ storeview de huidige webshop vervangen.

2. Toegang tot de webshop

In sprint 1 kunnen we prima alleen interne medewerkers toegang geven, en laten we Google nog even niet indexeren. Zolang we maar feedback krijgen. De sprints daarna wellicht wat bekenden, enkele trouwe klanten of een klein aantal Adwords of Facebook advertenties. Des te meer vertrouwen we winnen, des te meer verkeer we toelaten. Vaak is een echt domein en de gedachte aan potentiële bezoekers al genoeg om de mindset van alle betrokkenen te veranderen.

3. Atomic design

In plaats van design per pagina uit te werken, gaan we van het kleinste element naar boven werken. Eerst fonts, achtergrondkleuren en individuele elementen. Daarna de afstanden daartussen, bijvoorbeeld een knop en een invoerveld. Daarna groeperen we dit, in bijvoorbeeld een header of een formulier. Dit vormt dan de basis voor de pagina’s. We verfijnen zo het design, maar hebben vanaf sprint 1 de basis toegepast. We krijgen onmiddellijk feedback en weten wat te verbeteren. Vaak zit de winst in informatie op de juiste plek, niet in de perfect gradient. Ook hier geldt, wanneer het goed genoeg is, kunnen we stoppen. Maximale waarde voor het budget, ook in design.

Dit is slechts een greep uit de vele opties die er zijn. Voor ieder project is de context weer net even anders, en daar gaan we dan ook ‘Agile’ mee om. Creatieve oplossingen ontstaan wanneer de klant, consultants en ontwikkelaars nauw met elkaar samenwerken. Niet discussiëren over beperkingen, maar zoeken naar mogelijkheden, dat doen we bij MediaCT het allerliefst. Zo zijn en blijven we samen succesvol.


Zelf interesse om op deze manier een project aan te vliegen? Neem eens contact op met een van onze specialisten. Zij helpen je graag verder.