Waarom is het beter definiëren van je product belangrijk?

Agile is product georiënteerd. Dit komt doordat we ons op waarde richten, en die waarde in producten zit verpakt. In tegenstelling tot een eindig project, is het bij Agile werken de bedoeling dat er doorlopend, op een oneindig vol te houden tempo en gedurende de gehele levensloop wordt gewerkt aan die dingen die de meeste waarde vertegenwoordigen binnen dat product.

Het concept van waarde is veranderlijk en dat is een sleutelargument voor wendbaarheid. Dat is trouwens ook de reden dat we voortdurend moeten overwegen of we de juiste dingen op de goede manier aan het doen zijn. Wanneer we dit onderzoek op ervaringen en experimenten baseren, heet dit empirisme – de kern van scrum. In softwareontwikkeling werken we vaak met een ‘minimal viable product’, zodat we snel onze verwachtingen kunnen toetsen en dus empirisch te werk gaan.

Maar wat is je product nu eigenlijk?

Het antwoord daarop blijkt vaak minder evident dan je zou denken. Toch is een goed opgestelde product definitie van cruciaal belang voor het bereiken van succes met jouw (Agile) organisatie.

Zeker wanneer we Agile toepassen binnen grotere organisaties, of werken aan een Agile transformatie, wordt product definitie een lastiger maar steeds belangrijker concept. Er zijn immers meer teams die moeten samenwerken, meer stakeholders die belangen hebben en meer elementen die – terecht of onterecht – als product kunnen worden beschouwd. In deze complexiteit leidt het onvoldoende definiëren van je product tot onlogische werkverdelingen, teams die te ver afstaan van wat de eindgebruiker meemaakt, gebrekkige communicatie, conflicterende implementaties en duplicaat werk (verspilling). Kort samengevat blokkeert het dus de doorstroming van waarde of flow.

Aan de keerzijde stelt een goede product definitie ons in staat om relevante metingen te doen, zoals de door Scrum.org zelf voorgestelde Evidence Based Management methode. Er ontstaat per product één Product Backlog, gevuld met features. Dit scheelt niet alleen in beheer, en dus overhead, maar vergemakkelijkt ook de samenwerking en faciliteert de transparantie waar Agile voor staat. Dit alles komt de eerder genoemde doorstroming van waarde ten goede.

Vaak wordt er bij het definiëren van een product vooral gekeken naar de technische kant van het verhaal maar misschien nog wel net zo belangrijker is het feit dat een goede product definitie ervoor zorgt dat een team een doel heeft. Weten waar je aan bijdraagt helpt bij het samenwerken in en tussen teams.

Hoe definieer ik mijn product dan?

Een allesomvattende oplossing voor dit vraagstuk hebben we niet, maar enkele handvatten (van Bas Vodde, oprichter van LeSS, mogen we geen ‘best practises’ meer zeggen) kunnen we wel bieden:

1. Het populaire SAFe (Scaled Agile Framework) maakt gebruik van Value Stream Mapping. Deze term, voortkomende uit het Lean gedachtengoed waaruit dit framework deels put, gaat uit van een reeds opgestelde product definitie. De methodiek blijkt echter ook relevant voor ons vraagstuk: Door Value Streams in kaart te brengen leren we begrijpen waar het einddoel ligt en hoe waarde daar dwars door de organisatie heen naartoe stroomt. In deze analogie kun je traditionele silo’s zien als dammen, welke moeten worden opgeheven om een onverhinderde stroom tot stand te brengen.
2. LeSS maakt gebruikt van verbredende en vernauwende vragen. Het idee is om zo breed mogelijk te starten, waardoor vaak een allesomvattende product definitie ontstaat, zoals “verzekeringsdiensten” of “geld beheer diensten”. Deze wordt vervolgens praktisch gemaakt door bepaalde begrenzingen aan te brengen, welke bijvoorbeeld technologisch (is er een gezamenlijke codebase of niet?) of logistiek (wordt het element intern of extern beheerd?) van aard zijn. LeSS stelt dat minder beter is. Bijvoorbeeld ook qua aantal Product Owners die een organisatie nodig heeft.
3. Design Thinking is een methode waarin het vaststellen van de juiste probleemstelling en daarvoor de juiste oplossing vinden centraal staan. Hierbij worden concepten als ideation, gemba walks en rapid prototyping omarmd. De beoefenaar wordt uitgedaagd om te denken als een eindgebruiker. Een treffend voorbeeld is bijvoorbeeld de gloeilamp: Edison begreep dat deze wonderbaarlijke glazen bol (het component) op zichzelf weinig meerwaarde zou bieden, maar een electriciteitsnetwerk zou vereisen om haar revolutionaire krachten te ontketenen door de wereld te verlichten (het product). Een interessante voortzetting van deze case study is Signify (voormalig Philips Lighting), dat dit concept letterlijk heeft gemaakt middels een “Light as a Service” aanbod.

Om deze theorie duidelijker neer te zetten geven we een praktijkvoorbeeld.

Een grote Britse telecom provider nam omstreeks 2016 een internet serviceprovider over en vormde daarmee plotsklaps een allesomvattende multimedia organisatie. Deze organisatie bediende in 2020 omstreeks 4 miljoen huishoudens van internet en (digitale) televisiediensten en nog eens 5 miljoen van mobiele telefonie.

Welke producten zou deze organisatie definiëren? Hoe zouden de waardestromen hieromheen kunnen worden georganiseerd? Zeer breed genomen kunnen we spreken van multimedia services die eindgebruikers bedienen door:

1. telecommunicatie mogelijk te maken;
2. vermaak te bieden;
3. klanten geïnformeerd te houden.

Deze multimedia services als product nemen zou erg breed en daarom minder bruikbaar zijn. Een voor de hand liggende splitsing zou die van “televisie”, “internet” en “mobiele telefonie” zijn, waarbij televisie nog kan worden opgesplitst in analoge “ouderwetse” tv en digitale, moderne televisie. Het voordeel van die verdeling is dat deze natuurlijk aanvoelt; de klant ziet immers dezelfde producten op de website en maakt waarschijnlijk gevoelsmatig een soortgelijke onderverdeling. Aan de andere kant zijn er veel raakvlakken en overlappende gebieden: Je telefoon heeft internet, je bekijkt online televisie, je televisie komt uit een box die online verbonden is. Zelfs op de website bestel je meestal een combinatiepakket.

Voorbeeld waardestromen en overlap multimedia bedrijf.

Is dan de eerder genoemde A, B, C een meer logische verdeling? De implicatie is dat teams zich bezig zouden houden met features die een van deze categorieën raken, via welk medium ze ook worden geleverd. Dit roept technische uitdagingen op; het is onwaarschijnlijk dat genoeg medewerkers breed genoeg onderlegd zijn om bijvoorbeeld vloeiend van mobiele telefonie naar digitale televisie te kunnen omschakelen. Aan de andere kant is een veelvoorkomend voorbeeld van het goede product georiënteerde werken het team dat dezelfde content maakt voor zowel iOS als Android. Agile heeft daarnaast de instelling dat het opdoen van nieuwe kennis altijd een strevenswaardig doel is.

Onze conclusie is dat deze A, B, C definitie minder natuurlijk voelt voor de klant en te onpraktisch is voor de uitvoering, dus kiezen wij uiteindelijk om onze producten te definiëren als “televisie, internet en mobiele telefonie”, al betwijfelen we of er een juist antwoord is en gaan we hierover graag in discussie.

We kunnen onze definitie verder specificeren door de stellen dat het webportaal geen apart product is, maar een feature waarop door meerdere producten moet worden aangesloten. Ook kiezen we ervoor om de content die op televisie te zien is geheel buiten onze product definitie te houden: Deze wordt immers niet door onze organisatie gemaakt. Ten slotte maken wij zelf geen hardware, maar hebben een netwerk aan vertrouwde leveranciers en vanzelfsprekend genoeg kennis in huis om dit geen obstakel te laten zijn.

Nu we middels verbredende en vernauwende vragen onze producten hebben gedefinieerd, kunnen we onze waardestromen hierop laten aansluiten. We hebben drie producten, welke ieder één backlog krijgen met één Product Owner, welke de visie bepaalt en de prioritering aangeeft. De verder bedrijfskundige inrichting hangt af van het gekozen model.

Hopelijk wordt aan de hand van dit voorbeeld al iets duidelijker welke vragen we tegenkomen bij het behandelen van dit onderwerp. Het gaat verder dan je zou verwachten!

Samengevat: Met een sterke product definitie kunnen we het volgende niveau in onze wendbaarheid ontgrendelen. We kunnen waardestromen structureren, ons werk in het geheel prioriteren, afhankelijkheden stroomlijnen, nagaan of onze teams om features of componenten zijn georganiseerd (https://less.works/less/framework/product), onze stakeholders beter betrekken en DevOps goed implementeren.

Daarom is het slotadvies om met je kernteam samen te gaan zitten, een whiteboard erbij te nemen en tijdens een interactieve sessie jullie product(en) in kaart te brengen. Wanneer je hierbij wat hulp kunt gebruiken, of geïnteresseerd bent geraakt en verder wilt sparren, kun je contact opnemen met onze Agile experts van Valid.