Wat komt er na SCRUM

Hoe ga je verder na SCRUM? DevOps is het logische vervolg. Van releases naar continu opleveren. Van project naar vaste teams. De next level voor IT teams.

3 min Blog Robert van Son 11 juni 2015

In de blog Laten we de IT organisatie niet vergeten stipte ik kort aan dat DevOps en Continuous Delivery inmiddels hun weg hebben gevonden binnen IT organisaties. Toch is nog niet iedereen bekend met deze fenomenen. Tijd voor een korte introductie.

Continuous Delivery vs SCRUM

SCRUM is als projectmethodiek niet meer weg te denken. Veel organisaties hebben hun Prince2 aanpak aan de wilgen gehangen en de overstap gemaakt. Vaak succesvol, soms ook met mindere resultaten. In die laatste gevallen zien we vaak dat men te veel blijft vasthouden aan oude waterval elementen binnen SCRUM. Bijvoorbeeld het blijven eisen van een volledig uitgeschreven Functioneel Ontwerp. Met dezelfde problemen waar men vroeger ook tegenaan liep: veel tijd verspillen aan een document dat vrijwel altijd achterhaald is als het project is afgerond. Was niet één van de principes in het Agile Manifest “Working software over comprehensive documentation”? Of de eis dat een SCRUM project fixed price moet zijn (dat is het van nature al) èn fixed scope. Dat werkte met Prince2 al niet, maar kan ook niet met SCRUM. Maar waar de regels en principes van SCRUM goed worden gevolgd en er tijd is besteed aan het trainen van betrokken medewerkers is SCRUM zeker vele malen succesvoller dan oude waterval methoden. Maar dan? Een SCRUM project heeft een eerste versie van het product opgeleverd. Wachten we dan een jaar om in een volgend SCRUM project versie 2.0 op te leveren? Een jaar waarin de business op de deur staat te bonken om aanpassingen doorgevoerd te krijgen. Zij eisen echt een hogeren release frequentie. Je kunt dan uiteraard vaker per jaar een SCRUM project starten. Maar hoe vaak? Hoe effectief is SCRUM als de business eist dat er maximaal een maand mag liggen tussen idee en opgeleverd in productie? Dan wordt het interessant om te kijken naar Continuous Delivery (CD). Bij CD wordt een zogenaamde pipeline ingericht om de gehele flow van idee (user story) tot en met in beheergenomen productie systemen. De pipeline is de harde kant van CD. In een volgende blogpost zal ik dieper ingaan op hoe zo’n pipeline er voor SharePoint Online uitziet. Maar voor nu: de pipeline is een straat van tooling die het proces van idee, coderen, testen en installeren (al dan niet in een OTAP straat) afhandelt. Geautomatiseerd, wel te verstaan. Als dit goed is ingeregeld, praten we niet meer over een release als een verzameling gerealiseerde functionaliteiten die wordt geïnstalleerd in de omgeving. Een release is het installeren van een enkele user story in de omgeving. En dat met grote regelmaat (indien geëist zelfs meerdere malen per dag).

De voordelen van CD ten opzichte van het periodiek release van grotere updates zijn evident. De business wordt snel voorzien van nieuwe gewenste functionaliteiten en kunnen hiermee zelf ook veel aan slagkracht winnen. IT wordt daarmee echt een onderdeel van het succes van een organisatie, waar het nu vaak een remmende factor is. Business en IT zijn niet meer gescheiden, maar vormen samen het hart van de organisatie.

DevOps

Om volgens CD te werken, moet de IT organisatie veranderen. De mate van samenwerking tussen met name developers en beheerders moet sterk worden verhoogd. Als de pipeline in rap tempo nieuwe releases aanbiedt die niet op productie mogen landen omdat de beheerders het eerst moeten accepteren en vervolgens installeren, ontstaat vertraging in de pipeline. En wordt het effect te niet gedaan. Developers en Operators moeten dus letterlijk worden samengevoegd met DevOps. Alleen als dat één team is, werkt CD. Je creëert dus een team waarin alle rollen zitten en dat full time beschikbaar is. Dat lijkt op één van de uitgangspunten van SCRUM: het werken met vaste teams. Met het grote verschil dat een DevOps team een permanent karakter heeft. Hiermee is het erg geschikt voor organisaties waar de IT intern is geregeld met (grotendeels) eigen mensen. Organisaties waar projectmatig wordt gewerkt met externe partners zullen als ze met DevOps aan de slag willen goed moeten kijken naar de samenwerking met de externe partner. Huur je de specialisten in? Besteed je het hele DevOps team uit naar een partner? Het principe van CD wordt er niet anders van, maar om de voordelen te halen, zul je goed naar je organisatie moeten kijken.

 

DevOpsbg-web

 

SCRUM kan heel goed worden ingezet om de eerste versie van een systeem op te leveren. Hetzelfde team kan vervolgens worden omgevormd tot een DevOps team om met behulp van CD door te ontwikkelen. Op deze manier ontstaat een snelle en effectieve manier om een systeem te maken en met grote regelmaat in lijn met de business en de omgeving te houden. Er kan snel worden gereageerd op veranderingen in de markt. Ook kunnen makkelijker zaken worden uitgeprobeerd. Het is immers snel te introduceren en aan te passen als het niet het gewenste resultaat oplevert. Dit is cruciaal in een omgeving waarin “disruption” het toverwoord is.

Deel je enthousiasme

Robert van Son

Het succes van een IT organisatie hangt steeds minder af van technologie. Commodity software en cloud services zorgen voor een verregaande standaardisatie van de techniek. Adoptie door de eindgebruiker en een IT organisatie die snel reageert op vragen en veranderingen zijn de sleutel tot succes. Mijn passie voor organisatiekunde en techniek drijven mij om samen met klanten op zoek te gaan naar de optimale invulling van IT én de IT organisatie. Grote dromen en kleine stapjes zijn de manier om deze doelen ook echt te realiseren.

Stuur Robert een e-mailBekijk alle blogs van Robert