Category Archives: Bitching

In de IT wordt Agile en Scrum vaak toegepast. Helaas wordt het in veel gevallen misbruikt om een ander doel te behalen. In deze categorie schrijf ik wat er naar mijn mening mis is met deze processen.

Agile is een geloof aan het worden

Zoals ik in mijn blog post over perspectieven zeg, zijn er geen echte waarheden, maar alleen perspectieven. Geloof is een perspectief voor de mensen die hierin geloven. Deze groep zal dit zien als hun ‘waarheid’.

Als Agile Test Coach binnen de IT, werk ik veel met Agile. Maar sinds een paar jaar begin ik me zorgen te maken over Agile werken. Het begon als een inspirerende visie om op de juiste manier software te maken. Maar het lijkt erop dat ieder jaar Agile meer en meer wordt gezien als de ‘waarheid’. Regelmatig vertelt een collega of manager mij dat wij een bepaalde techniek of methode moeten hanteren, omdat dit ‘Agile’ is…

Maar… maar… Wat is ‘Agile’ nou voor argument? Dat is ongeveer hetzelfde als zeggen dat wij nu allemaal kaas moeten eten, omdat kaas!

En toch doen steeds meer mensen dit. Steeds meer mensen gebruiken Agile als een waarheid hoe wij moeten werken, zonder ons af te vragen waarom? En toen besefte ik het me…

Agile begint een geloof te worden

Agile begint steeds meer karakteristieken te vertonen van een geloof. Aanhangers van Agile voelen zich persoonlijk aangevallen als jij ze vraagt wat de toegevoegde waarde is van het SAFe framework. Medewerkers en managers voeren nieuwe methodes en technieken in, omdat ze ‘Agile’ zijn. Wat zelfs in tegenstrijd is met de values van Agile…

Ik hou van Agile. Met heel mijn hart. Maar de gedachte dat Agile een geloof wordt, breekt mijn hart.

Laten we gewoon weer eens gaan nadenken. En doordachte keuzes maken. In plaats van alles maar doen omdat Agile.

Waarom zijn wij een marathon aan het sprinten?

Enkele jaren geleden had ik een discussie met een collega over Scrum. Scrum is een framework om software op te leveren. Zelf ben ik een groot voorstander, maar hij kwam wel met een ongelofelijk goed argument tegen Scrum.

De naam sprint. Blijkbaar lever je software in sprints op. Een zin zoals dit is ondertussen normale taal geworden binnen de IT, zelf dacht ik er ook nauwelijks over na. Maar zodra je er beter over gaat nadenken, is dit volstrekt belachelijk. Want Scrum is ook een framework dat zich richt op iteratief, kleine stukjes software opleveren. Want software is tenslotte nooit af, er kan altijd wel iets verbeterd worden. Daarom is het belangrijk dat je zo snel mogelijk een minimale versie van de software oplevert, en deze daarna stap voor stap verbeterd. Op basis van de wensen van de markt. Want zo zorg je ervoor dat je waardevolle software maakt. Door continu kleine stukjes op te leveren en te controleren of iedere aanpassing voldoet aan de wensen van de markt.

Maar hiermee zeggen wij dus eigenlijk, dat software onderhouden nooit af is, en vergelijken zou zijn met een marathan. Maar alsnog werken wij in ‘sprints’ om software te schrijven. Onderbewust ontstaat hierdoor de misopvatting: dat wij continu een marathon aan het sprinten zijn.

Dat kunnen wij niet. Dat kan niemand. En dat is voor een deel het probleem waar veel IT organisaties tegenaan lopen. Zij verwachten echt dat developers de marathon blijven sprinten.

Laat ik maar even met het verlossende woord komen:

Als je over een lange periode je software wilt blijven onderhouden, moet je niet te sprinten!

Dus hierbij nog een oproep naar alle developers: stop met sprinten! Kijk naar de toekomst en doe het eens rustig aan! Want anders ben jij de volgende met een burn-out!

Agile draait niet om snelheid

Binnen IT wordt Agile als methode vaak ingezet voor ‘Maximizing Value’. Mijn theorie is dat dit een gevolg is van de volgende agile principe:

Working software is the primary measure of progress.

Naar mijn mening is dit principe verkeerd. Het gaat namelijk niet om werkende software! Het gaat om waarde leveren!

Voorbeeld van waarde toevoegen

Ik kan me nog goed een IT project herinneren waar wij als team gevraagd werden om een kleine aanpassing te maken in een complex scherm. Nadat wij naar de code hadden gekeken en enkele testen hadden uitgevoerd kwamen wij tot de conclusie dat het huidige scherm onwerkbaar was geworden. Dit scherm werd vervolgens omgedoopt tot ‘de draak’ van de applicatie. Met name omdat dit scherm een ongelofelijk zwaar en groot monster was geworden, waar je niet aan wilt komen. Want dat zal zomaar je leven kunnen kosten.

Als reactie gaven wij aan dat wij de aanpassing konden maken, mits wij daar 3 sprints de tijd voor zouden krijgen, om het scherm te refactoren (op te schonen). Met een beetje moeite ging de business gelukkig hiermee akkoord. Het heeft ons 3 sprints gekost om de aanpassing door te voeren, maar het is ons gelukt. We hadden de minimale aanpassing eindelijk opgeleverd.

Stukje context: dit scherm werd eenmaal per jaar gebruikt om berekeningen te kunnen maken, en ieder jaar resulteerde dit gebruik in vele duizenden klachten en vele uren extra werk voor de medewerkers die dit scherm bedienden.

Nadat wij de aanpassing hadden opgeleverd, en het scherm nogmaals werd gebruikt, kregen wij als team feedback hierover… Door de extra tijd die wij hierin hadden gestopt, was het aantal klachten en de extra uren die hierin gestopt moesten worden, verlaagd met ongeveer 90%!

Dit was niet het doel van de user story, maar is bereikt enkel en alleen maar vanwege het daadkrachtige optreden van het team. Dit is waarde toevoegen!

Om nogmaals de slogan van m’n blog te herhalen: ‘Screw efficiency, let’s focus on what really matters!’.

Het gaat niet om snel software op te leveren, het gaat om waarde toe te voegen!

Agile werken gaat namelijk niet om zo snel mogelijk user stories opleveren! Het gaat om waarde toevoegen! En één goed uitgewerkte user story, kan in veel gevallen meer waarde toevoegen dan vier redelijk uitgewerkte user stories!

Deze fout wordt nog steeds door veel teams gemaakt. Met name omdat de meest gebruikte meetinstrumenten worden ingezet om het aantal user stories bij te houden! Het is namelijk veel moeilijker om echte waarde bij te houden!

Het framework Scrum gebruikt velocity als voornaamste meetinstrument. Velocity is de hoeveelheid werk dat het team verzet. Maar naar mijn mening is dit een volstrekt nutteloze metric. Dit pusht mensen om zoveel mogelijk troep naar productie op te leveren, in plaats van waardevolle veranderingen.

Sorry, maar naar mijn mening zijn meetinstrumenten zoals velocity  complete troep.

Hoe dan wel?

Om deze blogpost toch even met een duw in de juiste richting af te sluiten, geef ik ook nog wel een tip om het wel goed te doen.

Het meetinstrument dat jij zichtbaar gebruikt binnen je team, wordt vanzelf hetgeen waar het team zich op zal richten en op afgerekend zal worden. Simpelweg omdat het zichtbaar is.

  • Als het aantal gebruikers per dag dagelijks op een dashboard wordt weergegeven, zal het team zich vanzelf gaan richten om dat aantal te verhogen.
  • Als jij metrics op het dashboard toont van het aantal foutmeldingen in productie, zal het team zich gaan richten om dat aantal te verlagen.

Als je waarde wilt toevoegen, moet je ‘waarde’ concreet maken en ervoor zorgen dat dit zichtbaar gemeten wordt. Dan zal het team zich hier vanzelf mee bezig houden.