Zo leer je praktisch Agile denken bij deelopleveringen

Werknemers hebben instinctief de neiging om toch naar zekerheden te grijpen, ook al zijn alle agile rituelen goed ingericht. Agile denken is de oplossing, maar hoe? Agile vraagt drie denkstappen.

Drie denkstappen voor agile werken

  1. Maak het belangrijkste eerst
  2. Ga live
  3. Toets of je de juiste snaar raakt.

Iteraties of incrementen

Opdelen van een project zou in de oude stijl leiden tot zogenaamde iteraties; de aloude deelopleveringen. Vaak wordt het meer gebruikt als controlemiddel: je laat het ontwikkelteam meerdere malen in het proces tonen wat ze hebben gemaakt en geeft daar feedback op.

Geen slechte gedachte, maar vaak bestaan die deelopleveringen meer uit een ‘ruwe status van ontwikkeling’ dan een op zichzelf staand product. Oftewel, een uitgeklede ‘basisversie’ van je product. En natuurlijk wat testcontent. En dat kan niet live. Kan je hiermee waarde toevoegen aan je organisatie? Nee, dat ook niet, want er is nog niets daadwerkelijk af. En om eerlijk te zijn is de deeloplevering een voorproefje van wat je al in eerste instantie dacht te gaan maken. Je hebt je al enigszins gecommitteerd: bijsturen is eigenlijk niet meer makkelijk.

De theorie praat altijd over incrementen; elkaar opvolgende werkende software. Maar dat vraagt wel anders denken. Wat kun je iets anders doen in het proces zodat ook delen van het product levensvatbaar zijn en waarde opleveren? En hoe kan je daarmee je visie blijven toetsen en bijsturen wanneer nodig?

Minimum Viable; niet alles, maar wel al live

Teruggrijpend op het scenario van het intranet in Iteratief opleveren, waar gaat het mis?  is duidelijk dat de gebruikersgroep een aantal duidelijke pijnpunten heeft. Als je je pijlen op specifiekere verbeterpunten richt en je niet voor een grootse opzet kiest, komt vanzelf boven drijven dat juist die punten als eerste uitgewerkt kunnen worden

Omdat agile werken een multi- (of liever een cross-) disciplinair team aanbeveelt, ben je in staat je te richten op het opleveren van werkende software. Niet in één keer (big bang), maar incrementeel, in onderdelen of “vertical slices”. Het is immers noodzakelijk om aan te tonen dat je succes kan oogsten, en met een ‘brede’ conceptversie kan je vaak juist dat niet aantonen.

Minimal Loveable Product

theFactor.e kent als hulpmiddel ook de term “M❤P” voor Minimum Lovable Product. Deze herinnert je er aan dat je alle toepasselijke onderdelen om een feature een succes te maken ook moet vervullen. Een feature die slecht is uitgewerkt mag nooit ‘viable’ genoemd worden, maar het mag nog wel ruimte voor verbetering kunnen hebben; we weten allemaal dat liefde ook niet vanaf dag 1 perfect hoeft te zijn. Het moet wel goed genoeg zijn om er een warm gevoel van te krijgen.

Als je je dus goed voorbereidt en goed nadenkt over wat je MVP en opvolgende incrementen kunnen zijn, kun je je dus veel sneller aanpassen en waarde toevoegen. Je kan er immers al de bühne mee op, en wellicht los je er vanaf je eerste livegang al problemen mee op.

Tegelijk heb je minder risico om teveel moeite te stoppen in minder belangrijke, nu nog niet belangrijke, of erger nog, totaal onbelangrijke zaken. Juist omdat je de gelegenheid feedback te krijgen op het belangrijkste. Het is niet makkelijk om je visie in delen te realiseren. Gelukkig zijn er meerder manieren om zelf, of met je stakeholders te bepalen hoe testbare incrementen ontworpen kunnen worden.

“What’s on the box?”, een praktische denk-oefening om je MVP te bepalen

Het opstellen van een MVP en het opdelen van de waslijst aan potentiële features is best lastig. Maar stel je product eens voor als een fysiek object dat in de winkel ligt. Productontwikkelaars besteden veel aandacht om hun belangrijkste features eenvoudig tentoon te stellen aan hun potentiële klanten. Hebben ze de juiste combinatie, dan verkopen ze het product. Zo niet, dan blijft het op de plank liggen. Je kan dus voor de impulsaankopen alleen al op basis van de doos toetsen of je klanten je product een succes vinden!

Vergeet niet; een paar maanden later ligt er al een nieuwe versie van het product op de plank. Met een mooie gele sticker met ‘vernieuwd’, of een luxe versie. Hoe heeft het bedrijf bepaald wat er op de eerste doos stond, en wat op de daaropvolgende?

De doos van een koffiezetapparaat

Neem het voorbeeld van een koffiezetapparaat. Je doel is duidelijk; de markt op en tussen de andere koffiezetapparaten opvallen. Je praat met je doelgroep, en je hebt een hele lijst aan wensen. Het apparaat moet:

  • Klein en mooi zijn
  • Niet te duur zijn
  • Goede koffie kunnen zetten
  • Latte Macchiato kunnen maken
  • Chocolademelk leveren
  • Kindveilig warm aan de buitenkant worden
  • Cup-a-soup kunnen leveren
  • Civetkatkoffie ondersteunen
  • enz…

Je besluit dat al deze features belangrijk zijn en op de doos getoond kunnen worden. Je weet echter; de doorslaggevende features zijn de vorm, de prijs en het feit dat er goede koffie uit komt. In de klassieke vorm zou je je richten op het risicovolle traject waarin je alles tegelijkertijd probeert te realiseren “omdat dat is waar de markt om vraagt”, maar in agile proberen we ons juist niet vast te pinnen op de toekomst en om feedback te vragen.

Wat zou nu je MVP zijn? Na een korte marktanalyse in feite alles tot punt 3. Je besluit je productontwikkeling iteratief en incrementeel op te zetten, en alhoewel je wellicht communiceert dat je druk bezig bent met de realisering van de belangrijke punten na 4 ga je al aan je marktonderzoek beginnen met een minimaal product. Je besteedt voldoende tijd om ook de juiste research over de koffiekwaliteit te krijgen, iets wat anders bijzaak zou zijn.

Op de eerste doos verschijnt dus een fraai ogend koffiezetapparaat, dat praktische dimensies heeft, en een paar duidelijke eyecatchers:

  • Ondersteunt de beste koffie-pads in de markt
  • Designed by Allessi
  • een concurrerende prijs

Met deze doos op de plank weet je of je aannames al genoeg conversie opleveren om de potentie van je productvisie te toetsen, bij je testpanel of belangrijke influencers. Vervolgens kan je al feedback verzamelen over de volgende versie van je product. Zijn mensen geïnteresseerd in chocolademelk, of speel je beter in op de wensen door het product uit te breiden met een dubbelwandige uitvoering?

Wellicht maak je een fout in je aannames en moet je je prioriteiten aanpassen. Maar het kan ook aanslaan, en wat let je dan eigenlijk ermee op de markt te gaan? Time-to-market kan zo ook omlaag!

Je kan in versie 2 vervolgens met de feedback een betere versie op de markt zetten. Of dat dezelfde versie 2 is die je nu voor ogen hebt,is nog te bezien. Zo kan je dus waarde opleveren, feedback krijgen EN nieuwe inzichten verwerken in nieuwe releases.

En hoe ziet de doos van jouw product eruit?

Kan je je product voorstellen als een doos? En is dat de ultieme versie, of kan je je al voorstellen hoe er een minder uitgebreide versie de plank op kan? En zie je dan al voor je hoe de ‘new and improved’-versie er daarna uit komt te zien? Zie je kans om  de eerste doos en de daaropvolgende dozen aan je gebruikers of stakeholders  te tonen? Wat voor feedback krijg je hierbij op je productvisie? Neem er eens de tijd voor, en kijk dan eens hoe je je team kan sturen op deze waarden.

Let op de kernwaarden:

  • Eerst het belangrijkste voldoende uitwerken
  • Maak het presentable
  • Vraag om feedback

Meer kennis opdoen, lezen of in de praktijk delen

Benieuwd waar anderen tegenaan lopen? theFactor.e organiseert Agile Events. Kom luisteren en praten met product owners, agile coaches en andere geïnteresseerden.

Meer leesvoer en goede documentatie vind je hieronder:

Iteratief ontwikkelen
Iteratief ontwikkelen 2

Product box; the workshopV

Vertical Slicing
Vertical Slicing 2

Lean Inception; een workshop vorm om je MVP te bepalen

Wil je met Bart overleggen? Stuur hem dan een mail via b.wesdorp@tfe.nl of bel hem op 050 – 57 57 888.