Soms doet het pijn aan mijn ogen

Over het algemeen sta ik bekend als een positief, enthousiast persoon voor wie het glas half vol is. Deze blog zal anders zijn, omdat ik iets met jullie wil delen waar ik me groen en geel aan kan ergeren: de kennis van sommige mensen op het gebied van Scrum. Want zeer regelmatig kom ik bij organisaties die zeggen dat ze met Scrum werken, maar bij enig doorvragen bijzonder weinig kennis van Scrum blijken te hebben en een aantal essentiële onderdelen van Scrum niet blijken te doen. Een paar voorbeelden.

Een tijdje geleden kwam ik op een nieuw project en de projectmanager vertelde me dat ze met Scrum werkte. Nu heb je in Scrum al geen projectmanager, dus dat was al opmerkelijk. Maar goed, ik vroeg toen wie de Product Owner was, de respons die ik kreeg was: wat is een Product Owner? Toen heb ik maar gevraagd wie de Scrum Master was. Ook die functie bleek niet bekend te zijn. Het enige wat op Scrum leek was dat ze met een Kanbanbord werkte, waarop de taken stonden. Nu is een Kanbanbord, ook wel Scrumbord genoemd, vaak onderdeel van het Scrumproces, maar officieel is het geen onderdeel van Scrum. Anyway, werken met een Kanbanbord is onvoldoende om te zeggen dat je Scrum toepast.

Een tweede voorbeeld is een IT-organisatie die besloot om met Scrum te gaan werken. Eén van de uitgangspunten was dat, ik citeer, ‘de business niets mocht merken van de implementatie van Scrum’. Eén van de essenties van Scrum is dat de samenwerking tussen business en IT verbetert, en dat er meer en intensiever wordt samengewerkt. De business moet er dus juist wél heel veel van merken en worden meegenomen in het hoe en waarom van Scrum!

Het laatste voorbeeld dat ik wil geven is een projectmanager (daar hebben we hem weer!) die me vertelde dat ze Scrum toepaste. In de eerste sprint werden de requirements opgesteld, in de tweede sprint werd de architectuur uitgewerkt, in de derde sprint werd het ontwerp gemaakt enzovoort. Ik weet dan eigenlijk niet waar ik moet beginnen met mijn antwoord.

Hierbij een lijst van opmerkingen of vragen waaruit blijkt dat degene met wie je spreekt weinig weet wat Scrum is:

  • "De projectleider voor dit project is <<naam invullen>>"
  • "Kun je me garanderen dat per <<datum die verder dan 1 maand in de toekomst ligt>> dit-en-dit klaar is."
  • "Het budget voor het realiseren van het systeem is <<bedrag invullen>>"
  • "Ik ben de ontwikkelaar"
  • "Het testen wordt door het testteam gedaan"
  • "Kwaliteit is een afdeling"
  • "In het projectplan staat <<invullen wat je wil>"
  • "Het ontwikkelteam bepaalt wel de volgorde waarin we de dingen realiseren"
  • "Als alles klaar is dan krijgen de gebruikers het wel"
  • "We hebben <<aantal invullen>> sprints nodig om het systeem te realiseren"
  • "We maken eerst de specificaties van het systeem voordat we gaan bouwen."

De real-life cases laten zien dat sommige organisaties zonder goede kennis van zaken zomaar wat roepen en doen. En dat doet pijn aan mijn ogen. Scrum is een samenhangend, complex geheel van maatregelen waar een gedachte achter zit, de agile gedachte. De verschillende onderdelen grijpen op elkaar in en iedere maatregel heeft toegevoegde waarde. Naar mijn mening moet je goede kennis van Agile en Scrum hebben om het toe te passen en als je bepaalde maatregelen niet toe wil passen moet je dat wel goed kunnen onderbouwen. En dat begint dus met een grondige kennis van de methode. 

Moet je dan heel Scrum toepassen om te mogen zeggen dat je Scrum doet? Dat wil ik zeker niet bepleiten, ik heb Scrum regelmatig aangepast aan de specifieke context van een klant. Toen ik een dergelijke case presenteerde op de conferentie Agile Practitioners 2017 in Tel Aviv kreeg ik de vraag: wat zijn de minimale eisen om nog van Scrum te spreken? Dat vind ik een lastige vraag want er is altijd wel een situatie te bedenken waarin een specifieke maatregel beter op een andere manier geïmplementeerd kan worden. Daarom als toegift een lijst van 10 maatregelen die volgens mij van groot belang zijn om goed met Scrum te werken. Maar afwijken van één of enkele van deze punten mag natuurlijk wel, maar dan wel op basis van (zeer) gedegen kennis en ervaring met Scrum en met goede alternatieve maatregelen.

Toegift 1: Lijst van eisen aan Scrum:

  1. Er is een Product Owner die de business vertegenwoordigt.
  2. Er is een Scrum Master die de toepassing van het Scrum Proces faciliteert.
  3. Er is een multifunctioneel team die de oplossing ontwerpt, ontwikkelt en test.
  4. Er wordt geprioriteerd op basis van business waarde.
  5. Er is een product backlog met daarop de features/user stories/use cases die gerealiseerd moeten worden.
  6. Er worden in de komende sprint te realiseren features/user stories/use cases door het team gedetailleerd en begroot (refinement).
  7. Er wordt gewerkt in korte sprints van maximaal 3 weken.
  8. Er wordt iedere 3 weken software opgeleverd die in principe direct te implementeren is.
  9. Er is een definition of done waarin de eisen staan waaraan voldaan moet worden om een feature/user story/use case op done te zetten (en wordt deze definition of done ook toegepast).
  10. Er wordt regelmatig (in principe na iedere sprint) geëvalueerd wat de afgelopen sprint goed ging en wat de volgende sprint anders (hopelijk beter) wordt gedaan.
Jan Jaap Cannegieter

Jan Jaap heeft meer dan 20 jaar ervaring in ICT, vooral op het gebied van testen, requirements en procesverbetering. Daarnaast heeft hij een aantal boeken en artikelen in deze vakgebieden gepubliceerd en spreekt hij regelmatig op (internationale) conferenties.

Volg me op LinkedIn.