View Sidebar

Andre sites

Køb Scrum tilbehør og kurser on-line
ScrumMaster.dk shop

Login
 
 

Arkiv for kategori: Scrum at large

Hvordan man IKKE indfører Scrum! – Kapitel 3

Hvordan man IKKE indfører Scrum! – Kapitel 3

cropped-ImprovementLogo832.pngKonstante afbrydelser

Som den tredje måde at sørge for at en indførelse af Scrum mislykkes har vi så: Konstante afbrydelser. Der er dem, der vil sige, at det er den mest udbredte af alle grunde til at Scrum implementering mislykkes. Hvad mener vi med “afbrydelser”.

I den her sammenhæng er der tale om afbrydelser af Teamet, det team i Scrum, der formodes at “committe” (det gode danske ord, vi ikke har) til at levere en vis mængde småleverancer i et Sprint.

Teamet planlægger deres arbejde og går igang. Ikke så snart de er kommet igang, før der dumpes en ny opave på dem, som de også lige skal løse. Jeg mener “der dumpes”, det er som om, det bare er noget systemet gør, der er ikke rigtig en person, der tydeligt tager ansvar for omprioriteringen. Nogle gange går et af teammedlemmerne hen til kaffemaskinen efter en kop mokka og kommer tilbage med sådan en abe på skulderen, Han mødte lige “nogen”. Nogen gange ryger der en telefon ind, eller der kommer en vildfaren e-mail. Det behøver ikke at være af ond vilje, det er sikkert vigtige ting, der skal gøres. Det var bare ikke det, der var prioriteringen.

Andre gange er det selvfølgelig mere direkte og udspekuleret. Især i store organisationer hvor den etiske selv-korrektion, der ligger i små teams er forsvundet, er der folk, der mere eller mindre lever på at hi-jacke ressourcer til egne projekter. De ligner som regel chefer, så Teamet mener jo nok, at de er nødt til at adlyde. Det her falder ofte sammen med, at den slags aktiviteter sjældent tåler for meget synlighed.

Der er også situationer, hvor situationen i foretagendet er så tynget af problemer, at det hele tiden slår tilbage og rammer Teamet. Det kan for eksempel være, hvis man har fået produkter ud i marken med seriøse problemer. Så er man i kaos hjørnet og enten så løber Teamet skrigende bort, eller også må der en håndfast krisestyring til, hvor et team stabiliserer situationen, mens et andet forsøger at finde en ny positiv vej videre.

Ret skal være ret. Der er også Teams, der selv opsøger afbrydelser. Det kan selvfølgelig være at de mangler udfordringer, men det er oftest bare en dårlig vane, man er blevet vænnet fra at koncentrere sig og fokusere. Det synes af mere at zappe rundt imellem opgaver.

Hvad end grunden til afbrydelserne er, så er det ødelæggende for Teamet og fremdriften:

Når afbrydelserne når en vis størrelse, en tommelfingerregel er ca 10%, så holder selvorganiseringen i Teamet op med at virke. “Hvad kan det nytte, der kommer jo alligevel snart nogen med noget andet, vi skal lave”. Efter en vis tid, holder Teamet op med at planlægge og siger ret vilkårligt ja til indhold af Sprints.

Afbrydelserne har også en helt konkret indvirkning. Task-switching er voldsomt dyrt, det koster minutter, ja måske timer at skifte imellem to opgaver. Derudover, så er det også dyrt på kvaliteteskontoen. En afbrydelse får folk til at glemme, hvad de havde gang i, og de glemmer måske det halve af indholdet.

Derfor Scrum Mastere: beskyt Teamet, frem med synligheden, røde lapper på taskboardet. Folk kan så se afbrydelserne, hvor de kom fra osv. Det er forbavsende, hvor meget alene det hjælper. De, der kommer med afbrydelserne, er som regel ikke meget for, at de skal kendes af alle.

Hvis ikke det er nok, så må man som Scrum Master fysisk spærre adgangen til Teamet. Hop ind foran en sådan tidrøver på vej ind til Teamet og spørg med jeres mest uskyldige smil, om der er noget, I kan hjælpe med. I vil opleve at mange af dem er “gået forkert”.

2017-08-19Se mere
Hvordan man IKKE indfører Scrum! – Kapitel 2

Hvordan man IKKE indfører Scrum! – Kapitel 2

Spred frygt, usikkerhed og tvivl!

Tæt efter nummer et på listen over effektive måder at afspore indførelse af Scrum på finder vi en gammel klassiker: Den går ud på at sprede frygt, usikkerhed og tvivl. På engelsk kalder man dette princip FUD (Fear, Uncertainty and Doubt), og spredningen af den slags er en klassiker blandt store IT leverandører.

2017-08-18Se mere
Hvordan man IKKE indfører Scrum! – Kapitel 1

Hvordan man IKKE indfører Scrum! – Kapitel 1

The most common way to fail in introducing Scrum is to call it Scrum, but to bastardize it beyond recognition. It can happen out of ignorance as well as with evil intent of proving Scrum to be a bad idea.

2017-08-17Se mere
Nyt agilt bibliotek

Nyt agilt bibliotek

Her er vores sidste version af det agile bibliotek

2017-01-08Se mere
Hvordan det ikke gøres …

Hvordan det ikke gøres …

Jeg har flere bøger i serien “XYZ for dummies” og “The complete idiot’s guide to XYZ”. Det er nok symptomatisk for, at vi alle gerne vil have nogle hurtige løsninger, og det skal helst ikke være sværere end at læse en tegneserie.

2016-11-06Se mere
Hvorfor sander en Scrum process til?

Hvorfor sander en Scrum process til?

Nu har jeg efterhånden været igang med Scrum i mange år, og det er stadig spændende, især når man ser, at det kan flytte milepæle. Men jeg bliver ved med at undre mig over, hvorfor det så let sander til. Hvorfor det er så svært at holde fast i mønstret og processen? Hvad er det, der trækker så hårdt i organisationer for at komme tilbage til de gamle vaner?

2014-11-02Se mere