Een ananassnijder: wat een handig ding. Je hoeft niet langer te klooien met de harde prikkelschil en de bittere kern die je niet mee mag snijden mijd je zorgvuldig. Maar eerlijk: hoe vaak gebruik je ‘m daadwerkelijk? Ik durf te stellen dat dit hulpje hooguit één à twee keer per jaar uit je keukenla komt. Maar de kans is ook groot dat je nu pas beseft dat je zo’n snijder überhaupt ergens hebt liggen. Zo is het ook bij het ontwikkelen van nieuwe applicaties: je ontwikkelt iets wat handig lijkt, gebruikt het vrijwel niet en bedenkt je pas na een flinke tijd dat het er überhaupt is. Veel features binnen applicaties worden niet of nauwelijks gebruikt. Dat weet je als Product Owner natuurlijk allang. En je weet waarschijnlijk ook dat hier behoorlijk wat geld aan verspild wordt. Al deze features worden namelijk wel gebouwd en moeten vervolgens ook onderhouden worden – ook al worden ze zeer beperkt of soms zelfs helemaal niet gebruikt. Maar is de rest van je team zich hier ook voldoende van bewust en wat kun je doen om dit proces te verbeteren, en te voorkomen dat er onnodige applicaties worden gebouwd én vergeten?
Iets goed doen of het goede doen?
Vanuit psychologisch opzicht worden, wij mensen, graag beloond. Het ene type persoonlijkheid is hier gevoeliger voor dan het andere, maar over het algemeen wil iedereen het graag goed doen. Maar iets goed doen is iets heel anders dan het goede doen. En dat is waar het in ontwikkelteams toch nog steeds vaak misgaat, vooral als er veel waarde wordt gehecht aan de mening van de klant. Een tevreden klant betekent niet automatisch dat het juiste is gedaan. Maar hoe krijg je dit tussen de oren van je team? Hoewel medewerkers het principe en verschillen tussen ‘het goed doen en het goede doen’ vaak wel begrijpen, worden ze toch snel weer meegezogen in de waan van de dag waarbij de vraag van de klant meer dan eens bepaalt wat er gedaan wordt. Teamleden gaan er al snel vanuit dat de klant weet wat hij wil en dat zijn business case klopt, terwijl dit keer op keer getoetst moet worden.
Onderliggende doel?
Het moet eerst duidelijk zijn wat het onderliggende doel van de klant is. Bij de meeste klanten is dit uiteindelijke doel een goede verhouding tussen de investering en wat het idee onderaan de streep aan waarde oplevert. Juist daarom is een Minimum Viable Product (MVP) visie zo interessant, want je wil met minimale inspanningen een maximaal effect behalen. Hiervoor wil je dingen van de klanten weten zoals: met welke functionaliteit wordt veel geld verdiend? Welke functionaliteit levert de meeste en juiste efficiency op? Maar ook: welke functionaliteit is complex en aan welk onderdeel kleven grote risico’s? Vaak betekenen deze vragen dat de klant prioriteiten moet gaan stellen: welk aspect van een oplossing is het meest cruciaal voor het toevoegen van waarde?
Je kunt er als Product Owner flink van balen als je ziet dat je teamleden in de praktijk niet zo kritisch nadenken. Hoewel een MVP-aanpak de verantwoordelijkheid is van een heel team, ligt de eindverantwoordelijkheid toch bij de Product Owner. Jij moet deze visie zodanig borgen in je organisatie dat deze wordt nageleefd. Enkel zeggen dat je team ook verantwoordelijk moet zijn, heeft weinig effect.
Het juiste doen, wat houdt dat in?
De sleutel naar verbetering van het ontwikkelproces is het concreet maken van wensen en verwachtingen binnen je team. Wat betekent ‘het juiste doen’ bijvoorbeeld? Dit is een interessante vraag om onderling te bespreken. Hoe kijken teamleden hier tegen aan? Vervolgens kun je een concrete werkwijze opstellen die deze visie borgt, zoals bijvoorbeeld de ‘5 x Why-methode’ volgens het Lean Six Sigma principe. Als Product Owner is het vervolgens belangrijk dat je regelmatig toetst of deze werkwijze gehanteerd en nageleefd wordt. Als je dit niet doet, geef je de indruk dat het niet belangrijk is en verdwijnt de aanpak alsnog naar de achtergrond. Borgen betekent dus ook: een manier inbouwen waarmee je toetst.
Daarnaast is het belangrijk dat je psychologische veiligheid creëert in je team. In een veilige werkomgeving spreken teamleden zich uit, durven ze fouten te maken, stellen ze elkaar kritische vragen en leveren kritiek. Helaas wordt het woord ‘kritiek’ nog steeds geassocieerd met iets dat negatief is. Het is natuurlijk niet leuk om kritiek te ontvangen, maar het is wel een belangrijke sleutel voor ontwikkeling. Van het individu maar zeker ook voor het team.
Lees Link magazine digitaal of vraag een exemplaar op: mireille.vanginkel@linkmagazine.nl
Wanneer jij als Product Owner concreet maakt wat het juiste doen en waarde toevoegen betekent en zorgt voor een psychologische veilige werkomgeving, heb je belangrijke randvoorwaarden gecreëerd voor een succesvolle MVP-werkwijze. Zo creëer je een team dat niet alleen dingen goed doet, maar de juiste dingen doet. Dat is een groot verschil. In de praktijk betekent dit dat je team niet klakkeloos aan de slag gaat met een klantvraag, maar met een kritische blik onderzoekt welke features en acties waarde toevoegen voor de klant en welke niet.
Ivo Diepstraten, Information Analyst bij Info Support
