Door op 01/01/2020

Voor een transitie naar agile ligt geen draaiboek klaar. Wel zijn er experts die bedrijven helpen bij zo’n transitie. Steven Happee is zo’n expert. Steven heeft verschillende organisaties gecoacht bij hun transitie om agile te gaan werken en vertelt welke valkuilen je zeker moet vermijden.
De liefde van Steven Happee voor agile is ontstaan in de jaren negentig, toen hij in een klein, multidisciplinair team software ontwikkelde, op een manier die nu agile genoemd zou worden: veel klantcontact, snel waarde opleveren, transparant werken.

Nu, twintig jaar later, helpt hij bedrijven bij hun transitie naar een wendbare en lerende organisatie. Hij gebruikt hierbij zijn ruime ervaring als product owner, Scum master, developer én manager om waardevolle experimenten te starten. Op basis van deze ervaring deelt Steven de zeven meest voorkomende valkuilen voor een agile transitie.

1. De transformatie alleen top-down benaderen

Agile transformaties kunnen op twee manieren worden aangepakt: top-down en bottom-up. Bij een bottom-up benadering neemt een team het initiatief, vaak in IT, om met één team meer agile te werken.

Bij een top-down komt het initiatief van een directeur, CEO of CIO en is het doel vaak om de hele organisatie of een groot deel meer agile te maken. De top-down benadering is relatief nieuw. De laatste jaren is het een hot topic geworden en krijg je steeds meer CEO’s en CIO’s die denken ‘Moeten wij niet iets met agility?’ Een goed idee, maar dit werkt niet als er geen draagvlak is in het bedrijf.

Een aanpak die alleen bottom-up werkt, heeft meer kans van slagen. Dat zie je vaak bij IT-teams ontstaan, waar het agile gedachtegoed natuurlijk ook vandaan komt. Iemand in het team wil ermee experimenteren, diens manager is enthousiast en er wordt een Scrumteam in het leven geroepen. Als dat goed gaat, komen er misschien meerdere teams, en wordt de rest van de organisatie nieuwsgierig.

Het beste werkt natuurlijk de combinatie van top-down en bottum-up: een team neemt het initiatief om agile te werken en vindt een goede sponsor in de top van de organisatie.
Wil je weten waarom agile niet het einde hoeft te betekenen voor ITIL? Lees dan hier verder »

2. De waterval-methode hanteren voor je agile transitie

Tien jaar geleden was er nog een hele stroming aan mensen die vond dat je een agile transitie volgens Prince2 moest aanpakken. Eerst een ontwerp maken, dat stapsgewijs uitzetten, mijlpalen uitzetten enzovoorts. Dat is natuurlijk paradoxaal.

Gelukkig zijn de meeste mensen er tegenwoordig van overtuigd dat je ook een transitie op een agile manier moet aanpakken. De transitie naar agility is immers een complex project. Een soort meta-agile, dus. Mensen gaan anders met elkaar samenwerken, je werkwijze gaat op de schop en je gaat met andere tools werken. Die transitie kun je dus het beste iteratief doen met een multidisciplinair team en een veranderbacklog. Dan geef je direct het goede voorbeeld.

3. Te strikt omgaan met de technieken

Agile frameworks als Scrum bieden technieken om de agile principes in praktijk te brengen. Een backlog, standups, retro’s – hele zichtbare dingen. Maar die technieken zijn slechts het topje van de ijsberg; het zichtbare deel van agile werken. Ze zijn gebaseerd op bepaalde opvattingen over hoe je je werk inricht, en die steunen weer op principes zoals je die vindt in het Agile manifesto of Modern Agile.

Sommige mensen hebben de neiging heel strikt de technieken te volgen, zonder de onderliggende principes te snappen. Dat kan botsen. Sommige technieken werken misschien niet goed voor jouw organisatie, dan is het zonde als je daar strikt aan vasthoudt. Uiteindelijk is het de bedoeling dat je handelt naar de waarden van agile, niet naar de technieken. Daarom is het goed om iedereen die iets met agility wil ook de onderliggende principes uit te leggen, zodat men daarop kan terugvallen.

Vind je het lastig om termen als agile en Scrum uit elkaar te houden? Lees dan hier wat het verschil is »

4. Te snel variëren op bestaande technieken

Ja, je moet agile technieken naar je hand zetten. Maar niet vanaf het begin. In de agile wereld wordt vaak verwezen naar ShuHaRi, een Japans model voor hoe je je in 3 fasen een bepaalde vaardigheid eigen maakt:

1.In het begin volg je strikt de bestaande technieken (Shu).

2.Als je die regels hebt geïnternaliseerd, kun je erop variëren (Ha).

3.Tot je bij Ri uitkomt: dan ben je onbewust bekwaam en heb je geen regels of technieken meer nodig.

Je ziet teams vaak al beginnen met variëren op bestaande technieken, of elementen verzamelen van verschillende frameworks. Cherry picking. Daar hoor je heel veel excuses voor, zoals: ‘Ik ken de theorie, maar bij ons gaat dat niet werken’ of ‘We experimenteren graag, dus we combineren wat verschillende technieken.’ Experimenteren is goed, maar zorg dat je varieert vanuit een basis. Volg een half jaar of een jaar een bestaande methode, en ervaar wat het is. Hoe werken sprints? Wat is een goede retro? Hoe formuleren we klantwaarde? Pas als de basis goed hebt, ga je variëren.

5. Mensen werken in een agile team én in een projectteam

Agile werken en projectmatig werken kennen fundamenteel verschillende uitgangspunten. Bij agile heb je vaste teams, met teamleden die op elkaar ingespeeld raken en ontwikkelen. Je brengt werk naar teams. Bij projectmatig werken heb je werk, waar je tijdelijk mensen bij gaat zoeken – je brengt teams naar werk. Dat kun je niet combineren.

Een valkuil is dat organisaties projectmatig willen blijven werken én de agile teams willen laten groeien. Dan krijg je de situatie waarin mensen twee dagen per week in een Scrumteam zitten en drie dagen in een projectteam, ‘want dat project is ook belangrijk’. Vaak komen dan én je teams niet van de grond én je projecten lopen uit.Lees in dit blog ook meer over hoe je agile service management in de praktijk toepast »

6. Een agile transformatie beschouwen als een kunstje van IT

Wat vaak voorkomt, is dat men een te beperkte opvatting heeft van de impact van agile werken. Het is geen kunstje van en voor het IT-Scrumteam. Een agile transformatie is een cultuurverandering, die impact heeft op alle processen en mensen in je organisatie, van Finance en HR tot het management. Als teams zelfsturend worden, wat wordt dan de rol van teamleiders? Hoe beoordeel je mensen in de Scrumteams? Gaan jaarlijkse budgetten en Scrumteams eigenlijk wel samen? En vaak komt vanuit andere teams in de organisatie na verloop van tijd ook de wens om meer agile te gaan werken.

Hoe eerder je snapt dat een agile transformatie impact heeft op het hele bedrijf, hoe makkelijker de transitie gaat. Veel managers zien dit ook als een kans om een cultuurverandering door te voeren, zoals meer klantgericht werken of meer eigenaarschap van werknemers. Managers hebben soms al allerlei cultuurprogramma’s stukgeslagen op die cultuurverandering. Bij agile technieken ontstaan veranderingen als een meer klantgerichte mindset of een groter gevoel van eigenaarschap als bijgevolg van een nieuwe werkwijze.

7. Te vroeg opschalen

Er is in de agile-wereld nu veel ervaring met agile werken op teamniveau. Maar als het team eenmaal draait, hoe schaal je dan naar twee of drie teams? Of twintig? En hoe werk je agile bij afdelingen als Sales of HR? Met die puzzel is de agile wereld nu volop bezig.

Er zijn verschillende frameworks voor het schalen van agile teams, zoals het Spotify-model, SAFe (Scaling Agile Framework) en LeSS (Large Scale Scrum). De belangrijkste les: als je niet hoeft te schalen, schaal dan niet. Kijk of het lukt om teams onafhankelijk van elkaar te laten werken. Ga pas denken aan een schalingsframework als je echt niet anders kan. Sommige organisaties willen al schalen als de eerste paar mensen enthousiast zijn. Wacht daarmee. Pas als je merkt dat er dingen beginnen te schuren, doe er dan wat aan.

Verder lezen?

Wil je meer weten over dit onderwerp? Download dan ons e-book! Het is een compleet handboek waarin je leert hoe je flexibeler werkt en sneller diensten uitlevert, praktijkvoorbeelden, hoe je jouw meldingenbeheer meer agile maakt en nog veel meer.

Vorige blogpostV