5 Uitdagingen bij het opschalen van Agile

Praktisch aan de slag

Agile werken op teamniveau gaat vaak best goed, maar zodra wordt opgeschaald komen nieuwe uitdagingen en weerstand om de hoek kijken. Is weerstand tegen coördinatie, standaard processen en documenteren herkenbaar? Wordt er geworsteld met het draaiend houden van de softwarefabriek tijdens de agile transformatie? Is het lastig om de Product Owner rol op te schalen en voldoende business eigenaarschap te krijgen, ook van IT gerelateerd werk?

  • 28-01-2019
  • Blog

In dit artikel worden vijf herkenbare uitdagingen en praktische oplossingen uit de praktijk beschreven.

Doorschieten in Agile Values

De eerste uitdaging is het doorschieten in de Agile Values. Individuen gebruiken deze vaak om onder werk uit te komen dat niet leuk of moeilijk is. Neem “Working software over comprehensive documentation”. Ontwikkelaars hebben over het algemeen een hekel aan documenteren en gebruiken deze Agile Value om ook onder het minimum uit te komen. Hoe meer teams betrokken zijn bij de applicatie, des te belangrijker wordt documentatie. Hoe verder je opschaalt, hoe meer dit een uitdaging wordt.

Een ander goed voorbeeld is “Individuals and interactions over processes and tools”. Ook deze Agile Value wordt soms gebruikt als argument om afgesproken processen en tools niet te gebruiken. In kleinere omgevingen gaat dat meestal goed, maar processen en tools zijn juist meer nodig als de omvang toeneemt. Dat wil natuurlijk niet zeggen dat alles via de processen en tools moet lopen, maar ook hier geldt dat bij opschalen de noodzaak toeneemt. Een oplossing die goed werkt is om persoonlijke interactie te intensiveren naast het gebruiken van de processen en tools: “JIRA[1] is geen communicatiemiddel, loop ook even langs bij je collega’s”.

Op dezelfde manier wordt ook bij de andere twee Agile Values, “Responding to change over following a plan” en “Customer collaboration over contract negotiation”, doorgeschoten richting een uiterste. De opstellers van het Agile Manifesto zelf geven terecht aan dat er ook waarde zit in “de rechter kant” van de vergelijking: het ene is niet in plaats van het andere.

Agile implementatie is niet “af”, hybride situatie

De tweede uitdaging bij het opschalen van Agile is dat het implementeren van Agile en Scrum niet op één dag is geregeld en meestal geruime tijd duurt. Zeker bij een wat grotere omvang van de organisatie. Tijdens deze periode moet de fabriek ook gewoon blijven doordraaien. Deze uitdaging is niet specifiek voor het opschalen van Agile, maar geldt in het algemeen voor fundamentele aanpassingen in de werkwijze.

Een vaak voorkomend voorbeeld is wel specifiek voor Agile: de financiële sturing is nog traditioneel. Dat betekent onder andere projectbudgetten in plaats van product- of teambudgetten. Daarmee is geld nog gekoppeld aan scope, terwijl bij Agile geld gekoppeld wordt aan tijd, waarbij scope wordt losgelaten.

Een goede manier om met de Agile transitie om te gaan is het werken met een plateauplanning: een planning in stappen die elk op zich”, een afgerond en werkend geheel vormen. Daarbij wordt pas begonnen aan het volgende plateau als de vorige helemaal is bereikt. Dit geeft de mogelijkheid om een tijdje in een stabiele situatie te werken, voordat de volgende verandering wordt opgestart. Dit sluit ook heel goed aan bij het incrementele verbeteren dat in het Agile gedachtengoed zit. Het voorkomt te grote verandering die niet in één keer te behappen is.

Voor specifieke punten waar het in een bepaald tussen-plateau nog wringt, kan een concrete (tijdelijke) maatregel worden genomen. In het voorbeeld van de financiële sturing die nog niet product- of teamgeoriënteerd is, kan bijvoorbeeld in het financiële systeem al wel de team- of productdimensie worden toegevoegd, zodat al langs beide invalshoeken kan worden gerapporteerd en gestuurd.

Het opschalen van de Product Owner rol

Bij Scrum, de meest gebruikte Agile methode, is er voor het team een business vertegenwoordiger met mandaat: de Product Owner (PO). Deze prioriteert het backlog en accepteert de resultaten van een sprint. Bij één team kan het al moeilijk zijn om iemand te vinden die voldoende mandaat heeft en voldoende tijd. Bij het opschalen levert dat twee uitdagingen op. Ten eerste is het voor één persoon bijna niet haalbaar om voor meer dan 1 of 2 teams tegelijk de PO rol in te vullen. Het team heeft behoefte aan voldoende detailniveau en beschikbare tijd, terwijl het aantal stakeholders en het inhoudelijk af te stemmen gebied toenemen. Ten tweede wordt met het groeien van de omvang ook extra coördinatie over teams heen nodig. Er ontstaan afhankelijkheden, voor een bepaalde “feature” zijn meerdere stories nodig in verschillende teams die in een bepaalde volgorde gerealiseerd moeten worden.

In het Scaled Agile Framework (SAFe)[2], één van de vaker gebruikte raamwerken voor het opschalen van Agile, wordt de PO rol opgeschaald door de introductie van een Product Manager, die het product backlog beheert en de PO’s van de teams coördineert zodat er samenhang ontstaat.

Niet altijd zijn er voldoende business vertegenwoordigers om in een dergelijke situatie invulling te geven aan de PO rol. In een hybride situatie kan het een goede oplossing zijn om (business) analisten een dubbelrol te geven als PO. Zij maken toch al de specificaties (en/of stories) en zitten in of dichtbij het team. Daarmee zijn ze ook goed in staat om te beoordelen of de gebouwde functionaliteit aansluit bij wat was bedoeld en kunnen ze de uitkomst accepteren. Ook hebben ze vaak al contacten met de business, die dan de Product Manager rol kan vervullen.

Coördinatie “is niet Agile”

Een andere uitdaging is dat het toevoegen van coördinatie over teams heen door sommige Agilisten als “niet Agile” wordt beschouwd. Een goed voorbeeld is de weerstand die ontstaat als een team wordt gevraagd meerdere sprints vooruit te plannen, zodat afhankelijkheden tussen teams kunnen worden geadresseerd. Als argument wordt dan aangevoerd dat alles nog moet kunnen veranderen en dat het vastleggen van wat er in een sprint zit erg lijkt op de waterval methode waarbij scope aan tijd wordt gekoppeld. Dat lijkt in eerste instantie een valide argument, totdat je bedenkt dat het bij Agile niet gaat over niets plannen maar over het flexibel omgaan met verandering (“Responding to change over following a plan”). In dat opzicht is dit ook een voorbeeld van het doorschieten in de Agile Values.

De crux van de oplossing zit hem dan ook in het maken van afspraken over wat te doen bij gewijzigde omstandigheden of nieuwe inzichten. Een invulling uit de dagelijkse praktijk is, om niet alleen vooraf een (sprint)planning voor een release te maken over alle teams heen (bijvoorbeeld met behulp van het Program Board van de PI Planning in SAFe), maar deze ook iedere sprint bij te stellen, in de vorm van een rolling forecast. Dat geeft de ruimte voor het maken van afspraken en het sturen op afhankelijkheden in combinatie met het bijstellen van plannen als er iets anders loopt dan gepland. Hierbij hoeven dan niet alle teamleden aanwezig te zijn, maar is een vertegenwoordiging vanuit elk team, samen met de PO’s en de Product Manager, in veel gevallen voldoende.

Onvoldoende business eigenaarschap van IT: geen technische upgrades

Een laatste uitdaging bij het opschalen van Agile is dat de business onvoldoende eigenaarschap neemt van IT en daardoor eenzijdig naar het backlog kijkt. Daarmee krijgen technische upgrades (om bij te blijven met de laatste architectuur inzichten en bijvoorbeeld ook library versies) geen prioriteit en neemt de technische kwaliteit van de software af. Op enig moment wordt dat een beperkende factor voor de functionele kwaliteit en mogelijkheden. Omdat het meestal een glijdende schaal is wordt de urgentie bijna nooit hoog, totdat het te laat is. Dan duurt de technische wijziging ineens lang en komt er weinig nieuwe functionaliteit bij in die periode.

In de ideale wereld is de business zich bewust van dit dilemma, maar in de praktijk is dat zeldzaam. Een oplossing om deze situatie te doorbreken is om de Product Manager (en ook de Product Owners) te laten adviseren door architecten die het technische geweten zijn, en deze een gelijkwaardige rol te geven ten opzichte van de business. In het SAFe model wordt onderscheid gemaakt tussen “features” en “enablers”, waarbij die laatsten goed passen bij de technische onderstroom die ook moet worden ingevuld. Een praktisch besturingsmodel is een driehoek met de Product Manager, de business (change) manager en de architect[3], die gezamenlijk het backlog besturen. De business (change) manager is vooral verantwoordelijk voor de “features”, de architect voor de “enablers”. De Product Manager zorgt voor het continu maken van de juiste afwegingen.

Conclusie

Het opschalen van Agile is lastig, maar zeker niet onmogelijk. Belangrijke succesfactoren zijn doorzettingsvermogen, een praktische instelling, kennis van zaken en de juiste mensen.

Over de auteur

Martijn van Nierop is een ervaren Agile manager, die in diverse omgevingen Agile software fabrieken heeft opgebouwd en ingericht die ook daadwerkelijk resultaten opleveren. Hij zit in de examencommissie van studenten aan de TU Delft die afstuderen op onderwerpen gerelateerd aan Agile (project)management, en begeleidt hen daarbij. Daarnaast is hij SAFe 4 Certified Program Consultant.

[1] Agile / Scrum tool van Atlassian voor o.a. het beheren van backlogs.

[2] www.scaledagileframework.com

[3] Dit model is onder andere in gebruik bij de Rabobank.

  • Martijn van Nierop

    Senior Projectmanager

    Martijn is een resultaatgedreven professional met visie en focus op het ontwikkelen van IT organisaties en het leiden van teams die oplossingen ontwikkelen voor complexe vraagstukken. Martijn combineert leiderschap met een solide technische achtergrond en haalt het beste uit het team.

    Meer over Martijn van Nierop

  • Martijn van Nierop

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 030 – 600 47 79 Stuur ons een bericht