Tagcloud

Krijg de business aan boord!

Om een agile aanpak het meest effectief te laten werken, weten we dat we de ‘business’ actief betrokken moet zijn en samen moet werken met het delivery team. De vraag die ik vaak gesteld krijg is: “Hoeveel tijd kost dat dan?”. Uiteraard is dit afhankelijk van de projectomvang en de projectsituatie. Wel  kunnen we stellen dat het doorgaans geen full-time betrokkenheid is. Op zijn minst gaat het om ongeveer vier tot acht uur om iedere sprint de requirements te identificeren, te prioriteren en te communiceren en hands-on  betrokken te zijn bij het reviewen van sprintresultaten. Idealiter ook een paar uur extra voor hun betrokkenheid gedurende de sprint om samen te werken met het team daar waar nodig. Als richtlijn zou hun betrokkenheid niet meer dan 10-20% van hun tijd in beslag moeten nemen. En hierbij doel ik nadrukkelijk op een optimale samenwerking met het team (just enough, just in time). In complexere omgevingen met meerdere stakeholders is er intern de nodige politiek en afstemming nodig om de neuzen van de verschillende stakeholders in dezelfde richting te krijgen. Hoe kiezen we nu de juiste vertegenwoordiger?

In sommige organisaties ligt een vertegenwoordiger met de meeste business kennis voor de hand. (In dat geval wordt het probleem vaak het organiseren van hun beschikbaarheid. Iets dat ik in een andere blog nog eens aandacht ga geven.) In andere situaties kan het moeilijk zijn om iemand te vinden met voldoende kennis om de belangen te behartigen van alle betrokkenen, die baadt het hebben bij de projectresultaten. Of een vertegenwoordiger te vinden met voldoende kennis in de breedte en in de diepte om het volledige spectrum van de business requirements af te kunnen spiegelen op het delivery team.

Voordat een organisatie met een Agile aanpak kan beginnen heeft het dan ook een kritische beslissing te nemen:

  • Zorgen dat de prioriteiten en de hoeveelheid werk wordt aangepast zodat een (of meerdere) bekwame personeelsleden worden vrijgemaakt om als Product Owner deel te nemen.
  • Huren van een competente business analist om de requirements van de business (owners) te vertegenwoordigen, in de veronderstelling dat de stakeholders uit de business beschikbaar zijn om tot wel 2 uur per week ‘hands-on’ samen te werken met de business analist.
  • Het werk uitstellen totdat er wél deskundige medewerkers (of gekwalificeerde vertegenwoordigers) beschikbaar  zijn om deel te nemen in een mate die nodig is voor het project om succesvol te zijn.

Een goed begin is het halve werk
In praktijk zien we dat betrokken dit advies niet zo serieus nemen en voor alternatieven kiezen. Eén benadering die sterk ontmoedigd wordt, is om iemand uit het delivery team aan te wijzen als vertegenwoordiger van de business (Proxy Product Owner). Dit is namelijk nadelig voor het proces op om minimaal drie redenen:

  • Iemand uit het delivery team heeft, ondanks opgebouwde kennis uit het domein,  zelden het vereiste kennisniveau vergelijkbaar met iemand uit de business zelf. (En beslissingen nemen op basis van oppervlakkige business kennis, kan een riskant en kostbaar alternatief zijn voor de organisatie.)
  • Teamleden zijn sterk gedreven in het denken in oplossingen, helaas niet aan de onderliggende behoeften.
  • De betrokkenheid van het team bij het verrichten van het werk belemmert hun objectiviteit in het reviewen van deelresultaten. Daarmee  is het stellen van de prioriteit voor opvolgende werkzaamheden ook moeilijker.

Een andere aanpak die sterk wordt ontmoedigd is gebruik te maken van minder gekwalificeerde vertegenwoordigers van business (bijv. junior medewerkers), in de veronderstelling dat deze waarschijnlijk makkelijker beschikbaar zijn dan meer ervaren medewerkers. De eerder genoemde valkuil met betrekking tot oppervlakkige business kennis is natuurlijk ook van toepassing in deze situatie.
Een derde en laatste aanpak die afgeraden wordt, heeft te maken met het inhuren van extern personeel. Zoals vermeld kan een organisatie er voor kiezen om gebruik te maken van een business analist als brug tussen stakeholders en het delivery team. Het is van belang daarbij een onderscheid te maken tussen een gekwalificeerde business analisten en een ‘notulist’. Een competente business analist neemt de tijd om de behoeften van het bedrijf echt te begrijpen. Bovendien zal deze vragen en kritiek te leveren op output van betrokkenen uit de business en de resultaten van elke sprint in opdracht van de business kritisch bekijken. Iemand die niet alleen begaan is met het begrijpen van behoeften, maar ook iemand die toetst of en hoe hier invulling aan wordt gegeven. Een ‘notulist analist’ daarentegen legt klakkeloos de requirements vast en draagt deze letterlijk over aan het team in sprintplanning sessies. Daarnaast beschrijft deze de sprintresultaten aan de business zodat zij hier op kunnen reageren in plaats van zelf feedback te geven aan het delivery team tijdens de sprint review. Dit voegt niet alleen weinig toe aan het agile proces, het kan ook leiden tot significante vertragingen, inefficiënt gebruik van projectresources en uiteraard de nodige miscommunicatie. Dit alles leidt weer tot herstelwerkzaamheden (‘garbage in = garbage out’).

Daarom, tenzij er een externe business analist als product owner op kan treden naar het delivery team, is het aanbevolen om de prioriteiten in de organisatie te wijzigen om de benodigde resources voor het project vrijmaken of het project uit te stellen. Als een project belangrijk is, dan kan het niet zo zijn dat beschikbaarheid de bottleneck is. Geen tijd = geen prioriteit. De enige manier om een Agile aanpak echt effectief te laten zijn is door het direct betrekken van mensen uit de business, die zelf de requirements goed begrijpen, die in staat zijn de requirements goed over te dragen aan het delivery team en die gepositioneerd en geautoriseerd zijn om beslissingen te nemen namens de organisatie.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution