Iteratief opleveren, waar gaat het mis?

Agile werken betekent dat je veel toetsingsmomenten inlast, zodat projecten in no time zijn bij te sturen. In de praktijk blijkt het vaak toch anders te werken. Waarom gaat het toch vaak mis? En hoe zorg je er nu voor dat je niet alles in één keer achter gordijntjes gaat ontwikkelen? Tips om iteratief opleveren te laten slagen.

De nachtmerrie van iedere agile professional: Het is de dag van je productlaunch. Het moment waarop je product eindelijk het levenslicht ziet; eindelijk ga je succes oogsten. En dan volgt een oorverdovende stilte… teleurgestelde gezichten vliegen langs. Je grootste fout; je hebt niet tussendoor gekeken of het succes gehaald ging worden. Je hebt niet regelmatig gekeken of je in de goede richting zat. Maar wacht, je deed er toch alles aan om dat te voorkomen? In de praktijk blijken veel projecten alsnog weinig toetsingsmomenten te hebben en zonder veel bijsturing naar een livegang te werken.

Wat zegt de theorie ook weer?

Je team werkt in sprints of iteraties aan het product, maar dat blijft een intern feestje tot je een deel van het product aan de werkelijkheid kan toetsen. Zonder deze toetsing, bij je eindgebruikers en stakeholders bijvoorbeeld, mis je dus de feedback om op het scherp van de snede te kunnen blijven functioneren.

De theorie is helder. Stel jezelf ten doel om de aannames en doelen van je productvisie zo helder te krijgen dat je jezelf de vraag kan stellen: “wat is er nodig om zo vroeg mogelijk te zien of dit succesvol is”, en “welke combinatie van features is als het aangeboden kan worden al uit zichzelf waardevol”.

Mik op het minimale om je (belangrijkste) doelen te bereiken of te kunnen toetsen; je “Minimum Viable Product”. Het is van belang te checken of je uitgangspunten gedurende het proces nog kloppen en die zo snel mogelijk bevestigd te krijgen. Dat kan het beste als je het niet in één keer goed probeert te doen, maar in delen.

Voor de meeste professionals die van agile hebben gehoord klinkt dit zo voor de hand liggend als wat. De theorie praat wel in officiële termen als “incrementen”. Maar je merkt al snel dat in de praktijk water bij de wijn wordt gedaan.

Waar gaat het in de praktijk mis?

Vaak vallen we terug in oude patronen: de zoektocht naar perfectie, het voorkomen van kritische feedback en uiteindelijk; het volgen van nauwkeurig uitgewerkte plannen.  Je kan dit snel herkennen in een project. Een greep uit de belangrijkste symptomen:

• Er is vooraf een visueel / UX ontwerp gemaakt dat in zijn geheel wordt gebouwd, en niet per iteratie kan worden veranderd
  
• Er is geen plan om het succes van resultaten uit sprints te meten of feedback te verzamelen
  
• Technische uitdagingen zijn niet als proof-of-concept benoemd, maar er zijn uitputtende technische architecturen uitgedacht die in alles voorzien.
  
• Het team ziet de sprint review als een progressie- of status-update en niet als een moment waarop de richting van het product kan worden getoetst en bijgesteld
  
• De belangrijkste aannames die de business case moeten bekrachtigen staan niet centraal bij de zoektocht naar feedback, en het product wordt dus niet tijdig kritisch tegen het licht gehouden.
  
• Er wordt gestuurd om het product gelijk in een complete vorm live te zetten, waarna er geen aandacht meer voor is en aan andere zaken wordt gewerkt
  
• Na de livegang / eerste lancering is ook het complete budget al op

Een voorbeeld

Een intranet is toe aan vernieuwing, en het uitgangspunt is dat er een nieuw product ontwikkeld wordt. Veelgehoorde klachten zijn een gebrek aan vindbaarheid van informatie, een missend smoelenboek en een wens om personalisatie. Oh, en een nieuw jasje mag ook wel weer eens. Mobile-first, natuurlijk.

Vroeger, voordat je agile werkte, zou je het intranet in haar geheel gaan bouwen en na vele maanden en een bijna crimineel migratieproces eindelijk een volledig product lanceren. Wellicht strip je aan de hand van budget wat features, maar de medewerkers zien het pas als de belangrijkste stakeholders het ‘af’ vinden.

Een tweede voorbeeld; je maakt een nieuwe uitbreiding op de online ‘mijn omgeving’ van je verzekeringsmaatschappij, waarin het mogelijk is om de status van betalingen en declaraties te zien. Samen met je collega’s en een enthousiast UX-team maak je een verbluffend mooie self-service oplossing die uiterst compleet en gebruiksvriendelijk is. Archieven, chatfuncties; the works.

Helaas, omdat de technische uitdagingen een grote mate van complexiteit hebben, duurt het vervolgens maanden voordat deze omgeving het daglicht ziet. Uiteindelijk bleek je time-to-market te lang, en naast de inkomsten heb je ook nog de boot gemist om je klanten te verbluffen.

Met deze aanpak wisten we dat eigenlijk al van te voren. Toch hebben we de neiging om voor het complete portaal te gaan, want wat als de gebruikers het niet goed genoeg vinden? Zou het vervelend overkomen als we niet alles al gelijk aanbieden?

De backoffice klaagt echter gedurende deze periode over de grote mate van telefonische ondersteuning om mensen verder te helpen… en die dure archief zoekoptie blijkt in de praktijk twee keer per maand gebruikt te worden. Laat opleveren en sturen op eigen aannames over wat je gebruikers willen. Dat klinkt allemaal niet Agile.

Hoe kan dat anders?

Herkenbaar? Zoek je naar een methode om dit te voorkomen? Lees dan verder in “Praktisch Agile denken bij deelopleveringen” Of liever sparren? Benieuwd waar anderen tegenaan lopen? Dinsdag 21 november organiseert theFactor.e het Agile Event. Kom luisteren en praten met product owners, agile coaches en andere geïnteresseerden.