Agilelicious 5398 x bekeken

Drie uitstekende manieren om je Scrum project om zeep te helpen

11 mei 2016 - Michael Heymans

Scrum is een uitstekende manier om grip te krijgen op complexe projecten, maar zeker geen wondermiddel. Ik beschrijf drie mogelijke oorzaken van een mislukt Scrum project.

1. Kies een ongeschikte Product Owner


De primaire taak van een Product Owner (PO) is zorgen dat het Scrum team elke sprint zo veel mogelijk waarde toevoegt aan het product. Om dit voor elkaar te krijgen zijn enkele belangrijke persoonskenmerken en eigenschappen noodzakelijk.

Geen mandaat

We hebben het allemaal wel eens meegemaakt: er wordt een nieuw project gestart waarin we iets moois gaan maken voor een belangrijke klant. Onze contactpersoon heeft het alleen zo druk met zijn/haar werk dat iemand anders uit de organisatie tot PO omgedoopt wordt. Is deze persoon wel de juiste?

Een PO die zelf geen beslissingen mag nemen, of telkens door de achterban teruggefloten wordt, zorgt voor besluiteloosheid. Dit leidt tot onrust in het team, en dat leidt weer tot verwarring en onnodig re-work. Een PO moet sterk in zijn schoenen staan, zelfstandig beslissingen kunnen nemen en vaak ook (soms tegenstrijdige) belangen van stakeholders vertegenwoordigen. Dit laatste is soms ook een politiek spel waarbij hij niet iedereen tevreden zal kunnen houden.

Zonder deze mandaat loopt het project gegarandeerd in de soep!

Geen tijd = geen prioriteit
Een PO met te weinig tijd om zijn/haar rol te vervullen kan niet op tijd vragen van het Scrum team beantwoorden, de backlog groomen of zelfs aanwezig zijn bij Scrum meetings.

Het team moet niet alleen gedurende een sprint vragen kunnen stellen, maar ook naar de backlog kijken voor de toekomstige sprints. Een backlog is namelijk niet iets wat je als PO een dag voor de volgende sprint even aanvult. Het team kan zichzelf dan niet alleen niet voorbereiden, maar nog kwalijker is dat het team niet kan meedenken.

2. Slechte backlog items en / of verkeerde prioriteiten


“Als bezoeker wil ik een homepage op de website zodat ik weet bij welk bedrijf ik terecht ben gekomen en ik verder kan browsen door de site.”

Op het eerste gezicht lijkt er niets mis met dit backlog item. Toch? Als je probeert te achterhalen welke informatie hier nu eigenlijk uit te destilleren valt, dan kom je toch van een koude kermis thuis.

Wie?
Wie is de bezoeker? Wat komt de bezoeker doen? De meest simpele website onderscheid vaak meerdere soorten bezoekers. Zijn het potentiële klanten op zoek naar een product? Zijn het werkzoekenden die willen weten of je bedrijf nog vacatures open heeft? Is het iemand die alleen maar informatie komt inwinnen over de branche?

Wat?

Een homepage is geen functionele wens. Een homepage bevat wél functionele onderdelen zoals een navigatiemenu, een productzoeker, de aanbieding-van-de-week widget, de drie laatste nieuwsberichten en verzin het maar. Maar een homepage op zichzelf is geen goed backlog item.

De verleiding is groot om je backlog te vullen met gegroepeerde onderdelen (zeker als er vooraf al een design gemaakt is). Voor beginnende Product Owners is het erg natuurlijk om de backlog te vullen vanuit een visuele insteek. Je kan ze later echter niet meer los van elkaar prioriteren. Wat als de aanbieding-van-de-week widget straks toch minder belangrijk blijkt te zijn dan het kunnen afrekenen van je online aankopen? 

Er is voor het team en de Scrum Master een taak weggelegd om de Product Owner te helpen met het definiëren van ‘zo dun mogelijke plakjes functionaliteit’. Natuurlijk mogen er onderaan de backlog vage Epics blijven staan, zolang deze maar specifieker worden naarmate ze hoger op de backlog komen.

Waarom? 
De bezoeker wil weten bij welk bedrijf hij terecht is gekomen? Onzin natuurlijk, de bezoeker heeft op een link geklikt of je URL ingetypt en weet dat echt al wel. De bezoeker heeft een doel op je site (en dat doel is niet ‘navigeren’). Achterhaal in dit geval de persona’s van je bezoekers en definieer de bijbehorende doelen. 

Hoe dan?

“Als potentiële sollicitant wil ik snel zien welke vacatures open staan, zodat ik online kan solliciteren.”

“Als klant van de webshop wil ik per categorie, subcategorie en prijsbereik kunnen zoeken door de producten catalogus, zodat ik snel het product kan vinden dat ik wil kopen.”

“Als marketing manager wil ik dat alle bezoekers van onze website de laatste drie nieuws items kunnen lezen zodat wij ze op de hoogte kunnen houden van de vastgoed branche.”

Alle drie bovenstaande user stories zouden uiteindelijk op de homepage van een website tot realisatie kunnen komen. Nu zijn ze echter los te prioriteren, geven duidelijk aan wat het onderwerp en wat het doel is.

3. Technical debt


Het kan lastig zijn om aan een niet-technisch persoon uit te leggen wat technical debt (letterlijk vertaald: technische schuld) is. Dit komt doordat het niet tastbaar is.
 
Het komt nog het dichtst in de buurt van “goedkoop is duurkoop”. Hoe langer het scrum project loopt, hoe meer je rekening moet houden met technical debt. Zie onderstaande tabel:
Zichtbaar Onzichtbaar
Positieve waarde Feature Architecture
Negatieve waarde Bug Technical debt

Een bug hoef je niet te verklaren. Deze is zichtbaar en negatief. Hetzelfde geldt voor een Feature, deze is zichtbaar maar voegt juist wel waarde toe.

Architecture is al wat lastiger. Je ziet het namelijk niet, maar het is er wel en het voegt zeker waarde toe. Een goede architectuur is als de fundering van je huis. Is er iets mis met de fundering, dan stort uiteindelijk alles in.

Technical debt is de ‘schuld’ die je opbouwt door er vandaag de kantjes vanaf te lopen. Door vandaag de Quick & dirty oplossing te kiezen, zodat je deze sprint binnen budget blijft, maar waarvan je weet dat je er in de toekomst (misschien al wel volgende sprint) last van gaat krijgen. 
Technical debt heeft na verloop van tijd vaak de consequentie dat elke bug die je oplost drie nieuwe bugs veroorzaakt, in een Scrum project is dit te zien dat na verloop van tijd de Velocity per sprint steeds verder zal zakken.

Technical debt voorkom je niet door goed te testen, immers de backlog items zijn correct opgeleverd en hebben goed de test doorstaan. Technical debt kun je voorkomen door in je Definition of Done op te nemen dat alle code door een vakbroeder gereviewed moet worden (voldoet het aan de coding standards, is het voldoende gerefactored). Ook al kost dit tijd die niet direct te vertalen is in added value, op lange termijn betekent het happy customers, happy programmers en happy bosses!

Nog even een recap
Natuurlijk zijn er legio andere manieren te bedenken om je Scrum project om zeep te helpen maar in mijn ervaring heeft dit vaak te maken met een ongeschikte PO, een onjuist gevulde/geprioriteerde backlog of technical debt. 
 

Michael Heymans

Smarter results together -> Als lead developer en scrum evangelist probeer ik altijd om samen met mijn team maximale waarde toe te voegen. Niet alleen voor onze klanten maar ook in onze eigen werkwijzen. Ik geloof niet in het dood analyseren van een project maar in een Agilicious aanpak waarin we in incrementele iteraties bouwen, testen en bijsturen.

Reacties ()