Continue zichtbare kwaliteit met Agile

Op maandag 11 juli organiseerde AgileOverheid een open space, over het onderwerp “Agile en Kwaliteit”. Dat je met agile in staat bent om kwaliteitssoftware te leveren is (voor mij) al bewezen. Maar hoe maak je dat zichtbaar voor de stakeholders van een agile project?

De eerste discussie in mijn groep was waarom je kwaliteit zichtbaar wilt maken? Kun je niet gewoon vertrouwen hebben dat het agile team kwaliteit levert, is het wel nodig om het te “controleren”? In een eerder blog over “Het nieuwe werken – zelfde kwaliteit in een nieuw jasje?” beschreef ik dat controle op de kwaliteit een hulpmiddel is om tijdiger actie te ondernemen. Bij agile betekent het dat het zichtbaar maken en bespreken van de kwaliteit moet helpen om eerder signalen te krijgen van mogelijke kwaliteitsproblemen, die zonder deze signalen gemist zouden worden. Aanvullende dus aan alle ingebouwde kwaliteitspractices die agile heeft.

De discussie die daarna ontstond leverde de volgende manieren op om kwaliteit continue zichtbaar te maken:

  • Demo van de software, vooraf gegaan door een product check tegen de Definition of Done. Kwaliteit heeft dan enerzijds te maken met het proces (DoD), en anderzijds met het laten zien van werkende software,  Quality in the eye of the beholder, in dit geval de product owner.
  • Inzichtelijk maken van schattingen (bv storypoints, velocity) en de werkelijke voortgang (burn down chart). De afwijking tussen schatting en werkelijkheid moet als het goed gaat steeds kleiner worden.
  • Het aantal storypoints wat per iteratie gerealiseerd wordt. Is primair een indicator van de productiviteit en efficiency, maar het kan ook kwaliteitsproblemen signaleren.
  • Statische checks op de geleverde code, bv. met Sonar of andere tools. Overigens merkte 1 van de deelnemers op dat sommige tools heel veel metrieken geven, maar het niet altijd even duidelijk is hoe je de data kunt gebruiken om kwaliteitsrisico’s zichtbaar te maken.
  • Overzichten vanuit automatisch testen, bv. test coverage, uitgevoerde testen (Fitnesse, JUnit, etc).
  • Regelmatige “soft meting” hoe het team zich voelt, bv. door wekelijk in het team een rondje te maken en dat te laten zien met een Agile Smiley ( :-), :-|, 🙁 ). Vaak wordt dit in een retro gedaan aan het eind van de sprint, maar het kan goed zijn om het frequenter te checken.

Ik was (en ben nog steeds) onder de de indruk van de vele manieren die we samen in een korte tijd vonden om continue zichtbaar te maken hoe het gaat met de kwaliteit in een agile team. Wederom een bewijs dat een open space een hele efficiënte manier is om ervaringen te delen en van elkaar te leren! (op naar de volgende AgileOverheid open space in september…).

Maar er kwam nog een toetje (naast het ijs wat we inmiddels, met dank aan het Agile Consortium, aan het verorberen waren). Als ik in een organisatie kom, dan begin ik met vragen stellen en observeren. Door deel te nemen aan bv. stand-up, demo, retrospective en scrum-of-scrums vorm ik mij een beeld waar de organisatie staat. Ik kijk hoe de teams agile toepassen, of de  “juiste” onderwerpen besproken en aangepakt worden, naar de manier waarop gecommuniceerd wordt en ook naar wat non-verbaal of niet gecommuniceerd wordt. Dat werkt omdat ik bekend ben met agile, en weet waar ik naar moet kijken.

Organisatie die agile implementeren moeten niet alleen aandacht besteden aan de agile teams, maar ook aan de managers. Steeds meer managers worden zich ervan bewust dat agile een andere manier van managen vereist, met name in de ondersteuning van de teams. Managers moeten leren om “agile te kijken”. Te zien hoe hun teams en medewerkers het doen, door niet alleen naar cijfers te kijken maar ook rond te lopen (Management by Wandering Around, MBWA) en met eigen ogen te zien hoe het gaat. You can observe a lot by just watching, hardstikke waar, maar dan moet je wel weten waar en hoe te kijken!

Aan ons, agile coaches, de schone taak om managers te helpen om met een agile bril naar agile teams te kijken. En met de signalen die ze dan krijgen door te vragen, om een goed beeld te krijgen wat er speelt bij de teams, en wat ze kunnen doen om teams te ondersteunen en ontwikkelen, en daarmee continue hoogwaardige software op te leveren!

Share this Experience
  • 8
    Shares

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.