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.