Bij implementatie van welke methodiek of framework dan ook treedt altijd het fenomeen van toepassen van antipatronen op. Antipatronen zijn een eigen interpretatie van een methodiek of framework die juist indruisen tegen de bedoeling in, of die niet het gewenste effect opleveren die met het framework is bedoeld.
Google maar eens op antipatronen bij Scrum. Die zijn er legio. Enkele voorbeelden:
- Alleen een daily stand-up doen en dan zeggen we passen Scrum toe (Het makkelijkste toepassen en dan denken dat je er al bent);
- Denken dat je een User Story altijd mag doorschuiven naar een volgende sprint als je je sprint planning niet haalt, ‘want dat is toch agile’. (Verzuimen om je eigen planning proces dusdanig te verbeteren opdat je wel elke sprint je sprint doelen haalt en een stabiele velocity kunt bereiken, en daarmee een goede voorspelbaarheid);
- Een user Story realiseren in 3 sprints (Waterval werken over sprints heen);
- Wel een retrospective uitvoeren maar niets met de resultaten doen;
- Etc.
In mijn werk als management coach voor grote transities kom ik nu al antipatronen tegen bij het opschalen van agile werken over een organisatie. Ik heb met name ervaring in het toepassen van Scaled Agile Framework als leidraad hiervoor.
Ik ga 3 grote antipatronen die zich nu beginnen te manifesteren bespreken:
- Plotten van bestaande organigram op lagen in SAFe;
- Hernoemen van bestaande programma’s en projecten en bombarderen als value streams en release treinen.
- Geen tijd alloceren voor continue product- en proces kwaliteits- verbetering
Plotten van bestaande organigram op lagen in SAFe
De criticasters van SAFe krijgen op dit punt gelijk. Wat we zien is dat grote organisaties zich vereenzelvigen met de ‘grote plaat’ van Scaled Agile Framework. Dit met de veronderstelling dat men dan niet hoeft te reorganiseren, geen mensen hoeft bij of om te scholen of hoeft te laten gaan vanwege ‘afdoende rollen’ in SAFe.
Ik kom veel organisaties tegen met deze gelaagdheid:
- Business
- Informatie Management
- IT
- Operations
Wat je ziet is dat men de ‘SAFe plaat’ hierop gaat ‘plotten’ als volgt:
- Business = Portfoliolaag
- Informatie Management = Programmalaag
- IT = Teamlaag
- Operations = ‘Leuk voor erbij als we ook DevOps willen doen’
Gevolg hiervan is dat de hoge muren tussen de bestaande afdelingen onverminderd blijven staan. Elke medewerker zoekt in de plaat welke rol hij nu kan gaan vervullen. Men probeert bestaande functieprofielen op SAFe rollen te plotten.
Wat we juist willen zien is dat de organisaties hun organigram loslaten, en de boel zo plat mogelijk gaan slaan. Dus de business kort op de IT. Dit betekent dat je multi disciplinaire teams gaat samenstellen van medewerkers uit alle genoemde afdelingen, en dat afdelingsgrenzen er niet meer toe doen. Teams van teams willen we gaan richten op business producten. Deze teams van teams worden ook wel release treinen, Tribes, een NeXuS, of productgroepen genoemd, al naargelang welk scaling framework je pakt. Dus het afdelingsbelang, en daarmee de suboptimale doelen van een afdeling, moet bedrijfsbelang worden, of nog sterker, het belang van het business product waar dit team van teams voor staat.
Plotten van functieprofielen op rollen in SAFe (maar lees ook Spotify en LeSS), is zinloos, want er is geen 1 op 1 vertaling. Een projectmanager die voorheen veel focus had op de requirements in zijn projectscope, kan een goede Product Manager of Product Owner zijn. Maar had deze meer focus op proces, plannen, organisatie en faciliteren, dan is hij/zij wellicht een betere Scrum Master of Release Train Engineer.
Dus waar moet men naar gaan kijken? Naar de competenties van de medewerkers. Het houden van vlootschouwen en medewerkers laten solliciteren op bepaalde rollen wellicht.
Maar dit ligt moeilijk in het kader van medewerker medezeggenschap in de vorm van ondernemingsraden, die hierin moeten worden meegenomen. En hier zie je weer waar je mee te maken hebt als je agile werkwijzen gaat opschalen: een complete reorganisatie! En dat betekent weer commitment van het top management om dit ook zo in te zetten.
Sommige organisaties kiezen meer voor een geleidelijke invoering, ik noem dat evolutionair. Andere weer voor een big bang benadering, meer revolutionair. Bij de evolutionaire benadering liggen de genoemde gevaren veel meer op de loer dan bij de revolutionaire. Al heeft een revolutie ook weer zijn eigen nadelen.
Reorganiseren blijft moeilijk.
Hernoemen van bestaande programma’s en projecten en bombarderen als value streams en release treinen
Diegenen die een training SAFe hebben gevolgd weten dat je de organisatie moet indelen in zgn. Value streams. Die value streams worden weer bemenst met teams of teams van teams (release treinen). Dit correleert met de paradigmaverschuiving ‘Van het brengen van medewerkers naar het werk (tijdelijk project team samenstellen voor een project), naar het brengen van het werk naar vaste teams (Continue flow van klant eisen die in productreleases worden verwerkt door vaste product teams). Zie ook mijn blog over paradigma verschuivingen: https://newgility.eu/2015/10/28/paradigma-verschuivingen-bij-scaling-agile/
Omdat het top management bijna nooit vanaf dag 1 zich van deze zaken bewust is, noch commitment hiervoor heeft gegeven, zie je vele hybride situaties ontstaan. Dit mede omdat de hele agile beweging meestal bottom up vanuit de IT is opgekomen. Zolang het bij Scrum in de IT bleef, was het niet zo een probleem. Maar bij het opschalen en omklappen van de organisatie van functionele naar business georiënteerde silo’s, zijn besluiten van de top nodig om het in goede banen te leiden. Je kunt evolutionair een tijdje een hybride situatie laten ontstaan. Ik propageer altijd dat je met 1 domein moet beginnen als pilot, en dan uitbouwen. Dat is impliciet een hybride situatie creëren.
Met hybride bedoel ik dan deels al een indeling in vaste business domeinen (al dan niet virtueel (onafhankelijk van bestaand organigram), dan wel letterlijk (organigram aangepast)), en deels nog de tijdelijke organisatievormen met programma’s en projecten.
Is het top management zich echter niet bewust van deze hybride situatie, dan ontstaat er een dusdanige sub optimale situatie, dat je door de programma’s, projecten, value streams en release treinen het bos niet meer ziet.
Wat men dan vaak doet is het hernoemen van een tijdelijk programma tot een release trein, en tijdelijke projecten tot teams. Dan denkt men dat het is opgelost, maar in feite handhaaf je dezelfde complexiteit van een projecten matrix organisatie met tijdelijke projecten. En daar willen we juist vanaf.
Een tijdelijk programma of project is in de nieuwe situatie namelijk een Epic geworden. Een klant eis, die door 1 of meerdere vaste, op business producten georiënteerde, release treinen moet worden opgepakt, in stukjes gehakt, en in releases in productie gebracht. Dit is een RADICALE andere manier van besturen van de IT. Ik kan het niet genoeg benadrukken.
Als top management bewust omgaan met deze verandering, en gefaseerd domein voor domein invoeren is gewenst. Hiervoor is top down besturing van de verandering noodzakelijk, bovenop het bottom up laten inklinken van een nieuwe werkwijze, ander gedrag, toepassen van good practices en continue verbetering.
Geen tijd alloceren voor continue product- en proces kwaliteits- verbetering
Dit is geen nieuw antipatroon. Bij toepassen van Scrum gebeurt dit ook al op grote schaal. Het is zeer frappant, je zou denken dat als men (en wie is ‘men’) de agile en lean principes omarmt (en dat doe je wat mij betreft als je Scrum, dan wel SAFe gaat toepassen), dat men ook het principe van continue verbeteren omarmt. Dit gebeurt op grote schaal NIET (zie ook de voorbeeld antipatronen aan het begin van deze blog).
Even ter herinnering: de 4e zuil van de Lean tempel zegt: ‘Relentless improvement’. Dit staat zelfs voor ‘Meedogenloos verbeteren’. Principe nummer 12 van het Manifesto voor software ontwikkeling zegt: ‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly’.
Dit betekent voor mij concreet in de praktijk: Elk team krijgt 10% van de beschikbare tijd per sprint voor procesverbetering, afgestemd met de Product Owner. Die 10% is een richtlijn, maar het gaat erom dat er iets wordt afgesproken. In SAFe ga ik nog verder, om ook het team van teams te kunnen verbeteren is er in SAFe de zogenaamde IP sprint. Dit staat voor innovatie en planning sprint. Deze gehele sprint is dedicated aan het verbeteren van product- en proces-kwaliteit over teams heen. Dus team overstijgende verbeteringen om het team van teams te optimaliseren.
Tel je deze allocaties voor procesverbetering bij elkaar op, dan kom ik op een (richtlijn van) 20% tijdsbesteding overall voor een team van teams om structureel, per PI (Program Increment) periode, te besteden aan product- en proces kwaliteits- verbetering.
Wat zie ik dan in de praktijk: men, en dit keer is het meestal het management, kan die te besteden tijd aan product- en proces-kwaliteitsverbetering niet verantwoorden. Men is gebonden aan KPI’s als uren per functiepunt (help! Het aantal uren per functiepunt gaat omhoog als we dit doen!). Of het is gewoon een besturingsvraagstuk. Alleen functionele zaken hebben een budget. Voorheen kregen de projecten een budget, en nu de Epics. En buiten het budget voor die Epics om, is er geen budget.
Dus sta ik als management adviseur regelmatig te verdedigen waarom structurele tijdsbesteding aan product- en proces-kwaliteitsverbetering op lange termijn een productiviteitsverhoging! zal laten zien. En dat het juist geen tijd alloceren hiervoor een stilstand is die juist een productiviteitsverlaging zal laten zien.
Hier zie je wederom dat de ingesleten besturings-paradigma’s door management moeilijk losgelaten kunnen worden, om vele redenen. Dit is eens te meer een reden om de consequenties van een initiatief voor het opschalen van agile werken in ketens goed onder de aandacht te brengen bij top management. En dan bedoel ik training en begeleiding van top management. Zonder dat worden de basis agile en lean principes vanaf dag 1 met voeten getreden, terwijl men denkt en zegt agile principes toe te passen.
