Veel bedrijven stappen bij hun veranderinitiatieven over van de wat meer rigide project management methodieken naar wendbaar werken. De beloften zijn hoopvol. Beter op de behoefte aansluitende producten, hogere kwaliteit en snellere oplevering. De ontwikkelaars krijgen veel vrijheid wat ze duidelijk inspireert en motiveert. Als na de eerste kleine experimenten besloten wordt wendbaar werken groots uit te rollen komen klassieke vraagstukken rond sturing weer boven. Niemand heeft de mogelijkheid onbeperkt op te schalen door meer geld of middelen in te zetten en dus zijn keuzes noodzakelijk. Maar hoe richt je dit in? En wie verzamelt de informatie en maakt deze geschikt? Wij zien een nieuwe functie ontstaan: de Agile Officer.
Waar komen projecten, of liever wat algemener gezegd veranderinitiatieven vandaan? In de literatuur zijn vele definities in zwang maar in de kern gaat veranderen over het bereiken van iets dat gezien wordt als gewenst. Dit kan op basis van een visie en strategie zijn, maar ook een reactie op een van buiten komende bedreiging of kans. Voor deze verandering zijn nieuwe producten of diensten nodig om de organisatie in staat te stellen de verandering te realiseren. Om deze te maken ontstaan projecten of worden ontwikkelaars direct aan het werk gezet. Gekeken moet worden naar op welke manier de strategie het meest effectief en efficiënt bereikt kan worden. Hiervoor kan gebruik gemaakt worden van prioriteringsprocessen om de schaarste in geld en resources zo goed mogelijk in te zetten. Dit proces is portfoliomanagement.
Kern van succesvol veranderen
Bij veranderen gaat het om twee zaken. Allereerst de juiste dingen doen, en daarnaast de dingen juist doen. Hoe eenvoudig dit ook klinkt, het valt niet altijd mee. Er is namelijk ook nog sprake van een tijdsaspect waardoor het begrip ‘juist’ steeds een iets andere betekenis kan krijgen. Welke zaken de juiste zijn om te doen hangt af van de omstandigheden die kunnen wisselen in de tijd. Maar ook als je bezig bent is het bij de dingen juist doen zaak om ook te houden voor de zich ontwikkelende omgeving. De crux is hier om twee zaken te scheiden.
Allereerst hebben we het over de aanpak van het realiseren van verandering. Dit is het terrein van het ‘hoe’. Bij doen van projecten is er sprake van een ontwikkelmethode aan de hand waarvan producten gemaakt en opgeleverd worden. Het ‘wat’ en ‘wanneer’ zijn vraagstukken die als het ware boven op de ontwikkeling liggen.
Het verschil laat zich goed uitleggen aan de hand van een voorbeeld. Een ontwikkelmethode zegt iets over de aanpak en wijze van totstandkoming van een product. Denk aan metselen in halfsteensverband. Het gaat hem daarbij om de technieken en instrumenten die gebruikt worden. Een procesmethode ligt daar als het ware een niveau boven en gaat over de aanpak van het grotere geheel aan op te leveren zaken. In ons voorbeeld dat we eerst de muren optrekken en pas daarna aan het dak beginnen. Het zegt iets over het proces, de te volgen stappen en de beheersing van het project.
In traditionele omgeving ligt het accent vaak op uitvoering van het plan in voorgeschreven stappen en de beheersing van dat proces tot in detail. Dit is schadelijk voor de wendbaarheid die nodig is om het hoofd te bieden aan wisselende omstandigheden.
Wendbaar werken kan met Agile methoden zoals Scrum. Maar ook hier is beheersing nodig. Hoe dit te doen laten we zien in de volgende paragrafen.
De traditionele omgeving
In de (wat we noemen) traditionele omgeving is sprake van (product)ontwikkeling aan de hand van een ontwerp met toetsing achteraf. Deze methode, ook wel waterval ontwikkeling genoemd, heeft als voordeel dat eerst nagedacht wordt over het eindresultaat, maar als nadeel dat het tijdrovend is en de omstandigheden en eisen tussentijds kunnen veranderen. Met als ultiem gevolg dat het opgeleverde product uiteindelijk niet bruikbaar blijkt. Of dat bij geconstateerde gebreken in het ontwerp het gehele ontwerpproces opnieuw moet als al begonnen is met de productiefase. Een andere veel gehoord nadeel is dat de eindgebruiker (te) lang in onzekerheid wordt gelaten over het eindresultaat. Na de start van het project is er weinig mogelijkheid tot het aanpassen van de eisen doordat al bij aanvang aspecten als kosten en tijd zijn vastgelegd.
Bij het beheersen van waterval processen wordt in Nederland veel gebruik gemaakt van de projectmanagement methode PRINCE2, dat sterk de nadruk legt op documenteren en formele besluitvorming. Door de sterke nadruk op vastleggen van alle projectaspecten is het voordeel dat er goed zicht is op de prestaties van het project. De bruikbaarheid van het op te leveren product is daarmee enigszins geborgd door de nadruk op het aanwezig zijn van een voortdurende zakelijke rechtvaardiging van het product. De ervaring leert echter dat een business case alleen bij het verkrijgen van budget een rol speelt en daarna vaak niet meer. Als gevolg hiervan is er nauwelijks tussentijdse toetsing of het project nog voldoet aan veranderende omstandigheden, wensen of eisen. De beleving van de eindgebruiker is dat na het formuleren van zijn wensen het project langdurig onder water verdwijnt, om vervolgens omhoog te komen met wat het denkt dat de gebruiker wenste zonder oog te slaan op een veranderende wereld. In omgevingen met een sterk ontwikkeld portfoliomanagement gaat dit overigens beter doordat zij periodiek de projecten wegen. Dit is vaak een jaarlijks proces, wat de wendbaarheid niet ten goede komt.
De agile omgeving
De snel veranderende omstandigheden dwingen veel bedrijven om kort-cyclisch en adaptief te veranderen. De verandering die vandaag nodig lijkt kan morgen anders zijn. In projecttermen is er een verschuiving gaande van nadruk op vaste scope, naar kant-en-klare producten binnen een vaste oplevercadans.
De opkomst van het agile werken laat zien dat deze behoefte steeds meer gevoeld wordt. Er bestaan al heel lang methoden die meer recht doen aan een constant veranderende omgeving en die goed om kunnen gaan met onzekerheid over de eisen aan het uiteindelijke product. Op dit moment is de Scrummethode erg in zwang in Nederland. De populariteit van scrum wordt veroorzaakt doordat wendbaarheid en snelheid nu belangrijker zijn dan voorspeldbaarheid die waterval ontwikkeling biedt. Scrum maakt wendbaar werken mogelijk op een eenvoudige manier waarbij veel autonomie wordt gegeven aan de ontwikkelaars. Daarnaast neemt de complexiteit en dynamiek enorm toe de laatste jaren. Hierdoor is het niet meer mogelijk een project van voor tot achter van te voren te overzien. Dit maakt gebruik van de waterval methode minder aantrekkelijk.
De scrum methode is iteratief waarbij in korte cycli een tussenproduct getoond wordt aan de opdrachtgever en gebruikers. Deze kan dan zijn mening geven en zijn inzicht aanscherpen over wat hij (of zijn klanten) precies nodig hebben.
We zien op dit moment veel hybride omgevingen waarbij meer traditionele project management methoden gebruikt blijven worden. De scrumteams worden dan aangestuurd zoals een traditioneel ontwikkel team. In volledig scrumomgevingen ontbreekt de rol van de projectmanager geheel. De taken van de projectleider worden daarbij opgeknipt en komen deels bij de scrummaster (leider van het scrumteam) en deels bij de product owner (vertegenwoordiger van de business als ontvanger van het resultaat) terecht. Deze vorm van ontwikkeling werkt uitstekend als het om geïsoleerde eindproducten gaat waarbij het op voorhand nog niet geheel duidelijk is wat het eindproduct is.
Schaalbaarheid
Belangrijk kenmerk van het werken met scrumteams is dat ze zo snel gaan als ze gaan en werken volgens de prioriteit die ze is aangegeven door de opdrachtgever (in scrum termen: product owner). In grote organisaties zullen meer product owners actief zijn die ieder naar hun eigen maximale waarde streven. Dit kan op bedrijfsniveau conflicteren waardoor het gevaar van sub optimalisatie dreigt. Deze sub optimalisatie komt om de hoek kijken doordat ieder team alleen zijn eigen product owner tevreden stelt. De belangen van deze persoon hoeven niet gelijk te liggen aan die van andere product owners of van het bedrijf. In theorie is het zelfs mogelijk dat twee teams elkaars ‘waarde’ opheffen. Bij meer dan één scrumteam komen dus weer de klassieke vraagstukken over prioriteiten en verdeling van de inzet van resources naar voren.
Het kernbegrip binnen Agile werken is waarde. In het klassieke denken was het de afweging tussen kosten en baten, maar het begrip waarde is breder. Het is tegelijk gericht op het elimineren van verspilling. Scrum komt dan ook voort uit de Lean traditie. Het is dus zaak om het totale overzicht van de ‘Value Stream’ te hebben zodat er geoptimaliseerd kan worden. Dit wordt des te belangrijker als er bij de ontwikkeling gebruik gemaakt wordt van meerdere scrum teams.
Over deze schaalbaarheidsvraag (hoe richting te houden bij meerdere scrum teams) is uiteraard veel nagedacht. Een nu veel gebruikt model is het Scaled Agile Framework (SAFe). Dit is een vreselijk ingewikkeld plaatje dat in essentie regelt hoe te komen tot een lijst met werk op basis van de strategie en hoe deze te ordenen en te beheersen. En zo sluipt er toch weer een procesmethode in. Het kan ook niet anders, want zonder wind is de vaan richtingloos, ook bij Scrum teams. Zo lang resources niet eindeloos schaalbaar zijn zal er richting gegeven moeten worden aan de teams om aan die zaken kunnen te werken die de dat moment de meeste waarde opleveren. Uiteindelijk wil een bedrijf toch zijn strategie uitgevoerd zien. Met Scrum als Agile methode kan dit iteratief en wendbaar, zodat snel geschakeld kan worden bij het bereiken van de strategie. Ook kan een wijziging van de strategie snel opgevolgd worden.
Een vergelijking met Alice in Wonderland dringt zich op. Wanneer Alice om de weg vraagt aan de kat, is de wedervraag waar zij naar toe wil. Als Alice zegt dat het haar eigenlijk niet uitmaakt, zolang zij maar ergens komt, antwoordt de kat dat dat zeker gebeurt als zij maar genoeg doorloopt. Maar wanneer Alice geen bestemming (doel) heeft en haar richting niet kan bepalen, loopt zij het risico uiteindelijk hopeloos te verdwalen. Wij zien daarom een nieuwe functionaris opstaan die richtinggevend en ondersteunend kan werken. Wij noemen deze de Agile Officer.
De Agile Officer
Wij zien genoeg kansen voor de Agile Officer binnen het SAFe framework maar ook in andere omgevingen waarin sprake is van Agile werken op grotere schaal. Voor nu concentreren we ons op het SAFe framework als dominant model ion de markt. Helemaal linksboven in het plaatje zien we de bedrijfsstrategie verbeeld. De voor de Agile Officer interessante onderdelen van deze methodiek zitten in de onderdelen Portfolio Management, Metrieken, Roadmap. Dit is de vertaling van de strategie naar meetbare doelen en een planning op hoofdlijnen.
De portfolio manager vertaalt de strategie naar Value Streams (thema’s) met zijn collega’s en de architect. Dit werk is uitermate geschikt voor een Agile Officer. De portfolio manager is in deze context ook een Agile Officer, en kan ervoor kiezen zich te laten assisteren door een minder ervaren Agile Officer die vooral informatie verzamelt en rangschikt. Hiervoor is wel enig strategisch inzicht nodig omdat de directie wel het wat, maar niet het hoe heeft overgedragen.
Er is vervolgens nog een laag nodig die de zaken in beweging zet. In de terminologie is ook duidelijk beweging terug te zien, men spreekt over Agile Release Trains. Welke trein wanneer vertrekt staat in de dienstregeling, in SAFe
termen de ‘Roadmap’. Het portfolio proces leidt uiteindelijk tot een company backlog die de scrum teams op zullen kan pakken. De Agile Officer ondersteunt dit proces. De portfolio manager wil geïnformeerd blijven over de uitvoering en zal dus een dankbaar ontvanger zijn van door de Agile Officer verzamelde en geaggregeerde metrieken over de voortgang.
Maar daar blijft het niet bij. Kijk maar in het donkere gedeelte helemaal links in het SAFe model. Daar zien we de Agile Coach staan die tot doel heeft om de scrum teams bij te staan op het gebied van de methode. Deze rol geeft uitleg over de manier van werken. Ook hier liggen kansen voor de Agile Officer om het agile gedachtengoed in een organisatie te verspreiden. Een Agile Officer is immers vakinhoudelijk onderlegd op het gebied van agile/scrum net als zijn collega PMO professional dat is op het gebied van projectmanagementmethodieken.
Conclusie
Gezien het voorgaande zijn wij ervan overtuigd dat de rol van Agile Officer waarde toevoegt in een agile omgeving. De Agile Officer is actief bij het portfolio management en niet te vergeten bij het bewaken van de voortgang en afhankelijkheden en bij het opstellen van rapportages. Juist wanneer er op grotere schaal gewerkt gaat worden is het de Agile Officer die inzicht en overzicht biedt. Ook zien we de Agile Officer toegevoegd zien aan functionarissen in de rol van Product Owner om deze te ondersteunen.
Waar we nadrukkelijk ook toegevoegde waarde zien van de Agile Officers is daar waar het gaat om afhankelijkheden. Zeker wanneer het aantal scrumteams groter wordt ligt het gevaar op de loer dat werk dubbel, of vanuit een aanname, niet uitgevoerd wordt. De Agile Officer kan hier een cruciale rol in spelen en hier inzicht in bieden zodat de scrum teams zich kunnen richten op het ontwikkelen van waarde. Steun voor deze stelling zien we terug in de markt. Met namen als ‘Consultant Agile
Reporting’ of ‘Agile Analist ‘ zien we dat beschreven competenties erg gewild zijn. Want inzicht en overzicht dat willen we allemaal!