Scrum: van sprookje naar werkelijkheid

'We hebben een go, het project gaat door!' Het is december 2013 wanneer dit nieuws mij bereikt. Er moet een generiek softwarepakket gemaakt worden in SharePoint, volledig configureerbaar en geschikt voor elke markt. Bovendien moeten ontwikkelaars uit drie verschillende landen eraan werken. Kortom, we staan voor een uitdaging.

Inmiddels zijn we ruim drie jaar verder en door schade en schande een stuk wijzer. Het sprookje dat Scrum heet bestaat nog steeds, maar we doen het net een beetje anders dan een paar jaar geleden. Als uitgangspunt gebruiken we de Scrum Guide, maar soms moet je daar wel eens van afwijken.
Er zijn namelijk nogal wat valkuilen als je op een Agile-manier SharePoint-projecten wilt aanpakken. Bij de start van ons project was SharePoint 2013 net gereleased en wij waren pioniers op het vlak van SharePoint 2013 add-ins. Alles wat we deden was nieuw en verrassingen lagen overal op de loer.

Hoe het begon
Bij onze eerste sprintplanning ging het al mis. Onze product owners bleken onvoldoende kennis van SharePoint te hebben, waardoor we regelmatig in eindeloze discussies over functionaliteit belandden. Ook op het ontwikkelvlak hadden we problemen. Voor onze ervaren programmeurs was het al lastig genoeg om voor het eerst een SharePoint add-in te ontwikkelen, maar ons team groeide uit tot meer dan 10 mensen. Bovendien wilden slechts een paar mensen het woord voeren bij de sprintplanning, sprint review en retrospective.

Cultuurverschil
En dan was er nog het feit dat onze teamleden uit verschillende landen kwamen. Hierdoor hadden we te maken met een taalbarrière en culturele verschillen. Zo werden onze Scrum Master en product owners steevast als managers gezien. Hierdoor durfden onze buitenlandse collega’s niet vrijuit te praten tijdens de retrospectives. Met als gevolg dat we onze manier van werken niet konden afstemmen op hun wensen.

De oplossing
Het is je misschien al opgevallen, maar in ons team zaten meerdere product owners. Hoewel ik dit niet zou aanraden, was dat op zich nog niet eens zo’n groot probleem. Wel problematisch was dat zij SharePoint niet goed kenden en niets wisten over de filosofie van Microsoft op dit gebied. Zo wisten ze bijvoorbeeld wel dat je met SharePoint sites kan aanmaken op basis van een webtemplate, maar niet dat dit afgeraden wordt en je het aanmaken van sites via provisioning met CSOM moet doen, zoals Office Dev PnP dat tegenwoordig doet. Om dit soort problemen te voorkomen, hebben we ervoor gekozen om de architect zijn werk niet tijdens, maar voor de sprint te laten doen. Door de architect en product owner samen te laten werken, kan het team zich volledig richten op softwareontwikkeling. Dit bleek een gouden zet, want daarna konden we stappen maken.

Stap voor stap
Door onder andere een aantal technische beslissingen werd ons project veel groter dan verwacht. Om toch de deadlines te halen (ook bij Scrum heb je die soms), werd ons team uitgebreid met een flink aantal nieuwe mensen, veelal junioren. Die hebben begeleiding nodig en ik kan wel zeggen dat zoiets heel veel tijd kost. Iemand vertelde me ooit dat het eenvoudig is om iets nieuws te leren, maar dat het zeer complex is om twee dingen gelijktijdig te leren. Als voorbeeld noemde hij breien en fietsen. Beide activiteiten kun je relatief eenvoudig leren, maar als je ze afzonderlijk niet beheerst, is een combinatie bijna niet te doen. Ik wil maar zeggen: het is goed om eerst te leren programmeren, voordat je dat in SharePoint gaat doen. Zet dus ervaren mensen in als er haast geboden is en werk junioren in wanneer daar tijd voor is. Hiermee voorkom je waarschijnlijk ook dat het team groter wordt dan negen personen, want zoals de Scrum Guide ook aangeeft dat blijkt inderdaad dat niet te werken.

Onbekend maakt onbemind
Bij Scrum is de retrospective misschien wel het belangrijkste onderdeel van een sprint. Dit is het moment om te zeggen wat er goed gaat en – vooral – wat er beter kan. Zo kan het gebeuren dat een teamlid een project doet, maar eigenlijk niet goed weet hoe hij bepaalde zaken moet aanpakken. Misschien heeft hij niet de juiste technische kennis of begrijpt hij de user story’s niet goed. Wat er in dat geval gebeurt, is even logisch als onhandig. Tijdens de retrospective zal hij zeggen dat alles goed gaat. Het ligt namelijk niet voor de hand dat iemand die zichzelf nog moet bewijzen tegen een groep mensen gaat zeggen dat hij iets niet begrijpt. Toch is dit zonde, want je mist hierdoor de kans om jezelf en het team te verbeteren. Dus hoe los je dit probleem op? Vaak helpt het door mensen een op een te spreken. Dit is een taak die ervaren teamleden op zich kunnen nemen. Merk je dat iemand uit jouw team moeite heeft zich uit te spreken, weet dan dat het niet verboden is om voor of over een ander te spreken, zolang die persoon zich in dezelfde ruimte bevindt. Zo kun je tijdens de retrospective gerust zeggen: ‘Ik merk dat de Javascript-kennis van mijn collega onvoldoende is, kunnen we daar iets aan doen?’. Pas als je problemen bespreekbaar maakt, kun je ze oplossen.

Manager
Dat alleen honden een baas hebben en mensen niet, is vooral in Nederland bekend. Wij merkten bij onze Belgische en Roemeense collega’s dat de product owner, en in mindere mate de Scrum Master, als managers werden gezien. Maar een van de krachten van Scrum is juist dat je zelfsturende teams hebt. Die kracht wordt meteen tenietgedaan zodra bepaalde mensen als baas worden bestempeld.

Voor ons huidige team geldt, dat de Scrum Master ook ontwikkelaar is. En dat bevalt erg goed en draagt bij aan de openheid in de communicatie. Eerder in het project hadden we een Scrum Master met een achtergrond in projectmanagement. Wat je merkte, was dat ondanks alle goede bedoelingen problemen toch vaak achter zijn rug om werden opgelost of juist verzwegen.

Soft skills
In de afgelopen drie jaar hebben we heel veel fouten gemaakt. Toch blijken de regels van Scrum goed te werken. Ook het communiceren via Lync en Slack en het gebruik van TFS met bijbehorend Scrumboard werkt prima. Technische problemen zijn vrijwel altijd op te lossen en planningen kunnen worden bijgesteld.
Wat vooral fout gaat bij projecten, dus ook bij Scrum, is de communicatie. Een ontwikkelaar moet tegenwoordig vooral in staat zijn om user story’s te vertalen naar vaak complexe source code en technische problemen kunnen vertalen naar zinnen die iedereen begrijpt. Niet iedereen is daar goed in, maar elk team heeft dit soort mensen nodig.

Een sterk pluspunt van ons team is dat onze Scrum Master ‘gewoon’ ontwikkelaar is en goed kan luisteren. Nu is de Scrum Master de eerste bij wie we kunnen uithuilen wanneer er weer een nieuw probleem opduikt. Op deze manier komen problemen op de plek terecht waar ze opgelost kunnen worden.

Wat als …
Wat zouden we gedaan hebben als we aan het begin van ons project zouden beschikken over de kennis die we nu hebben? Dat is natuurlijk een interessante vraag. Het antwoord op die vraag heb ik ook. Een half jaar geleden hebben we namelijk buiten ons project om nog een extra team opgericht. Dit nieuwe team werkte twintig weken lang aan een nieuwe feature.

Een van de junioren in ons oorspronkelijke team was erg goed in programmeren en kende ons product goed. In dit feature-team lag de nadruk minder op SharePoint, waardoor deze collega ineens veel waardevoller werd. Daarnaast bestond de rest van dit team vanwege de tijdsdruk uit ervaren mensen. In deze samenstelling was het zeer prettig werken en waren we ruim binnen de deadline klaar.
Met deze kennis hebben we vervolgens ons SharePoint-team opnieuw samengesteld. De kern bestaat nu uit vijf ervaren ontwikkelaars, aangevuld met een junior die ons product nog niet kende, maar wel ervaring had met programmeren en SharePoint. Ook dit werkt erg goed.

Grote stappen, laat thuis
De moraal van mijn verhaal: het is net als trap lopen, je moet geen treden overslaan. Als je een team samenstelt, moeten de teamleden een toegevoegde waarde hebben voor je project. Het kan dus ook gebeuren dat je met een kleiner team moet starten. Vandaaruit kun je mensen dan toevoegen of junioren opleiden.
Wij draaien inmiddels op volle kracht en gaan vrolijk verder met ons project. De werkelijkheid zou zomaar mooier dan het sprookje kunnen worden.

Deze blog verscheen eerder op www.centric.eu/craft
Willem de Boer is werkzaam bij Centric en actief als Craft Expert.