De weerstand tegen Agile
In mijn werk als trainer en coach voor agile werkwijzen kom ik veel organisaties tegen die de transitie van klassiek waterval naar een agile werkwijze hebben ingezet. Maar wat mij telkens weer opvalt is de (initiële) weerstand van management en project managers tegen deze meer efficiënte werkwijze. Dit komt vaak voort uit een gevoel van gemis aan controle. Het zou niet voorspelbaar zijn, en men heeft het over een variabele scope! Vaak hoor ik de uitspraak: ‘Ik heb geen zin om een Cart Blanche te geven aan dat project!’. Hebben zij nu gelijk of ongelijk?
Ja, ze hebben gelijk!
Ik wordt als coach vaak ingeroepen om een Scrum team te coachen dat bijvoorbeeld al een jaar bezig is. De klacht van management is dan dat het team niet productief is en niet voorspelbaar. Wat dan vaak blijkt is dat het team inderdaad niet voorspelbaar is. Zij passen wel wat elementen van Scrum toe, maar juist de meest essentiële niet! Sommige elementen die maken dat een team voorspelbaar wordt zegt de Scrum theorie ook niets over. Dat zijn gewoon best practices die over de hele wereld aanvullend zijn opgedaan. Het vergt dus goede coaching vanaf de start door ervaren professionals om beginnende teams op het goede pad te krijgen. Anders gaat de geloofwaardigheid van de Agile belofte er snel vanaf!
Ik mis dan vaak drie belangrijke elementen waardoor het potentiële rendement dat met Scrum gehaald kan worden, absoluut niet wordt gerealiseerd:
- Het team meet haar productiviteit niet.
- Het team werkt niet bewust met technisch risico.
- Het team verbetert zichzelf niet elke sprint.
De reden dat dit vaak wordt nagelaten is een gebrek aan discipline. Dat is het grootste nadeel van werken op een iteratieve manier; het kost veel meer discipline dan men gewend is!
Nee, ze hebben geen gelijk!
Het kan dus in de meeste gevallen anders. Met meer discipline en toepassing van de juiste best practices kunnen Scrum teams wél voorspelbaar worden. Willen beginnende teams zo snel mogelijk management overtuigen van de voordelen van de agile werkwijze, dan dienen zij de volgende drie zaken vanaf het begin op te pakken:
- Toekennen van story points aan de backlog items, bijvoorbeeld met planning poker. Hiermee kan de productiviteit (velocity) worden gemeten;
- Bewust omgaan met technische risico’s. De grootste technische risico’s als eerste beslechten door werkende software te bouwen;
- Verbeterpunten die in de retrospective worden genoemd, ook daadwerkelijk direct omzetten in verbetertaken of acties per sprint.
Een Scrum team dat deze principes toepast kan binnen een half jaar voorspelbaar worden, en vanaf dat moment gaan werken aan aantoonbare verbetering van de productiviteit! Dat eerste halve jaar is dan wel even doorbijten voor het management.
Risico gedreven werken geeft het voordeel van de wet van Böhm
Ik hoor veel argumenten waarom men een agile werkwijze maar niets vindt, en men niet krijgt wat men wil, of het juist langer zou duren:
- ‘Agile werkt met een variabele scope en schuift stories voor zich uit als deze in een sprint niet worden gehaald. Stories aan het einde van de release kunnen er hierdoor afvallen, dan heb ik niet de scope die ik wilde!
- ‘Ik moet elke sprint repetitieve taken uitvoeren, dat is veel meer overhead!’
- 'Al die planning sessies en review en retrospective sessies kosten veel meer overlegtijd!'
- 'Al dat werk aan requirements van tevoren en het creëren van een backlog kost veel tijd!'
- 'Elke sprint weer testen kost veel meer testinspanning!'
- 'Het realiseren van kleine (deel) oplossingen, en het completeren ervan in een volgende sprint, levert een toenemende kans op dat ik nieuwe fouten creëer in code die al in de vorige sprint was gerealiseerd!'
- 'Het inleren van een nieuwe werkwijze kost teveel tijd voor dit belangrijke project, we willen op tijd opleveren, dus nemen we geen extra risico en doen het op onze bestaande werkwijze!'
Wat deze mensen niet weten is dat door goed risicogedreven te werken je de wet van Böhm activeert. Deze wet zegt: Hoe later in een project je fouten vindt, hoe exponentieel duurder het is om ze op te lossen’. Door nu actief goed met requirements te werken, en de grootste technische risico’s eerst te elimineren door het bouwen van werkende software, activeer je deze wet omgekeerd, en bespaar je exponentieel veel kosten!
Mijn stelling is dan ook altijd: bij een goed lopend agile team dat voorspelbaar is en risicogedreven werkt, krijg je doorgaans tweemaal zoveel functionaliteit opgeleverd als met een watervalmethode!
Wil je meer weten over hoe je het meeste rendement haalt uit agile werkwijzen? Neem dan contact op.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile of lees hier meer Agile gerelateerde blogs.