Altijd gedacht dat Scrum en XP – eigenlijk Agile in het algemeen – een sterke nadruk legt op kwaliteit. Zo sterk zelfs dat het team geacht wordt om elke sprint een werkend product op te leveren, die “in potentie” daadwerkelijk vrijgegeven zou kunnen worden.
Blijkbaar heeft niet iedereen die ervaring. Sterker nog, is de ervaring dusdanig dat er door de NLJug een hele “University” sessie over software craftmanship aan gewijd wordt:
In de afgelopen jaren is de nadruk binnen software development enorm komen te liggen op Agile werken. Hoewel dit absoluut een enorme verbetering is ten opzichte van traditionele project methodieken heeft het ook een minder welkom neveneffect.
Doordat Agile methodieken zoals Scrum heel erg sturen op functionaliteit wordt de kwaliteit van de software op een tweede plek gezet! Dit heeft als gevolg dat de applicatie snel kan worden opgeleverd met een grote hoeveelheid aan functionele wensen van de klant, maar dat de onderhoudbaarheid en beheerbaarheid van de applicatie minder is!
De voor mij opvallendste zin is “Doordat Agile methodieken zoals Scrum heel erg sturen op functionaliteit wordt de kwaliteit van de software op een tweede plek gezet!”
Scrum heeft opzettelijk geen regels over hoe het werk uitgevoerd moet worden, geeft weinig meer richtlijnen dan het product goed genoeg moet zijn om vrij te geven en dat het liever algemene rollen ziet dan specifieke rollen, wat zich te vertalen valt in dat alle team leden verantwoordelijk zijn voor kwaliteit en dat de taken behorende bij de tranditionele rol “tester” door iedereen uitgevoerd moet worden.
Scrum teams hanteren over het algemeen een Definition of Done, een lijst -checklist- van zaken waaraan voldaan moet worden om te kunnen zeggen dat het werk klaar is. Items die niet voldoen aan de DoD worden niet opgeleverd aan het einde van de Sprint, of tellen in het minste geval niet mee met het behaalde resultaat.
In alle DoDs ben ik tot nu toe tegen gekomen staat in ieder geval iets in over dat de ontwikkelaar een poging gedaan moet hebben om de kwaliteit te waarborgen. Oftewel door het handmatig getest te hebben of door voldoende unit tests.
Extreme Programming heeft juist wel regels over de uitvoering van het werk, het is gebaseerd op een aantal principes die elkaar versterken en ondersteunen. Veel mensen die aan Extreme Programming zijn de mening toegedaan dat Scrum zonder de XP regels kan werken. Scrum kan echter ook toegepast worden buiten software ontwikkeling, zoals bijvoorbeeld er in onze organisatie voorzichtig geëxpirimenteerd wordt met het gebruik van Scrum bij het ontwikkelen van trainingen ten bate van onze producten.
De eisen die XP stelt aan het proces die bijdragen aan de kwaliteit zijn:
- Schrijf eerst de unit test
- Alle productie code wordt ontwikkeld met pair programming
- Alle code heeft een unit test
- Alle testen moeten slagen voordat de code in productie kan
- Voor een defect moet een unit test geschreven worden
- Acceptance testen moeten regelmatig worden uitgevoerd en de score gepubliceerd.
Zelfs met zoveel aandacht die Scrum en XP teams over het algemeen hebben voor kwaliteit komt het helaas nog steeds voor dat er fouten in de software sluipen. Een effectief team zal in de retrospective regelmatig proberen te achterhalen hoe dat komt en wat daar aan te doen is.
Dat de kwaliteit van de software op een tweede plaats gezet wordt is in mijn ervaring juist veel meer een eigenschap van traditionele software ontwikkel methoden. Daar worden Functionaliteit, Kosten en Tijd vastgezet, waardoor automatisch, en ongewild, Kwaliteit de variable is. En daarna blijken Kosten en Tijd en ook nog Functionaliteit niet haalbaar. Agile zet juist Kwaliteit ‘vast’, tezamen met Kosten en Tijd. Functionaliteit is daardoor automatisch de variable en die wordt actief en transparant voor iedereen gemanaged.
De aandacht voor kwaliteit komt niet vanzelf. Deed je als bedrijf voordat je met Scrum begon onvoldoende aan kwaliteit dan komt het niet magisch goed als je met Scrum gaat beginnen. Je zal als team en bedrijf daar hard aan moeten werken, maar Scrum maakt dat wel mogenlijk en inzichtelijk.
Ben je overigens geïnteresseerd in de aspecten van software craftmanship dan is het een idee om actief bij te dragen aan het Agile Skills Project, een project door en voor ontwikkelaars waar een algemene set van kunde wordt vastgesteld die een een software ontwikkelaar in agile projecten zou moeten beheersen.
April 7th, 2010 - 23:17
[...] Dit blogartikel was vermeld op Twitter door Gerrit Koster, Gerrit – Mind Mappen. Gerrit – Mind Mappen heeft gezegd: Scrum zet kwaliteit op de tweede plaats… Pardon? from: @scrumnl http://bit.ly/dorIxL [...]
April 8th, 2010 - 08:26
Volgens mij heeft een gebrek aan aandacht voor kwaliteit veel minder te maken met de ontwikkel-aanpak (traditioneel of agile), maar veel meer met de bedrijfscultuur.
Ik hoorde pas van een bedrijf waar de business stelt: “kwaliteit van project deliverables is niet belangrijk, dat los je maar op tijdens de maintenance fase.” Achtergrond hiervoor is dat de business moet betalen voor projecten, terwijl de maintenance fase onderdeel is van de overhead die toch al betaald is. Door dus niet expliciet hiervoor te hoeven betalen wordt de illusie gewekt dat dit gratis is.
Dit probleem los je niet op met Scrum, met XP, met CMMI of met Six Sigma.
Hoe wel is nog wel de grote vraag. Ik erger me kapot aan dit perverse gedrag!
April 8th, 2010 - 09:42
Lastig onderwerp, en erg afhankelijk van de invalshoek. Zit men in de kantoor automatisering waarin specificaties vaak niet helder zijn dan is Scrum een kwaliteitsverbetering ten opzichte van volledig vooraf ontwerpen. Dit is omdat Agile methodieken het inzicht vergroten in wat het eind product gaat worden.
Werkt men in de technische automatisering waar men te maken heeft met hardware (minder agile). Of heeft men te maken met complexe software architectuur dan zou Scrum of een andere Agile methodiek kwaliteitsverlagend zijn. Dit omdat architectuur (i.e. vooraf ontwerpen) achteraf niet in de programmatuur toegevoegd kan worden zonder aanzienlijke inspanning. Architectuur vereist een blikveld dat breder is dan die de Agile methodiek hanteert. Waar Agile methodieken kijken naar ‘the problem at hand en de unit’ kijkt architectuur naar het complete product en de plaats van het product binnen de product portfolio. Architectuur heeft impact op lange termijn onderhoudskosten.
Dus, vooraf ontwerpen kan kwaliteits verbeterend werken, Agile ontwikkelen kan ook kwaliteits verbeterend werken.
Dit is een discussie waarop nooit een eenduidig antwoord zal komen, software ontwikkelen is een artistiek beroep, tegelijk het is ook een engineering discipline. Het is aan de professional om af te wegen wanneer hij welke methodiek toe moet passen. Binnen bedrijven word vaak een ‘one glove fits all’ selectie gedaan als het gaat om ontwikkel methodieken. Dit is kortzichtig, men moet nadenken en afwegen welke methodiek er geschikt is voor het specifieke pakket dat ontwikkeld moet worden.
Gebruik geen Agile in een kerncentrale en gebruik geen RUP voor een tooltje dat eenmalig gebruikt gaat worden.
Unit testen moet natuurlijk altijd of je nu een Agile methodiek gebruikt of niet.
April 8th, 2010 - 09:56
Indien bedrijven overstappen op Agile/Scrum dan verwacht je toch dat men in de Definition of Done minstens dezelfde afspraken maakt over wanneer en hoe een “shippable product” opgelevrd wordt? Dit betekend namelijk dat de kwaliteit minstens gewaarborgd blijft.
Het probleem ligt hier wat mij betreft dan ook bij de organisatie (en bijvoorbeeld het feit dat men geen tester aan het team toevoegd). Niet bij de methodiek, scrum, xp, agile technieken, etc.
April 8th, 2010 - 16:11
Dit is overigens een typisch argument van de Agile Naysayers.
Kwaliteitseisen zijn IMHO juist een van de voorwaarden van een Agile proces, wat volgt uit het Lean principe “Built Integrity In”. De kwaliteit mag niet ten koste gaan van de druk van de organisatie om features, dit is waar de PO in samen werking met de SM ook van overtuigd moeten zijn, anders gaat het niet werken. Kwaliteit zou ook een belangrijke drijfveer moeten zijn voor een PO, een product met allerlei coole features wat in de basis werkt niet werkt heeft uiteindelijk geen bestaansrecht. Een term die ook vaak gebruikt word in de Agile wereld is “Technical Debt”, als je de kwaliteit op z’n beloop laat, zal je dit je uiteindelijk op gaan breken.
In een waterval proces waar je een project afsluit met een test fase van 2 maanden heb je eigenlijk de test druk alleen aan het eind. Maar in een Agile proces met korte iteraties moet je product eigenlijk elke iteratie aan alle kwaliteitseisen voldoen. Als er handmatig word getest zal de test druk exponentieel met het aantal features oplopen, en zal de verhouding coden/testen steeds verder uit verband raken, wat in veel gevallen niet echt bij zal dragen aan een succesvol project. Als men dan de conclusie trekt dat het dus wel aan Agile zal liggen is uiteraard niet juist.
Het is dus eigenlijk een voorwaarde om XP toe te passen inclusief Continious Integration en automatisch Unit en UI testen. Hierdoor houd je de kwaliteit continu op peil en houd je de test druk beheersbaar, mits het team uiteraard de automatisch test serieus neemt en failing tests ook direct fixt.
April 8th, 2010 - 16:12
Hi Niels,
Het is wat jammer dat de methode Scrum niet rechtstreeks gekoppeld is aan de Lean principes. De methode volgt wel uit die Lean principes, maar je ziet het niet direct bij de training. Als je nu wel een CSM training volgt, maar je verder weinig verdiept in Lean, dan kan ik mij voorstellen dat “Build integrity in” gemist wordt.
Voor mij was dat in ieder geval een eye-opener. Pas na de Scrum training, toen ik de boeken van de Poppendiecks las, begreep ik het echt.
Als je nu toevallig wel XP kennis hebt dan ben je wellicht wel in staat zoiets als technical debt te begrijpen zonder je te verdiepen in Lean.
Ik zie in de praktijk hoe dan ook dat het moeilijk blijft om de kwaliteit optimaal te bewaken. Technical debt is nu eenmaal een grijs gebied. Wanneer is een stuk software goed genoeg en wanneer ga je de debt voelen (en snapt het team dat het beter moet)? Het gaat verder dan alleen de kwaliteitseisen.
De druk om deliverables op te leveren zal bovendien altijd gevoeld worden. Zo werkt dat nu eenmaal met mensen, wat zichtbaar is heeft voorrang op wat niet zichtbaar is.
Ook denk ik dat geautomatiseerd testen geen absolute voorwaarde is om te kunnen Scrummen met behoud van kwaliteit. Ik heb net een project afgerond met de archaïsche techniek van Oracle Designer, zonder geautomatiseerd testen, zonder continious build, maar wel op tijd en met behoorlijke kwaliteit (maar niet foutloos). Testen deden we gewoon handmatig. Na 16 iteraties van 3 weken hadden we nog steeds geen last van technical debt. In alle opzichten was het een bijzonder succesvol project.
Om even terug te wijzen naar mijn inleiding, het is toch wel bijzonder handig als je de principes van lean software development uitlegt aan het team en daar ook continu op terug komt. Als je begrip kunt creëren voor die principes, dan heb je ook het draagvlak om samen te kijken naar de beste manier om die principes toe te passen.
April 8th, 2010 - 16:14
Tijdens mijn CSM training (begin 2006) werd ons op het hard gedrukt dat Quality bovenaan stond voor Scrum. Ook het inbouwen van integriteit is toen vorrbijgekomen. Veel Agile en dus ook Scrum is uit Lean gekomen. Je kunt veel van Lean terugvinden in Agile al zijn er soms wat verschillende gedachten over Scrum vanuit Lean (product backlog zou voor Lean geen items mogen bevatten die we toch nooit oplossen). Ook continuus integration kwam terug in de training.
Wel is het nodig een tester in het team op te nemen om kwaliteit te waarborgen en kwaliteit meetbaarheid binnen Definition of Done op te nemen.
April 8th, 2010 - 16:16
Wellicht dat voor kort durende projecten de investering in het opzetten van continuous integration en automatisch testen het niet waard is,
Uiteraard zijn er altijd uitzonderingen op de regel, ik ben sowieso niet iemand van verplichten, het moet een middel blijven en geen doel op zich.
Maar je moet zeker kritisch gekeken hebben naar het handmatig testen met het oog op het belangrijkste principe van Lean: “Eliminate Waste”
April 8th, 2010 - 16:19
ep, bewuste keuzes maken op basis van wat ‘in principe’ goed is, daar gaat het om.
In dit geval zag ik netto geen winst, techniek die niet mee wilde werken, mensen zonder enige ervaring met geautomatiseerd testen, etc.
Dan wordt het dus wel een uitdaging om die kwaliteit op een goed niveau te houden!
Die uitdaging durfde ik (het team) wel aan omdat ze al een tijdje zo samenwerkten en dat ging best wel goed.
De ‘waste’ in dit project zat vooral in de samenwerking met de opdrachtgever, lange doorlooptijden ontwerp, onnodige requirements, etc.
April 8th, 2010 - 16:19
Als je je ontwikkelstraat goed hebt ingericht is het opzetten van (in ons geval) cruisecontrol voor een project een minimale hoeveelheid werk. Minder dan 5 minuten. Dit betaald zich altijd terug.
April 8th, 2010 - 16:20
Confirmed.
Continuous integration: niet te lang over ouwehoeren, gewoon doen (ook voor kleine projecten).
Ik heb de Scrum cursus gevolgd bij Xebia eind januari en kan bevestigen dat Agile methodieken steeds meer in “de leer” worden geintegreerd. Het woord “YAGNI” werd door Jeff zelf in grote letters op een flip-over geschreven.