Het is geen geheim dat veel bedrijven onder grote druk staan, in een wereld die razendsnel evolueert. Alles moet snel en sneller, ook software-ontwikkeling. Zo realiseerde het Nederlandse bedrijf Luscii op amper 5 dagen een Corona Check app. Om zo’n resultaat te kunnen bereiken is er een andere manier van werken nodig. Mede daarom maken veel organisaties de stap naar Agile.
De meest voorkomende redenen om Scrum of een andere Agile methodologie te implementeren zijn, volgens het laatste rapport van State of Agile*:
een snellere time-to-market
een verhoogde voorspelbaarheid van oplevering
een lager risico bij de ontwikkeling van de software
Heel wat bedrijven hebben dan ook al één of andere vorm van agile werken geïntroduceerd in hun bedrijf. Meestal voor de ontwikkeling van software, maar meer en meer ook voor andere afdelingen.
De transitie naar agile werken zal een aantal problemen of uitdagingen oplossen maar Agile is helaas geen wondermiddel. Wat de transitie wel zal bewerkstelligen is het blootleggen van de problemen en blokkades in de organisatie.
Ron Jeffries gaf het enkele jaren geleden al aan :”Scrum lost je problemen niet op. Scrum maakt enkel de problemen in je organisatie zichtbaar en je wordt verondersteld om die problemen zelf op te lossen.” Geloven dat de obstakels waar je momenteel tegenaan loopt, zullen verdwijnen is ijdele hoop. Bijvoorbeeld:
Als medewerkers geen verantwoordelijkheid opnemen in de huidige manier van werken, dan zullen ze dat na de Agile transitie niet plots wel doen
Als werknemers hun eerlijke feedback niet durven delen tijdens team meetings en zich niet veilig voelen om zich uit te spreken, dan zal het invoeren van een stand-up of een retrospective weinig veranderen aan die situatie
Als bepaalde personen altijd te laat opdagen voor meetings, dan zal dat niet zomaar veranderen
Als managers geen ruimte laten voor eigen initiatief, dan kan je moeilijk innovatie of verbeteringsvoorstellen van je teamleden verwachten
Transitie? Transformatie? Wat is het verschil?
Als we bovenstaande anders willen omschrijven, dan is Agile voornamelijk een transitie naar een andere manier van werken, waarbij de verwachte uitkomst duidelijk is. Bedrijven willen hun producten sneller op de markt kunnen brengen, een betere kwaliteit aanbieden of beter aansluiten op de wensen van de klanten.
Die duidelijk verwachte uitkomst is een kenmerk van iedere transitie. We gebruiken echter vaak het woord “transformatie” als we het hebben over de verandering naar agile werken. Dit is in mijn ogen niet correct. Bij een transformatie is de gewenste uitkomst niet op voorhand volledig bekend, het resultaat zal zich gaandeweg tonen. Om te weten of een transitie voldoende is, of dat er een transformatie nodig is, moeten we kijken naar de verschillende soorten problemen die we tegenkomen in organisaties
Omgaan met blokkades tijdens een Agile transitie
Wat zijn nu de mogelijkheden om om te gaan met de problemen die naar boven komen?
De problemen die zichtbaar worden door de Agile transitie kunnen zich op drie niveaus bevinden. Hiervoor gebruiken we de metafoor van de ijsberg, met een zichtbaar gedeelte boven water en een (groot) verborgen gedeelte dat zich onder het water bevindt.
Level 1 issues: Vind de juiste "quick fixes"
Level 1 problemen of uitdagingen bevinden zich in het zichtbare gedeelte van de ijsberg, boven de waterlijn. Dit zijn vooral procesmatige uitdagingen: procedures, KPI’s, de velocity van agile teams die problematisch is. Het doel is om de processen zo veel mogelijk te optimaliseren en verstoringen te elimineren. Dit vraagt om een analytische aanpak waarbij meten en weten een cruciale rol spelen.
Een voorbeeld: bij het afsluiten van de sprint blijkt dat er nog heel wat user stories niet afgewerkt zijn. Het team kan tijdens de retrospective onderzoeken wat de mogelijke redenen zijn. De tester kan bijvoorbeeld ziek geweest zijn, of men heeft te veel user stories ingepland of de complexiteit was te laag ingeschat. Het team kan dan voorstellen om tijdens de volgende sprintplanning minder user stories in te plannen en op het einde van de sprint het resultaat van dat verbetervoorstel bekijken. Indien er effectief een verbetering is, wordt de oplossing verder uitgevoerd. Indien niet, dan wordt een andere oplossing gezocht.
Door steeds opnieuw de manier van werken in vraag te stellen en verbeteringen voor te stellen, kan het team of de organisatie steeds performanter werken. De retrospective, één van de scrum events, is erop gericht om op regelmatige basis als team samen te komen om mogelijke verbeteringen te bespreken. Belangrijk is wel om de behapbaarheid van verbeteringen in het oog te houden.
Samengevat: Bij problemen op het eerste, zichtbare niveau gaat het om het vinden van oplossingen voor de concrete uitdagingen van de organisatie of het team. Er is een probleem, met een oorzaak en een gevolg om op te lossen. Methodes die hierbij van pas komen zijn het visgraatdiagram of de 8D-probleemoplosmethode.
Level 2 issues: Zoom uit om de echte oorzaak van het probleem te ontdekken
Net onder de waterlijn vinden we steeds terugkerende problemen, die niet opgelost raken ondanks voorgestelde en uitgevoerde oplossingen. Om deze “Level 2” problemen te bekijken, is het noodzakelijk om het hoofd onder de waterlijn te houden en uit te zoomen om zo die terugkerende problemen te identificeren..
Een voorbeeld van zo’n probleem is de communicatie die stroef blijft lopen tussen teams of individuen, ondanks alle inspanningen of eerdere oplossingen om mensen samen te brengen en te laten praten met elkaar. Als een extra meeting geen soelaas brengt, dan moet er dieper gegraven worden:
Wat is de reden dat de communicatie stroef verloopt?
Wat zorgt ervoor dat teamleden niet voor hun mening uitkomen?
Wat maakt dat het team niet oplevert wat het vooropgestelde doel was?
Bij level 2 gaat het eerder om inzichten dan oplossingen. Vaak zijn de problemen eigenlijk symptomen, die een diepere oorzaak hebben en waarbij de oorzaak geen relationeel verband heeft met het gevolg. Het zichtbaar maken van de belemmerende patronen is al een interventie op zich en deel van de oplossing.
Het doel is om een nieuw perspectief te bieden, naar het probleem kijken met een andere bril om nieuwe informatie te verkrijgen waarmee het team of de organisatie weer verder kan. Level 2 problemen zullen niet vanzelf verdwijnen door eenvoudige oplossingen. Hiervoor moeten patronen, trends en gebeurtenissen die steeds opnieuw voorkomen onder de loep worden genomen. Deze data en inzichten kunnen ons dan helpen om de dieperliggende oorzaken boven water te brengen en duurzame oplossingen te implementeren. Hiervoor moeten we uitzoomen en het probleem bekijken in een bredere context. Uitzoomen kan gebeuren door vragen te stellen als:
Hoe zijn veranderingen in het verleden verlopen?
Welke prijs moet er betaald worden om dit probleem op te lossen?
Wat moet er achtergelaten worden om tot een oplossing te komen?
Level 3 issues: Aanvaard de nood tot een transformatie
Soms zijn er problemen die zich nog dieper onder water bevinden, op het zogenoemde Level 3. Om deze problemen aan te pakken, is een transitie niet voldoende. Er is een transformatie nodig: het loslaten van het huidige denken en open staan voor wat er zich aandient tijdens het proces. De implementatie van een agile framework biedt geen oplossing voor deze dieperliggende uitdagingen.
Een voorbeeld van een beperkend element dat ingebakken zit in het DNA van een organisatie is: “Wat we zelf doen, doen we het best”. Dit kan er voor zorgen dat er geen externe hulp wordt ingeroepen om de agile transitie te begeleiden of dat externe kennis niet voor waarheid wordt aangenomen. Dat kan dan weer voor tunnelvisie zorgen en ervoor zorgen dat een nieuwe manier van werken niet het gewenste effect levert.
Een goede methode om meer inzichten in de verborgen dynamieken te verkrijgen, is het maken van een tijdslijn van het team of de organisatie. Elke deelnemer voegt zijn kernmomenten, die voor hem of haar belangrijk zijn, toe aan de tijdlijn en bespreekt kort de motivatie om het element toe te voegen. Momenten uit het verleden, zoals het ontstaan van de organisatie, de vorming van de teams, speciale gebeurtenissen zoals fusies, maar ook ongevallen, schandalen, ... kunnen een impact hebben op de huidige werking. Een externe facilitator kan via het stellen van de nodige vragen en het leggen van verbanden patronen blootleggen.
Conclusie: Beweeg, experimenteer, evalueer
Een transitie naar een agile manier van werken kan heel wat in beweging zetten. Ik geef nog de volgende key take-aways mee:
Ten eerste, het gaat om een transitie: een traject met een vooraf vastgelegde gewenste uitkomst- bijvoorbeeld die snellere time-to-market, grotere voorspelbaarheid of verlaging van risico’s.Het is geen wondermiddel voor alle problemen.
Ten tweede: Uitdagingen onderweg horen erbij. Een agile transitie gebeurt niet in 3 maanden. Voorzie voldoende tijd voor de overgang en accepteer dat bestaande blokkades zichtbaar worden. Experimenteer en evalueer. Onderzoek op welke niveaus de problemen zich bevinden, zodat je de juiste aanpak kunt gebruiken om ze op te lossen.
En ten slotte: een transitie is niet hetzelfde als een transformatie. Sta open voor een transformatie als dit nodig blijkt, als er problemen op het diepste niveau blijken te zijn. Een transformatie gaat (veel) verder dan een transitie. Er is bij een transformatie geen vooraf duidelijke gewenste uitkomst, het resultaat gaan jullie gaandeweg samen ontdekken.
Wil jij hier meer over weten? Neem snel contact met ons op, zodat we kunnen luisteren naar jouw uitdagingen!
* https://digital.ai/resource-center/analyst-reports/state-of-agile-report/