De Agile Swing
Agile: rozengeur en maneschijn?
In de knel
Agile in de echte wereld
Tegengeluid
Nog meer vormen van de Agile Blues – en wat er aan te doen
Het geval 'Andre Keijzer' is volgens mij slechts het topje van de ijsberg. De afgelopen periode sprak ik Agile coaches die in een vakmatige spagaat leken te staan: als onstopbare facilitator zendelingswerk moeten verrichten voor het adopteren van de Agile mindset, maar tegelijkertijd begrip tonen voor professionals in Agile teams, die het nieuwe organiseren ervaren als te haastig en te korte termijn gericht. Met een Product owner in een grote en toonaangevende Agile organisatie sprak ik over zijn rol, die regelmatig overruled werd door andere stakeholders maar waarbij pogingen om dit te stoppen als inflexibel en control-freakish (en zeker on-Agile) gedrag werden afgedaan. PO or Puppet?
Wil je als organisatie 'Agile implementatie impediments' aanpakken, dan moeten deze obstakels allereerst bespreekbaar worden. Daar zijn trouwens allerlei creatieve werkvormen voor (zie ook de eerdere blogpost over Agile: cowboys en broodtrommels in de corporate wereld en de onderstroom in teams). Daarmee krijg je zicht op de bezwaren en -nog waardevoller- het achterliggende professionele commitment.
Zie jij ook de Agile Blues om je heen?
Beste Jervis,
Allereerst hartstikke fijn dat je geïnspireerd bent door het verhaal van André Keijzer. Zoals ik in mijn boek ook aangeef, het verhaal van André staat niet op zichzelf en er meerdere mensen zoals hij en meerdere verhalen van mensen bij wie Agile niet helemaal past. Dit ligt niet altijd aan de persoon, soms ook aan de wijze waarop agile wordt geïmplementeerd. Ikzelf ben wel fan van het agile werken en heb bij veel organisaties gezien dat het zijn vruchten oplevert. Maar merk ook dat bij sommige teams de samenwerking moeilijk is. Samen in een ruimte vanuit dezelfde backlog betekend nog niet dat je aan het samenwerken bent. Bij andere teams is het feedback leveren een uitdaging. In de retro worden wel zaken genoemd, maar het echt elkaar aanspreken is en blijft moeilijk. Maar, dit is van alle tijden en heeft misschien niet eens met agile te maken, misschien meer met cultuur. Echt samen voor een doel gaan, en jezelf wegcijferen voor het teamresultaat is moeilijk.
Niet iedereen staat open voor feedback op het persoonlijke vlak. Dus daar waar we bij succesvolle implementaties rekening moeten houden met medewerkers als André, en het een taak is voor team, scrum master en agile coach om deze medewerkers in hun kracht te zetten. Moeten we ook rekening houden met teamleden die niet direct het nut zien het benoemen van de onderstroom. Een uitdaging voor de agile coach die het team wil helpen een effectieve agile werkwijze te vinden en rekening moet houden met de individuen. Die de leermomenten kan laten ontstaan zodat het team gaande weg vanzelf het nut en noodzaak ziet. Gelukkig heb ik ook succesvolle teams gezien waarbij dit helemaal geen issue was en die gewoon het agile gedachtengoed omarmen en lekker aan het werk zijn.
Hi Derk-Jan, helemaal herkenbaar en ik ben ook een groot voorstander van Agile werken 🙂
Naast de factoren die je noemt op het persoonlijk vlak (open staan voor feedback, jezelf wegcijferen voor het teamresultaat, etc) zie ik in organisaties ook andere ‘bottlenecks’ – op het vlak van governance (mn de vaardigheid én de behoefte om het overrulen van teamprioriteiten op een volwassen manier uit te leggen) en verschillende percepties op kwaliteitsbeheersing (korte termijn keuzes durven maken binnen het commitment om lange termijn kwaliteit te blijven handhaven). Daar spelen niet alleen de Agile mindset van ‘starre’ professionals als André een rol, maar ook de communicatieve vaardigheden en geloofwaardigheid van architecten, portfolio-boards en andere team-overstijgende disciplines. Herkenbaar?
Groet, Jervis
Een verfrissend geluid! Kritiek op de hype? Dan ben je een dinosaurus en gedoemd uit te sterven…of uitgestoten te worden. Elke keer weer is het verhaal: als het niet goed lukt met Agile te werken dan is het gewoon niet goed geïmplementeerd. Tsja. Agile werken is geen implementatie. Agile werken is een cultuurverandering. En die implementeer je niet. Die vormt zich.
Ik voeg graag wat Blues toe aan de discussie. Reakties zijn natuurlijk welkom…..
Het grootste bezwaar dat ik tegen het tegen-de-klippen-op-persé-met-Agile-werken heb, is gelegen in de volgende elementen die met het ambacht van goed IT-werk en opdrachtgeverschap te maken hebben. Indien je die niet tackled kun je de cultuurverandering ook niet bereiken: je hebt immers wel de competenties en aanpak nodig om het goed te kunnen doen.
– Agile leidt in het algemeen in de uitwerking (Technisch ontwerp en realisatie) tot veel kleine componenten / objecten / services. Dit betekent een enorme foutenkans en bemoeilijkt het foutzoeken. Door het hoge aantal iteraties neemt ook het rework aan al die componenten toe. Dit komt de code en dus betrouwbaarheid en het uiteindelijke beheer niet ten goede. En overigens lijdt ook de voortgang van iteraties hieronder.
– Technisch ontwerpen heeft niet meer de focus. Er is een use-case en dat werken we even uit. Met als gevolg: in technische zin slecht ontworpen systemen. Dit is een al decennia teruglopende competentie omdat geheugen- en rekencapaciteit niet meer het probleem is (maar waarom treden er dan zo vaak memory-leaks op en klapt je applicatie eruit of wordt het systeem onverwacht traag?). “Vroeger” moest je wel zuinig doen met deze resources omdat ze heel duur waren.
– Er is veelal geen ontwerp vanuit het grote – functionele en datamodel-technische – geheel en bij de ontwerpers/bouwers geen zicht op dat geheel. Hele stukken code worden opnieuw gebouwd (maar dat is juist goed en hartstikke Agile hoor ik de adepten al roepen) omdat bij de volgende iteraties blijkt dat er toch nog wel andere functionaliteiten en koppelingen in moeten zitten waar bij de eerdere iteraties nog geen rekening is gehouden (want we maken alleen wat nodig is hoor en dat is hartstikke Agile!)
Als het niet opnieuw wordt gedaan treedt het pindarotsjes-effect op: de code wordt uitgebreid met allerlei plukjes extra code die er eigenlijk niet horen en als je een goed ontwerp had gemaakt beter ergens anders zouden passen. En een beheerprobleem is geen Agile-probleem, toch?
– Goed opdrachtgeverschap is in veel IT-projecten een issue. De rol van Product Owner is in Agile al beter dan gemiddeld (een business-mens yes!) maar het gaat ook nu weer om de invulling en: heeft de PO het formele (en informele!) mandaat echt gekregen? Vaak wordt een PO nog in de wielen gereden want politiek haal je niet uit de organisatie met Agile.
Mijn conclusie na vele Agile-teams in werking te hebben gezien: de basiscompetenties om tot een goed systeemontwerp te komen en het PO-schap in te vullen zijn in de gemiddelde organisatie in onvoldoende mate aanwezig. Ook bij de ingehuurde externen. (Ja dat zal me ook niet in dank worden afgenomen natuurlijk!) Begin dan niet aan Agile. Als je Agile goed wilt doen heb je hele goede, zelfkritische en taakvolwassen mensen nodig zowel in het IT-team als aan de business-kant.
Kies dus de aanpak en methode die past bij de (status en ontwikkeling van de) organisatie, dan is de succeskant het grootst. En blijkt dat Agile te zijn? Good for you!
Hi Edwin,
Dank voor de in-depth uitwerking van de Agile Blues. De pindarotsjes-metafoor is verrassend en klinkt smaakvol 🙂
De vraag is of je als organisatie moet/kan wachten op ‘hele goede, zelfkritische en taakvolwassen mensen’. Ik denk het niet, maar ik mis in een aantal organisaties die met Agile zijn gaan werken wel de kritische aansturing op het zsm bereiken van die kwaliteiten in de bemensing. Als het al op de prioriteitenlijst staat zie ik weinig consequente monitoring van deze succesfactor voor Agile. Maar mijn blikveld is natuurlijk ook maar beperkt; benieuwd naar ervaringen van anderen.
Jervis,
Ik heb inmiddels in verschillende organisaties kennis gemaakt met “agile” werken. Overall zie ik veel enthousiasme, echter er zijn veel mensen, die moeite hebben met deze open manier van samenwerken. In het verleden toen agile werken nog onder de noemer “kwaliteit” werken, zelfsturende teams werd gebracht, zag je exact dezelfde problemen, die net zo hard onderdrukt werden als nu. Het heeft veel te maken met karakters van mensen en de wil en bereidheid, maar vooral ook het vermogen om te veranderen. Ervaring leert dat wanneer ook deze hype uitgewoed is, er weer ruimte en aandacht komt voor de downside en er een correctie gaat plaats vinden. Te hopen is dat deze tegenstribbelende mensen nog aanwezig zijn en niet met een burn-out of ontslagen thuis zitten. Goed om hier aandacht voor te vragen en het bespreekbaar te maken, juist van de coaches, maar ook de project managers zou je dit mogen verwachten, maar ook zij hebben te maken met de druk van de omgeving.
Bernard Juffermans
Bernard,
Het risico van een hype ligt natuurlijk op de loer en het zelfregulerend vermogen zal ook hier gaan werken. Interessante vraag is of het hier gaat om ‘tegenstribbelen’ of dat mannen als André (uit Derk-Jan’s boek) gewoon een terecht punt van kritiek hebben. Volgens mij is Agile trouwens een meer fundamentele paradigma-shift (om dat begrip maar weer eens te gebruiken) dan TQM en zo, en ook nog eens marketing technisch zwaar ingezet (dus Durf maar eens NEE te zeggen tegen Agile).
Hi Jervis
ik ben met je eens dat wachten niet een goede optie is, maar geforceerd Agile invoeren is dat m.i. ook niet. Daarom pleitte ik voor een aanpak en methode die passend is. Wellicht kun je iets als projectmatig creëeren een eerste stap maken. Die methode versterkt (persoonlijke) betrokkenheid.
Je constatering dat consequente monitoring op de persoons-kant ontbreekt is denk ik correct. Maar versterkt mijn gevoel dat men Agile denkt te kunnen gebruiken om de stap te maken maar dan schrikt van resultaten en vooral de consequenties van doorpakken. En het dan op zijn beloop laat. Gemiste kansen…..
Mooie en voor mij zeer herkenbare discussie over dit steeds belangrijker wordende onderwerp. Eigenlijk zou ik het statement in de titel nog wat sterker willen maken: “Zeg maar NEE tegen Agile”. Dat creëert mijns inziens meer openingen dan maar geforceerd en tegen beter weten in Agile te blijven pushen vanuit het operationele (scrum) niveau. Dat NEE zeggen begint dus ook in de teams. Teams moeten volwassen en professioneel genoeg zijn om lef te tonen door NEE te zeggen. Dat gebeurt naar mijn ervaring nog veel te weinig. Dan krijg je onherroepelijk de situatie dat teams gedwongen worden meer te presteren dan ze kunnen omdat ze teveel impliciete risico’s op hun bord krijgen die door de niveau’s boven de teams zijn ‘weggemanaged’ (eigenlijk: ontkend). Dat leidt maar al te vaak tot de situatie dat het team de schuld krijgt van zaken waar ze niets aan kunnen doen en waarmee management een stok krijgt om mee te slaan en zichzelf hiermee uit de wind kunnen houden. Het gaat er dus om dat je op alle niveau’s in een organisatie de cultuurverandering en mindset change in gang zet om verantwoordelijkheid te nemen, kwetsbaar te zijn, transparant te zijn. Door NEE te zeggen, maak je duidelijk dat iets nog niet kan of nog niet werkt, niet om het niet te willen doen, maar om een signaal af te geven dat er veranderingen moeten worden ingezet die over het algemeen niet voor de hand liggen en daardoor niet op de aandachtspunten of eisen en wensenlijst staan.
Hi Ben, krachtig beroep op de assertiviteit van teams. Welke veranderingen denk je aan als je zegt “…om een signaal af te geven dat er veranderingen moeten worden ingezet die over het algemeen niet voor de hand liggen…”?
Hi Ben,
Even een snelle primaire reactie. Als de teams goed in staat zijn om nee te zeggen, zijn dit niet juist ook de teams die in staat zijn om een succes van agile te maken. Dit zijn de teams die een Scrum proces kunnen aanpassen aan hun eigen behoefte, een duidelijke bewaking hebben op welke items ze in de sprint opnemen en ook nee durven te zeggen tegen de PO als de sprint vol zit. Een team dat nee durft te zeggen en kan onderbouwen waarom ze nee zegt, weet waarmee het bezig is. Het probleem zit hem misschien meer in minder volwassen teams, die geen nee kunnen of durven te zeggen. Die lopen meer het risico om verstrikt te raken in een van boven-af opgelegde werkwijze die niet past bij de missie en de aard van het team.