[vc_row padding_top=”0″ padding_bottom=”0″][vc_column][vc_column_text]Managen van strakke tijdslijnen en scherpe deadlines, de 
vrees en hoofdpijndossier voor elke projectmanager. Met de komst van Agile-productontwikkeling en het steeds toenemend gebruik van Scrum (State of Agile 2022) zijn deze nog lastiger te managen. Met name omdat Agile en Scrum teams vaak dwars kunnen ogen en jij als projectmanager vaker zinnen als “wij zijn agile, wij doen niet aan planning” en “we kijken maar twee sprints vooruit, kom daarna maar weer terug” voor je kiezen krijgt. Maar ja, als je geen grip meer hebt op tijd, wat kan je dan wel managen om waardevolle projecten op te leveren?
De meeste organisaties zijn in transitie van een projectmatig werken naar een product georiënteerd werken (bron). Bij deze transitie is het vaak nodig om de oude manier van werken in stand te houden, terwijl de nieuwe manier van werken vorm neemt. Voor de meeste organisaties wordt een complete/gelijke transformatie als te risicovol ervaren en wordt gekozen voor een geleidelijke transitie. In deze transitie verwachten we nog steeds de rapportages rondom het behalen van tijdslijnen en status van onze projecten zodat onze verschillende stuurgroepen in staat zijn beslissingen te nemen. Als gevolg hiervan besteden teams meer tijd aan het opstellen van statusrapportages dan aan het sneller leveren van waarde aan de klant. De vraag is hoe lang deze twee manieren van werken naast elkaar kunnen blijven bestaan. Ik deel drie oplossingen die ik in het verleden heb gebruikt bij organisaties om de transitie te versoepelen en het gesprek te hebben over het leveren van de juiste waarde i.p.v. het maken van statusrapportages en behalen van deadlines om een gevoel van zekerheid en voortgang te hebben.
Maak projecten kleiner
Een van de problemen waar ik vaak tegenaan loop, is dat projecten veel te groot zijn. Dit zorgt ervoor dat ook de bijbehorende projectdoelen erg groot en niet makkelijk haalbaar zijn. Als vuistregel hanteer ik: hoe groter het project, hoe complexer, onvoorspelbaarder en moeilijker het wordt om dit te managen. Daarnaast neemt de afhankelijk tussen teams ook meer toe. Hoe meer afhankelijkheden, hoe groter de behoefte aan afstemming en dus “juiste” tijdslijnen en deadlines zal zijn. Het is een vicieuze cirkel die we moeten doorbreken.
Als jouw organisatie met Scrum werkt, dan kan een Product Owner jou ondersteunen om de projecten kleiner te maken. Een goede PO is in staat om de het enorme aantal projectdoelen van grote projecten te analyseren en op te splitsen in losse, onafhankelijke doelen die sneller waarde leveren. Dus niet hoe je in kleinere stukjes het ontwerp kunt afronden, waarbij alleen aan het einde van het traject alles bij elkaar komt en waarde oplevert, maar hoe je het project dusdanig op kunt knippen, zodat je zo snel mogelijk bruikbare onderdelen oplevert die direct waarde opleveren. Door het opdelen van een project in mini-projecten, die allemaal individueel waarde leveren, zal de behoefte aan afstemming ook afnemen. Doordat je snel en regelmatig werkende producten hebt, zal de vraag naar tijdslijnen ook verkleinen.
Een belangrijk effect die deze opsplitsing heeft is dat doelen behapbaar en realistischer worden. Hierdoor neemt de focus voor zowel teams als de stakeholders toe. Daarnaast geeft dit de Scrum teams de mogelijkheid om goede sprintdoelen op te stellen zodat je per sprint de voortgang richting eerste doel kunt inspecteren en tijdig kunt aanpassen.
“Story Mapping is een betere manier om met User Stories om te gaan” – Jeff Patton
Ik heb story mapping gebruikt als een techniek om projecten kleiner te maken. Deze techniek helpt je om het project op te delen. Het helpt ook om te bepalen waar je ‘nu’ op moet richten en wat later komt. Ook gebruikte ik de gemaakte story map om de stakeholders tijdens de sprint review context te geven over welke waarde we willen leveren. Per sprint stelden we het sprintdoel vast aan de hand van de story map en onderzochten we in hoeverre we moesten afstemmen met andere teams.
Verbind jouw stakeholders en de verschillende silo’s
Een andere uitdaging is dat elke afdeling de klant wil helpen, maar alleen vanuit hun eigen perspectief. Een belangrijke taak van een stuurgroep is om beslissingen te nemen en te bewaken dat de losse projecten per afdeling bij blijven dragen aan de algehele strategie. Hoewel de meeste stuurgroepen vanaf het begin al hun vraagtekens hebben over de businesscase, de algehele organisatorische afhankelijkheden en haalbaarheid van het project wordt een project toch goedgekeurd om te starten. Zodra een project goedgekeurd is, is het een race tegen de klok om het project volgens de beloofde tijdlijnen af te ronden. Elk project legt met de woorden als “akkoord van de stuurgroep” dan druk op individuen en teams om functionaliteit met prioriteit op te leveren. Het niet halen van deze deadlines betekent dat je voor de stuurgroep moet uitleggen waarom je de beloofde deadlines niet kunt halen.
In deze gevallen kan een sterke Product Owner de waarden van de verschillende belanghebbenden bij elkaar brengen. Zij kan de verschillende silo’s eraan herinneren dat het organisatiebelang zwaarder weegt dan het belang van één afdeling of project. Dit vereist dat stakeholders deel uit moeten maken van het besluitvormingsproces. Wat bouwen we? In welke volgorde? En wat gaan we dus niet doen? Door het op deze manier te organiseren, worden beslissingen genomen door mensen die daadwerkelijk het werk doen of de gevolgen ervan ondervinden.
Ik heb in een situatie gezeten waar we drie stakeholders hadden, waarbij elk 1/3 van de financiering van het team leverden en daarom ook 1/3 van de sprint capaciteit vroegen om aan hun eigen wensen te besteden. Los van het verlies van effectiviteit doordat we geen sprintdoel konden formuleren door allerlei verschillende wensen, kon ik op basis hiervan dus ook niet de waarde maximaliseren omdat ik vast zat aan de verdeling van de capaciteit. Na een paar sprint reviews heb ik de individuele stakeholders gevraagd om inzicht te geven in de cost-of-delay van hun wensen. cost-of-delay is een indicator van hoeveel geld je verliest doordat een functionaliteit nog niet in productie is (bron). Ik deed dit om meer inzicht te geven dat we sneller waarde kunnen leveren als we eerst één functionaliteit afmaken i.p.v. met drie tegelijk bezig zijn. De cost-of-delay van de verschillende stakeholders heb ik tijdens een sprint review transparant gemaakt en uitgelegd waar we keuzes over moesten maken. Toen dit eenmaal uitgelegd was, zeiden twee van de drie stakeholders dat ze echt wel een maandje of twee konden wachten. “Als stakeholder 3 nu even alle aandacht krijgt, ga ik alvast met mijn achterban de voorbereidingen treffen zodat we daarna volle kracht vooruit kunnen”. In de sprint reviews daarna maakte ik transparant hoe ver we gevorderd waren en wanneer we aan het werk van de andere stakeholders konden beginnen.
Verleg het gesprek van focus op tijd naar focus op waarde
Agile Product Ownership is erg moeilijk omdat het een verandering in de cultuur vereist. In een waardegedreven organisatie wil je je richten op het leveren van waarde, in plaats van te focussen op het leveren van projecten volgens de afgesproken tijdslijnen. Dit betekent dat je voortdurend de aandacht moet vestigen op de waarde die je wilt creëren. Telkens wanneer er een vraag komt over “wanneer is het af?”, moet je deze stakeholder uitdagen door te vragen: “Hoe leveren we sneller waarde aan klanten door dit te doen?”. Het is niet de bedoeling om hiermee een vrijbrief te krijgen en te bouwen wat je maar wilt, wanneer je maar wilt, maar om op een dieper niveau te accepteren dat alle gesprekken over tijdslijnen en deadlines uiteindelijk zinloos zijn in de complexe wereld van softwareontwikkeling. Geen enkele mate van planning, plannen of deadlines gaat het werk voorspelbaar maken. Dus in plaats van te focussen op het behalen van deze tijdslijnen, richten we ons op het leveren van werkend software aan klanten na elke sprint.
Het kan even duren voordat dit landt en geaccepteerd wordt, maar mensen zullen beginnen in te zien dat dit uiteindelijk de risico’s van softwareontwikkeling sterkere vermindert dan welke vorm van planning dan ook. Je ontvangt waardevolle functionaliteit binnen een sprint zodat je tijdens de sprint reviews gerichter feedback kunt geven om het proces en product te verbeteren.
En wanneer je gaat focussen op een gesprek over waarde i.p.v. tijd, zul je merken dat de betrokkenheid van alle partijen gaat groeien.
Als Product Owner kreeg ik vaak de vraag “wanneer is het af”. Dit vond ik een van de lastige vragen om te beantwoorden. Ik heb het gesprek opgestart met de stakeholders en zowel de waarde als de “effort” van de gewenste functionaliteiten transparant gemaakt. Daardoor konden we de focus verleggen naar het oppakken van de functionaliteiten die het meeste waarde opleverden en het minste effort kosten om het te maken. Daarna was de uitnodiging om items die wel veel waarde opleveren, maar ook veel effort kosten op te gaan splitsen zodat we met minder effort toch veel waarde konden opleveren.
Conclusie
Het managen van projecten op het behalen van deadlines is lastig. In een omgeving waar we meer niet weten dan wel weten (complex), hebben we een meer empirisch aanpak nodig en willen we het gesprek hebben over waarde in plaats van deadlines. Ga daarom met name in gesprek met een Product Owner in jouw organisatie en werk samen om te onderzoeken hoe je sneller meer waarde kunt leveren voor de organisatie. Laat de Product Owner jou ook ondersteunen om de genoemde drie technieken binnen jullie organisaties toe te passen en meer waarde te creëren:
- Maak projecten kleiner
- Verbind je belanghebbenden en de verschillende silo’s
- Verleg het gesprek van focus op tijd naar focus op waarde
Ik hoop dat deze tips je helpen om op een effectievere manier met tijdslijnen en deadlines om te gaan. Als je nog tips of trucs hebt die je gebruikt om ze te managen, voel je vrij om ze met de community te delen.[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”20″][vc_column][vc_column_text]
Een bijdrage van
Ziryan Salayi is een Agile professional, scrum.org gecertificeerd Professional Scrum Trainer en mede-oprichter van Scrum Facilitators, SF Professionals, en The Cultivators. Hij heeft een passie om het beste uit de mensen te halen. Hij helpt organisaties om meer Agile te worden en hun processen aan te passen naar de behoeften van de mensen die dagelijks waarde leveren voor de klant. Zelf-organisatie en mandaat zo laag mogelijk in de organisatie leggen is hierbij een van zijn speerpunten. Niet alleen bij organisaties die hij coacht, maar ook bij de organisaties die hij heeft opgericht.
& Co-Host
Erik de Bos begon zijn carrière als ecoloog, maar vond betere werkgelegenheid als programmeur. Daar begon hij zich snel af te vragen waarom projectmanagement nooit lijkt te werken. Overtuigd dat we veel meer plezier zouden moeten hebben in ons werk, begon hij aan een zoektocht naar oplossingen. Voor hem is Agile de heilige graal, een win-win voorstel en de nieuwe competitieve basis waarop alle organisaties worden beoordeeld. Hij is een Scrum Master, Agile Coach, schrijver, spreker en redacteur. Hij werkt bij Scrum Facilitators met een groep idealisten, waar ze zich inzetten om iedereen te helpen Agile te begrijpen en toe te passen.[/vc_column_text][kleo_social_share][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_single_image image=”18182″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://www.hdmwp-demo.nl/de-waarde-van-lid-zijn/”][/vc_column][vc_column width=”1/2″][vc_single_image image=”17425″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://www.hdmwp-demo.nl/winkel/eventkalender/”][/vc_column][/vc_row][vc_row padding_top=”0″][vc_column][vc_posts_grid loop=”size:12|order_by:date|post_type:post|categories:813″][/vc_column][/vc_row]