Klantverhaal

DevOps werken bij Eneco

“We combineren Scrum en Kanban op onze eigen Eneco-wijze”

Dat Scrum niet alleen waarde heeft in Dev-omgevingen, maar ook gebruikt kan worden in een Ops-wereld, is al langer bekend. Toch worstelen veel softwarebeheerteams met een juiste implementatie van Scrum en DevOps in beheeromgevingen. Zo niet Eneco. Het SAP DevOps Team deed een jaar of vijf geleden de eerste ervaring op met Kanban. Daar werd later Scrum aan toegevoegd, waarna van lieverlee een eigen ‘Scrumban’-methodiek is ontstaan die helemaal past bij de behoeften van de organisatie. myBrand levert vast vier tot vijf mensen aan het team en kan snel opschalen in tijden van piekbelasting. Wat maakt deze werkwijze zo succesvol?

We vragen het Wim Priem, operationeel manager SAP bij Eneco. Hij heeft daarnaast ook een rol als agile coach in het SAP DevOps Team.

Het team bestaat uit zestien mensen, circa elf fte. Tot 2017 werkte het op een traditionele manier. Priem was eindverantwoordelijk, maar wist niet precies welke teamleden waar mee bezig waren. Gemiddeld duurde het toen 78 kalenderdagen voordat een wijzigingsverzoek live was gebracht.

Introductie Kanban en Scrum

In een poging overzicht te creëren en de business beter te informeren over de opleverdatum van wijzigingen, besloot het team Kanban te introduceren. “Er kwam een Kanban planbord, waardoor het zo broodnodige inzicht in de status van het onderhanden werk ontstond. En het werk werd anders verdeeld”, zegt Priem. “De essentie van Kanban is dat je de hoeveelheid werk die je aanneemt limiteert. Ons team is gemiddeld twee uur per dag bezig met incidentenafhandeling. Dat betekent dat er van de veertig uur in een fulltime werkweek nog maar dertig overblijven voor wijzigingsverzoeken en grote projecten zoals upgrades. Als een teamlid drie dagen per week wordt ingepland voor een groot project, dan blijven er dus nog maar twee keer zes uur over voor kleinere wijzigingsverzoeken. We planden mensen nog slechts in voor twee van die kleinere wijzigingsverzoeken tegelijkertijd, want anders werd het te veel. Op die manier zorgden we voor focus.”

Na een paar jaar op deze manier te hebben gewerkt, kwam er een nieuwe afdelingsmanager die ervaring had met Scrum. Iedereen kreeg een Scrum-training, er werd een externe Scrum-coach ingehuurd en het team ging volledig volgens de regels van Scrum werken. Maar al snel liepen ze tegen beperkingen aan, zoals het verdelen van expertise over de Scrum-teams en het feit dat de business geen product owners vrijmaakte voor die taak. Daarom heeft het team een aantal Scrum-principes losgelaten (zie kader) en een mengeling gemaakt van Scrum en Kanban. Deze eigen werkwijze noemen ze gekscherend ook wel Scrumban.

Zeer flexibel inspringen op behoeften

Het belangrijkste voordeel van de eigen Scrumban-werkwijze is dat het team heel flexibel is geworden om in te springen op behoeften die plotseling ontstaan. En dat is nodig, zegt Priem. “Vroeger stond ons team redelijk op zichzelf. Het werk was overzichtelijk en we konden het relatief goed plannen. Maar op een gegeven moment kregen we nieuwe taken erbij. Zo werden de assets bij consumenten thuis (denk bijvoorbeeld aan de slimme meters) ook opgenomen in SAP. Ons team kreeg dus asset management erbij, wat veel werk met zich meebracht. Bovendien kwamen er meer en meer interfaces naar andere IT-systemen, waardoor we vaker betrokken worden bij andere projecten die een change request in SAP tot gevolg hadden. En tot slot verandert de wereld om ons heen steeds sneller. Neem bijvoorbeeld kleine energiemaatschappijen, waarvan er enkele  failliet zijn gegaan. Dan moeten Eneco heel snel in staat zijn om ineens enkele tienduizenden klanten over te nemen. Dat verstoort de planning natuurlijk behoorlijk en daar moeten we goed mee omgaan.”

Niet te veel plannen

De zelf bedachte Scrumban-methode biedt die flexibiliteit. Priem: “Eén van de dingen die we namelijk relatief weinig doen, is exact plannen. Idealiter zou je dat wel doen, zodat je ook vooraf bijvoorbeeld tijd kunt reserveren bij de business om wijzigingen te testen. Maar omdat we met zoveel onvoorziene zaken te maken hebben, zouden planningen heel vaak wijzigen. Dus of je er dan zoveel mee opschiet, weet ik niet. Natuurlijk betekent minder plannen dat we soms wat langer moeten wachten totdat de business tijd heeft gevonden om een wijziging te testen. Maar zo lang iedereen daar vrede mee heeft, is dat niet erg. Bovendien stemmen we bij wijzigingen die haast hebben wat vaker af met de business. We gaan er flexibel mee om en dat werkt goed.”

Waar het team ook flexibel mee omgaat, zijn de werktijden. “Zo af en toe komt het werk nu eenmaal in golven, dus de ene week werk je wel eens 45 uur en de volgende 35. Ook dat laat zich ook niet altijd helemaal plannen. Bovendien gaat de ene medewerker hier makkelijker mee om dan de ander. Het fijne aan onze flexibele methode is dat die zich hier naadloos aan aanpast, juist omdat we niet al te veel plannen.”

Opschalen bij piekmomenten

Standaard zitten er vier tot vijf myBrand consultants in het operationele SAP-team. Bij piekmomenten kan dat aantal worden opgeschaald. Priem: “Dat werkt heel goed. myBrand past zich aan aan onze werkwijzen. Omdat consultants die tijdelijk worden ingehuurd makkelijk even te rade kunnen gaan bij collega’s die onze werkwijze goed kennen, maken zij zich de Eneco Scrumban-methode snel eigen. Wij hebben er daardoor eigenlijk geen erg in dat het voor buitenstaanders best even wennen kan zijn dat we DevOps en Scrum zo anders toepassen dan hoe het volgens de theorie hoort.”

Soms haalt het team van Priem expertise elders vandaan, bijvoorbeeld als myBrand geen ervaring heeft op dat specifieke gebied. “Maar in de regel kijken we eerst of myBrand kan bijspringen als we snel moeten opschalen, temeer omdat we weten dat de onboarding dan heel snel gaat.”

Advies voor DevOps in SAP-omgeving

Priem kan zich goed voorstellen dat andere organisaties worstelen met de implementatie van DevOps in een SAP-omgeving. Want het Dev-deel vereist heel andere dingen dan het Ops-deel. Voor die organisaties heeft hij wel een advies. “Begin gewoon met het uitrollen van de theorie in jouw praktijk. Dan zie je vanzelf welke concepten vanuit de theorie niet passen bij jouw bedrijf. Bedenk daarvoor een alternatief. Gooi niet rücksichtsloos dingen weg, want er is wel een reden waarom die zijn bedacht. Bedenk hoe je die reden op een andere manier invult.”
Een goed voorbeeld is het weglaten van de product owner-rol. Als je operationeel beheer op SAP doet, dan zit je zelf per definitie al heel dicht tegen de business aan. Maar krijg je een keer een wijziging op een nieuw proces waar je minder feeling mee hebt, dan zou je op dat moment wél een product owner vanuit de business erbij kunnen betrekken. “Want”, zegt Priem, “je moet kijken wanneer iets toegevoegde waarde heeft. Doe het pragmatisch. Bespreek expliciet met het hele team hoe jij invulling geeft aan concepten binnen Scrum of Kanban die niet goed passen bij jouw bedrijf. Want als je dingen zomaar weglaat, dan verwatert het en behaal je de voordelen niet meer.”

Beperkingen aan Scrum in een DevOps-omgeving

Scrum is een methode voor softwareontwikkeling die bij uitstek goed past bij Development-omgevingen: het ontwikkelen van nieuwe software die van de grond af aan moet worden opgebouwd. De methode biedt ook meerwaarde in Operations-omgevingen, waar wijzigingsverzoeken de basis vormen van iedere vorm van softwareontwikkeling. Maar lang niet alle Scrum-principes komen daar goed tot zijn recht. Waar liep Eneco tegenaan?

Geen product owners

Het SAP Operations Team van Eneco kreeg het niet voor elkaar dat er product owners werden vrijgemaakt. “De business was gewend dat wij zelf ons werk prioriteerden. Dat kunnen wij goed, want we zitten dicht tegen hen aan, we begrijpen hun processen en kunnen de urgentie van wijzigingsverzoeken goed inschatten. Het was dus ook niet zo gek dat de business de noodzaak er niet van inzag om hier een rol in te vervullen. We werken nu dus gewoon, zoals we eerder ook al gewend waren, vanuit een backlog en prioriteren zelf het werk”, zegt Priem.

Scrum-team per change

Een ander struikelblok was de indeling van de Scrum-teams. In het SAP Operations Team werken zestien mensen verdeeld over ongeveer elf fte. Voor veel specifieke taken is slechts één specialist aanwezig. Een voorbeeld daarvan is het toekennen van autorisaties. Als je zestien medewerkers verdeeld over twee Scrum-teams, aan welk team wijs je dan de autorisatiespecialist toe? En hoe organiseer je het als het andere team autorisatie-expertise nodig heeft? “Dat bleek veel te ingewikkeld, dus we hebben de vaste Scrum-teams losgelaten”, zegt Priem. “We werken nu met een klein Scrum-team per change. Bij kleine wijzigingen bestaat het team soms uit slechts één of twee mensen. Hoe groter de wijziging en hoe meer verschillende soorten expertise nodig zijn, hoe groter het team.”

Geen daily stand-ups en retrospectives

Omdat medewerkers niet iedere dag werk verrichten voor een bepaald Scrum-team, zijn de daily stand-ups afgeschaald naar twee per week, plus een vaste planningssessie. “Omdat je soms wel aan vier Scrum-teams tegelijkertijd bent toegewezen, zou je anders meer aan het stand-uppen zijn dan aan het werk”, vindt Priem. “We zorgen dat we het werk onderling goed afstemmen. Dat kan vaak prima op een andere manier dan iedere dag een kwartier met alle betrokkenen tegelijk vergaderen.”

Ook de retrospectives zijn losgelaten. Priem: “Een retrospective kijkt naar hoe het team samenwerkt. Bij ons werken de meeste mensen al jarenlang in het SAP DevOps Team. Dan hoef je niet iedere twee weken te reviewen hoe je de onderlinge samenwerking kunt verbeteren.”

Reviews pas bij oplevering

Reviews op de productkwaliteit zijn er wel, maar niet na iedere sprint zoals Scrum voorschrijft. Want je kunt bij Ops-werkzaamheden geen minimal viable product live zetten wat je vervolgens sprint na sprint verbetert en uitbreidt. Pas op het moment dat een user story af is, is het zinvol om een review te doen. Priem: “Natuurlijk zijn we wel tussentijds kritisch op elkaars werk. Maar we plannen geen vergadermomenten in om het vergaderen. We kijken wanneer het nut heeft om een tussentijdse review te plannen en wanneer niet.”

Interesse of meer informatie over onze oplossingen of diensten? Neem contact met ons op.

Adviesgesprek aanvragen