artikel

Pas op de valkuilen van agile werken

Organisatie & Strategie

Agile, de flexibele manier van werken die zich steeds opnieuw richt naar de klant, ligt onder vuur. En nog wel van de mensen die het bedacht hebben: softwareprogrammeurs. Welke valkuilen kent agile en hoe ga je daar omheen?

Pas op de valkuilen van agile werken

Agile komt (net als scrum) uit de IT-hoek. Softwareontwikkelaars bedachten de techniek om software sneller aan te passen op wensen en eisen van klanten en markten. Iedereen die ooit iets in de IT heeft gedaan, weet dat die wensen steeds sneller veranderen en steeds onvoorspelbaarder worden. Nieuwe software lineair ontwikkelen, waarbij je eerst de vereisten opstelt en dan het product (de app) maakt volgens die specs, betekent dat het product hopeloos verouderd is zodra het op de markt komt. De klassieke bezwaren zijn: het komt te laat, het is drie keer zo duur als begroot en het kan twee keer zo weinig dan verwacht.

Klikt prachtig

Door agile te werken kan een organisatie sneller en beter inspelen op veranderende omstandigheden. Vaak vertaald als flexibel, en het geldt als ideaal voor professionals, teams, organisaties en zelfs branches. En het klinkt ook erg prachtig: iedereen past zich op tijd aan op de omstandigheden, vlak voordat ze veranderen in de richting die jij al zag aankomen.

Fout vanaf het begin

Maar juist de mensen die als eerste agile gingen werken, de softwareontwikkelaars, krijgen steeds vaker een vieze smaak in hun mond als ze het woord horen. Ze vinden dat agile niet meer hun eigen manier van werken is. Het gaat meestal vanaf het begin al fout. Het management benoemt een project manager of scrum master van buiten de eigen afdeling of zelfs afkomstig buiten het eigen bedrijf. Hierdoor ontstaat al direct een kloof tussen “wij” en “hij”.

Meewerkend voorman

Een van de principes van agile, de meewerkend voorman, wordt dan geschonden. In plaats van controleren en opdrachten stipuleren moet de manager heel dicht op het proces zitten, om voortdurend te herijken of de specs nog wel goed aansluiten op de omstandigheden die de ontwikkelteams onderling steeds opnieuw definiëren. Daarover moet dan snel een besluit worden genomen, vaak over iets dat onvoorzien was bij de start van het project.

Veilige omgeving

Bovendien moet het in een veilige omgeving gebeuren, waarin mogelijke veranderingen bediscussieerd kunnen worden zonder gevaar op ‘afbranden’. En dat gebeurt steeds vaker in de dagelijkse meetings en team-ups. De manager of master rekent de specialisten af op de mate waarin ze van tevoren bepaalde doelen hebben behaald. Is dat niet voldoende, dan krijgen de werkers daar een preek over. Vervolgens gaat men maar weer snel aan het werk om regelmatig met ‘iets’ nieuws te kunnen komen. Ook als dat ‘iets’ niet goed is getest en kwalitatief onvoldoende is. Bovendien moet het steeds vaker in een keer goed. Er is gewoon geen tijd om het werk nog eens na te lopen, of je goed in te lezen voordat je het halfproduct (code bij softwareontwikkelaars) moet opleveren. De gevolgen van dit ‘klassiek managen’ laten zich raden.

Fijnslijpen maakt bot

Maar het kan ook aan het team en de teamleden zelf liggen als agile niet goed werkt. Het traditionele team bestaat uit specialisten en perfectionisten, zeker in de IT. Zij zijn gewend om op de gestelde tijd een duidelijk gedefinieerd eindresultaat op te leveren dat (meer dan) voldoet aan alle specificaties. Tussentijdse wijzigingen, aanvullende wensen en veranderende omstandigheden worden daarbij consequent genegeerd, want anders ‘komt het niet af’. Bij agile gaat het juist om tussentijdse aanpassingen. Maar teveel slijpen maakt elk instrument bot.

De juiste verhoudingen

Het gaat bij agile dus om de juiste verhouding tussen de onderdelen zelf, en om de relatie met de klant. Daarvoor is overleg noodzakelijk. Daarvoor zijn die team ups, scrums en andere tussentijdse meetings. Als key users en specialisten bereid zijn om te leren van elkaars manier van werken, daarbij geholpen door een training gesprekstechnieken, dan onstaat een eindresultaat dat beter aansluit bij het doel van het project. Ook al is dat misschien duidelijk anders dan oorspronkelijk geformuleerd, en zijn de kosten opgelopen door ‘halffabrikaat’ dat geschrapt moest worden. Dat is even wennen en even slikken voor de meeste ‘klassieke’ managers. Bij agile hebben de makers de controle over het eindresultaat, samen met de klant. Als die tevreden is, is het doel bereikt.

7 Tips vanuit de agile praktijk

  • De teamleden benoemen een ‘meewerkend voorman’ uit de eigen gelederen. Geen externen. Iedereen voert ook uit.
  • Ideaal is als ook iemand van de klant / opdrachtgever meewerkt. Maar dan ook echt ‘meewerkt’, niet alleen toezien.
  • Bespreek de vorderingen vaak en kort, maar alleen onderling.
  • Speel niet op de man, bespreek het proces, de manier van werken.
  • Als het ‘werkt’ of goed genoeg is voor de rest van het project, dan is het af.
  • Breng de uitkomsten van elke bespreking direct in praktijk, bespreek de resultaten snel daarna, ga dan verder met de volgende stap.
  • Pas wanneer er resultaten zijn die echt voordeel opleveren voor de (eind)klant, licht je het senior management in.

Het perfecte agile team

Het meest waardevolle agile team bestaat niet uit louter toppers. Dat stelde senior softwareontwikkelaar David Akka vorig jaar al. Een team dat goed kan samenwerken richting het resultaat waar de klant of opdrachtgever het meeste aan heeft is het meest agile. Daarvoor moet de klant zelf wel betrokken blijven bij het hele proces. Misschien is dat wel waar het echt om draait van agile werken.

Reageer op dit artikel