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 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. Hij vertelt: “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.”
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.
Klant
Eneco
Markt
Energie & Utilities
Publicatiedatum
13 april 2022
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.
