De blogtitel is een citaat van Francis Bacon, een Engels filosoof en staatsman die leefde rond 1600 en brengt meteen de kern van deze blog.
Product owners (POs) die prioriteiten bepalen van de product backlog, doen veel meer wanneer ze met prioriteit bepaling bezig zijn. Voordat een prioriteit gezet kan worden, wordt gekeken naar verschillende facetten. Bekende eigenschappen van product backlog items (PBIs) in deze context zijn vaak: afhankelijkheden, risico’s en de (intrinsieke) waarde. Eigenlijk wordt hier al op high-level architecten niveau de dependency matrix in kaart gebracht. Ontzettend handig ook voor release management bijvoorbeeld. Prioriteiten stellen vereist dus ook samenwerking met verschillende stakeholders.
Een minder vaak besproken eigenschap is tijd. Meestal blijft het bij schattingen. Sommige POs werken met tijdschattingen, veelal in uren of dagen. Anderen werken met story points als eenheid voor schattingen, zoals ik. Vaak volgt dan een vraag of een story point voor een x aantal uur staat. Mijn antwoord is steevast: 1 story point is 1 gummy bear. Uiteraard volgt meer uitleg.
Maar naast schattingen blijft het aspect tijd nog steeds een rol spelen. Er zijn bijv. klant afspraken gemaakt die nagekomen moeten worden, er zijn afhankelijkheden met andere productlijnen die op elkaar afgestemd zijn, er zijn bijzondere kosten verbonden aan specifieke huur van apparaten of personeel die de kostprijs enorm verhogen, enz.
De Agile principes hebben ervoor gezorgd dat de duivelse driehoek (iron(y) triangle), met op de zijden: functionaliteit, budget en tijd en binnen in de driehoek de eigenschap kwaliteit, compleet op z’n kop is gezet ten opzichte van traditionele softwareontwikkelmethoden. Overigens, je kan die termen ook husselen op die driehoek. Effect blijft hetzelfde.
Iron(y) triangle
Kostbare tijd
Als je lekker gaat BBQ, dan gaat het niet alleen om dat lekker stuk vlees. Dat kun je ook krijgen door ‘m in de grillpan op het fornuis te bereiden. Het gaat om de sfeer, het genieten van het samen zijn. Eén van de zichtbare resultaten is een lekker stuk vlees op je bord dat je door een heerlijk zelfgemaakt knoflooksausje heen haalt en verorberd. Het gaat dus niet alleen om dat stukje vlees, maar óók om de aanloop er naartoe. Dat het niet moet eindigen in een zwart geblakerd stuk, is dus wel een vereiste. En juist daar waakt de bereiding voor: de juiste tijd levert het lekkerste stukje op en een goeie sfeer.
BBQ met vis, karbonade en zoete aardappel
Zo zie ik het ook in software ontwikkeling. Het gaat om een goede, al dan niet langdurige, klantrelatie. Ik lever als PO liever werk af waarbij ik weet dat de klant het accepteert, niet omdat het afgesproken is volgens contract, maar omdat de klant het ook daadwerkelijk graag wilt. Investeer in die relatie. Hou met het prioriteren rekening met deze factor.
The law of expectation management
Het is cruciaal in een agile project om een satisfied customer te hebben. In tegenstelling tot traditionele softwareontwikkelmethodieken, kun je je hier niet verschuilen achter contracten. De schade zal vrijwel onherstelbaar zijn. Damage control zal weinig uithalen. Customer satisfaction zou in een agile omgeving niet alleen PO gerelateerd moeten zijn, maar direct gekoppeld moeten worden met marketing strategie.
Het principe achter customer satisfaction is, zoals vaker in de agile community, eenvoudig. Customer satisfaction hangt af van twee zaken:
- het uiteindelijk resultaat dat je oplevert
- de verwachtingen die je hebt geschapen
Customer satifcation = Result – Expectation
Zijn de verwachtingen hoger dan wat je uiteindelijk oplevert, dan zal de klant teleurgesteld zijn.
Disappointment = Expectation – Result
De valkuil vaak is door de focus te leggen op het resultaat. Hoe beter het resultaat, hoe meer tevreden de klant zal zijn. Wat hier meestal bij gebeurd is dat de verwachting niet wordt bijgesteld. Het risico daarbij is, dat de verwachting van de klant ook omhoog gaat naarmate je meer (tussentijdse) resultaten toont.
Op het moment dat je enige tegenslag ervaart, is de customer satisfaction weg, en is al je extra inspanning voor het resultaat voor niets geweest. Een common pitfall is dat pas aan expectation management wordt gedaan op het moment dat er iets is misgegaan. Te laat.
De law of expectation management: first lower the expectations, then achieve great results.
BBQ
In de foto van de BBQ zie je een Weber Quickstarter. En ja: dat werkt echt. In plaats van tenminste 45 min. zijn de briquetten nu in 20 min. helemaal klaar, genoeg voor zeker 6 personen 2 uur lang BBQ. Tijd speelt bij BBQ een ondergeschikte rol, maar voor mij ligt het plezier niet in kooltjes heet krijgen, maar het vlees en de groenten op een juiste manier grillen, stomen, whatever.
Ik zie graag design driven development gecombineerd met test driven development om een software product te bouwen. Beide methoden vertragen de productie, althans op (relatief) korte termijn. Maar ik heb liever een trots team én tevreden stakeholders en klanten, dan een afgemat team met tevreden stakeholders en klanten. In die laatste situatie ken ik weinig succesvolle projecten, in die eerste ken ik ze juist in overvloed.
Voorheen duurde een software release 10 jaar. Tegenwoordig kan het binnen 3 maanden. Maar zit de klant daar écht om te springen? Het kan ook tegen je werken: wéér een update? Bij de vorige ging alles mis, ik sla deze maar over hoor. Ow, na 4 updates overslaan, ben je verplicht de volgende te nemen en anders verloopt je service contract. Nee, met hoge frequentie een nieuwe versie opleveren betekent niet per definitie een satisfied customer. Er zijn maar zeer weinig sectoren buiten de ICT waar snelle regelmatige lever cycli worden gewaardeerd. Hou hier rekening mee met release management, marketing strategy, prioriteren en klant contact.
Tot slot: geniet samen. Neem de tijd.
