En hoe doe je dat precies?
In de praktijk zien we dat een product vaak al geruime tijd bestaat is als men gaat nadenken wat nu écht het product is. Bovendien, producten (en hun definitie) veranderen voortdurend. In deze blog onderzoeken we waarom product definities zo belangrijk zijn en geven we je een aantal handvatten om een goede, werkbare product definitie op te stellen. Eentje die ook nog past binnen jouw organisatie!
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.
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.
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:
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:
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.