Dit artikel is onderdeel van de themareeks BI & Techniek, bedoeld om de meer technische aspecten van BI voor het voetlicht te krijgen. Het is geschreven voor project-managers en ontwikkelaars binnen de BI, die zich afvragen hoe agile zich in de BI-praktijk staande houdt.
SCRUM
In ons vorige blog vertelden we dat we alweer flink wat jaren succesvol met SCRUM werken. Er waren toentertijd meerdere redenen om SCRUM te introduceren. Eén van die redenen was het goed beleggen van ‘rollen en verantwoordelijkheden’. In dit blog gaan we hier verder op in.
Rollen: veel is weinig
In vergelijking met andere methodes (Prince2: negen rollen, RUP: negen rollen, DSDM: tien rollen) heeft SCRUM slechts drie rollen gedefinieerd: ProductOwner, Teamlid en SCRUMmaster. Dit lijkt misschien wat weinig, waardoor je zou kunnen verwachten dat de rollen en verantwoordelijkheden in SCRUM niet goed belegd worden. Het is heel menselijk om alles in regeltjes vast te willen leggen, op papier te zetten, te tekenen met bloed en dan te denken dat alle gaten gedicht zijn. Dat voelt fijn, zeker en rustig. Helaas worden in de praktijk alle rollen van Prince2, RUP of DSDM zelden goed ingevuld. Zeker in onze cultuur, waar ‘de werkvloer’ niet zo op het naleven van formaliteiten en regeltjes is. Prince2 is niet voor niets een Engelse uitvinding.
Door te stellen dat we een methode gebruiken die in alles voorziet wordt een vals beeld van veiligheid gecreëerd als we die methode in de projectpraktijk niet goed invullen of naleven. Als rollen niet goed worden ingevuld of dubbel worden gedaan, laat men in werkelijkheid juist zaken liggen. En als het dan fout loopt, wijzen we naar elkaar met de -met bloed - ondertekende contracten.
Een rol versus 'commitment'
We verwezen in ons vorige blog al naar het 'Agile Manifesto'. Deze stelt in het kader van ons blog-onderwerp:
• 'Individuals and interactions OVER processes and tools'
• 'Customer collaboration OVER contract negotiation'
Het blijft knap hoe zij met die korte statements, toch zoveel waarheid kunnen uitspreken. Wat mij betreft zouden ook vooral grenzen helder gemaakt moeten worden en zeker ook bewaakt moeten worden (de SCRUMmaster voor de processen, de ProductOwner voor de producten). Hiernaast is echter iedereen verantwoordelijk voor het eindresultaat en dat moet ook zo voelen. Als je dat weet te creëren dan zie je dat verantwoordelijkheid gepakt wordt om tot dat eindresultaat te komen. De sleutel ligt hier in het kunnen en willen committeren.
Als het SCRUM team zich ergens aan wil committeren (de sprint), dan moeten ze zich hierbij veilig voelen. De voorwaarden om het voor mensen mogelijk te maken om zich te kunnen committeren aan een sprint, zullen dus wel geschapen moeten worden. Hierbij speelt in eerste instantie de ProductOwner een belangrijke rol. Hij of zij moet zorgen dat voldoende stories ingeschat en geprioriteerd zijn. De stories moeten van voldoende kwaliteit zijn om een realistische inschatting te kunnen maken, die door het hele team gedragen wordt. Als er onvoldoende stories aanwezig zijn om ingeschat te kunnen worden, omdat ze bijvoorbeeld niet aangeleverd worden of het team ze niet voldoende begrijpt, dan kan een sprint NIET starten. Voorkom het tegen wil en dank inschatten van halve/onduidelijke stories om zo tóch een sprint te kunnen starten, bijvoorbeeld omdat de organisatie grote druk op het team legt. Doe je dat toch, dan zal er uiteindelijk zoveel onzekerheid in de sprint zitten, dat het team zich niet kan committeren. Natuurlijk voorziet de SCRUM-puntenschaal in bepaalde vorm van omgaan met onzekerheid, maar onzekere stories zullen snel ‘epic’ worden (en daardoor niet in een sprint passen).
Creëer rust
Daarnaast is het belangrijk om rust te creëren. Een SCRUM team kan zich niet ergens aan committeren als er steeds ingebroken wordt in een sprint.
- Om te beginnen zorgen wij ervoor dat vóór de start van de sprint, alle stories minimaal langs de checklist 'Definition Of Ready (to start)' zijn gegaan. Hiermee stellen we zoveel mogelijk zeker dat aan alle randvoorwaarden is voldaan. Als een story bij sprintplanning 2 nog niet aan de Definition of Ready voldoet, belandt hij niet in de sprint.
- Vervolgens zijn we erg strikt op de regel dat als de sprintbacklog is vastgesteld deze met rust gelaten wordt. In deze bewegelijke wereld is het heel verleidelijk om toch nog even iets te wisselen of ergens iets tussen te proppen. Met als argument: ‘dat kost toch maar een uurtje?’. Maar al die 'ene' uurtjes en de inefficientie door het vele verlies van focus bij elkaar opgeteld, kost je uiteindelijk toch de sprint. Het helpt om de ‘heartbeat’ van de sprints niet te laag te houden. Elke twee weken (of sneller) een sprint, biedt vaak voldoende mogelijkheid om snel te kunnen anticiperen en eventueel die fix of aanpassing uit te voeren. Door de heartbeat hoog te houden en je sprints te halen, zul je automatisch het vertrouwen winnen en acceptatie krijgen op het 'niet-inbreken' in de sprints.
- Wanneer deze verstoringen toch optreden dan is het aan de SCRUMmaster om dit terug te duwen. Trap hierbij ook niet in de val van het combineren van de ProductOwner en SCRUMmaster rol, want een belangenverstrengeling zal snel optreden.
Strikt zijn helpt
Wat ons betreft mag dit spel best hard gespeeld worden. SCRUM kent maar een paar simpele regels, dus naleven moet niet al te moeilijk zijn. Ondanks waarschuwingen van onze kant, moeten onze SCRUMmasters in de praktijk nog vaak verstoringen terugduwen en maken we het nog steeds mee dat onvoldoende (op dat moment geschikte) stories voorradig zijn. Als die situatie voortduurt, kan het (bij een interne ICT-omgeving) soms helpen om een keer een sprint te vullen met ‘eigen’, maar natuurlijk wel zeer nuttige, stories zoals performance & proces verbeterende items. De SCRUM-puristen onder ons zullen dit misschien beschouwen als ‘niet SCRUM’, het is immers niet de expliciete wens van de ProductOwner. Maar naar de ProductOwner en achterliggende organisatie toe, geeft het wel duidelijk het belang aan van een goed gevulde en geprioriteerde backlog en wie daarvoor moet zorgen.
SCRUM is niet een heilige graal, maar de 'simpele' rolverdeling biedt weinig plekken om je te verstoppen en legt daarmee vaak de vinger op de zere plek. Volwassen worden met vallen en opstaan is onvermijdelijk en hoort erbij, zolang je daarvan kan leren.
