soemirno

Het afgelopen jaar ben ik begonnen wat processen rond onderhoud van een systeem op te zetten. Als leidraad hiervoor heb ik Scrum gebruikt. Het systeem had een goede basis:

• een duidelijke product owner die erg betrokken is en prioriteiten kan bepalen
• een codebase dat TDD is gebouwd met goede code coverage en continuous integration
• moderne project infrastructuur: OTAP omgevingen, project wiki, ticket systeem, versiebeheer, etc.

Op de werkvloer waren de 'agile' invloeden dus al duidelijk aanwezig, nu was het zaak om het door te trekken.

Het werken in iteraties was al bekend, maar het concept van een product backlog met  sprints om deze weg te werken nog niet. Het was niet moeilijk om dit te verkopen, het klinkt allemaal heel logisch. Overigens noemen we het geen Scrum sprints, maar gewoon een release.

De eerste focus was het bijhouden van de backlog. In het verleden hebben we verschillende tools gebruikt om issues te registreren:

• een agile project management tool
• een buglist op sharepoint
• en ook nog de oude vertrouwde spreadsheet.

Ik heb besloten voor nog iets anders: het Trac ticket systeem Trac was al in gebruik als wiki en als webview over subversion, dus waarom ook niet het ticket systeem ervan gebruiken.

Klinkt logisch, alleen valt de gebruiksvriendelijkheid van Trac wel tegen, met name als je niet gewend bent aan wiki syntax. In het begin maakte ik zelf de tickets aan, maar intussen voert de product owner zelf ook tickets in. Er zijn echter nog genoeg issues nog niet ingevoerd en misschien moet ik maar een keer een sessie plannen om het samen allemaal in te voeren. De backlog geeft immers de werkvoorraad aan en ik heb er persoonlijk belang bij inzichtelijk te hebben dat er genoeg werk is.

Aan de hand van de backlog, plannen we dus de sprints. Tot nu toe heel simpel: we plaatsen de tickets die gedaan moeten worden in de huidige release en gaan aan de slag. Nog zonder timeboxing en tijd inschattingen, de sprint is klaar als het klaar is. Beetje open source instelling. Dit is wel een puntje dat ik nog moet oppakken, in elk geval het timeboxen. Inschattingen vind ik nog niet relevant, omdat de meeste taken toch ongeveer even groot lijken te zijn.

Ik ben nog niet tevreden hoe het gaat met de sprints. Er is nog geen goed ritme van vaste releases. Ik hoop dat het time-boxen dit gaat fixen.

Het blijkt ook best wel moeilijk de focus vast te houden en in een goed ritme te komen. Een reden is dat ik het maar twee dagen in de week doe. Dat op zichzelf is nog niet zo een probleem, maar in die twee dagen moet ik ook nieuwe teamleden zien in te werken.

Dit is ook iets waar je even over na moet denken. Afhankelijk van de instelling van de persoon kan dit energie kosten of juist energie opleveren. En dan merk je dat software ontwikkeling best wel een teamsport is, het gaat om de samenwerking. Dat zit nu wel goed. Doe nu vaker pair programming en merk dat het echt sneller gaat. Veel sneller dan als ik alleen zou werken, terwijl ik tegelijk toch ook iemand aan het inwerken ben. De 'high performance team' dat scrum belooft is met dit team echt binnen handbereik. Nu maar hopen dat het team lang genoeg bij elkaar blijft om het voor elkaar te krijgen en er van te genieten.

Ik heb het woord Scrum nog niet gebruikt in de organisatie. Ik wilde gewoon iets dat werkte en van Scrum pik ik gewoon wat goede ideeen, eigenlijk dus gewoon Scrumbutt. Ik wilde ook niet meteen de aandacht vestigen op wat ik doe en in alle rust dingen uitproberen. Maar nu ik het gevoel heb dat het kan werken is het misschien tijd om wel wat stricter Scrum te gaan volgen. Misschien beginnen met mensen vertellen wat Scrum is en enthousiast krijgen hiervoor.