SCRUM. Je hoort het tegenwoordig overal, ook al noemt men het soms ook wel losjes “Agile”. SCRUM is tenslotte een Agile-ontwikkelmethode. “Agile” is echter veel breder dan SCRUM. Het lijkt nieuw, maar dat is SCRUM niet. Het is de laatste jaren wel veel populairder geworden, omdat doorlooptijden voor softwareontwikkeling door de jaren heen steeds verder op zijn gelopen.
SCRUM en ITIL? Zij die ermee werken zullen misschien denken dat ik nu wel heel verschillende dingen bij elkaar trek, maar om deze link te leggen is niet geheel onlogisch (ik ben niet de eerste). De inrichting van ITIL wordt door medewerkers veelal gezien als een logge, administratieve draak, waar SCRUM zich juist presenteert als een soepele libelle: licht implementeerbaar, snel en flexibel, ofwel: Agile.
Als SCRUM-ontwikkelteam zit je niet te wachten om stapels documenten op te moeten leveren, of administratieve rompslomp door te moeten worstelen, gedurende een sprint. Kan je dan met SCRUM ontwikkelen, in een organisatie waarbij het beheer is ingericht volgens ITIL?
Agile ITIL
Uit de gedrochten van tools beschikbaar, om werkelijk alles binnen een organisatie vast te leggen, lijkt ITIL wel een directe tegenhanger van de Agile SCRUM-ontwikkelmethodologie: ITIL lijkt log en omslachtig. Dat hoeft het echter niet te zijn, wanneer je objectief gaat kijken naar wat je echt gebruikt bij het minimaliseren van risico’s en om een goed overzicht te houden van wat er werkelijk allemaal binnen de organisatie speelt.
SCRUM beperkt zich in basis tot het ontwikkelteam en heeft daarbij wel degelijk gevolgen voor, of omvat taken vanuit, de manier waarop met name Change-, Release- en Configuration Management zijn ingericht. Hierbij zal het SCRUM-team misschien wat meer vrijheid gegeven moeten worden dan men wellicht gewend was, maar SCRUM is geen excuus om alle administratie of voorbereiding los te laten. Ook SCRUM kent een degelijke voorbereiding voordat het werkelijk vruchten kan gaan afwerpen. Denk bijvoorbeeld aan het bepalen wat er in de Definition-Of-Done opgenomen moet worden en de eerste opzet van een product backlog, op zo’n manier dat het team de taken kan oppakken. SCRUM zou echter wel goed de ogen kunnen openen voor een teveel aan administratief werk en pijnpunten waar winst te behalen valt door te standaardiseren of te versimpelen.
Lees ook: http://enterprise.bcs.org/_downloads/agile-whitepaper.pdf
Conclusie
Bij zowel Service Management, performancetesten, als bij vele andere dingen, geldt: bedenk vooraf waarom je het doet en wat je er uiteindelijk mee wilt bereiken. Kijk verder dan alleen de richtlijnen en onderneem geen acties zonder dat je begrijpt waarom het aangeraden wordt. Zorg daarnaast dat de mensen die ermee moeten werken ook begrijpen waarom, zodat ook zij de meerwaarde kunnen zien. Zoals ik in eerdere blogs ook al aangaf: een goede voorbereiding scheelt uiteindelijk veel meer tijd en geld.
ITIL blijft zo zeer waardevol in een ICT-organisatie en belangrijke facetten ervan blijven onmisbaar voor het succesvol opzetten en uitvoeren van (o.a.) performancetesten.
Interessante andere blogs aangaande SCRUM:
- http://confluex.com/blog/why-companies-fail-at-scrum/
- http://www.netobjectives.com/blogs/questioning-large-scrum-failure-rates
- http://gristmillanalytics.com/blog/?p=1965
Tot slot
Bovenstaande links zijn niet bedoeld om mensen af te schrikken van de SCRUM-ontwikkelmethode, maar meer om aan te sporen goed na te denken waarom mee gaan met andere ontwikkelingen op ICT-gebied en wat dit werkelijk voor de organisatie betekent. Niets is zo geldverspillend als blind achter de meute aan te lopen...
