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.
Forstår ikke helt hvordan man kan se hvem der har løst hvad? Har man navn på opgaver?
Så længe opgaver ligger på Sprint Backlog er der ikke navn på. Når en eller flere personer påbegynder en opgave markeres det typisk på opgaven.
Har tit forsøgt at få folk til slet ikke at have navne på – for at forbedre fællesansvaret, uden den store success.
Når opgaven er løst, er der vel ikke noget at bruge navnet til?
Man kunne måske bare have hver sin farvede magnet så lederne ikke begynder at misbruge det?
Det hedder Security by obscurity og løser ikke det reelle problem.
Der sidder en person som enten ikke gør sit arbejde eller laver noget lederen ikke kender til. Scrum Boardet er blot et medie der har gjort lederen opmærksom på dette.
Ja. Men hele ideén med ikke at have navne på opgaver er noget andet. Jeg tror det vil gavne i nogen grupper hvis alle ejer alle opgaver.
Forstår ikke helt hvordan man kan se hvem der har løst hvad? Har man navn på opgaver?
Så længe opgaver ligger på Sprint Backlog er der ikke navn på. Når en eller flere personer påbegynder en opgave markeres det typisk på opgaven.
Har tit forsøgt at få folk til slet ikke at have navne på – for at forbedre fællesansvaret, uden den store success.
Når opgaven er løst, er der vel ikke noget at bruge navnet til?
Man kunne måske bare have hver sin farvede magnet så lederne ikke begynder at misbruge det?
Det hedder Security by obscurity og løser ikke det reelle problem.
Der sidder en person som enten ikke gør sit arbejde eller laver noget lederen ikke kender til. Scrum Boardet er blot et medie der har gjort lederen opmærksom på dette.
Ja. Men hele ideén med ikke at have navne på opgaver er noget andet. Jeg tror det vil gavne i nogen grupper hvis alle ejer alle opgaver.
//I den pågældende situation havde en leder brokket sig over det manglende “load” på en given medarbejder i meget negativ tone.//
også set andre steder :-/ Typisk når “lederen” ikke deltager på stand-up men bare sidder bag sin skærm og tæller.
Det lyder som noget der skulle tages op på et retrospective, hvis ikke man vil tage den med “lederen” i hverdagen.
//I den pågældende situation havde en leder brokket sig over det manglende “load” på en given medarbejder i meget negativ tone.//
også set andre steder :-/ Typisk når “lederen” ikke deltager på stand-up men bare sidder bag sin skærm og tæller.
[…] opmærksomme læser har gennemskuet at de 3 nævnte procestrin kan mappes direkte over i et Scrum Board der typisk arbejder med opdeling i Todo, Doing og […]