Misbrug af Scrum
See this blog post in English using Google Translate
Jeg har bemærket at mange tager enkelte dele ud af scrum og putter ind i den klasiske command and control model og kalder det så derefter scrum, hvilket jeg syntes er meget forkert. Det vil jo svare lidt til at jeg tog en rat fra en Mercedes og puttede ind i Lada og derefter kaldte min Lada for en Mercedes. Hvis jeg så har nogen med ud og køre og jeg fortæller dem at det er en Mercedes og de syntes den ikke levet op til det de toede Mercedes var, så har jeg jo lige sørges for at de aldrig vil købe en Mercedes. Jeg har altså givet noget et dårligt lys på falske påstande.
Jeg vil her forsøge at liste nogle af de ting jeg kan se der bliver pillet ud af Scrum og brugt i en klasisk command and control model, hvorefter man siger at man bruger Scrum.
Sprint
Dette bliver mange gange misforstået som at sprint blot er øget frekvens af releases. Dvs. istedet for at man før fx havde release hver halve år har man nu hver 14 dag. Det er jeg ofte ser er så bare at man ikke er konsekvent omkring hvad der så skal ligge af arbejde i sprintet. Dvs man holder et sprintopstartmøde hvor man siger “vi vil have det er det med i dette sprint”, men dagen efter sprintopstart ser planen ofte helt anderledes ud, og når man når til sprintslut så er det begrænset hvad der er blevet løst af de ting der blev aftalt ved sprintopstart. Det betyder altså at man holder et møde hvor man aftaler noget, men som man ikke overholder. I princippet er tiden brugt på dette opstartsmøde så spildt!
Daily Scrum
Dette møde skulle gerne være hvor teamets deltagere i fællesskab skal planlægge dagen arbejde, ala “hvis nu jeg tager den her så kan du tage den her og så kan vi lave den der i morgen”. Men jeg ser mange gange at det møde slet ikke et teamets møde men projektleders møde, et tidspunkt på dagen hvor han lige kan finde ud af hvad folk laver (control), så kan lettere kan give styre hvad han syntes folk skal lave (command). Så Daily Scrum er for en klassisk command and control projektleder en gave, fordi han nu hurtigt, let og dagligt kan få den information han skal bruge for at kunne styre hvad der skal laves. Og denne projektleder kan gøre det i skyggen af Scrum for han henholder sig jo bare til at dette Daily Scrum jo er en del af at køre Scrum, han glemmet bare at han som projektleder ikke er en pig, men en chicken.
Scrum Master
Jeg ser ofte at ScrumMaster titlen bliver brugt som et skjul for projektlederen. Skjul på den måde at han han trække i den forklædning og så kan praktisere sin normale command and contol praksis, med formaning om at det jo er Scrum. Det at være Scrum Master er for mig at se ikke en leder af teamet, men mere en assistent, der har til opgave at sørge for at teamet hele tiden har optimale forhold til at yde deres bedste i.
Jeg kan se din pointe, og ifølge SCRUM så er project manager en Chicken. Dvs. at projekt lederen i realiteten kun må deltage i Sprint Planning & Sprint Review.
Er dit syn ikke ud fra en bestemt ledelsesstil? En leder kan jo godt deltage aktivt og producere/udvikle på linje med alle andre, samtidigt med at han/hun er 100% commit’ed til projektet.
I den forstand indtager lederen samme rolle som alle andre Pigs, men vil være bedre egnet til at fjerne impediments end en SCRUM master, da han har overblik og viden fra hans erfaringer som projektleder.
SCRUM masteren derimod, skal kunne gøre opmærksom på når nogen bryder mod processen. Jeg tror noget af det vigtigste inden man forsøger at indføre SCRUM, er at, både skriftligt & fælles, definere et regelsæt for hvordan SCRUM skal bruges, inden den tages i brug, så alle har en chance for at blive enige om hvordan processen køres.
Hvis sprintplanning (sprint opstartsmødet) går i vasken ved at projekt manager dikterer hvad der skal laves i det næste sprint, så har man ikke anvendt planning game, eller i det mindste den demokratiske process som det bør være. Det kunne i dit eksempel være derfor at estimeringen fejler.
Hvad forstår du ved Command & Control?
Mvh.
Lasse Finderup