For nylig deltog jeg i et agilt netværksmøde udenfor min arbejdsplads. Det er altid spændende at møde nye mennesker og høre om deres erfaringer fra deres virksomheder.

Den mest interessante læring jeg tog med mig hjem er: Scrum Boards kan være skadelige.

Det var en kommentar der blev givet i forbindelse med en demonstration af praktisk anvendelse af Rational Team Concert (RTC) i Danske Bank. Kommentaren kom fra en af deltagerne i mødet, som ikke er ansat i Danske Bank.

En af funktionerne i netop et Scrum Board, som deltagerne i projektet bruger i forbindelse med deres daglige Scrum møder. På mødet besvares de 3 spørgsmål og opgaver flyttes rundt og status opdateres. Det er altsammen “pretty straight forward” hvis du spørger mig. Det samme ville formentlig ske i andre værktøjer og endda også hvis man kører analogt med whiteboards, brown paper, post-its eller andre artefakter.

Fordelen ved et Scrum Board er at man løbende kan se “load factor” hos de forskellige personer og dermed kan alle planlægge at hjælpe til i områder hvor der er “overload” eller tilbyde assistance hvis man selv er “underloaded”.

Kommentaren om “Scrum Boards kan være skadelige” gik på at vedkommende havde erfaring med at visse ledertyper anvender denne information i negativ retning. I den pågældende situation havde en leder brokket sig over det manglende “load” på en given medarbejder i meget negativ tone.

Mit ordvalg i ovenstående afspejler måske min holdning til situationen: Det er ikke Scrum Boardet der er skadeligt!

Personligt synes jeg det er dybt forkasteligt at en leder kan finde på at agere som ovenfor. En øget transparens i et team bør altid tages imod med kyshånd – specielt af en udenforstående leder. Indførsel af Scrum, og dermed også Scrum Board, er som sådan ikke det reelle problem.

Viser Scrum Boardet den fulde virkelighed? Der kan være mange årsager til hvorfor en enkel person ikke har afsluttet 5, 10 eller 100 opgaver i løbet af et sprint. Det kan være af personlig karakter (sygdom, familieproblemer, o.ln.) men det kan også være af profesionel karakter – nemlig at vedkommendes opgaver slet ikke er på tavlen!

Jeg har erfaret ved flere lejligheder at folk bliver booket til at deltage i flere projekter eller skal udføre driftsopgaver samtidig med at de kører projekter.

I begge tilfælde vil et Scrum Board der ikke indeholder denne type opgaver give indtryk af en “ikke effektiv” medarbejder.

Løsningen er, naturligvis, at have 100 % allokerede medarbejdere i projektet. Omvendt er det ikke altid en pragmatisk løsning der kan udføres i virkeligheden. I de tilfælde hvor man har aktiviteter udenfor projektet, så bør det noteres og synliggøres så alle (også lederen) får indblik i hvad der foregår.

En teknik til at synliggøre “fravær” fra projektet er at få det planlagt og prioriteret på Sprint Planning. Det kan komme i form af en timebox på “40t driftsupport” der bliver lagt ind i sprintet og prioriteret på ligefod med alle andre opgaver. Udover at det skaber synlighed omkring allokering til projektrelaterede opgaver, så vil det også give en indikation omkring prioritet. Driftsupport har ofte højere prioritet end projektarbejde, hvorfor det også er naturligt at når en medarbejder påtager sig opgaver med det, så må andre assistere og hjælpe med de opgaver der resterer i projektet. Et team trækker på fælles hammel.

Jeg vil meget gerne høre hvis andre har løsninger på ovenstående udfordring. Skriv gerne en kommentar eller send mig en mail.