LinkedIn herinnerde me er vorige week aan dat ik mijn 11^e werkjubileum bij Roularta mocht vieren.
11 jaar al! Time flies when you’re having fun…

Even een flashback naar de periode toen ik hier begon. De nieuwe drukkerij was nog in volle opbouw toen ik hier startte. Je kon de gebouwen van Roularta in Roeselare in die periode van ver herkennen door de vele kranen op de bouwwerf. Handig om niet verkeerd te rijden die eerste dagen.

In die 11 jaar is mijn jobinhoud al een paar keer gewijzigd: ik startte bij de promotie- en marketingafdeling van de magazines waar ik na enkele maanden het online luik verder kon helpen uitbouwen, zowel op het vlak van wedstrijden, mailings, als voor de uitbouw van een online shop. Na een korte tussenstop bij Line Extensions kwam ik in mei 2010 op mijn huidige job van Online Product Manager terecht.

Ook binnen mijn huidige functie blijft het nieuwe uitdagingen regenen. Niet in het minst na de overname van de Sanoma-titels die ook online de nodige aandacht vragen en vergen. Een nieuwe blik op de wereld dus en zo behoud ik meteen ook een frisse kijk op mijn job. En ondertussen weet ik al blindelings de weg naar mijn werkplek…

Na een intensieve periode van projectdefiniëring, functionele en technische analyse en ontwikkeling, is het als Online Product Manager steeds spannend wachten naar het moment waarop de testfase is aangebroken. Het is het moment waarop de Sherlock Holmes in mij naar boven komt, en ik als een echte speurneus op zoek ga naar eventuele fouten die nog aanwezig zijn in de ontwikkeling.

Afhankelijk van de grootte van het project en het aantal fouten, kan de testfase enkele uren tot dagen in beslag nemen. Soms beperkt het testteam zich tot mezelf of nog een extra persoon binnen onze afdeling. Maar bij grote projecten, waar meerdere afdelingen bij betrokken zijn, kunnen dit er 6 of meer personen zijn. Bij dergelijke grote projecten organiseren we doorgaans enkele testdagen waarbij we samen in een vergaderzaal alles grondig testen.

Onze leidraad bij het testen is een testplan waarbij alle mogelijk testscenario’s uitgeschreven worden. In het uitwerken van dit plan steken we de nodige tijd om er zeker van te zijn dat geen enkele stap of functionaliteit vergeten wordt bij het testen.

En hoe graag ik ook als Sherlock Holmes met m’n vergrootglas op zoek ga naar mogelijke bugs, toch stemt de testronde me het meest tevreden wanneer na afloop alles blijkt te werken zoals ik het had uitgeschreven in de voorbereidende functionele analyse. Of om het als Hannibal Smith uit the A-Team te zeggen: ‘I love it when a plan comes together’. Dat houdt meteen ook in dat het project naar z’n einde loopt en er al kan uitgekeken worden naar een nieuw project mét bijhorende testperiode.

Nog enkele weken en het is zover: dan start onze 100^ste sprint! Voor je begint te denken dat we met z’n allen onze loopschoenen aantrekken tijdens de werkuren, kan ik je geruststellen. We zijn niet letterlijk aan het ‘lopen’.

Ongeveer 4 jaar geleden zijn we binnen ons team beginnen te werken volgens het scrum-principe. Scrum is een agile manier van werken die er voor zorgt dat projecten binnen een team op een vlottere manier opgeleverd worden tijdens een vooraf gedefinieerde tijdspanne. Zo duurt bij ons een sprint telkens 2 weken.

Het scrum-team bestaat traditioneel uit een ontwikkelteam, een scrum master en één of meerdere product owners. Zelf vervul ik de laatste rol. Als product owner ben ik de tussenschakel tussen enerzijds de business (= de redacties, de regie,…) die een bepaalde vraag heeft, en anderzijds het ontwikkelteam dat de vraag uitwerkt.

Mijn taak bestaat er in om zo goed mogelijk te luisteren naar de wensen van de business en ze vervolgens te vertalen naar concrete vragen of ‘user stories’ die uitgevoerd kunnen worden door de ontwikkelaars.

Alle openstaande user stories komen terecht in onze backlog. Vooraleer we ze kunnen uitwerken tijdens een sprint moeten de vragen eerst ingeschat worden door de ontwikkelaars. Dat gebeurt tijdens de backlog refinement. Tijdens die meeting licht ik mondeling de user stories toe aan de ontwikkelaars. Niet altijd eenvoudig, want de vragen van de business kunnen soms zeer complex zijn of blijken niet zo eenvoudig realiseerbaar volgens de ontwikkelaars wat er voor zorgt dat ik vaak als een ‘politieke onderhandelaar’ terug moet gaan naar de business met een alternatieve oplossing voor hun vraag.

Eens alle stories ingeschat zijn, geef ik ze een specifieke volgorde in de backlog, waarbij de vragen met de hoogste prioriteit bovenaan staan en het zo duidelijk is wat er in de volgende sprint ontwikkeld moet worden.

Na bijna 100 sprints of 200 weken, ben ik nog steeds enthousiast over deze manier van werken, ook al zorgde ze al voor vele vergaderuren met de ontwikkelaars en overleg met de business. Het zorgt ervoor dat projecten duidelijk gedefinieerd en ingeschat worden, zodat iedereen concreet weet wat er moet gebeuren en in welke tijdspanne. En door het toekennen van prioriteiten kunnen we ook aan de business duidelijk maken welke projecten voor ons belangrijk zijn.

Bijna 100 sprints… Dat verdient toch een applausje, niet?