De ontwikkeling van hét ‘model’; ‘het ei van Columbus!?’

Om direct maar aan te geven, ITIL en Agile Scrum kunnen uitstekend naast elkaar bestaan, sterker nog ze zijn absoluut niet met elkaar in tegenspraak en er is geen sprake van onverenigbaarheid. En in combinatie met Lean IT is het plaatje echt compleet; de organisatiecultuur en de mens binnen de IT-omgeving zijn hierbij twee belangrijke factoren.

Domeindoelen

Scrum is een specifieke manier om resultaten te leveren. Het is een iteratieve, adaptieve en incrementele aanpak en een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Het is voor elke vorm van levering geschikt, ook buiten de IT, en is uitgegroeid tot veruit de meeste populaire Agile-aanpak.

ITIL gaat over de best practice IT-servicemanagement. Het is een holistische verzameling ideeën en processen over hoe IT-services te definiëren, ontwerpen, in productie nemen en operationeel runnen, en met name het continu verbeteren van de IT-serviceverlening als geheel. Dit is bekend als de servicelevenscyclus.

Het operationele oogpunt is binnen ITIL belangrijk, in aanmerking nemend dat de klantwaarde wordt geleverd tijdens de fase serviceproductie (service operation). De operationele eisen dienen vroegtijdig weerspiegeld te worden in de fase serviceontwerp (service design) en worden tijdens de fase servicetransitie (service transition) geconcretiseerd.

Een projectmatige aanpak is onontbeerlijk. ITIL en Scrum zijn dan ook eerder complementair dan tegenstrijdig. De uitdaging is hoe de twee met elkaar omgaan. Een belangrijk ondersteunende aanpak betreft Lean IT als het gaat om continue verbetering en respect voor mensen. Zie de blog: Lean IT gaat verder dan Agile.

De aansluiting

ITIL en Scrum passen uitstekend samen, zelfs op een hoog niveau. Vanuit ITIL-perspectief start Scrum met serviceontwerp en eindigt met het leveren van een IT-service. Eigenlijk begint het steeds weer opnieuw, zeker ook omdat een IT-services zich steeds verder ontwikkeld aan de wensen en eisen van de klant/gebruiker. Dit is waar Lean IT een belangrijke rol speelt; een continue verbetercyclus en een integrale ketenbenadering (met als doel ketenintegratie) en in lijn daarmee een alomvattende aanpak over alle lagen van de organisatie heen (systeemdenken). Zie de blog: Er is altijd wel iets te verbeteren.

Tijdens de ITIL-fase serviceontwerp wordt op basis van een goedgekeurde business case (vanuit ITIL-servicestrategie) de eisen verzameld in de vorm van user stories en geprioriteerd. Het resultaat is de geprioriteerde Product Backlog.

Tijdens de ITIL-fase servicetransitie worden de Product Backlog items (user stories) afgehandeld door timeboxed Sprints van één maand of minder. Iedere Sprint begint met een Sprint Planning waarin de user stories zijn opgenomen voor de volgende Sprint (de Sprint Backlog is een subset van de Product Backlog). De Dagelijkse Scrum (een timeboxed bijeenkomst van maximaal 15 minuten) helpt om de voortgang te volgen en om blokkades (impediments) op te verhelpen en op te heffen. De Sprint eindigt met een Sprint Review (een timeboxed bijeenkomst van maximaal vier uur) waarin de nieuwe/veranderende IT-service formeel wordt aanvaard, gevolgd door een Sprint Retrospective (een timeboxed bijeenkomst van maximaal drie uur) die resulteert in de geleerde lessen voor de volgende Sprint.

De grote uitdagingen

Een van de problemen met het pure gebruik van Scrum is dat er geen directe zorg is voor serviceproductie en de focus sterk gericht is op de utility (het nut); de geschiktheid voor het doel (de functionaliteit die de IT-service biedt om aan een bepaalde behoefte te voldoen). IT-serviceoplossingen worden maar al te vaak ‘over de muur gegooid’ en vooral garantie-aspecten (warranty) van een IT-service (capaciteit, beschikbaarheid, veiligheid en continuïteit) worden buiten beschouwing gelaten en aan het einde van de keten wordt de IT-service nog steeds geleverd zonder de noodzakelijke toegevoegde waarde.

Een van de grote bijdragen van ITIL is dat de operationele aspecten al zijn opgenomen in een vroegtijdig stadium tijdens de fase serviceontwerp, althans zo zou het moeten zijn! Toegepast op Scrum betekent het in ieder geval dat tijdens het opstellen van de user stories en de Product Backlog ook de operationele eisen worden verzameld. Tijdens de Sprint houdt het Scrum Team vervolgens rekening met alle operationele aspecten (bijvoorbeeld infrastructurele, monitoring, incidentafhandeling et cetera). Lean IT ondersteund vervolgens met een aanpak omde klantwaarde te maximaliseren door het minimaliseren van verspilling in de processen en activiteiten.

Change Management & Release Planning

Vanuit operationeel oogpunt fungeert wijzigingenbeheer als de beschermer van de productieomgeving door het (laten) identificeren van risico’s van iedere wijziging en het voorkomen van negatieve gevolgen. Algemeen gesteld valt iedere wijziging op een configuratie-item onder wijzigingenbeheer (bijvoorbeeld de Product Backlog die tijdens de fase serviceontwerp wordt gemaakt). De lastige vraag is in welke mate? Aan de ene kant zal het meer stabiliteit geven en aan de andere kant wordt meer administratie gecreëerd en wordt ingeboet op flexibiliteit.

Het is dus een wisselwerking. Wijzigingenbeheer is ook een belangrijk onderwerp binnen Scrum. Iedere Sprint eindigt bijvoorbeeld met de Sprint Review waarin de Product Owner de Sprint beoordeeld en goedkeurt. Tijdens serviceontwerp fungeert de Product Owner dan ook als poortwachter voor iedere user story (wijzigingenbeheer boven vereisten). Er zijn veel voorbeelden van wijzigingenbeheer, een aantal RFC-plaatsen zijn weergegeven in onderstaande schema.

Om het juiste evenwicht tussen flexibiliteit en stabiliteit te bereiken is het belangrijk om te beslissen wat wel of niet onder wijzigingenbeheer valt en daarenboven dienen de juiste vertegenwoordigingsmodellen toegepast te worden (in verband met governance-regels).

Een aantal voorbeelden:

• Wijzigingenbeheer over de Product Backlog is gedelegeerd aan de Product Owner. Ondanks dat dienen serviceproductieteams ook betrokken te worden om de operationele garantievereisten (warranty) zeker te stellen in de vorm van user stories.
• Wijzigingenbeheer over de Sprint resultaten is gedelegeerd aan de Product Owner en in het geval dat de Sprint wordt opgenomen in een toekomstige release fungeert de reguliere operationele CAB ook als goedkeuring.
• Wijzigingenbeheer over de Sprint Backlog is gedelegeerd aan het Scrum Team; de Product Owner, de Scrum Master en het reguliere Ontwikkelteam.

Geautomatiseerd testen

Gebruik maken van Agile Scrum betekent (meer) frequente releases. Testen is evenwel vaak een echt pijnpunt. Dit betreft veel minder het testen van nieuwe functionaliteiten (hier ligt vaak al voldoende aandacht tijdens de Sprint) maar eerder de regressietesten (controleren of bestaande functionaliteit nog steeds werkt).

Het automatiseren van regressietesten is de sleutel. Teams die werken volgens het zogenoemde ‘test fabriek-’model dienen vroegtijdig betrokken te worden en op basis van de Product Backlog dienen testgevallen te worden ontwikkeld en te worden geautomatiseerd. Veelal zijn dergelijke teams gepositioneerd als een chapter (volgens het Spotify-model); samengebrachte vaardigheden die binnen eenzelfde algemeen competentiegebied werken en worden ingezet over Scrum Teams heen.

De rollen

Scrum kent slechts drie belangrijke rollen: De Product Owner (de ‘stem van de klant’), de Scrum Master (de facilitator) en het Ontwikkelteam (de professionals). ITIL kent vele rollen, in de context van Scrum zijn de rollen Service Owner, Change Manager, CAB en CSI Manager de meest relevante.

De rol van Service Owner versus de Product Owner heb ik in een eerdere blog uitgebreid besproken. Samengevat is het logisch, zeker als het gaat om bestaande IT-services, dat de rollen Service Owner (ITIL) en Product Owner (Scrum) in een en dezelfde persoon is opgenomen. Beide rollen fungeren als ‘stem van de klant’ en kennen de eisen-kant. Zie de blog: Service Owner versus Product Owner.

Kijkend naar wijzigingenbeheer zal de Scrum Master en de Product Owner onderdeel dienen te zijn van de CAB wanneer het gaat om de release van een Sprint. De Product Owner, vanuit het oogpunt van de Sprint Backlog, treedt op als CAB-goedkeurder.

Binnen Scrum is het continu leren een integraal concept. In een Sprint Retrospective worden procesverbeteringen geïdentificeerd en in de Dagelijkse Scrum worden belemmeringen op succes opgeheven. Dit is een verantwoordelijkheid van de Scrum Master. Structurele verbetering van het Scrum-proces dient te worden beschouwd vanuit organisatorisch ontwikkelperspectief en dient onderdeel te zijn van het CSI-register. De Scrum Masters en de CSI Manager dienen op een regelmatige basis contact te onderhouden. Zie de blog: De opmaat voor Agile Service Management.

Als iemand eenmaal heeft laten zien hoe het gedaan moet worden, weet iedereen hoe het moet.

Conclusie

Het gaat om een viertal specifieke onderwerpen om tot integratie te komen van de servicemanagementprocessen (ITIL) met de Agile-aanpak (Scrum), zeker als het om bestaande IT-services gaat, en met de Lean IT-aanpak als het gaat om continue verbetering en respect voor mensen.

Scrum is niet alleen voor ontwikkeling van nieuwe producten in een geïsoleerde wereld. Het is uitgegroeid tot een belangrijke stroming voor twee belangrijke ITIL-aanpakken: serviceontwerp en servicetransitie, zeker als het gaat om bestaande IT-services. Historisch gezien praten deze werelden niet of onvoldoende met elkaar, in ieder geval wordt niet op dezelfde golflengte gepraat. Aan de ene kant de ontwikkelaars en aan de andere kant de operationeel IT-professionals. Dit is de reden voor een geïntegreerde en praktische aanpak over hoe ze bij elkaar te brengen om een wederzijds begrip te creëren hoe beide werelden werken.

Het betreft een totaalvisie op de gehele keten, van het starten van het ontwikkelproces tot en met het in productie gaan van softwarecomponenten en het operationele beheer ervan.

Kortom, we hebben het over DevOps; een aanpak waarbij de communicatie, samenwerking en integratie tussen ontwikkelaars en de operationeel IT-professionals wordt benadrukt maar zich hiertoe zeker niet beperkt.

Download het artikel: Inbedden van DevOps in de organisatie

Binnen het vakgebied IT-servicemanagement woedt een al jarenlange discussie wat het verschil is in diverse rollen. Neem de rol van Service Manager, of de diverse rollen zoals Incident Manager, Availability Manager, Capacity Manager, Change Manager et cetera. Een belangrijk reden om deze rollen in een organisatie te introduceren ligt in het feit dat er een behoefte is vanuit afdeling overschrijdend belang of over verschillende IT-services heen, afzonderlijk van andere rollen.

De rol van bijvoorbeeld Service Manager wordt op veel verschillende manieren gebruikt. Van een generieke term voor iedere manager bij een IT-serviceprovider tot een manager die verantwoordelijk is voor het beheer van de end-to-end levenscyclus van een of meer IT-services. De inhoud van deze rol is erg organisatieafhankelijk. Als het om een IT-serviceorganisatie gaat die diensten aan externe klanten verkoopt lijkt de rol van Service Manager veel op de rol van Product Manager. Dit werkt prima in situaties van grootschalige toepassingen of hosting-diensten.

In het ‘vergelijk’ tussen IT-servicemanagement en het populaire gebruik van Agile Scrum gebruik ik de rol van Product Owner binnen Agile Scrum als uitgangspunt. De Product Owner is degene met mandaat, degenen die de acceptatiecriteria definieert en verifieert of hieraan wordt voldaan, het is degene die enerzijds samenwerkt met het uitvoerende ontwikkelteam en anderzijds samenwerkt met de stakeholders in de organisatie. Kortom, de Product Owner zorgt voor het maximaliseren van de waarde van hetgeen geleverd dient te worden en vertegenwoordigt hiermee de stem van de klant (voice of the customer).

IT-service ontwikkeling

Binnen IT-servicemanagement gaat het primair om het ontwikkelen van een IT-service (los van het feit of het om een nieuwe IT-service of een gewijzigde IT-service gaat) die aansluit op de wensen en eisen van de organisatie. Dit is per definitie een groeipad. Het is een utopie te denken dat een IT-service ‘in een keer goed’ is. Het ontwerpen en ontwikkelen van een IT-service zal zich dan ook altijd in de loop van de tijd verder ontwikkelen. Aansluitend is het belangrijk dat er, nadat een IT-service is geoperationaliseerd, er voortdurende verbeterslagen worden uitgevoerd. Deze context heb ik beschreven in de blog: De opmaat naar Agile Service Management.

De rol van Service Owner

De Service Owner, in lijn met de Product Owner, speelt een belangrijke rol in de ontwikkeling van de servicestrategie en is verantwoordelijk voor de inhoud van de serviceportfolio. De Service Owner vertaalt de organisatievereisten en de producteisen aan bepaalde IT-componenten en draagt zorg voor de levering en exploitatie. Dit kan de Service Owner vanzelfsprekend niet allemaal zelfstandig. Hier komen een of meerdere ontwikkelteams, zoals binnen Agile Scrum gedefinieerd, om de hoek kijken. De Service Owner vertegenwoordigt diverse stakeholders binnen de organisatie, begrijpt de verschillende service-componenten en neemt volgens de standaard definitie deel aan de onderhandelingen of is belanghebbende in diverse onderliggende processen.

Wat betekent dit nou voor de praktische werking voor IT-servicemanagement en de parallelle processen.

De praktische werking

Het verzamelen van de servicelevel vereisten van de klant of het onderhandelen en onderhouden van de SLA’s met de klant is een secundaire rol van de Service Owner. Vervolgens is veelal de servicelevel manager de uitvoerende rol die hier invulling aan geeft. Vanuit de optiek van Agile Scrum ligt de primaire rol bij de Service Owner; de servicelevels dienen namelijk te evolueren en maken integraal onderdeel uit van de Backlog van de betreffende IT-service. Dit geldt ook voor het reviewen van de SLA’s. De Service Owner heeft hierin een primaire rol, los van wie een eventuele SLA-reviewmeeting heeft met de klant.

De verantwoordelijkheid

Vanuit Agile Scrum optiek is de Sprint Review het moment dat er een nieuw IT-service Increment wordt geleverd en het resultaat wordt geïnspecteerd. Directe vervolgacties worden op de Backlog van de IT-service opgenomen. Het kenmerk van een IT-service is dat het gebruik ervan in de loop van de tijd aangeeft of er wel of niet aan de vereisten wordt voldaan. Dit wordt veelal zichtbaar op basis van de diverse verstoringen die zich voordoen, met als gevolg een indicator van (potentiële) kwaliteitsvermindering aan een IT-service.

De vervolgactie(s), nadat er een grondige analyse heeft plaatsgevonden, zullen op de Backlog van de IT-service worden vermeld. In feite ontstaat er een Backlog met verbeterinitiatieven, naast de strategische initiatieven en mogelijk zelfs procesinitiatieven. Een gevolg kan zijn dat er ook drie basistypen Sprints ontstaan: een strategische sprint, een procesactiviteit sprint en een verbetersprint en vanzelfsprekend kunnen hier combinaties in worden gemaakt.

De verantwoordelijkheid van de Service Owner heeft waarschijnlijk ook betrekking op zorgen voor en onderhandelen over de onderliggende contracten en overeenkomsten op operationeel niveau. Zeker in de eerste periode van de ontwikkeling van een IT-service zal de Service Owner zich richten op werkzaamheden die normaliter worden uitgevoerd door (proces)managers die zich richten op beschikbaarheid, capaciteit, configuratie of wijziging.

Hoe verder een IT-service zich zal ontwikkelen en zich een mate van stabiliteit ontwikkeld zal de Service Owner meer en meer slechts gebruik maken van de cijfers die voortvloeien uit het gebruik van de IT-service en ze niet zelf genereren of het eigenlijke werk doen. Het enige wat door de Service Owner vaak dan nog wordt gedaan is in veel situaties beslissen over wijzigingen en de assets & configuraties, of is in ieder geval verantwoordelijk voor het maken of verkrijgen van de noodzakelijke beslissingen.

Dit betekent dat de Service Owner consensus dient te bereiken (als belangrijke stakeholder) met de vaak verschillende Product Owners.

Het vergelijk

De Service Owner heeft in veel opzichten een match met hetgeen de Product Owner doet, in termen van IT-vereisten die betrekking hebben op de exploitatie en het leveren van de IT-service, met een focus op technologische infrastructuur en de operationele procedures. De Service Owner acteert en functioneert tussen de service-unit, business units en product ontwikkeling, met een focus op het vertalen van de bedrijfsvereisten en de producteisen naar acties binnen de IT-serviceorganisatie.

Het is zeer aannemelijk dat de rol van Service Owner en die van Product Owner, zeker als het over bestaande IT-services gaat, is opgenomen in een en dezelfde persoon. Beide rollen fungeren als een ‘stem van de klant’ en kennen de ‘eisenkant’.

Het is aan de organisatie zelf om een keuze te maken hoe de rol van Service Owner wordt gepositioneerd. De Service Owner kan ofwel een fulltime rol/functie zijn, of mogelijk een ervaren systeembeheerder met de juiste kennis over het product of de IT-service, maar altijd wel iemand met uitstekende vaardigheden ten aanzien van de mensen en de business.

Ik ben benieuwd naar hoe jij de combinatie legt tussen de diverse rollen. Ik lees dan ook graag jouw reactie.

Continue verbetering is een veranderingsvorm, gericht op het vergroten van de effectiviteit en/of de efficiëntie van de organisatie ter ondersteuning van het beleid en de (strategische) doelstellingen. Het is daarmee niet beperkt tot alleen kwaliteitsinitiatieven. Verbetering van de bedrijfsstrategie, bedrijfsresultaten en de relaties tussen klanten, werknemers en leveranciers zijn het onderwerp van continue verbeteringsactiviteiten. Simpel gezegd: ‘steeds beter worden’.

Wat kan er beter?

Continue verbetering dient zich te richten op zogenoemde enablers zoals leiderschap, communicatie, middelen, (organisatie)architectuur, mensen en processen – met andere woorden, alles in de organisatie, binnen alle functies en op alle niveaus.

Continue verbetering dient te leiden tot betere resultaten, zoals de prijs, de kosten, de productiviteit, de time to market, de levering, de responsiviteit, de winst en klant- en medewerkerstevredenheid. Er is een tendens dat verbeteringsactiviteiten zich richten op een niveau (afdeling, proces, component e.d.) die de overall bedrijfsresultaten niet verbeteren. Dit leidt tot het verplaatsen van beperkingen of problemen naar ergens anders in de procesketen.

Wanneer kan het beter?

Verbetering gaat niet over het gebruik van een set van tools en technieken. Verbetering gaat ook zeker niet alleen over organisatiebewegingen, het organiseren van verbeterteams en het opleiden van mensen.

‘Verbetering is een gevolg’

Er is sprake van verbetering na een gunstige verandering in organisatieprestaties. Indien de gunstige verandering uitblijft, dan dienen er activiteiten uitgevoerd te worden, op welk vlak dan ook, om de gunstige verandering alsnog te bereiken. De grote vraag is, zijn dit verbeteringsactiviteiten of herstelactiviteiten? Zie hiervoor de blog: Er is altijd wel iets te verbeteren. 

Waarom kan het beter?

Alle managementactiviteit zijn gericht op controle of op verbetering. Managers wijden ofwel hun inspanningen aan het handhaven van de prestaties, het voorkomen van grote verandering of het creëren van verandering; als doorbraak of als verbetering. Wanneer een bedrijf stil blijft staan, verliezen zij hun concurrentiepositie, dus dienen er verbeteringen plaats te vinden om gelijke tred te houden in de vaak complexe bedrijfsomgevingen.

Geen zin? Dan maak je maar zin!

Hoe kan het beter?

Elk systeem, programma of project dient te voorzien in een verbeteringscyclus. Daarom dienen, als een doelstelling is bereikt, de activiteiten gericht te zijn op het identificeren van manieren om het werk (nog) beter te doen.

Continue verbetering wordt uitgevoerd door teams die problemen opsporen, naar oplossingen zoeken of veranderingen doorvoeren. Deze teams kunnen afdelingsgericht of afdeling-overstijgend werken. Voorwaarde is dat het beleid en de (strategische) doelstellingen wordt ondersteund. Dit vraagt een adequaat sturingsmechanisme die de teams naar hun doel leidt, en er vooral voor zorgt dat de omgeving succesvol is!

Conclusie

Continue verbetering heeft betrekking op de gehele organisatie en alles wat het doet. Het dient de hoogste prioriteit te zijn van het uitvoerend management en het succes hangt af van betrokkenheid van de top. Deze toezegging dient duidelijk zichtbaar te zijn. Het is niet genoeg om alleen beleidskaders af te kondigen. Als uitvoerend management haar betrokkenheid niet toont door te doen wat het zegt, kan niet worden verwacht dat anderen zich committeren aan het beleid.