Hvis man fornemmer en vis ironisk distance fra min side, så er det korrekt. Det er ikke fordi, at jeg er uenig - på ingen måde - det er mere, at jeg føler at det er nogenlunde lige så banebrydende, som hvis man havde konkluderet at jorden er rund, eller at der i gennemsnit er varmere om sommeren end om vinteren.
Jeg er heller ikke vanvittigt imponeret af grafen. Bevares, der er da nogle gode pointer i den, som man måske nok ville kunne komme til at overse, hvis man glemte at tænke sig om:
- Der er en faldende grænsenytte på den ugentlige arbejdstid (vi økonomer ynder at tale om "grænse-et-eller-andet, og så tænker vi på det, som matematisk orienterede ville kalde den 1. ordens afledte...). Man når med andre ord ikke så meget på den 10. arbejdstime, som på den første.
- Bliver arbejdstiden lang nok, så bliver grænsenytten negativ. Der er altså et punkt, hvor det at arbejde en time mere vil gøre at man når mindre - ikke fordi at man i den sidste time ødelægger noget, at det, som man har lavet i den første time, men simpelthen fordi at effektiviteten af alle timerne i en lang uge samlet set er mindre end effektiviteten af alle timerne i en kort uge.
- Ved en fornuftig planlægning af arbejde, så kan man nå mere end ellers (et væsentlig bidrag til at "scrum"-kurven ligger højere er antagelsen om, at man undgår en pæn portion arbejde uden nytteværdi).
- Nytten af arbejde kan blive negativ - vi kender det selv; der kommer et punkt, hvor det er bedre at gå hjem for at sove, for ellers vil man lave begynde er lave ulykker, som det vil tage længere tid at rydde op i bagefter.
Alle der har prøvet at arbejde i firmaer, som har en vis historie bag sig, ved at firmaerne over tid kommer til at akkumulere en vis mængde overflødige rutiner, formelle som uformelle, som ikke længere bidrager til noget. Ved at indføre scrum udfordrer man relevansen af alle rutinerne, og beskærer eller optimerer dem, hvor nødvendigt. Det er en god ting, og det vil give en større effektivitet - men at sige at scrum er godt af den grund alene, er nok et stort spring, for man kunne have realiseret samme gevinster med konventionelle metoder, ved at arbejde lige så målrettet med procesforbedring, som man gør, når man indfører scrum (i det ligger også, at arbejder man allerede målrettet med procesforbedringer, så er der ikke så stor gevinst ved at indføre scrum som ellers).
Nå, nu har jeg vist uddelt nok verbale øretæver til Scott og Jeff, for jeg tror faktisk at de har fat i noget væsentligt, nemlig: Sustainable velocity. Begrebet ser man flere og flere steder efterhånden, og det må nok ses som en modreaktion til den eufori, som greb alle i starten, hvor det nærmest gik ud på at smide så meget som muligt overbord, for at kunne sprinte hurtigst muligt afsted.
Det morer mig også ganske meget, at se at de to herrer regner sig frem til, at der ikke rigtig er noget merværdi i at arbejde ud over 35-40 timer per uge - det rammer lige ind i den gamle diskussion om vores "korte" arbejdstid i Skandinavien, hvor vi som modsvar altid har hævdet, at det er effektiv tid i modsætning til hvad de andre præsterede, og at det totalt set gav god mening.
I mit første job var jeg anset i et stort, internationalt firma, og der blev vores 37 timers arbejdsuge betragtet med stor skepsis - resultatet var, at vi fik løn for 37 timer, men der allerede ved ansættelsen blev udtrykt en forventning om, at man selvfølgelig arbejdede ca. 10% mere uden kompensation.
Nu var vi ikke dummere, end at vi godt kunne gange og dividere, så vi regnede det selvfølgelig bare ind i vores lønforventning, og så endte det mere eller mindre at med at gå lige op for os.
Det havde derimod den - for firmaet - kedelige effekt, at det var svært at opsuge de fluktuationer, som der kunne være i arbejdsmængden; når vi nåede et projekts afslutning, så var der tit brug for at "give den en ekstra skalle" for at nå i mål, og der var ikke rigtigt noget at hente hos os - vi arbejdede jo alle allerede over, og selvom vi godt kunne arbejde en smule mere over, så var det ikke noget, som endte med at kunne gøre en forskel.
Den anden effekt, som jeg kunne se, var at arbejdet ikke var så intensivt i den tid, hvor vi var der, som ellers. Vi skulle jo alligevel være der til langt ud på aftenen, så vi tog tit roligt i løbet af dagen - der var ingen grund til at koncentrere sig om at blive færdig, for der var jo masser af tid. Det var mærkeligt for mig, for jeg var i min studietid vant til at arbejde målrettet og koncentreret, når jeg arbejdede - men jeg vænnede mig til det. Det var til gengæld hårdt, da jeg skiftede arbejde til et firma, som satte en ære i at arbejdstiden i gennemsnit passede, for da skulle jeg op i gear igen, for at kunne følge med!
Så den gamle sandhed om, at den part, som allerede har sat reserverne ind inden slaget begynder, ofte er den part, som ender med at tabe, gælder også her. Man mister både effektivitet og tilpasningsevne - det bliver sværere at udnytte pludselige chancer og at imødegå uventede trusler. Og deri skal man nok også finde årsagen til at scrum iflg. Jeff og Scott trækker imod kortere arbejdstid - agile metoder er i bund og grund et spørgsmål om effektivitet igennem fleksibilitet.
5 kommentarer:
Hej Bjarne!
Hvordan har du det med projektstyring? Det vil sige at
det sidder en chef og vurdere dig og dine tidsplaner hele tiden. Gør det at du tænker mere på tidsplaner end på programmering?
Interessant spørgsmål!
Lad mig starte med at sige, at jeg normalt skelner imellem projektledere og projektadministratorer. Den første type formår over tid at gøre sig selv mere eller mindre overflødige, ved at give projektgruppen mulighed for at blomste med det ansvar, som den får lov at få. Den anden type vil - medmindre at vedkommende reelt ser sig selv som en støttefunktion - kunne trække hele projektet ned med ligegyldige detajler.
Som det er blevet moderne at sige i de kredse, som kalder sig selv for agile: Beslutninger skal udskydes til det seneste fornuftige tidspunkt. Det betyder, at man ikke skal lægge unødigt detajlerede planer unødigt tidligt, men det betyder også, at man skal lægge de nødvendige planer i rette tid. Så planer og styring er bestemt nødvendigt, og hvis man tror, at det bliver nemmere af at man prøver at give projektet størst muligt manøvrerum ved at vente til det seneste fornuftige tidspunkt, så tager man helt fejl.
Med det af vejen, så lad os lige tage den anden del: Motivations- og ledelsesforskning viser, at der er en modstrid imellem at skulle samarbejde som et team, og så måle deltagerne på individuel performance. Enten performer man som team eller også performer man som individ. Jeg foretrækker helt klart at arbejde i teams, og derfor vil jeg synes at er ærgerligt, hvis der sidder en chef og vurderer dig og dine tidsplaner hele tiden. Det vil reelt være at sabotere de synergismer, som der gerne skulle være i at have et team.
Teams kender jeg ikke rigtig til, fordi der kun er en udvikler på
hver opgave.
At branchen ikke er social har vist sig i tidligere job ved at
fyringsprocenten for udviklere har været meget høj i modsætning til
for konsulenter, hvor der ikke er blevet fyret så mange.
Umiddelbart virker det som om, at cheferne skiller sig af med udviklere, hvis udvikleren ikke har fået 13 i at overholde tidsplaner og i ikke at have lavet nogen fejl. Man vil sælge overfor kunderne, at firmaets udviklerer er verdensmestre.
Lige en ekstra bemærkning.
NAV branchen minder meget om håndværkere. Der kommer jo ikke
et team, hvis en elektriker skal
skifte en pære.
Jeg tror godt, at jeg ved, hvad du mener - det er nok meget menneskelig at ville tilskrive evt. problemer til en dårlig udførelse, hvis man selv har stået for planlægningen, men har andre til at stå for udførelsen. Men det gælder vel også den anden vej rundt? ;-)
Hvis salget svigter, så lyder det måske retfærdigt at fyre sælgerne (for de har jo ikke lavet deres job godt nok!), men hvis man ingen sælgere har, så sælger man jo ikke noget. Så måske er svigtende salg tegn på, at man ikke har sælgere nok?
Nu nævner du selv håndværkere som analogi til udviklere - måske på mange måder et godt billede, men jeg foretrækker personligt nok mere kunstnere, for selvom du kan komme langt med rutine, så skal du altså også have flair.
Det giver så et andet problem, nemlig at man blandt ledere har et ordsprog, at man ikke kan lede, hvad man ikke man måle - og man må erkende, at man ikke kan måle på vidensarbejde (se f.eks. her joelonsoftware:Measurement). Mange begynder så i stedet at måle på indikatorer, men ender som konsekvens desværre op med symptombehandling fremfor noget der bare ligner helbredelse.
Hvilket i øvrigt får mig til at henvise til Wikipedia:Deming (se iøvrigt "Deadly disease" nr. 3) - jeg mener, at han var ophav til tesen om, at man ikke skal justere på et system, som "i kontrol" - man kan kun gøre det værre; systemer ude af kontrol kræver derimod indgriben - og kunsten som leder er at kende forskel (og her vender vi tilbage til starten på diskussionen, og grunden til at jeg ikke kan lide ordet projektstyring).
Så god projektledelse kræver også rutine ... og flair!
Send en kommentar