Zonder twijfel is SCRUM een van de meest gebruikte raamwerken door organisaties die agile willen worden. Wanneer de organisatie uit veel verschillende teams bestaat, is er de noodzaak om te schalen. Ook daar zijn weer verschillende raamwerken, zoals bijvoorbeeld SAFe of LeSS. Hoewel de bedoeling oprecht agile kan zijn, zijn er verschillende redenen waarom deze agile strategie niet zal werken. Er zitten namelijk een aantal ernstige weeffouten in de genoemde raamwerken die een duurzame wendbaarheid in de weg zitten.
Er is, en wanneer je de historie van deze raamwerken neemt niet verassend, een sterke focus op klantwaarde. Maar hoe deze bepaald wordt, is sterk de vraag. Agile in algemene zin en SCRUM in het bijzonder is populair geworden in de software ontwikkelingsindustrie. Nu heeft de IT niet echt wat je zegt een goed trackrecord waar het succesvolle projecten betreft. Een belangrijk deel van de projecten leverde niet precies die kwaliteit die men verwachtte, duurde langer en overschreed het budget. Door te time-boxen en het continu in korte cycli ontwikkelen waar de meeste klantwaarde voor is, hebben de raamwerken dit probleem slechts gedeeltelijk opgelost. Ik ben me bewust dat ik SCUM nu tekort doe, dus denk de ceremonies en artefacten er zelf maar bij.
Ik betwijfel of dit nu wel echt Agile met een grote A is? Slechts ten dele, want de teams die software ontwikkelen, doen dat voor de organisatie waar zij een deel van zijn. Het gevaar is zeer groot aanwezig dat dit toch zeer intern gericht is. We hebben de IT afdeling die maakt (supply) en de businessafdelingen die bepalen wat zij nodig hebben (demand). Maar waar is de echte klant? Waar is de invloed van de omgeving en wat nu wanneer de overall organisatistructuur een rigide hark is, meer gedreven door top-down machtspelletjes. Kan je dat nog wel agile noemen? Neen, dat kan je niet. Maar laten we eerlijk zijn, als alle teams en afdelingen scrummen dan is de structuur nog zeer rigide. Als je goed kijkt zie je de hark wel degelijk in een schalingsmodel zoals SAFe. Kortom een agile omgeving, vergeet het maar.
Wat is Agile met een grote A? Een organisatie die zich aanpast aan veranderingen in zowel de omgeving als in de behoeften van haar klanten (of afnemers van diensten). Dat betekent dus dat echt Agile werken ook een zichzelf doorlopend vernieuwende verzameling van mensen is. De aanpassingen zijn dan zowel in continue verbetering van producten en diensten, als in de wijze van werken en besturen. Teams onstaan en lossen op wanneer dat nodig is. Hetzelfde voor de rollen en verantwoordelijkheden, die komen en die gaan. De genoemde raamwerken, beschrijven veel te veel structuur en hinderen daardoor het aanpassingsvermogen van de organisatie zelf. Dat laatste is helemaal niet Agile!
Maar hoe worden we dan Agile wanneer SCRUM ons daartoe belemmert? Dat is niet eenvoudig , maar laat ik in het kort een schets geven naar een mogelijke aanpak. Ook wil ik je de reeks blogs over Agile met een grote A, die ik onlangs schreef aanbevelen. Waar begin je mee? Elk onderdeel van een organisatie heeft een reden van bestaan, dat is haar missie! Wat is de toekomst die je wilt realiseren, dat is je visie. Iets concreter wordt het doel, waar gaan we naar streven. Dat vertaal je naar subdoelen. Rond de doelen creeer je teams, tussen de teams creeer je terugkoppellussen. De teams werken empirisch wat wil zeggen dat ze volharden in hun aanpak wanneer het werkt en draaien wanneer niet. Als het doel verandert, dan ook het team. Als het doel bereikt is, lost het team op en gaan de mensen wat anders doen. Besluiten nemen we in consent (we doen iets als niemand een gegrond bezwaar heeft). Naast dat we steeds leveren waar de omgeving op zit te wachten, veranderen we de organisatiestructuur op een organische manier zodat deze steeds aansluiting vindt.
Dat mijn beste lezer, dat is Agile met een grote A. Iets anders dan SCRUM dus!