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

“Ons team moet ervoor zorgen dat SAP altijd beschikbaar is voor gebruikers. We lossen incidenten op, doen updates en upgrades, handelen wijzigingsverzoeken af en verzorgen de interfacing naar andere Eneco IT-systemen.”

Wim Priem • Operationeel manager SAP bij Eneco

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 Conclusion consultants in het operationele SAP-team. Bij piekmomenten kan dat aantal worden opgeschaald. Priem: “Dat werkt heel goed. myBrand Conclusion 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 Conclusion geen ervaring heeft op dat specifieke gebied. “Maar in de regel kijken we eerst of myBrand Conclusion 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.”