Wat komt er na SCRUM

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.     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.