Hoe de vernieuwing van het IT systeem door een Scrum team op tijd lukte.

Een grote uitdaging: een nieuw distributiecentrum. De voorbereidingen waren in volle gang om binnen een half jaar een nieuw distributiecentrum van een grote retailer te openen. Hiermee zou een veel groter assortiment aan artikelen kunnen worden geleverd aan online klanten.

Een onzekere factor was het IT systeem. Het systeem dat in de al bestaande distributiecentra werd gebruikt, moest grondig worden uitgebreid. Het was al jaren in gebruik en er waren slechts twee mensen die het systeem onderhielden. Alleen zij hadden de kennis om zo’n uitbreiding te realiseren, maar al snel werd duidelijk dat dit met z’n tweeën niet op tijd zou lukken.

De verantwoordelijke IT manager ging aan de slag om mensen te werven. Binnen een maand werden vier mensen aangetrokken die ervaring hadden met de gebruikte technologie. Om op stoom te komen kregen ze stapels documentatie te lezen. Ook spendeerde ze veel tijd aan het doorgronden van de omvangrijke broncode van het systeem.

Het team kwam echter moeizaam op gang. Men hikte erg op tegen een enorme berg werk. Wekenlang werd er niets opgeleverd dat echt werkte.

Scrum hielp orde te scheppen in de chaos.

De twee ontwikkelaars van het eerste uur trokken aan de bel bij de IT manager. Deze besloot om een ervaren Scrum Master te vragen het team te komen versterken. De eerste vraag die de Scrum Master stelde was: ‘wie heeft straks het grootste probleem als dit niet op tijd wordt opgelost?’ Het antwoord op die vraag bleek de logistiek manager te zijn.

In plaats van nog langer documentatie en broncode te lezen werd een sessie belegd met de logistiek manager. Hij nam het team helemaal mee in de business case. Gezamenlijk werd gekeken naar mogelijke oplossingen voor de knelpunten. Op basis hiervan werd een Product Backlog samengesteld, een geprioriteerde lijst van zaken die het team kon opleveren.

In plaats van een onoverzichtelijke berg technisch werk was er nu een duidelijke lijst met items die één voor één konden worden afgetikt. Op de lijst stonden items zoals:

• Ondersteuning van nieuwe productcategorieën.
• Toevoegen van mogelijkheden om producten anders te verdelen over de ruimte.
• Verbeteringen in de routering om orders samen te stellen.

Het slagen van dit project was zo belangrijk voor de logistiek manager dat hij in zijn drukke agenda ruimte vrijmaakte om de rol van Product Owner op zich te nemen. Hij nam verantwoordelijkheid voor de Product Backlog en maakte tijd vrij om regelmatig bij het team te kunnen zijn. Hierdoor kon hij gedurende het traject telkens toelichten, bijsturen en herprioriteren.

Logistiek manager nam team mee naar distributiecentrum

Kort daarop deed de logistiek manager iets dat een cruciale impact op het team had: hij nam het team mee naar een van de reeds bestaande distributiecentra en gaf een uitgebreide rondleiding.

De nieuwe ontwikkelaars zagen voor het eerst de mensen in het distributiecentrum hard werken met het systeem. Daar waar ze zich eerder hadden blindgestaard op abstracties in de broncode, begon het nu echt tot leven te komen. Door de praktijk te ervaren ging de wereld van distributiecentra nog meer voor het team leven. Het enthousiasme en gevoel van urgentie om het traject tot een succes te maken werd enorm vergroot.

Als team uitdagingen aangegaan.

De duidelijke Product Backlog en de verbeterde kennis en teamspirit wierpen al snel hun vruchten af. In vier Sprints van twee weken werd een belangrijk deel van de meest kritische functionaliteit opgeleverd. Het vertrouwen begon te groeien dat het wel eens zou kunnen gaan lukken.

Op basis van het deel van de Product Backlog dat tot dan toe was opgeleverd werd ingeschat hoe lang het resterende deel zou duren. Het bleek helaas nog niet snel genoeg te gaan.

Er was ruimte in het budget om het team verder uit te breiden. Deze optie werd met het team besproken maar stuitte op weerstand. Het inwerken van nieuwe medewerkers zou in dit stadium voor te veel vertraging zorgen.

Onder leiding van de Scrum Master werd gekeken wat dan wel zou kunnen helpen. Er bleek vooral behoefte aan hulp met een specifiek deel van het systeem, waarmee ook de twee oorspronkelijke ontwikkelaars niet bekend waren. Gelukkig kenden ze iemand die hier in het verleden veel aan had ontwikkeld.

Die persoon werkte nu op een andere afdeling, maar kon een deel van zijn tijd beschikbaar worden gemaakt voor het team. Hij hielp wanneer teamleden vastliepen en dacht mee over belangrijke ontwerpbeslissingen. Het resultaat was dat het team voldoende kon versnellen.

Team bleef bij elkaar na oplevering.

Uiteindelijk is het distributiecentrum vlekkeloos in gebruik genomen zonder lange avonden met pizza’s of stressvolle dagen op kantoor in het weekend. Het ging zo soepel dat het als een anticlimax kon worden ervaren. Gelukkig is het succes met het team uitgebreid gevierd, zowel in het nieuwe distributiecentrum als in een goed restaurant.

Na de opening groeide de online verkopen sterk en ontstonden er (noodzakelijke) wensen voor sterke uitbreiding van het IT systeem. Het team was lekker op stoom en kon in stand worden gehouden. Het was voor de logistiek manager qua tijdsinspanning echter niet mogelijk om nog langer zo nauw betrokken te blijven. Hij heeft zijn Product Owner rol geleidelijk overgedragen aan iemand van zijn afdeling die hij hiervoor vrij kon en ook wilde spelen.

Wat kunnen we hiervan leren?

De voornaamste 5 leerpunten van het traject waren:

• De teamleden hadden direct contact met degene die vanuit business de oplossing het hardst nodig had.
• Het team ging naar de plek waar de oplossing werd gebruikt.
• De business bleef gedurende het hele traject aan het stuur.
• Het team kwam zelf met oplossingen om te versnellen; er werden niet zomaar mensen aan het team toegevoegd toen het niet snel genoeg ging.
• De uiteindelijke in productie name werd goed gevierd.

Auteur: Marco Mulder, coach, trainer en consultant bij Zilverline.com.