Een agile gerelateerd blogonderwerp is meestal zo gevonden. Er gebeurt veel in dit werkveld, er zijn voortdurend nieuwe ontwikkelingen en ik zie het nodige in mijn dagelijkse praktijk. Inspiratie genoeg. Maar ik voelde zelden de hoge urgentie om mijn verhaal te vertellen, zoals ik die voel bij deze blog over het vergroten van de productscopescope in organisaties. Luister en huiver, want dit is een belangrijke boodschap.
Ter introductie: met de productscope bedoelen we het niveau waarop je iets als één product ziet. Bij het fictieve reisbureau TravelJoy heeft het product ‘online boekingen’ bijvoorbeeld een grotere productscope dan het product ‘Android app’ (onderdeel van ‘online boekingen’). In dit voorbeeld zou ik TravelJoy direct aanraden om het product ‘Android app’ te laten varen en ‘online boekingen’ (waar ook product ‘iPhone app’, product ‘website’ en product ‘online klantenservice’ onder vallen) als één product te zien. Met één backlog. Ik zal uitleggen waarom.
3 productteams
Stel, voor een nieuw te bouwen huis worden drie productteams samengesteld met ieder een eigen backlog. Één productteam is verantwoordelijk voor de badkamer, één productteam is verantwoordelijk voor de slaapkamers en één productteam is verantwoordelijk voor de woonkamer annex keuken. De productteams worden samengesteld uit het medewerkersbestand van het bouwbedrijf. Omdat alle ruimtes worden voorzien van elektra, sanitair én witte muren, zitten elektricien Jan, tegelzetter Piet en stukadoor Klaas in alle drie de productteams.
Bovenstaand voorbeeld is een simpele weergave van de dynamiek die in werking treedt bij organisaties die een (te) kleine productscope hanteren. Een dynamiek met drie problemen:
1. Jan, Piet en Klaas moeten hun werkzaamheden en tijd verdelen over de drie productteams. Als Jan gevraagd wordt in de slaapkamer, dan moet elektricien Jan (voordat de stukadoor komt) naar de slaapkamer en als tegelzetter Piet nodig is in de badkamer, dan moet hij daarheen (voordat het sanitair wordt gemonteerd). Dit vraagt veel verantwoordelijkheid en time management van Jan, Piet en Klaas. Dat zij hun andere teams teleur gaan stellen is onoverkomelijk. Ze hebben immers geen invloed op de planning van de verschillende projecten (en kunnen zichzelf ook niet in tweeën splitsen).
2. Ten tweede werken de voorwaarden – zoals het budget, de functie en indeling – die vooraf gesteld zijn voor de drie projecten belemmerend. Gedurende de bouw kan bijvoorbeeld blijken dat het budget voor de badkamer niet afdoende is, terwijl er in de slaapkamer heel efficiënt (onder budget) wordt gewerkt. Je speelruimte om dat wat daadwerkelijk belangrijk is te prioriteren, neemt af. Ook op het gebied van functie en indeling. De kennis die je onderweg opdoet, zal behouden blijven aan je eigen product en niet direct gedeeld worden met andere teams. Misschien blijkt achteraf wel dat de kastruimte in de badkamer overbodig is, omdat in een nis in de slaapkamer ruimte is ontstaan voor een grote kast, waar ook handdoeken kunnen worden opgeborgen. Wie zal het zeggen
3. Tot slot vragen kleine deelproducten meer aansturing. Bij het bouwbedrijf zal iemand vrij moeten worden gemaakt om het badkamerteam, het slaapkamerteam en het woonkamer annex keukenteam aan te sturen. Hij of zij bewaakt het grotere plaatje en zal er op een of andere manier voor moeten zorgen dat de verschillende productteams een bijdrage leveren aan de woondroom van de familie Klaasma, die straks in het huis gaat wonen.
Efficiënter en beter
Kortom: een constructie met drie verschillende productteams die los van elkaar werken aan een huis – het grotere product – brengt moeilijkheden met zich mee. Gelukkig ken ik geen bouwbedrijf die het bouwen van een huis op deze manier aanpakt. Het is veel logischer, efficiënter en beter om het huis als één product te zien. Bouwvakkers hoeven zichzelf niet meer op te splitsen, het eindproduct is beter uitgebalanceerd (zonder kastruimte in de badkamer) en er is geen middelmanager nodig die overziet of de drie productteams wel bijdragen aan het droomhuis van de familie Klaasma.
Tot zover het voorbeeld. Het grappige is dat in veel sessies waarin projecten worden geëvalueerd, communicatie als verbeterpunt wordt genoemd. In veel gevallen is dit het gevolg van een gebrek aan organisatie. Je kunt elkaar opleggen om beter te communiceren (nodig wanneer drie productteams werken aan één huis), maar je kunt ook samenwerken aan één product (het huis). Het is een ogenschijnlijk klein verschil, maar in de praktijk betekent het een grote verandering.
Één product
Bij veel projecten die ik begeleid speelt software een belangrijke rol. Het bouwen van die software of de implementatie ervan wordt vaak gezien als één project, terwijl die software eigenlijk onderdeel is van iets veel groters (in het geval van TravelJoy: online boekingen optimaliseren). Wil je ervoor zorgen dat de applicatie maximaal bijdraagt aan het eigenlijke doel, zorg er dan voor dat je ‘online boekingen’ als één product ziet.
Als je bovenstaande tot in den extreme doorvoert zou je kunnen zeggen dat de missie van een organisatie het grootst mogelijke productniveau is. In het geval van TravelJoy: gelukkige reizigers op betaalbare vakanties. Door die missie als één product te zien (met één backlog), voorkom je ruis op de lijn en zorg je dat alle deelactiviteiten maximaal bijdragen aan dat hoofddoel.
Één stap hoger
In de praktijk gaat één bedrijfsproduct misschien een stap te ver. Daarom is mijn tip (en huiswerk voor jou): probeer met jouw productteam eens één stap hoger te gaan in de productscope. Gooi de backlogs van product ‘Android app’, product ‘iPhone app’, product ‘website’ en product ‘online klantenservice’ op één hoop en ga aan de slag met product ‘online boekingen’.
Klaar? Prioriteren maar!
