Een agile training kiezen: Gimme the tools!

Als je op zoek gaat naar een geschikte aanbieder van een (agile) trainingen en workshops, dan let je er  uiteraard op dat de training vooral praktisch is. Je wil veel nieuwe tools aangereikt krijgen. Liefst niet veel theorie. Toch? Nou…dat lijkt wel de impuls van velen, maar is dat eigenlijk wel terecht? Welke balans tussen theorie en praktijk is nou eigenlijk verstandig?

Wij geven veel trainingen en workshops. We zien deelnemers van allerlei pluimage, maar één ding hebben de meesten gemeenschappelijk: een duidelijke voorkeur voor praktijk en tools t.o.v. onderliggende theorie. En dat snappen we ook wel. Je wilt ten slotte het geleerde meteen in de praktijk brengen. Dus uiteraard zijn onze trainingen voor het grootste deel op de praktijk gericht, met heel veel praktijkvoorbeelden, en oefeningen. En tools. Maar toch vinden wij het belangrijk een goede balans aan te brengen tussen praktijk en theorie.

“Gimme the tools!” Dat lijkt het credo als we inventariseren wat de wensen en verwachtingen van de training zijn. Wij framen die verwachting direct bij de start: “Ja, we bieden veel tools. Maar het is cruciaal dat je begrijpt waarom de tools werken, zodat je ze kunt aanpassen aan je eigen lokale context.” Tools zonder begrip zijn trucjes. Niks mis mee op zich. Het probleem is alleen dat trucs alleen werken in stabiele voorspelbare omgevingen. Elke keer als je de truc toepast, krijg je dan hetzelfde resultaat. Fantastisch! Niet meer over nadenken! Helaas bevinden we ons tegenwoordig nauwelijks meer in stabiele voorspelbare omgevingen. En de hele gedachte achter agile werken is juist dat we moeten leren omgaan met niet stabiele, niet voorspelbare omgevingen. Dus heb je geen trukendoos nodig, maar een gereedschapskist. Met de bijbehorende vakkennis om te weten welk gereedschap je waarvoor gebruikt. En waarom…

En daarom besteden we ook ruim aandacht aan de onderliggende principes. Waarom werken de tools nou eigenlijk? En in welke context? Zodat je het gebruik ervan kunt aanpassen op jouw situatie. Zodat je de onderliggende theorie kunt gebruiken om tools te combineren en nieuwe tools te ontdekken. We laten de deelnemers ruimschoots zelf met de materie werken en met elkaar van gedachten wisselen hoe en wanneer iets toe te passen.

Instemmende knikjes als we onze uitleg over balans tussen theorie en praktijk geven. En toch zien we steeds dezelfde sticky notes weer bij de tussentijdse evaluaties: “Nog meer tools graag!” De wens naar praktische tools is diepgeworteld. Zie het als het verschil tussen het volgen van een receptenboek en een chef. Een recept volgen is een trucje. Zolang de omstandigheden hetzelfde blijven, kun je prima scoren met je favoriete gerecht. Maar een chef kun je een setje losse ingrediënten geven, en hij schotelt je een fantastisch nieuw gerecht voor. En dat is wat wij graag willen bereiken met onze workshops: we willen mensen helpen een chef te worden op hun gebied, geen receptenboekvolger.

De wens naar tools is een begrijpelijke. Ook wijzelf betrappen ons er regelmatig op. Maar het is ook een potentiele valkuil waarvan je je bewust moet zijn. Dus de volgende keer dat je je innerlijke stemmetje “Gimme the tools!” hoort roepen, neem dan even gas terug en probeer te beredeneren waarom en wanneer iets werkt en wanneer niet. Spar erover met collega’s. In onze workshops krijg je daar in elk geval volop ruimte voor.

Commentaar op SAFe 4.5: puur cosmetisch?

SAFe 4.5 is pas uitgekomen. Natuurlijk kun je heel veel informatie over wat er nieuw is in SAFe 4.5 vinden bij SAI zelf, dus zal ik niet alles in detail hier behandelen, maar vooral hier en daar wat commentaar geven over het belang en nut van de wijzigingen, of het ontbreken daarvan.

Cosmetische chirurgie is niet altijd slecht

Laat me beginnen met iets dat misschien vooral cosmetisch lijkt, maar voor mij de meest belangrijke verbetering is, namelijk het feit dat de ‘Big Picture’ niet groter of gecompliceerder is geworden deze keer. Van SAFe 3.0 naar 4.0 ging het framework van drie lagen naar vier. In mijn SAFe trainingen grap ik nog steeds dat ik hoop dat SAFe 5.0 straks geen vijf lagen heeft. Ik besteed behoorlijk wat tijd om uit te leggen dat je die extra  Values Stream laag niet moet overwegen tenzij het een heel grote en complexe SAFe implementatie betreft. Natuurlijk is het coördineren van meerdere ARTs in een Value Stream een reële uitdaging. Echter SAFe’s oplossing in de Value Stream laag helt wel erg over naar processen als je even stilstaat bij de Agile Manifesto waarde Individuals and Interactions over Processes and Tools. Wat dat betreft waardeer ik het meest basic coördinatie mechanisme in LeSS erg: Just Talk. We kunnen hier een heel eind mee komen voordat het echt nodig is om formele processen te definiëren. En dit is in feite een valkuil voor veel grotere bureaucratische organisaties die zichzelf in een meer agile organisatie willen omvormen: ze hebben de neiging om alles in processen te modelleren in plaats van mensen te vertellen dat ze ook gewoon met elkaar kunnen gaan overleggen als er iets afgestemd moet worden.

Dus gelukkig is de Big Picture deze keer niet groter geworden. In feite is het een stuk cleaner geworden. De meest significante bijdrage daaraan is de nieuwe configurabiliteit van de Big Picture. SAFe heeft nu vier basis configuraties die elk op een eigen specifieke context zijn gericht. Elke configuratie toont alleen die elementen die relevant zijn voor die configuratie. En hierdoor is de Big Picture een stuk overzichtelijker en makkelijker te begrijpen. De vier configuraties zijn: Essential SAFe, Portfolio SAFe, Large SAFe, en Full SAFe. Een configuratie selecteren en de Big Picture zien aanpassen is eigenlijk best leuk en leerzaam. Ten tweede heeft de Big Picture een make-over gekregen en is daardoor veel minder druk en beter leesbaar. SAI claimt dat ze eigenlijk meer elementen hebben toegevoegd dan weggehaald, dus Kudos aan de visual designer. Ten slotte is de Value Stream laag hernoemd naar Large Solution. Dit lijkt ook weer puur cosmetisch, maar zoals ik al eerder schreef besteed ik veel tijd om mensen uit te leggen dat je niet alles dat op de Big Picture staat moet implementeren alleen maar omdat het erop staat. Door het Large Solution te noemen wordt het denk ik een stuk gemakkelijker te begrijpen dat je een Grote Oplossing alleen nodig hebt bij … een groot probleem.

Nu vraag je je wellicht af waarom ik zoveel aandacht besteed aan cosmetische wijzigingen. De reden hiervoor is dat de ‘compleetheid’ van de Big Picture zowel een zegen is, je kunt immers op alles klikken en een schat aan informatie krijgen, als een vloek. Organisaties hebben de neiging om alles op de Big Picture te implementeren omdat ze denken dat het nodig is. Een cleanere Big Picture kan helpen. Daarbij kan de overvolle Big Picture best overweldigend overkomen en afschrikken in eerste instantie. Maar een andere belangrijke reden is dat het SAFe een makkelijke prooi maakt voor die soms tamelijk luidruchtige groep aan agilisten die, comfortabel vanaf de top van Mount Stupid, naar beneden schreeuwen dat SAFe helemaal niet Agile is, en dat terwijl hun ervaring ermee over het algemeen niet veel verder rijkt dan het bekijken van de Big Picture op scaledagileframework.com. Ja, natuurlijk zou ik ze gewoon kunnen negeren, maar helaas hebben deze lui de neiging hun verhalen ook aan klanten te vertellen. Als je nog nooit van Mount Stupid, ook wel het Dunning-Kruger effect genoemd, hebt gehoord, dat is het fenomeen waarbij die mensen die het minst van een onderwerp afweten zich het meest comfortabel schijnen te voelen om hun mening erover te verkondigen. Klinkt bekend?

Lean Startup

Natuurlijk zijn er ook meer substantiele wijzigingen. Maar daar kun je alle details over lezen op de SAFe website.

Een ervan is de integratie van Lean Startup. Een zeer welkome aanvulling, dat zeker, maar om eerlijk te zijn was er natuurlijk in SAFe 4.0 al niets dat je in de weg stond om Lean Startup praktijken te gebruiken binnen SAFe. Ik promoot al vanaf het begin dat alles een hypothese behoort te zijn die we zo snel mogelijk moeten zien te valideren. Ik heb organisaties ook Alexander Osterwalder’s Business Model canvas en Value Proposition design zien gebruiken binnen SAFe; of Ash Maurya’s Lean Canvas. We hoeven het daarvoor niet per se op de Big Picture te hebben staan. Maar de adviezen zijn natuurlijk erg welkom.

Andere wijzigingen

De rol van DevOps neemt steeds meer toe in SAFe en dat is iets goeds. Veel meer dan dat kan ik er niet over zeggen. Continuous Delivery wordt ook meer benadrukt en krijgt wat meer substantie. Mooi, maar we wisten natuurlijk allemaal al lang dat we Continuous Delivery zeer serieus moeten nemen in elke (geschaalde) Agile omgeving.

Nu weten we ook allemaal dat delivery en release niet hetzelfde zijn, maar wel aan elkaar gerelateerd. Je wil op elk moment kunnen ‘deliveren’, maar niet per se tegelijkertijd ‘releasen’. Er is een enigszins opmerkelijke wijziging in 4.5 als het gaat om releasen: het ging van Release on Demand (v3.0) naar Release Anytime (4.0), en nu weer terug naar Release on Demand in v4.5. Make up your minds guys. 😉

Wat nog meer? De The Implementation Roadmap is er, maar eerlijkheid biedt te zeggen dat die al geruime tijd voor 4.5 uitgekomen is. De Implementation Roadmap is overigens wel een flink stap vooruit ten opzicht van het belachelijke 123 model dat van de Big Picture lijkt te zijn afgevallen. Gelukkig maar. De roadmap biedt veel nuttige informatie maar er blijft een belangrijk mankement: het is nog steeds min of meer een lineair proces. Ik hecht er sterk aan dat een veranderproces ook iteratief moet zijn, gebaseerd op experimenten, en korte feedbackloops. Ik kan je aanbevelen om te kijken naar Lean Change Management en dit te combineren met de Implementation Roadmap.

Conclusie

Dus, ondanks dat er veel nuttige toevoegingen en wijzigingen in SAFe 4.5 zitten, kunnen de meest belangrijke wijzigingen op het eerste gezicht puur cosmetisch lijken. Ik denk dat deze wijzigingen echter erg belangrijk zijn om te helpen voorkomen dat organisaties in een aantal geniepige valkuilen stappen.
[/av_textblock]