Meer agility door samenwerking op managementniveau

Als agile transformatie coach en consultant heb ik de afgelopen jaren bij veel organisaties in de keuken mogen kijken en mogen ervaren hoe daar met softwareontwikkeling wordt omgegaan. Eén van de essentiële problemen waar organisaties mee kampen is dat meerdere initiatieven (projecten of epics) tegelijkertijd in de lucht worden gehouden. 

Op zichzelf heeft ieder initiatief best bestaansrecht, maar door al deze initiatieven tegelijkertijd te laten lopen, wordt er maar weinig waarde gecreëerd. Wat er vaak gebeurd is dat, als er meerdere projecten lopen, er een grote vraag ontstaat naar de expertise van de individuele medewerkers. Medewerkers zullen hun aandacht over verschillende projecten moeten verdelen. Niet alleen de medewerker zal hierdoor zijn werk niet heel effectief kunnen uitvoeren, omdat hij zijn aandacht moet verdelen over verschillende projecten. Ook de samenwerking lijdt hieronder: stel je voor een architect werkt in meerdere teams, dan kan het voorkomen dat op een bepaalde dag het team niet verder kan; omdat er een antwoord van de architect nodig is en deze net op die dag niet beschikbaar is omdat hij of zij voor een ander team werkt. Het team kan niet door en vertraging is een feit. Als dit vaker voorkomt, kan het zomaar zijn (en ik heb het zien gebeuren) dat het team nog een taak erbij krijgt. Het team is daarmee zelf ook niet meer altijd beschikbaar voor het project en iemand met een vraag aan het team zal wellicht ook moeten wachten op een antwoord, enzovoort.

Wendbaarheid van de organisatie

Als je als organisatie wendbaar wil zijn, dan zal er meer moeten gebeuren dan op een agile manier software realiseren. Natuurlijk biedt een wendbare software ontwikkelproces veel mogelijkheden om ook wendbaar te zijn in reactie op klantvragen, zeker gegeven het feit dat klantprocessen meer en meer ondersteund worden met software. Echter voor wendbaarheid in het kunnen creëren van nieuwe services zal er meer moeten gebeuren dan enkel het samenwerken in teams om software te realiseren. De manier waarop management samenwerkt en gezamenlijke resources gebruikt vormt een belangrijke sleutel tot meer agility.

Uiteindelijk heeft een organisatie wel een doel als geheel, maar organisaties zijn vaak ingericht op een manier dat (unit) managers een eigen budget hebben en dit naar eigen inzicht inzetten. Units zijn veelal onderdeel van waardestromen en in waardestromen wordt het geld verdiend. Als voorbeeld van een waardestroom: een product wordt via de webshop besteld, via logistiek uitgeleverd is en de betaling komt via financiën binnen. Als een organisatie deze waardestroom wil optimaliseren moeten de verschillende afdelingen: webshop, logistiek en financiën gaan samenwerken. De manager van deze afdelingen moeten bereid zijn om hun budget of een gedeelte daarvan beschikbaar te stellen aan de waardestroom. Als in het voorbeeld het logistieke systeem de bottleneck is binnen de waardestroom, dan zou de manager van de webshop een gedeelte van zijn budget kunnen aanwenden om te helpen het logistieke systeem te verbeteren. Met als doel de totale waardestroom beter te laten functioneren. Deze oplossing klinkt eenvoudig, maar de manier waarop organisaties zijn ingericht staat vaak haaks op de noodzaak van organisaties om hun waardestromen te optimaliseren. Het veranderen van de inrichting van een organisatie is veelal niet op kortere termijn te realiseren. Als agile coach zal je op zoek moeten naar oplossingen waar je wel je teams op kortere termijn mee verder kan helpen.

Top 3 interventies

Net als bij de softwareteams, komen echte verbeteringen pas als individuen bereid zijn samen te werken. Om het hierboven geschetste probleem waarin de samenwerking van managers om reden van de organisatie inrichting agility tegenwerkt, het hoofd te bieden, is een aantal interventies nodig:

  1. Zorg dat er begrip is bij de betrokken partijen over hoe gedeelde resources effectief ingezet kunnen worden en hoe iedere partij meer uit de gedeelde resources kan krijgen. Dit kan door over te stappen van veel initiatieven parallel uitvoeren naar een zeer beperkt aantal initiatieven sequentieel uitvoeren. Het begrip dat er samengewerkt moet worden is daar een natuurlijk uitvloeisel van.  
  2. Zorg dat stakeholders afstappen van denken in een grote fixed scope initiatieven (project) naar denken in minimum viable products en mimimal marketable features. Dit maakt dat er hanteerbare tijdpaden en wachttijden ontstaan voor minder hoog geprioriteerde initiatieven. Als de stakeholders gezamenlijk prioriteiten niet op project, maar op feature niveau stellen en deze features kort cyclisch opgeleverd worden, zal er een continue flow ontstaan van het opleveren van steeds de belangrijkste onderwerpen.
  3. Zorg dat de samenwerking verbeterd en successen gevierd worden door kort cyclisch gezamenlijk te plannen en terug te kijken naar behaalde resultaten en de effectiviteit van het proces. Door deze samenwerking zal er steeds groter begrip gaan ontstaan voor elkaars belangen. Als vertrouwen groeit, zal er ook steeds meer ruimte zijn voor transparantie over ieders doelen.

Het veranderen van inzichten en werkwijzen gaat niet vanzelf, daar komt aardig wat maatwerk bij kijken. Iedere organisatie heeft zijn eigen cultuur en daarbinnen zal de verandering vorm moeten krijgen. Het is een continue zoektocht naar steeds nieuwe tastbare verbeterpunten om stap voor stap tot het optimale resultaat te komen. Maar het kan wel, en ook zonder ingrijpende organisatieverandering.

Zelf ben ik als agile transformatie coach betrokken bij een product team. Ik heb gezien hoe de managers vanuit verschillende business units door bovenstaande interventies hebben geleerd dat als ze beter samenwerken met betrekking tot verzoeken voor hun gezamenlijke resources, ze meer waarde kunnen realiseren. Waar ze eerder nog de teams bevalen dat het gehele “project” in een bepaalde periode geïmplementeerd moesten zijn, stonden ze een paar maanden later gezamenlijk voor het planbord. Ze waren bereid om met elkaar indirect contact met de ontwikkelteams te overleggen over welke features ze in de komende periode het beste op konden pakken om maximale waarde te creëren.

Wil je weten hoe een dergelijke verandering in jouw organisatie plaats kan vinden, neem dan gerust contact met mij of een van mijn collega’s op. 

Ook interessant

Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.


DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • 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
  • 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
  • ​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
  • From serving the business to delighting customers

    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. 

    Lees verder

Cookies op de website van Inspearit

Wij plaatsen functionele cookies, om deze website naar behoren te laten functioneren, analytische cookies waarmee wij het gebruik van de website kunnen meten en cookies van derden voor het weergeven van emdeded media (YouTube en GoogleMaps) Hieronder kan je aangeven welke andere soorten cookies je wilt accepteren:

Meer informatie