Agile is slecht voor ontwikkelaars, zegt Agile-vader

Organisaties misbruiken het 'agile'-label om ontwikkelaars aan te zetten om meer code sneller te kloppen dan redelijkerwijs mogelijk is, vat ZDNet de blog van Jeffries samen. Agile is big business geworden, concludeert Jeffries. "Er zijn honderden, zo niet duizenden zogenaamde 'agile'-coaches en -trainers en afgeleide frameworks en methodes die soms conflicteren met de grondgedachte. Zo zijn er agile leadership trainingen en aanbiedingen voor agile project management."

Organisaties varen doorgaans wel bij deze aanpak. Elke organisatie die probeert te vernieuwen, verbetert vaak ook wel. Maar ontwikkelaars zijn het kind van de rekening bij organisaties die het 'agile'-gedachtegoed verkeerd toepassen. Er is dan namelijk meer bemoeienis met de ontwikkelteams, er is minder tijd om het werk af te ronden en er is hoge druk om sneller met resultaten te komen. "Dat is slecht voor ontwikkelaars en uiteindelijk ook slecht voor de organisatie", zegt Jeffries. Hierdoor ontstaan meer fouten en gaat uiteindelijk het proces trager dan mogelijk was geweest. Bijkomend schadelijk gevolg is dat goede ontwikkelaars bij dergelijke organisaties vertrekken.

Scrum sucks

Jeffries hoort veel ontwikkelaars klagen over agile, of liever gezegd over de Scrum-werkwijze, want daarmee vullen veel organisaties de agile-methodiek in praktijk in. Vaak komt het er op neer dat de organisaties niet doen wat de opstellers van het Agile Manifesto of de Scrum-werkwijze hebben geadviseerd.

Hij steekt de getergde ontwikkelaars een hart onder de riem: zet een punt achter alle methoden die refereren aan 'agile'. Richt in plaats daarvan je aandacht en trainingsinspanningen op alle softwareontwikkelingsmethoden die vallen binnen de fundamentele principes van Agile Software Development-methodieken. Die somt Jeffries nog maar eens op:

• Produceer werkende, geteste en geïntegreerde software, elke twee weken. Werk aan je vaardigheden zodat je elke dag een nieuwe volledig operationele versie kan opleveren; elke dag, of twee keer per dag of zelfs meerdere keren per dag.
• Houd het ontwerp van de software 'schoon'. Naarmate de toepassing groeit, heeft het ontwerp de neiging onnodig complex te worden. Voorkom dit en keer de trend consciëntieus zodat je voortgang zo regelmatig en consistent mogelijk is.
• Gebruik alleen huidige versie van software als basis voor alle conversaties met het productmanagement en leidinggevenden. Spreek met hen in termen van wat er klaar is en wat zij graag zouden willen dat je het eerst oppakt.

Elke dag deadline

Volgens Jeffries is het belangrijk dat elke dag de deadline is. Door elke dag functionele software te leveren, kan er ook elke dag worden geïmplementeerd met het best mogelijke resultaat. Door je te richten op de huidige versie van de software, en de conversatie te richten op wat er in de volgende stap moet worden opgepakt, voorkom je de oeverloze discussie over de oneindige lijst met wensen van het management. Het is niet altijd gemakkelijk om te schakelen van 'doe dit allemaal' naar 'doe als eerste dit', waarschuwt Jeffries, maar het is de beste manier om het leven aangenaam te houden.