Purpose – Waarom zijn we hier mee bezig?

Waar zijn wij nou helemaal mee bezig? Wat gaat deze user story uberhaupt toevoegen? En nog erger, wat is de betekenis van deze user story in het grote plaatje? Is er uberhaupt een groter plaatje?

Allemaal vragen die naar mijn mening te weinig worden gesteld. Meestal, omdat er vaak niet eens antwoorden op deze vragen zijn.

Dit houdt dus in dat…

Omdat wij niet weten waarom wij ons werk doen, stellen wij de vragen ook niet meer…

Als je niet weet waar je voor werkt, wordt je vanzelf responsief op werk

Het gevaar als je deze vragen niet stelt, is dat dit ook nooit opgelost zal worden. En zolang dit niet opgelost wordt, zal de motivatie van iedere werknemer langzamerhand afnemen.

Binnen de IT, is ieder lid van een development team vanuit zichzelf intrinsiek gemotiveerd om aan het product te werken en het product gaaf te maken. Zo gaaf mogelijk! Want anders zou je daar niet willen werken.

Maar zolang het voor developers niet duidelijk is hoe hun contributie meehelpt aan het bereiken van een bepaalt doel, of het nastreven van een visie, zal die intrinsieke motivatie langzamerhand afnemen.

Lees hier meer over in mijn internalisatie blogpost (### Link naar internalisatie blogpost).

Als dit probleem voor een langere periode (een jaar) blijft bestaan, zal je langzamerhand signalen zien opkomen dat developers zich meer responsief en passief gaan opstellen richting het product. Bugs die niet op tijd worden opgelost, oude legacy code die niet wordt aangepakt, noem het maar op. Developers zullen zich minder hard inzetten om het product te verbeteren.

Mensen willen het product helpen, maar hebben daarvoor richting nodig

Zoals ik in mijn blog over mensen aangeef, wilt uiteindelijk iedereen elkaar helpen, gebruikmakend van zijn of haar eigen skills. Ook het product. Developers zijn gewoon intrinsiek gemotiveerd om het product gaaf te maken. Maar daarvoor moeten zij wel weten hoe zij dat kunnen doen.

Developers hebben richting nodig.

Hoe geeft je richting aan developers?

Richting geef je door mensen te laten begrijpen waarom iets belangrijk is.

NIET ALS: beste developer, voor de volgende user story moeten jullie de knop op de inlogpagina groter maken.

WEL ALS: Met dit product willen we mensen helpen om hun to-do lijstjes te ordenen, op dit moment maken meer dan 100.000 mensen hier al gebruik van. Wel hebben zij aangegeven dat zij de huidige manier van inloggen verwarrend vinden, vanwege reden X.

Het eerste voorbeeld is een klassiek voorbeeld van hoe het niet moet, en hoe hij bij de meeste organisaties nog steeds wordt gedaan (!). Dit leidt tot responsief gedrag en zou naar mijn mening verboden moeten worden.

Het tweede voorbeeld geeft richting aan een developer, door uit te leggen waarom dit product belangrijk is, en geeft de ruimte aan een developer om zelf na te denken over een mogelijke oplossing (want als hij hier zelf over gaat nadenken, gaat hij zich inleven in het probleem).

Zorg voor een shared vision over het product

Om nou bij iedere user story de context uit te leggen om developers te motiveren, is veel te vermoeiend. Dus dat raad ik af. Een effectievere methode is om een shared vision uit te werken van het product en deze op te hangen in de kamer van het development team. Met ‘shared’ bedoel ik dat deze door het hele team begrepen wordt en dat het hele team hier ook achter staat.

Er zijn verschillende technieken om de visie van een product uit te werken. Regelmatig zie ik het agile vision board langs komen. Maar het Agile Inception Deck spreekt mij iets meer aan.

Wat je ook gebruikt om tot een visie te komen. Het gaat er uiteindelijk om dat het hele development team de visie begrijpt en erachter staat. Want een goeie visie wordt regelmatig door developers gebruikt om uit te leggen waarom een bepaalde oplossing van een user story goed of juist slecht is. Dat is een mooie controle of je visie sterk genoeg is.

SLECHTE VISIE: “Ons product kan bijna hetzelfde als onze concurrenten”.
Een visie moet uitleggen waarom de developers dagelijks 8 uur aan dit product besteden, en dus niet morgen opstappen en bij de concurrent gaan werken.

SLECHTE VISIE: “Ons product gaat voor wereldvrede zorgen.”
Een visie moet ook acceptabel zijn, zodat de developers hier ook serieus achter durven te staan.

GOEDE VISIE: “Ons product gaat mensen helpen om kwaliteit van software inzichtelijk te maken.”
Dit spreekt aan en kan gebruikt worden om bepaalde user stories af te wijzen of op te pakken.

Met een shared vision, geef je teams richting op conceptueel niveau.

Maak belangrijke metrieken zichtbaar

Een Shared Vision geeft richting aan de user stories die door teams opgepakt worden. Maar zodra hieraan gewerkt wordt, zal deze visie een mindere rol gaan spelen. Dit omdat een visie bedoeld is om op conceptueel niveau keuzes te maken. Zodra code geschreven moet worden, werken dit soort conceptuele ideeën niet meer. Wat je dan nodig hebt, zijn concrete metrieken.

Met name zichtbare, metrieken spelen een grote rol in het werk dat teams doen. Veel mensen maken met Scrum de fout door de Velocity (het aantal user stories dat opgeleverd wordt) zichtbaar op te hangen in de teamkamers. Wat je dan ziet is dat het team zich zal richten op het verhogen van het aantal user stories dat opgeleverd wordt. Simpelweg omdat het zichtbaar wordt gemaakt. Vaak neemt de kwaliteit dan af en wordt de software vanzelf een rommeltje.

Wat je eigenlijk wilt doen is een lijst met *belangrijke* metrieken gebruiken, en deze zichtbaar maken.

Stel je visie is: “Ieder persoon op aarde te leren rekenen”.

Dan zou je de volgende metrieken zichtbaar willen maken voor het team (het liefst automatisch bijgehouden op een dashboard):

  • Het aantal unieke gebruikers van het systeem.
  • Het huidige rekenniveau van de gebruikers.

Opeens is het aantal user stories niet meer van belang, maar de impact die je daarmee maakt. En teams zullen zich daarop inzetten!

Door de belangrijkste metrieken zichtbaar te maken, geef je teams richting op taak niveau.

Zorg voor een shared vision over de organisatie

Als je het helemaal goed wil doen, zorg dan ook voor een shared vision over de organisatie zelf. Deze visie zou namelijk de reden moeten zijn waarom het product bestaat, en bepaalt voor een groot deel de cultuur van de organisatie.

Een duidelijke visie van de organisatie krijgen zou makkelijk moeten zijn. In praktijk lijkt dit helaas een stuk moeilijker te zijn, met name omdat het antwoord vaak varieert op basis van wie je het vraagt.

Mijn advies: maak het jezelf vooral niet te moeilijk. Vraag je Product Owner of manager om een visie van het bedrijf en gebruik deze. Als ze helemaal niets hebben, mag je hier best een impediment voor inschieten. Je zou het filmpje van Simon Sinek kunnen delen om ze uit te leggen waarom dit belangrijk is.

Nog even in het kort

Zelfsturend gedrag is niet een persoonlijkheids trek. Dit is gedrag dat voortkomt uit het niet hebben van een duidelijke visie voor het product en voor de organisatie. Want om zelfsturend te zijn, hebben mensen richting nodig. Zorg ervoor dat deze richting duidelijk is.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *