De komende vier weken plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Wellicht ben je bekend met deze projectaanpak en programmeertaal? Wij hebben er het afgelopen jaar een aantal succesvolle projecten mee gedaan en we hopen je met deze serie te laten zien hoe Finalist Ruby/scrum projecten aanpakt en waarom deze aanpak zo succesvol is. Deze week is het woord aan Firas Daoud die het afgelopen jaar als projectmanager een aantal scrum projecten heeft begeleid.In mijn verhaal focus ik me op het scrum gedeelte van een Ruby/scrum project, met name over de opstartfase. Inmiddels heb ik het genoegen gehad om een aantal scrum projecten met Ruby (on Rails) de doen. Meestal waren dit kleine projecten en om zo’n klein project goed te doorlopen is het eeuwenoude gezegde ook binnen de ICT nog altijd waar: “een goed begin is het halve werk”.

De voorbereiding van een scrum project vergt veel aandacht voor communicatie met de klant, maar vooral ook met je team. Persoonlijk begin ik nog steeds eerst met een interne kick-off waar het hele team bij wordt betrokken. De samenstelling van zo’n team is volgens mij afhankelijk van de applicatie die gebouwd moet worden. Voor de rollen interactieontwerper en tester gebruik ik meestal dezelfde persoon. Deze rollen hebben namelijk geen fulltime werk aan het project en op die manier houden we het team kleiner en voorkomen we dat testers en ontwerpers tussen teveel verschillende projecten heen en weer stuiteren.De belangrijkste vragen tijdens de kick-off meeting zijn: “wie wordt de scrum master, hoe gaan wij de dagelijkse stand-up meeting houden en hoe gaan we de backlog beheren”?. Hierbij is het belangrijk dat er een werkwijze gekozen wordt die niet alleen voor de projectmanager, maar voor het hele team prettig is. Zij moeten immers net zo vaak als ikzelf en als de klant gebruik maken van deze faciliteiten.Na de kick-off stellen we de backlog en de burndown chart op. Dit kan in een Excel bestand of op een groot vel papier, maar tegenwoordig zijn er ook een aantal verschillende digitale tools die je kunt gebruiken. Pivotal Tracker, XPlanner en Greenhopper zijn een aantal van deze tools die we de afgelopen tijd hebben getest en inmiddels hebben wij gekozen voor Greenhopper als vaste tool.

Tijdens de kick-off meeting besluit ik wie de rol van de scrum master mag gaan vervullen. In tegenstelling tot verschillende geruchten hoeft de rol van scrum master niet door de projectmanager vervuld te worden. In tegendeel, wanneer de scrum master een tech lead developer of een interaction designer is, levert het vaak betere resultaten op.

Het laatste belangrijke onderdeel van de kick-off meeting is het afspreken van de dagelijkse stand-up meeting. Als projectteam heb je niet altijd het gemak om bij de klant intern te kunnen werken, dus is het noodzakelijk om op een andere manier dan “face-to-face”? met het team te kunnen overleggen en de gang van zaken door te nemen. Hiervoor gebruiken wij momenteel een telefonische conference call. Dit telefoongesprek vindt elke ochtend plaats met het hele team. Tijdens deze conference call legt ieder teamlid uit wat hij of zij de afgelopen werkdag heeft bereikt en wat hij of zij vandaag probeert te bereiken. De klant heeft tevens tijd en gelegenheid om vragen te stellen of wijzigingen door te geven.

Goed, de interne kick-off meeting is geweest en de manier van werken is bepaald. Tijd om de planning vast te leggen en deze richting de klant te sturen. De planning tijdens een scrum project ziet er over het algemeen als volgt uit: tijdens de nulsprint maak je kennis met de klant en praat je over wat de applicatie moet gaan doen. De risico’s die tijdens het offertetraject naar boven zijn gekomen, worden ook besproken. Daarna leg je de scrum methodiek uit. Besteed daarbij vooral aandacht aan de consequenties voor de klant! In een scrum project wordt aanzienlijk meer tijd en inspanning van de klant verwacht dan bij andere projectmethoden.

Binnen scrum werken we met fasen, ook wel sprints genoemd. Meestal zijn dat sprints van twee weken. Aan het begin van elke sprint houden we een planningsessie. In de planningsessie bespreek je de functionaliteit die je gaat bouwen tijdens de sprint, in de vorm van zgn. “user stories”. Je prioriteert de functionaliteit en laat de developers al het werk inschatten op werkuren en complexiteit. De user stories geven meer informatie dan alleen wat een stukje functionaliteit inhoudt: wie is de gebruiker, wat is zijn rol, wat is de impact van deze functie en (niet geheel onbelangrijk) welk probleem wil de gebruiker oplossen met deze user story?

Voor het bepalen van de hoeveelheid user stories die gebouwd kunnen worden tijdens een sprint, gebruik ik de volgende regel: de hoeveelheid werkdagen minus de dagen die nodig zijn om bugs te fixen, plus een overhead van 2 uur per dag. Dat zorgt dus voor een zes uur durende werkdag voor het bouwen van functionaliteit, de overige twee uur zijn voor interne besprekingen en overleg tussen de developers.

Omdat de inzet van de klant zeer belangrijk is en de klant op korte termijn informatie moet kunnen opleveren, worden alle vaste afspraken direct tijdens de eerste sessie met de klant besproken. Dat zijn dus voor elke sprint een planningsessie, een acceptatierelease, afspraken tond interaction design en – last but not least -, de afspraak tussen de interactie ontwerper en de opdrachtgever om de user stories voor aanvang van elke sprint door te nemen.

Wanneer de nulsprint over is, de vaste afspraken staan en de eerste planningsessie succesvol is verlopen, is de taak van de projectmanager om regelmatig met de scrum master te brainstormen over het verloop van de user stories, de tijd die daarvoor gereserveerd is en wat er met de burndown chart gebeurt. Dit gebeurt zo’n twee keer per week. Hierdoor krijg je als projectmanager genoeg tijd om in te kunnen grijpen als er iets mis dreigt te gaan. Merk op dat het waarschijnlijk niet lukt om tijdens de eerste sprint al je user stories op te leveren; het team leert gedurende de eerste en tweede sprint hoe snel ze werken en wat reële schattingen zijn.

Tenslotte nog een aantal tips:
- Zorg ervoor dat je altijd duidelijk naar de klant communiceert. Vergeet de klant niet op het hart te drukken dat de developers een schatting afgeven van hoeveel werk ze kunnen af krijgen in een sprint. Het gebeurt regelmatig dat je niet alle user stories kunt implementeren. Natuurlijk kan het gebeuren dat je alle stories af hebt, in dat geval kun je stories uit het backlog oppakken.

- Zorg ervoor dat de klant leert omgaan met het issuetrackingsysteem dat jullie gebruiken als de klant hier issues moet invullen. Als het systeem (naar het idee van de klant) niet goed werkt, kan hierover irritatie ontstaan en dat wil je ten allen tijde voorkomen.

- Bezoek de klant regelmatig! Zorg ervoor dat de klant het gevoel heeft dat hij of zij open kan praten over het verloop van het project. Ook als het goed gaat. Hierdoor bouw je een goede klantenrelatie op.

- Praat regelmatig over de backlog. Hoe belangrijk zijn de overgebleven user stories die niet meegenomen gaan worden in het traject? Misschien kunnen die alsnog meegenomen worden direct na de laatste sprint? Hoe sneller je de backlog oppakt als meerwerk, des te beter dat is voor het gehele proces. Iedereen zit dan nog in het project en de applicatie staat niet weken stil!