From serving the business to delighting customers

In zijn boek Radical Management beschrijft Steve Denning de verschuiving die nodig is van geld verdienen voor shareholders naar het "delighten" van klanten door continue innovatie:

Delighting customers

Steve Denning on delighting customers: "In the 20th Century, firms got by on profits. In today’s more competitive world, profits can vanish overnight with the entry of a new product or service into the marketplace. Making profits is obviously required for survival, but if profits are all a firm has, it faces a precarious future. The true bottom line of any business—and the key to an enduring future—is whether customers are delighted. Delighting customers means continuously providing new value for customers sooner, so that they are willing to buy the firm’s goods and services not just today but also tomorrow. It’s goes beyond mere transactions; it’s about forging relationships. For this to happen, it’s not enough that customers are passively satisfied. That’s just the price of admission to the marketplace. Today, customers must be delighted."

Hij geeft in zijn boek richting over hoe je dit kan aanpakken. Zo beschrijft hij hoe Jeff Sutherland een langlopend probleem bij een organisatie met behulp van klantgerichte iteraties aan heeft weten te pakken; een aanpak waar Scrum uit is voortgekomen. Veel van de organisaties waar ik coach gebruiken de hieruit voortgekomen methodiek. Mijn ervaring is dat het teams meestal goed lukt om de scrumregels toe te passen. Het oplossen van een probleem in klantgerichte iteraties is echter een andere zaak: dit gaat meestal niet zonder slag of stoot.

In agile aanpakken is de product backlog de plek van waaruit de iteraties worden gevoed:

Scrum Guide: "The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements"

De items op de product backlog worden door de product owner samen met de business en het development team geprioriteerd. De volgorde van deze items en de inhoud ervan bepaalt daarmee wat in welke volgorde wordt opgeleverd. Of een team in klantgerichte iteraties werkt of niet, is dus direct af te lezen uit de product backlog. Het aflezen ervan behoeft een getraind oog. Aan de hand van een voorbeeld zal ik dit toelichten.

Een voorbeeld

Neem een middelgrote handelsonderneming. Zij worstelden met de communicatie rond hun producten en diensten, orders, verzendingen, contracten, kantoren et cetera. Er ging veel fout en business units interpreteerden gegevens op eigen wijze (die niet altijd overeenkwam met wat bedoeld is met de gegevens). Daardoor lukte het niet om consequent en consistent de juiste gegevens aan klanten te presenteren. De onderneming is een project gestart om de problemen op te lossen door alle referentiegegevens op één plek op te slaan en via een portal aan alle gebruikers beschikbaar te stellen. Zo zouden fouten in communicatie van gegevens worden opgelost en zouden interpretatieverschillen tussen verschillende business units verleden tijd moeten zijn. De onderstaande product backlog was hiertoe opgesteld:

  • Bepalen omvang en definitie van alle referentie gegevens
  • Registreren van alle referentie gegevens op een enkele plek
  • Beschikbaar stellen van alle referentie gegevens voor verschillende afnemers via een service bus (een service bus is een technologische oplossing om de gegevens aan verschillende applicaties beschikbaar te stellen)
  • Realiseren van een webportal voor het raadplegen en beheren van de referentie gegevens

Bad smells

Als we goed kijken naar deze backlog, dan zien we dat de business waarde (customer value) komt aan het einde van de rit: als het portal wordt opgeleverd. De backlog volgt een klassieke aanpak. Eerst wordt een analyse gedaan, vervolgens de basis op orde gekregen (alles op een plek registreren en een service bus realiseren) en als laatste wordt alles via een portal beschikbaar gesteld.

Laten we inzoomen op de tweede feature: "Registreren referentie gegevens op een enkele plek". Als we naar de beschrijving kijken, dan kunnen we daar use cases aan koppelen als: "Als een applicatie beheerder wil ik alle referentie gegevens in een enkele database opslaan zodat ik de gegevens op een enkele plek kan beheren."

Deze aanpak klinkt niet onlogisch. Deze feature waar waarschijnlijk vooral de IT-organisatie de hand aan heeft gehad is moeilijk te prioriteren door business mensen. Welke waarde creëer je immers voor klanten als een functioneel beheerder de gegevens op een enkele plaats kan opslaan? Nog steeds worden de onjuiste gegevens gecommuniceerd. De klant merkt er dus nog helemaal niets van!

Terug naar de echte behoefte!

Wat een goede stap is naar een betere backlog is om terug te gaan naar de behoefte van de klant. Het meest urgente probleem wat in dit voorbeeld aangepakt diende te worden was om actuele openingstijden van de verschillende locaties waar het bedrijf opereerde beschikbaar te stellen aan haar eindklanten. Deze informatie werd op verschillende plekken door verschillende personen bijgehouden en gecommuniceerd; zodoende ontbraken gegevens, ontstonden er fouten en waren er doublures.

De vraag van de business zou dan moeten zijn: Wat is het meest eenvoudige wat we kunnen doen om de belangrijkste oorzaak van dit probleem op zo kort mogelijke termijn op te lossen. Het meest eenvoudige, want dat is ook vaak het snelst te implementeren. De belangrijkste oorzaak, want de belangrijkste oorzaak aanpakken levert de grootste bijdrage aan de oplossing van het probleem. Op zo kort mogelijke termijn, want hoe eerder er een oplossing is, hoe eerder de eindklanten er profijt van hebben, hoe beter het is voor de organisatie.

De eenvoudigste oplossing die op korte termijn gerealiseerd zou kunnen worden is om de regio's waar de meeste fouten zijn geconstateerd te wijzen op hun verantwoordelijkheid om juiste openingstijden te communiceren. Corrigerende acties zouden lokaal ingezet kunnen worden, bijvoorbeeld door het opzetten van een intranet pagina, of een gedeelde spreadsheet op het file systeem.

De iets langere termijn oplossing zou kunnen zijn de openingstijden en locaties te gaan registreren en beschikbaar te maken via het portal. Mmerk op dat het hier dus niet gaat om alle referentie data, maar enkel de openingstijden van de locaties en het hier ook niet gaat om het realiseren van de volledige portal, enkel het gedeelte om locaties en openingstijden te tonen. De product backlog komt er dan uit te zien als hieronder geschetst:

  • Registreren en beschikbaar stellen openingstijden van kantoorlocaties via een klantportaal
  • Beschikbaar stellen definities zoals die gebruikt worden in contracten via een klant-portaal
  • Beschikbaar stellen contracten met eindgebruikers via een klant-portaal
  • Et cetera...

Features waar de businesswaarde vanaf spat!

De beschrijving van de eerste feature zou kunnen zijn: "Als een klant wil ik de actuele openingstijden van de verschillende locaties kunnen opzoeken zodat ik weet wanneer ik waar met mijn vraag terecht kan."

Dit is een feature die iemand uit de business aanspreekt. Dit is een feature waardoor de business een beeld van prioriteit krijgt. Dit is een feature die door het team binnen afzienbare tijd geïmplementeerd kan worden en waardevol zal zijn voor echte klanten.

Backlog brings you forward

Als je als organisatie stappen wilt zetten in je Agile transformatie, dan is het uitermate belangrijk dat de business en software development zich verbinden aan de activiteiten die worden ondernomen. Een goede backlog is daarin een essentieel hulpmiddel. Merk je als software development team dat de business niet betrokken wil zijn bij wat je maakt, kijk dan goed naar je backlog en ga na of je waarde creëert voor eindklanten. Blijf als business kritisch over wat je prioriteit geeft op de product backlog van het software team. Stel bij twijfel altijd de vraag: "Kan je uitleggen hoe deze feature waarde geeft aan onze klanten?". Als dat niet uitgelegd kan worden is het waarschijnlijk niet de juiste stap om te zetten.

Laat klantwaarde spreken. Verlies geen tijd aan het zo volledig mogelijk verbeteren van processen en systemen. Richt al je pijlen op het delighten van je klanten en doe wat daarvoor nodig is!

Ben je al aan de slag als product owner en wil je meer weten over het onderwerp, volg dan de Advanced Product Owner training bij inspearit | cibit academy. Neem gerust contact op als je inzicht wilt krijgen in de kwaliteit van jouw backlog of voor hulp bij het verbeteren ervan.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • ​Get Agile Business Analyst!

    Organisaties die business analyse hebben geïnstitutionaliseerd binnen informatiemanagement afdelingen worstelen met hun positionering binnen Agile. Dit whitepaper is tot stand gekomen na verschillende interviews van Agile coaches, business analisten en product owners.

    Lees verder
  • Raising the bar for the Agile Requirements Practitioner

    Scrum beschrijft WIE WAT doet en WANNEER, maar niet HOE. Moet je dan telkens opnieuw verzinnen hoe je omgaat met requirements? Ruud Bruls, docent van de sterk vernieuwde opleiding Agile Requirements Practitioner, geeft zijn visie.

    Lees verder
  • Wat is nieuw in SAFe 4.5

    Het zal je wellicht niet ontgaan zijn, de nieuwe SAFe versie is onlangs gelanceerd en bevat een aantal interessante toevoegingen en verbeteringen. Lees over de meest prominente wijzigingen.

    Lees verder
  • Meer agility door samenwerking op managementniveau

    "Ik heb gezien hoe de managers vanuit verschillende business units door deze top 3 interventies hebben geleerd dat als ze beter samenwerken met betrekking tot verzoeken voor hun gezamenlijke resources, ze meer waarde kunnen realiseren", blogt Ruud Bruls.

    Lees verder