Er alle timer ens?

Billedet til højre stammer fra Jeff Sutherlands blog-post "The Maxwell Curve: Getting more production by working less!", hvor han henviser til venture capitalist ved navn Scott Maxwell, som er kommet frem til den banebrydende konklusion, at man kan nå lige så meget ved at lade folk arbejde 40 timer om ugen, som hvis man presser dem til at arbejde 60 timer om ugen - ja, faktisk kan man få dem til lave endnu mere på de 40 timer, hvis man giver dem gode betingelser for deres arbejde!

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:

1. 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.
   
2. 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.
3. 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).
4. 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.
   

Men derudover, så er kurverne i grafen alt for pæne og runde til, at det giver mening, at have så præcise tal på akserne - der der tale en principskitse, og der er ingen form for videnskabelig evidens bag (vi har kun Scott Maxwell og Jeff Sutherlands ord for det, og der er ingen indikation af, hvordan de er kommet frem til deres tal!).

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.

Usikkerhed og uenighed

Engang for efterhånden nogle år siden, sad jeg og legede med et Hypercard stack - en fascinerende samling af noget, som blev kaldt "hypertext", og som blev kædet sammen af såkaldte "hyperlinks". Konceptet er i dag blevet så almindeligt, at vi ikke længere tænker over det, men dengang kan jeg huske, hvordan jeg blev fascineret over at starte en rejse et sted, og så via få hop, havne et helt andet sted.

Og det er lige sket igen - jeg startede egentlig med at trævle de mange blogs, som jeg følger med i, igennem for at se, om der skulle være noget interessant. Og så pludselig via et par mere eller mindre tilfældige hop, så mødte jeg pludselig noget, som kaldes "Stacey matricen" - og den vil jeg godt fortælle lidt mere om her (jeg har lige mødt den, som en god omgang snusfornuft og sund kildekritik, vil nok være på sin plads, min kære læser!).

Stacey-matricen har to dimensioner: Usikker/sikker hhv. uenig/enig.

Sikkerhedsdimensionen går på, om det er noget, som man har prøvet før mange gange før, eller om man er på vej ud i ukendt farvand - enighedsdimensionen går på, i hvor høj grad alle involverede parter har samme opfattelse af, hvad der skal til.

Hvis man accepterer dette landkort, så er der en række regioner:

Sikker/enig: Man er enige om, hvad der skal laves, og der er er ingen tvivl om, hvordan det skal gøres. Man kan bygge på tidligere erfaringer, og det er sådan set bare om at komme i gang.

Usikker/enig: Hvad der skal laves er klart, men hvordan er mere usikkert. Hold fast i visionen, og lav så plads til eksperimenter med hvordan det skal laves. Gør plads til prototyper, og "vildmænd".

Sikker/uenig: Der er styr på teknikken, men der er ikke enighed om, hvad der skal laves. Tilgangen skal her være politisk.

Ovenstående tre kendetegnes ved at være relativt uproblematiske rent metodemæssigt. Hvis man udviser situationsfornemmelse og snusfornuft, så er ikke specielt kompliceret. Det er også her, at mange lærebøger og metodikker boltrer sig.

Men helt ude i den anden yderligehed befinder sig:
Usikker/uenig: Her er kaos. Der er ingen enighed om, hvad som skal gøres - og slet hvis den var der, så er der ingen, som har prøvet det før. Man er kort sagt på Herrens mark.

Imellem den sikre grund med de første tre situationer, og randen af det kaos, som skitseres af den fjerde situation, befinder der sig i Stacey's tankegang en stor gråzone af komplekse situationer. Hvor kaoszonen kan være nedbrydende, og derfor noget, som man sandsynligvis vil forsøge at arbejde sig ud af (man kan også vælge at forsøge at ignorere den, og håbe på det bedste - vel en meget menneskelig, men nok ikke særlig hensigtsmæssig strategi), så er kompleksitetszonen et område, hvor der i gode tilfælde sker udvikling og innovation. Ulempen er, at man er dårligt hjulpet rent metodemæssigt.

Læs f.eks. mere om Stacey-matricen her (god beskrivelse, flot grafik), her eller her (lidt længere - har til gengæld til sidst et forsøg på at give gode råd til, hvordan kan navigerer det ukendte farvand).

Hvad kan vi så bruge denne tankegang til? Tjo, jeg vil jo mene, at vi i IT-branchen har en tendens til at koncentrere os så meget om "hvordan"-delen, at vi i høj grad - bevidst eller ubevidst, har en tendens til at ignorere "hvad"-delen. Eller i Stacey's termer, så kan vi håndtere usikkerhed, men forudsætter os ud af uenighed.

Vi ser det dels i BDUF's (jeg vil ikke sige "vandfald", for vandfald var oprindeligt en iterativ metode, som bare med tiden er blevet perverteret) insisteren på, at alt kan regnes ud og aftales på forhånd - men vi ser det også i Scrum's antagelse om at der findes een Product Owner, som er i stand til at agere lokalt orakel på, hvad der pt. er vigtigt (han er vist lige så almindelig som Julemanden og Påskeharen...!).

Men Stacey siger jo netop, at enighed ikke er noget, som man kan forudsætte - er den der, så giver det en lang række fordele for den opmærksomme, men ellers så skal vi være klar til at håndtere dens fravær. Og vi skal ikke grave os ned i tanken om, at hvis vi bare bruger tid på at få styr på teknikken, så vil der nok i mellemtiden udkrystallisere sig en eller anden form for magisk koncensus, så vi kan komme i gang med at levere. Vi bliver ikke (nødvendigvis) en succes, bare fordi, at vi har styr på f.eks. konstruktion, teknik, dokumentation, konfigurationsstyring eller kvalitetskontrol. Hvis man ikke ved hvor man skal hen, så er det ligegyldigt hvor hurtigt at man er i stand til at bevæge sig.

Den anden ting, som jeg mener at vi skal lære af Stacey-matricen, er den simple at forsøge at reducere to-fronts-krigene. Hvis der er enighed, så er der plads til eksperimenteren med, hvordan man bedst løser opgaven. Og hvis der er styr på, hvordan opgaven skal løses, så er der bedre plads til diskussion af, hvad der skal laves. I det sidste ligger måske også en opfordring til at have tålmodighed med kunderne, når de begynder at diskutere det trivielle - i virkeligheden, så kan det være udtryk for en glimrende situationsfornemmelse, at de ikke politiserer det vanskelige...!

Agil fotografering

Jeg hørte engang en sige, at hvis man skrev af et sted fra, så var det plagiat - men hvis man skrev af tre steder fra, så var det forskning! Og der er gran af sandhed, for ved at udvælge og sammenstille, så beriger man alle de oprindelige bidrag (og kommer herved med sig eget bidrag).

Jeg har prøvet at gøre mig den tanke til et mål for denne blog, og prøver derfor at få flere vinkler på en sag - og hvis jeg virkelig kun har en kilde, så i det mindste at supplere den godt med egne tanker. Men jeg vil gøre en undtagelse her, for jeg vil bare bringe et link til en blog-post om:

agil fotografering

Jeg har jo både prøvet at tale om agile metoder og om fotografering på denne blog, for begge dele optager mig meget. Men at kombinere dem, som i ovenstående - det havde jeg ikke lige tænkt på - og derfor er den chance for god til at lade få fra sig.

Agilister in spe kan læse artiklen som en kort, og rimelig OK, beskrivelse af store dele af området; og måske inspiration til at lade være med at være for snævertsynet og ortodoks i udlægning af teksten - og fotonørder kan finde inspiration til at gøre tingene anderledes og grænsende til det dogme-lignende, uden dog at blive direkte dogmatiske.

Stop op, og tænk dig om!

Det sidste stykke tid er vi nogle stykker, som har brugt en god del af vores tid på, at sidde og skrive testcases til vores nuværende projekt. Altså ikke småhygget med at programmere automatiske tests, men siddet og skrevet hardcore manuelle tests med "blyant og papir (dvs. vi har heldigvis en god wiki, og det gør arbejdet mange gange nemmere - hvis du er så uheldig, at du ikke ved, hvad en wiki er, så tænk "tekstbehandling", og du er ikke helt galt på den).

Man kan sige, at det er noget sent i forløbet, at vi får taget os sammen til at skrive testen - vores system har, for størstedelen af det, været i produktionslignende pilotdrift i noget, som efterhånden begynder at ligne et års tid. Når vi aldrig fik skrevet en formel test i første omgang, så er det nok fordi, at applikationen er groet langsomt frem, og pilotdriften er noget, som næsten er kommet snigende. Men nu, hvor applikationen bliver godt og grundigt hovedrenoveret, så er det en glimrende lejlighed til at få skrevet sådan en test.

Vi, der skriver testen, kender applikationen så godt, at vi sidder og skriver den "kold". Vi sidder altså ikke med applikationen kørende i baggrunden, imens vi skriver - vi skriver bare testen direkte fra hovedet og ned på papiret. Derfor kom det også som noget af et chok for mig, at min kollega pludselig kigger op og siger: "Bjarne, jeg har fundet en større fejl!" Jeg mener, fejl det er da noget, som man finder, når man prøver at bruge applikationen, ikk'? Og den har været i drift igennem længere tid uden problemer - så hvordan kan han sidde der, og så lige ud af den blå luft sige, at der er en fejl?!?

Men der var en fejl. En måde at bruge applikationen på, som ville give vildledende resultater. Det er nærmest tilfældigheder, som har gjort, at vi ikke er rendt ind i den - og vi introducerer lige om lidt ny funktionalitet, som ville have gjort det ganske sandsynligt, at rigtigt mange ville have oplevet det i praksis. Den eneste grund, til at vi fandt den nu, var, at vi, i og med at vi skulle skrive testen, havde tvunget os selv til at sætte os ned, og tænke applikationens brug systematisk igennem.

Micheal Feathers beskriver det samme fænomen i sin blog-post "The flawed theory behind unit testing". Det spørgsmål, som han stiller sig selv, er egentlig meget simpelt: Hvordan kan det være, at programkode, som er blevet unittestet, indeholder færre integrationsfejl? Og her tænker han ikke på fejl, som kunne være fundet af en unittest, men som på grund af utilstrækkelig unittest, først bliver fundet i integrationstesten - næh, det som undrer ham er, at det at lave unittesten tilsyneladende forhindrer flere fejl i at opstå, end hvad selve testen rent faktisk verificerer. Læs selv hans blog, den er kort og letlæst, og den kommer også forbi andre emner, som f.eks. TDD.

Michaal Feathers konklusion er, at unittestens umiddelbare værdi ikke så meget af selve testen (selvom han ikke er blind for, at automatiseret test øger muligheden for at lave efterfølgende ændringer på en sikker måde), men derimod at det tvinger os til at sætte os ned og tænke systematisk over det, som vi vil lave (eller måske lige har lavet). Han siger selv afslutningsvist:

The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.

Det var det, som min kollega oplevede - og jeg har selv oplevet det, når jeg har siddet og skrevet unittest: Pludselig finder man grundlæggende logiske fejl i det, som man har implementeret - altså ikke fejl i implementationen, men i præmisserne for den. Jeg har bare ikke rigtigt tænkt over det, førend Michael Feathers satte sin finger på det.

Kelly Waters er inde på noget af det samme i sin blog-post "Agile project initiation": Her beskriver han de lange dokumenter, som mange projektmodeller foreskriver, at man udarbejder inden et projekt starter op - dokumenter på over 50 sider, som det er vanskeligt at få nogen til at læse. De fleste folk, som skriver noget med "agil" i deres CV, vil her sige, at hvis der ingen er, som læser det, så skal man helt lade være med at skrive det. Men Kelly Waters bemærker, at det giver ham værdi - det tvinger ham nemlig til at tænke projektet igennem på en systematisk måde. Hans bud på, hvad man så gør, er at lave det som en powerpoint-præsentation, for dels kommer han igennem de samme overvejelser, og dels så kan han bruge det, som en diskussionsoplæg, og derved ydermere få en feedback, som han ikke oplevede ved de lange dokumenter. Powerpoint virker for ham, men pointen er vel, at alt hvad der ville tvinge ham til at arbejde sig systematisk igennem overvejelserne, ville være lige så godt.

Så, stop op, og giv dig tid til at tænke dig godt om - det er bedre, at komme stille og roligt afsted i moderat fart i den rigtige retning, end det er straks at sprinte afsted i den forkerte. Men det er ingen opfordring til at tage en "morfar" i hængekøjen - det virker kun, hvis du tvinger dig selv til at arbejde dig systematisk igennem det.

PS: Måske er det derfor, at COBOL programmer stadig er så udbredte - der er man pinedød nødt til at tænke sig godt om, inden man gør noget! :-)

Multiple specialer

Rasmus bloggede for en uges tid siden under titlen "Hvad gør et team crossfunctional?" om nogle af de udfordringer, som er forbundet med at skulle skulle nedmande, set ud fra de erfaringer som han har gjort sig med et konkret scrumteam (et team, som jeg indtil i år også var med i, så jeg bærer noget af skylden...). Det udartede sig til en godmodig meningsudveksling imellem Rasmus og mig om begreberne "cross functional" og "generalizing specialist" - begreber, som jeg gerne vil tale mere om her:

Lad os tage "cross functional" først, for det er på mange måder den nemmeste. Wikipedia skriver i artiklen "Cross functional teams" bl.a. flg.:

In business, a cross-functional team is a group of people with different functional expertise working toward a common goal.[...]

Cross-functional teams often function as self-directed teams responding to broad, but not specific directives. Decision-making within a team may depend on consensus, but often is led by a manager/coach/team leader.

A non-business, yet good example of cross-functional teams are music bands, where each element plays a different instrument (or has a different role).

Cross-functional er altså en egenskab ved en gruppe af mennesker - et team - og siger derfor ikke andet om medlemmerne i teamet, end at de kommer fra en forskellig baggrund.

Som det ses, så kommer Wikipedia også kort ind på den typiske beslutningsstruktur i et cross functional team, dog uden at uddybe det nærmere. Umiddelbart kan jeg dog ikke se nogen direkte sammenhæng - et team kan godt være cross functional uden at være konsensusbaseret; og omvendt, så kan et team godt være konsensusbaseret uden at være cross functional - når man måske nok ser en sammenhæng, så skyldes det efter min mening snarere, at de omstændigheder, som gør at man vil foretrække et cross functional team, også vil gøre, at man vil foretrække at gøre teamet selvbestemmende.

Umiddelbart ser det ud til, at den bedste kilde til det andet begreb - generalizing specilist - er Scott W. Ambler (han er i hvertfald ikke selv ked af at tage æren som ophavsmand); se f.eks. her: Generalizing Specialists: Improving Your IT Career Skills. Han skriver flg. om emnet:

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few.

...og fortsætter:

Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others. Specialists will often be blind to the issues which other specialists focus on [...]

En generalizing specialist er med Scott ord altså mere en "både og" end en "enten eller"; en person, som formår at kombinere det bedste fra generalisten og specialisten - og han understreger senere, at man helst ikke er specialist på bare et enkelt område, men gerne på adskillige - hvis bare man har dybden; dybden er vigtigere end bredden, for hvis man mangler dybde, så er man i bedste fald kun en generalist. Han anerkender dog, at dette ikke sker ad sig selv, og et ekspertise er noget, som kommer med erfaringen.

Det nærmeste Wikipedia har om emnet, er artiklen om versatilister - det er efter min mening ikke helt det samme, men trods alt så ens, at Scott anderkender begrebet som et synomym til generalizing specialist - og at Wikipedia linker til Scotts artikel.

Generalizing specialist er mao. en egenskab ved personen, og ikke ved teamet.

Generalizing specialist og cross functional teams er altså to forskellige begreber. Men begreberne er alligevel forbundne, for som Scott selv fremhæver, så det lige så god en ide at kunne spænde over flere specialer for et team, som for en person; på mange måder er det den samme ide, bare på to forskellige niveauer.

Begreberne er også fælles om at fokusere på kombinationen af specialer som det bærende element; hvis ikke, så er det bare den store middelmådighed, og det er ikke målet med nogen af dem. Og Rasmus' bekymring ved nedmanden er vel præcis den, at når opgaverne skal fordeles over stadig færre , så risikerer det at blive udvandet så meget, at muligheden for at specialisere sig går fløjten.

Det er svært at tale om scrum uden også at have en mening om generalizing specialist og cross functional teams som begreber. En oplagt grund er, at scrum fokuserer på opnå excellens, og det opnår man ikke uden at involvere specialister, men personligt mener jeg, at der en anden, og vigtigere grund: Grundtanken i scrum er, at et team som får lov at samarbejde om at løse sine opgaver på en regelmæssig måde, over tid vil lære at blive bedre og bedre til det.

Det vigtige er at altså teamet og regelmæssigheden - men hvor blev så det med cross functional og generalizing specialist egentlig af? De er der stadig, men årsager som er mere indirekte. Jeg kan umiddelbart se to:

For det første, så er det en forudsætning for at kunne lære som team, at man kan samarbejde. Det er ikke nok at trække opgaverne fra en fælles liste - eller for sags skyld, klistre dem op på en tale, og stå og snakke om dem en gang om dagen - hvis en person altid løser "de grønne opgaver" og en anden person altid løser "de røde opgaver". Det er ikke samarbejde, det er samtidigt arbejde! Cross functional er altså ikke nok for et team (det er vel end ikke et team, idet det "fælles" mål bare er kombinationen af en række individuelle mål). En generalizing specialist en umiddelbar fordel i forhold til at samarbejde, i det han allerede er vant til at spænde over flere specialer, og dermed allerede i sig selv er brobygger, og han vil derfor virke fremmende på samarbejdet i teamet.

For det andet, så er det en forudsætning for at kunne opnå en regelmæssighed, at teamet skal kunne tilpasse sig en vis variation i opgaverne - og det opnår man dels ved at have en vis bredde ved at være cross functional - men også ved at have en vis intern fleksibilitet, hvorved generalizing specialists igen bliver vigtige. Et team, som kun består at specialister, vil kæmpe for at tilpasse opgaverne til teamets profil - et team af generalizing specialists vil i højere grad tilpasse sig opgaverne karakter og lære at løse dem godt.

Fleksibiliteten er derfor vigtig. Man kan med en vis ret sige, at det bedste værktøj ikke altid er det mest specialicerede værktøj, men måske snarere det værktøj, som man har ved hånden. Jeg har prøvet at lodde med et stearinlys, og jeg har da også (gys!) lavet "mesterskruer" med batteriet på min skruemaskine.

Men på den anden side, så skal man passe på - fleksibiliteten har en pris. Man skal overveje, hvad der er ved at ske, hvis man igen og igen står med værktøj, som ikke passer til opgaven - loddekolber er bedre end stearinlys; og hvis man endelig falder for at lave "mesterskruer", så er en hammer bedre (endnu bedre er det selvfølgelig at have materialer, som passer til opgaven!). De forhåndenværende søms princip er altid en nødløsning; en næstbedst i bedste fald - og vil derfor aldrig give så godt et resultat, som at gøre det rigtigt. Det er på samme måde med et team - selvom opgaverne skal kunne ramme skævt i forhold til teamet uden at det er en ulykke i sig selv, og selvom et godt team kan klare næsten hvad som helst, så er det vigtigere at have det rette sammensætning af teamet end at klare sig med hvad man nu engang har.

Cross functional teams bestående af generalizing specialists kan være overraskende robuste og brede, men må ikke forveksles med forveksles med et hold af generalister, også selvom det ved første øjekast kan være nemt at overse forskellene. Resultaterne (og teamet) vil lide under det!

Afslutningsvist - og i nogen grad "off-topic"- så er der endnu en fordel i kunne spænde over flere specialer, som person eller som team, som egentlig ikke har noget med ovenstående at gøre (og som vel også er noget overset i sammenhængen): De innovative og kreative løsninger kommer sjældent indenfor et enkelt speciale; specialer kan være meget konserverende, og specialister kan være meget konservative - ofte kommer det fra brydningsfeltet imellem flere specialer - og et aktuelt eksempel kunne være neuroøkonomi. Men det er en helt anden snak.

Teampræstation

Hele familien var i Legoland i denne måned. Godt nok er det meste noget med at sætte sig ned og blive transporteret på et utal af forskellige måder (3 slags tog, biler, både, kanoer og rutsjebaner...), og vi elsker det. Eller måske rettere: børnene elsker det, og vi elsker at børnene elsker det. Vi bruger nemt en dag dernede. Meget traditionelt, og såmænd også yderst trivielt.

Men der er nogle enkelte forlystelser, som skiller sig ud, og en af dem er "Falck Fire Brigade". For dem af jer, som ikke har haft fornøjelsen af at prøve den endnu, så er her en kort beskrivelse: Man deles op i hold af ca. 4 personer (det passer godt med en kernefamilie, eller diverse fædre og sønner fra en skovtur), som hver får en af otte forskellige "brandbiler". Når klokken ringer og der er udrykning, så skynder man sig ud i bilen, og "pumper" den afsted - jo bedre man "pumper" jo hurtigere bevæger den sig. Når man er fremme, så er der to pumper og to sprøjter, og så gælder det ellers om at få mest muligt vand til at ramme "branden" i et vindue. Når vinduet har fået vand nok, så gælder det om at komme ind i brandbilen og "pumpe" den hjem igen, og det hold som kommer først har vundet (man vinder "kun" æren, og det er nok bedst sådan...).

Det første, som jeg synes er værd at hæfte sig ved, er, at der er faktisk er tale om en konkurrence - der er jo vindere og tabere. Der er da helt klart nogen, som tager det mere alvorligt end andre, og det er såmænd også i legens ånd, men faktum er, at uanset om man prøver at overbevise sig selv om, at man "kun er med for sjov" og at man "kun konkurrerer med sig selv", så kigger man alligevel til, hvordan de andre klarer sig. Og herved adskiller den sig markant fra så meget andet, som man kan lave i Legoland.

Det andet, og nok det også det, som gør det interessant i denne sammenhæng, er at det er en holdpræstation, som er afgørende. Det er i yderste konsekvens "sidste mand over stregen", som gør sig gældende.

Men hvad er det så, at der gør, at et hold vinder? Ja, det hjælper helt klart at have nogle stjerner. Fire toptrænede konstabler fra den danske hær vil nok til enhver tid kunne slå en familieudflugt, så en naiv holdning kunne være, at det er et spørgsmål om maksimal individuelle præstationer. Men legen er så snedigt konstrueret, at det ikke kun er det - et hold skal kunne samarbejde for at kunne opnå sit fulde potentiale.

Min store søn (stor her ment relativt) er meget konkurrenceminded og han hælder helt klart til det med de individuelle præstationer. Det startede med, at han ræsede foran alle os andre ind i brandbilen, og som en gal begyndte at pumpe løs - resultatet var, at vi andre måtte rende efter den og springe på i farten - og at jeg måtte bruge ekstra tid på at redde det "lille" (igen relativt) med ombord, inden at jeg kunne give en hånd med og dermed få sat ekstra fart i bilen.

Det næste punkt var så, da vi fordelte os på pumper og sprøjter. Jeg pumpede for den lille, og min kone for den store. Selvom det ikke fornægter sig, at min kone er tidligere konkurrencesvømmer, så kunne jeg nu stadig få pumpet mere vand end hun kunne. Problemet var bare, at den lilles "boldøje" ikke var det bedste, så halvt inde i forløbet bytter vi rundt, og derefter gik det bedre.

Hvad kan vi så lære af det? Jo, i hvertfald tre ting:

1. Når man er et team, så er det ikke altid en fordel at have en stjerne, som kan løbe hurtigt - måske løber han fra de andre.
   
2. Selv når alle gør deres bedste, så skal man stadig overveje, om man ikke kunne blande kortene på en anden måde, med et bedre resultat.
   
3. Det er ikke altid at man skal gøre det, som man er bedst til - vi voksne kunne nok ramme en del bedre end børnene (trods alt, for de er faktisk ret gode til at spøjte med vand), men vi har en komparativ fordel på pumperne, så er det det, som vi skal gøre (den opmærksomme læser vil her sikkert sidde og overveje, om ikke en bedre kombination ville have været to voksne på den ene sprøjte og to børn på den anden - måske, men der var tale om optimering af flere kriteriefunktioner på en gang...).

Så når det er det fælles resultat, som tæller, så er helheden ikke lig summen af delene - det er ikke nok at optimere den individuelle præstation.

Jeg mener at kunne huske en tv-udsendelse om udvælgelse af kosmonauter. Det er selvfølgelig et stærkt konkurrencepræget foretagende, og man skal virkelig være dygtig både fagligt og fysisk for at komme til tops (pun intended!). Men en af prøverne havde et uventet sigte: Tre aspiranter fik til opgave at få et system i balance. De måtte ikke tale sammen og de havde hver en måler og en drejeknap. Men de tre var koblet sammen, så når en aspirant forsøgte at bringe sin måler i balance, så ville han tilsvarende bringe de to andre voldsomt ud af balance. Prøver alle tre at gøre det samtidigt, så vil det i praksis være umuligt at få det til at lykkedes. Derfor var vinderen den, som først erkendte dette og tog hånden af sin knap, og lod til to andre om at skaffe balance i deres del, hvorefter han så kunne give sin knap et lille nøk ad gangen i den rigtige retning, imens han gav de andre tid til at reetablere deres balance undervejs.

At have et team bestående af folk, som hver i sær er dygtige er derfor ikke nok, og en væsentlig evne er derfor tit evnen til at kunne træde i baggrunden og se det store billede. Tit er det optimale ikke at yde sit optimale, men derimod på klog vis at give plads til andre.

Og nu kære læser, under antagelse af, at vi er enige om ovenstående, kan du så svare mig på, hvorfor så mange firmaer stadig indretter deres motivations- og belønningssystemer efter den individuelle præstation?

PS: Vores brandbil kom forresten først...

Agil opsplitning

Hvordan kan det være, at lige når man har trykket "Udgiv"-knappen, så går der mindre end et døgn inden man opdager noget, som burde have haft med? Jeg har prøvet at gå og vente med at skrive indlægget og jeg såmænd også prøvet at skrive det, og så ladet det ligge, men ingen af delene virker - effekten er uløseligt forbundet til "Udgiv"-knappen.

Og selvfølgelig er der lige sket igen. Jeg skrev så sent som i går om udfordringerne ved off-shoring under titlen Lost in translation, og allerede i dag falder jeg over blog-posten med titlen Agile India, som undrer sig over at der dels er en stor interesse for agil udvikling i Indien, men samtidig også bemærkelsesværdigt få succeshistorier. Forfatteren overvejer, om ikke dette skal tilskrives de udfordringer, der ligger i at kommunikationen ikke er så god, som hvis man sad lige ved siden af hinanden.

Men en egentlige perle i blog-posten er henvisning til Martin Fowlers artikel med titlen Agile Software Process with Offshore Development. Her beskriver Fowler en lang række snusfornuftige overvejelser omkring udfordringerne i at få agil udvikling til at fungere med Thoughtworks teamet i Bangalore. Bemærk at mange af overvejelser går på at få distribuerede teams til at fungere, så læs den endeligt selvom det ikke er Bangalore, men derimod Bagsværd eller Ballerup. Og læs den også selvom at det "kun" er kunden og udviklingsteamet som er adskilt, for Fowler prøver at få alt til at foregå offshore, men erkender at kravsspecifikation naturligt kun kan ske on-shore - og det svarer til det setup, som desværre er meget almindeligt med en offsite kunde.

Fowler har desuden flere pointer, som i bund og grund ikke er relateret til distribuerede teams, men som faktisk er generelt gode råd:

Han nævner, at en effektiv måde at få et nyt team introduceret til kodebasen på, er ved at lade dem lave fejlrettelser den første tid. Hans argument er, at fejlrettelser naturligt involverer langt mere kodelæsning end kodeskrivning. Det kan jeg skrive under på, og det gælder ikke kun for teams, men også når man skal introducere nye folk på projektet. Dels tvinger det en ud i hjørnerne af koden og dels så er det nemt at få en succesoplevelse - det er svært tilfredsstillende at få noget til at fungere, også selvom det i virkeligheden kun bestod i at skrive "not" foran en betingelse i en if-sætning. En anden effekt er, at det er nemmere at finde en fejl i en eksisterende programstump, når man ved hvordan den manifesterer sig, end det er en skrive en rimeligt fejlfri implementation fra bunden af.

Det er også med en vis glæde at jeg ser hans anbefaling af at foretrække en funktionelt opdeling. Han fodrer her en af de kæpheste, som jeg i går spændte foran min vogn, og det ser man specielt, hvis man følger linkene helt ud og ser at hans definition af funktionel opdeling er, at lade forretningen (eller med lidt god vilje, problemdomænet) determinere grænsernes placering.

Fowler har to pointer om distribuerede team, som jeg vil fremhæve:

Dels bemærker han, at hvis man påtænker at påtage sig det overhead der ligger i at have distribueret udvikling, så skal man gøre sig klart, at man i høj grad fraskriver sig en af de helt store fordele ved at være agil, nemlig at man kan erstatte store dele af den formelle dokumentation med uformel kommunikation, som jo er mange gange mere effektivt. Men i kraft af adskillelsen, så bliver det igen nødvendigt med en større formalisme i kommunikationen.

Desuden er hans klare anbefaling, at hvis man skal retfærdiggøre distribuerede teams og de udfordringer, som det bringer med sig, så skal man gøre det i forhold til at kunne tiltrække de rette kompetencer. Forskellen i produktivitet overstiger langt forskellene i aflønning, så det er dyrt i længden, hvis man køber billigt.

En enkelt ting, som jeg umiddelbart har svært ved at se, hvordan man skal implementere hvis udviklingen sker i Bagsværd fremfor Bangalore, er hans anbefaling af at udveksle lokale informationer og specialiteter. Så spændende er det heller ikke at høre om Bagsværd BK, og lokale specialiteter fra Bagsværd og omegn kan jeg ikke rigtigt komme i tanke om (selvom jeg har hørt øst-sjællændere beklage sig over de usle hotdogs, som de mener at vi har her i Jylland...).

Lost in translation

Bemærk: Der er kommet en opfølgning kaldet Agil opsplitning.

"Kødet havde en tanke, men vodkaen var god"

Der er for tiden meget snak om jobkort ordninger og off-shoring i IT-branchen, efter sigende fordi at man savner folk med de rette tekniske kompetencer.

Jeg tror ikke på det. Ikke fordi at jeg tvivler på, at vi ville kunne få god og rent teknisk yderst kompetent hjælp udefra. Jeg har haft ved flere lejligheder haft den store glæde og fornøjelse at få lov at arbejde sammen med folk fra andre kulturer, og alle gange har det dels være meget lærerigt, og dels har jeg hver gang været imponeret af den ildhu og det høje faglige niveau, som jeg har mødt.

Jeg tror ikke på det, fordi jeg ikke tror på, at det er de såkaldte tekniske kompetencer som i virkeligheden er udfordringen. Det er ikke der, hvor vi skaber den største værdi. I virkeligheden, så er vi i IT-branchen alle oversættere: Vi oversætter fra et situationsspecifik problemdomæne og over til et maskinfortolkningsvenligt domæne. Og som i en hver oversættelsessituation, så er det bedst at kunne tale begge sprog flydende.

Sådan har det ikke altid været. Engang var maskinerne komplicerede og uformående - og dels så var man lykkelig, hvis man kunne få lagt en række tal hurtigt sammen til f.eks. en folketælling, og dels så var maskiner noget som krævede stor indsigt og allerhelst en doktorgrad fra et teknisk universitet.

Men siden er maskinerne blevet lagt mere ydedygtige og det har vi benyttet til at hæve abstraktionsniveauet og dermed vores egen evne til at løfte stadig mere komplekse problemstillinger. Og med det flytter byrden naturligt fra at forstå "maskinerne" og deres problemer, og over til i højere grad at forstå "menneskene" og deres problemer.

Nu har jeg personligt brugt nogen tid indenfor det sundhedsfaglige område, og derfor grinede jeg højlydt, da jeg på Weekendavisens bagside fandt en henvisning til en artikel i Haderslev Ugeblad: Journalisten citerede en ikke nærmere specificeret "næstformand" for at mene, at det eksisterende Haderslev Sygehus ikke var egnet til psykiatriske patienter, fordi at det var "et somalisk sygehus". Det slog mig bagefter, at det i virkeligheden i høj grad er en intern joke, for selvfølgelig har "næstformanden" sagt "somatisk" og ikke "somalisk" (for en definition, se f.eks. wikipedia om somatic), og det er faktisk tankevækkende, at jeg som systemudvikler kunne fange joken.

For at minde mig om vigtigheden af at kunne forstå "menneskeproblemsproget", så går jeg i dag rundt med det udklip i min tegnebog. Tænk, hvis det ikke havde været en avisartikel, men derimod et journalsystem, som var blevet offer for den misforståelse.

Citatet en indledningen stammer fra det, som vi nok må betegne som en vandrehistorie om maskinoversættelse. Efter sigende skulle man engang have forsøgt at oversætte sentensen "The flesh is weak, but the spirit is ready" - den stammer fra biblen og hedder på dansk noget i retning af "Kødet er svagt, men sjælen er redebon". Efter at have oversat det til russisk og tilbage igen, så mistede teksten enhver form for kontekst. Selvom historien nok (desværre) ikke er sand, så har den alligevel noget på sig - se f.eks. flg. eksperiment med babelfish (prøv selv google for flere...).

Andre eksempler på fatale misforståelser, når budskaber krydser sprog og kulturbarrierer er der mange af. F.eks. hotelopslagene om, at man skal føle sig velkommen til at udnytte stuepigen... Og det er derfor, at jeg tror, at det er misforståelse, at vi kan få hjælp udefra til mere end de allermest finurlige teknikaliteter. Der vil simpelthen blive alt for mange misforståelser undervejs.

Jeg tror heller ikke på ideen om at skyde et "analyse og design"-led ind imellem. Dels fordi at der i hvert led går information tabt, og i hvert led er en iboende risiko for fejl - det ender med at blive samme effekt som den berømte "hviskeleg", hvor læreren starter med at hviske et ord til en elev, som så hvisker det videre til den næste etc. Når det er nået rundt, så er der ingen som kan genkende det igen.

Men også fordi, at det er nemt at beskrive noget som det tilsyneladende er konsistent og fyldestgørende - det er først når man skal omforme det til en utilgivende formel instruks til maskinen, at det viser sig, hvor tvetydig og inkonsistent det i virkeligheden var (alle programmører bander over de dårlige kravsspecifikationer, og alle der har skrevet kravsspecifikationer sværger, at næste gang, så bliver de bedre...). Derfor er det yderst vigtigt at den som har fået opgaven med at formalisere løsningen også har en god indsigt i problemet, for at kunne reagere tidligt på misforståelser og inkonsistenser.

Så jeg tror ikke på det, fordi jeg synes at det er svært nok at lave IT i forvejen, og fordi at vi har rigeligt med misforståelser i forvejen. Tror du på det...?

Mere om Planning poker

Efter jeg tidligere skrev om Planning Poker, så er der lige et par forhold, som jeg synes fortjener at få et par ord mere med på vejen.

For de mange, som gerne vil vide noget om, hvordan det egentlig fungerer i praksis, så er der kommet et glimrende video interview på InfoQ med Niels Haugen om Planning Poker.

Når noget får så megen opmærksomhed, som Planning Poker har fået, så kommer der næsten selvfølgeligt også en modreaktion. En af disse stammer fra Jeff Atwood i hans blog Code Horror, hvor han har skrevet et indlæg med titlen Lets play Planning Poker! Han betegner meget rammende Planning Poker som en solid gruppedialog og en estimat baseret på en form for konsensus - eller som han siger, en wideband Delphi i ny indpakning. Wideband Delphi har sine problemer, og dem har Planning Poker i vid udstrækning arvet (jeg kommer ind på nogle af dem i min tidligere blog), så er man interesseret i planning poker, så bør man også lige kaste et blik på erfaringerne med wideband Delphi.

Jeff Atwood fortsætter med at sige, at de bedste estimater er de estimater, som baserer sig på historiske data - og det bruger han så som afsæt til at foreslå en alternativ teknik (som jeg ikke vil forholde mig til her). I Scrum vil man typisk bruge Planning Poker i ideal dage, og så bruge erfaringer med teamet produktivitet (dets velocity) til at omforme estimatet til mandedage. Ved at tage turen forbi velocity, så får man et element af historiske data med i udregningen - og man få muligheden for efterfølgende at justere planerne, når produktiviteten ændrer sig (f.eks. fordi at teamet bliver bedre over tid, men måske også fordi at vilkårene for teamets arbejde ændrer sig over tid).

Det er oplagt, at måler man systematisk velocity, så vil man efterhånden få justeret for eventuelle systematiske bias, som måtte eksistere i estimeringsprocessen. Og selvom begrebet idealdage er godt udgangspunkt, så vil en brug af velocity forudsætte en stabilitet i estimaterne, som gør at det ikke længere er idealdage man skal estimere i, men i højere grad "det som vi dengang troede at vi kunne nå på en ideal dag".

Scrum er en proces, hvor man i høj grad fokuserer på stadige forbedringer af arbejdet (arven fra Lean fornægter sig ikke), og derfor undrer det mig egentlig, at man ikke i stedet fokuserer på, at give teamet feedback på dets evne til at estimere, så estimaterne kunne forbedre sig. Måske er årsagen, at man ikke kan skille omfang fra effektivitet, og teamet kun skal have feedback på det dets evne til at forudsige omfang?

En anden modreaktion er ikke så meget imod Planning Poker som sådan, men mere imod at den baserer sig på User stories. James O. Coplien advarer os om, at user stories kun rummer krav, og at der er brug for en bedre forståelse af, hvad det er, som giver værdi for kunden. Det nærmeste jeg har kunnet finde på skrift er denne anbefaling fra hans blog med titlen Religion's Newfound Restaint on Progress:

That means using Use Cases [...] instead of XP-style user stories (so you understand feature interactions up-front), [...]

Coplien fortsætter med en snusfornuftig advarsel om, at man i praksis skal overveje, hvad der er omkostningseffektivt. Det læser jeg på den måde, at han nok altid vil hævde at use cases er user stories overlegne, men at der selvfølgelig kan være situationer, hvor det bedste valg vil være user stories. Han opfordrer os mest af alt til at bruge hovedet!

Hvis vi lige trækker linjen tilbage til wideband delphi, så var grundlaget for den metode, en work breakdown structure. Det er et meget detajleret gæt på, hvad en løsning vil indebære, og langt fra den kravspecifikation som en userstory er. Uden at overfortolke Copliens budskab, så må man vel sige, at han opfordrer os til at overveje, om vi altid mener, at en kravspecifikation i virkeligheden er grundlag nok? Personligt har jeg en stærk tvivl - jeg har deltaget i en del planning poker sessioner, og det er tit at jeg sidder tilbage med en fornemmelse af, at vi er sprunget i mål med et estimat førend vi i virkeligheden har forstået, hvad opgaven gik ud på. Og alt det man overser, er jo 100% underestimeret!

Arkitekten er død...

...længe leve arkitekturen!

På dette års JAOO var der del, som luftede den mening, at arkitekter var en udøende race, og at agile udviklingsmetoder vil gøre arkitekter overflødige. Jeg kender efterhånden en hel del folk, som er gode arkitekter, og jeg så faktisk flere af dem gå og dukke sig efter denne svada.

På den anden side, så var der yderst interessant og velbesøgt spor, som delte sig over to hele dage om arkitektur, så faktisk var det ganske uretfærdigt. Pointen er ikke, at det være agil betyder, at man ikke længere behøver en arkitektur ("vi laver det som synes rigtigt nu, og hvis det senere viser sig at være forkert, så kan vi bare refactore det...!" synes det naive synspunkt at være).

Jim Coplien havde et tankevækkende, og til tider provokerende, foredrag på JAOO om agil arkitektur, og i det understregede han klart behovet for at få taget de nødvendige beslutninger på rette tidspunkt. Hvis man undlader at tage beslutninger, så vil du se god fremdrift de første par sprint, var hans påstand, men derefter man blive indhentet af virkeligheden med nedsat produktivitet til følge (eller velocity som vi vist ynder at kalde det nu om dage).

Coplien blev i høj grad bakket op af talerne fra ovennævnte arkitekturspor, og i virkeligheden så er det et faktum, at du får en arkitektur uanset om du planlægger det (intentional architecture) eller om det opstår mere som en eftertanke (accidental architecture).

Accidental architecture har en lidt kedelig klang af held fremfor dygtighed over sig, men hånden på hjertet, så er det heldigvis ikke alt, som sker som logiske videreførelser af allerede eksisterende ideer (jeg boede engang i samme opgang som en, der yndede at sige, at selv den mest metodiske og grundige planlægning aldrig vil kunne erstatte det rene og skære svineheld!). Grady Booch anerkender da også tilfældig arkitektur som værende positiv under to klare forudsætninger:

• de bagvedliggende beslutninger tydeliggøres.
• de vigtige synliggøres igennem resten af projektforløbet.

(se Grady Booch: The accidental architecture). Iøvrigt kan "rigtig" Accidental Architecture faktisk være ganske flot.

Men hvad er så egentlig arkitektur for noget? Kevlin Henney stiller også spørgsmålet (Kevlin Henney: What is Software Architecture), og besvarer det med henvisning til Martin Fowler og Grady Booch med, at det er de designbeslutninger, som er svære eller dyre at omgøre. Ud fra den definition er det tydeligt, at arkitektur ikke er noget, som man kan komme ind i systemet på et vilkårligt sent tidspunkt.

Betyder det så, at agile metoder er et luftkastel, og at vi stopper os selv blår i øjnene? Skal vi i virkeligheden tilbage til tidligere tiders dyder om et kæmpe design på forhånd? Så langt fra. Tanken om ikke at tage alle beslutninger på forhånd, hvor grundlaget for at træffe dem iøvrigt i bedste fald ville være tvivlsomt, holder stadig. Budskabet er udelukkende, at det ikke modsætningsvis betyder, at man ikke behøver tage nogen beslutninger overhovedet!

Nogle beslutninger kan man med fordel beslutte at tage på forhånd. Andre kan man - som Kevlin Henney fint illustrede i hans foredrag om Performance Art (man kan vist ikke beskylde ham for at være beskeden...) - tage en bevidst beslutning om at udskyde til senere, ved at afkoble sig fra et konkret valg. Man bliver nødt til at beslutte sig for et interface, men hvis man ligger tilstrækkelig omhu i konstruktionen af dette, så kan valget af implementation udskydes til et tidspunkt, hvor man har et bedre grundlag for at træffe en korrekt beslutning.

At det er et emne, som udfordrer alle med en agil tilgang til systemudvikling, kan ses af at ThoughtWorks var i stand til at lave en seksmands paneldiskussion om emnet med sig selv på dette års QCon-konference.

Hvad er så min konklusion? Jo, at den klassiske arkitekt som den store leder og beslutningstager, som vi kun så i opstartsfasen af et projekt, hvor han lagde de endegyldige rammer for en succesfuld applikation (som så på det groveste blev misforstået og fejlimplementeret efterfølgende!) er en udryddelsestruet race - og godt det samme!

Hvis vi er agile, så er arkitektur noget som fastlægges løbende og af os alle i fællesskab. Derfor har vi mere end nogensinde brug for folk med arkitektonisk flair, til at virke som facilitatorer for de "dyre" beslutninger og mentor for hele udviklingsgruppen, for at få forankret de gode beslutninger.

FY?

Mit team arbejder med scrum, og selvom der er gjort mange gode erfaringer, så er der (heldigvis!) stadig megen plads til eksperimenter. Der lægges stor vægt på, at man lærer af egne erfaringer - alligevel så er der nu ikke noget bedre end, også at kunne lære af andres. Og derfor kan jeg ikke lade være med at studere de scrumboards, som jeg kommer forbi på min vej.

Jeg kom fordi et den anden dag, og der hæftede jeg mig ved, at der var en task seddel på boardet, hvor nogen med fed rød tusch havde skrevet:

FY!

Halløj, tænkte jeg, her måtte der virkelig være tale om en større overtrædelse af teamets interne aftaler, og jeg nærlæste derfor sedlen. Det eneste, som jeg lige kunne se var specielt ved den var, at det oprindelige estimate på 6 var blevet nedskrevet til 3, og derefter skrevet op igen til 6.

Hmm. At blive klogere undervejs er vel kun en god ting, og lige så vel som man kan blive positivt overrasket over, hvor nemt noget, som i første omgang så svært ud, viste sig at være - lige så vel kan man blive overrasket over, at det som ved første øjekast så nemt ud, ved nærmere øjensyn viser sig at være sværere end ventet. Det er selvfølgeligt godt jysk trælst, at resttiderne stiger, men det er nu engang en konsekvens af, at vi gætter. Vi vinder nogle og vi taber nogle...

Så var det at jeg tænkte på, hvad der ville ske, hvis opgaver, hvor man opskrev resttiderne, alle skulle hænges ud til almindelig spot og spe? Ja, dels kunne man nok forvente en vis ulyst til at påtage sig andet end de mest trivielle opgaver, dels ville man hurtigt komme til at indregne et risikotillæg i estimaterne og dels ville der være en naturlig tøven med at nedskrive resttider før end man var helt sikker på, at det ville holde (f.eks. fordi, at man rent faktisk var færdig). Under alle omstændigheder har man herved ødelagt enhver fordel ved at have resttidsestimater (og i tilgift fået unikke ulemper oveni).

Det kan selvfølgelig være, at jeg tager fejl - måske er det i virkeligheden en hel anden synd, som man her vil sanktionere med at udstille synden (og dermed også synderen) offentligt. Under alle omstændigheder noget, som man skal tænke sig godt om, inden man gør. Hvis jeg på den anden side har ret, så har jeg kun en ting at sige, og det er:

FY!

Planning poker

For at kunne planlægge indhold, skal man kende omfang - og det gælder også for scrum, selvom om iterationerne er så korte, så man kan holde ud at sprinte igennem dem. Et af de foretrukne værktøjer til at anslå omfang af opgaver, når man bruger scrum som metode, er planning poker.

Det er der efter min mening en række gode grunde til:

• der er gode chancer for at få vendt alle relevante sten ("none of us is as smart as all of us")
• fremgangsmåden er lightweight - input er en "story" som kompakt beskrives et ønske, og så de fakta, som deltagerne spørger ind til, for at kunne danne sig en mening.
• vurderingen sker af dem, som skal udføre opgaven.
• der satses på konsensus.
• indbygget i metoden er hensyntagen usikkerheden stiger med resultatets størrelse.
  

Men der er også en række fælder:

Sammenfaldende interesser?

I det agile manifest slår man fast, at man foretrækker samarbejde med kunden fremfor kontraktforhandlinger (er jeg den eneste, som hæfter mig ved, at ordet kollaboration, som jo både på dansk og engelsk kan betyde samarbejde med fjenden, står lige ved siden af ordet kunde i manifestet?). Vi tror mao. på, at vi har fælles interesser, og så virker metoden da også bedst.

Men har vi fælles interesser? Product owner har jo en interesse i, at få så meget som muligt lavet, og er han menneske som os andre, så vil han nemt kunne fristes til at underspille omfanget af opgaven, for derved at få teamet til at love mere end det ellers ville. Tilsvarende vil et team, som tidligere er blevet udsat for opgaver, som har vist sig at være mere komplicerede end antaget under planlægningen, begynde at indregne risikotillæg i deres vurderinger.

Specielt kritisk bliver det, hvis man bruger vurderingsmetoden i et fastpris scenarie (og derfor mener jeg at man skal være meget forsigtig med at blande de to...), men effekten vil allerede opstå, hvor der ikke er fælles ejerskab af vurderingen ... hvis product owner efterfølgende kan slippe afsted med at sige "Jamen team, I lovede..." eller endnu værre, hvis teamets performance alene bliver målt på dets evne til at opfylde vurderingerne.

Diskussionen er specielt relevant, når man estimerer i fysiske tidsenheder (det være sig såvel kalender- eller, mere typisk, mande-dage), og et forslag har derfor været at estimere i story points i stedet - story point er meget lig function points i deres tilgang, i det at begge forsøger at estimere kompleksitet uden også at estimere effektivitet. Der findes også også argumenter imod at bruge storypoints.

Manglende konsensus

En stor fordel ved metoden er, at alle bliver hørt, og at der er enighed om vurderingen. Hvis det da er tilfældet...

For det er dels vigtigt, at hele teamet deltager i vurderingen, hvis hele teamet senere skal kunne forventes at bakke op om resultatet. En planning poker seance er med andre ord et glimrende tidspunkt til at skille pigs fra chickens - hvis der er nogen i teamet, som mener sig ude at stand til at deltage, så er der stor chance for, at de i virkeligheden er kyllinger i grise-kostumer....

Den anden fælde er, at man stopper diskussionen inden der er konsensus. Det er dræbende for det fælles fodslag, hvis deltagerne sidder tilbage med følelsen af "nu blev det godt nok 5 dage, men jeg tror nu mere på 8 dage...!"

For meget konsensus (eller af de forkerte årsager) kan nu også være af det onde.

Ovendreven tro på nøjagtigheden

I virkeligheden, så kan man jo skrive denne advarsel om stort set hvad som helst - at være sig begrænsninger bevidst er jo altid en god ting. Metoden har allerede indbygget en stillingtagen til usikkerheden i den kraftige progression, som der findes i kortenes talrække. Når man læser beskrivelsen hos ophavsmanden, så er det tydeligt, at han forventer at resultatet er en af disse diskrete værdier (man stopper ikke førend der er konsensus om en af disse).

Et alternativ, som jeg har set praktiseret, er at stoppe når spredningen er kommet under et vist niveau (vores tommelfingerregel er maks. tre på hinanden følgende diskrete værdier), og så tage et passende gennemsnit. Fordelen er, at man ikke bruger langt til på at få de sidste decimaler diskuteret på plads (det flytter næppe meget, og det kan tage lang tid), men ulempen er dels, at man kan opnå en distance til resultatet, og dels, at resultatet præsenteres med en nøjagtighed som det ikke kan bære.

Et eksempel: Vores regel vil acceptere flg. stemmer:

8, 13, 13, 20, 20, 20,

og det naive resultat vil være 15,7 dage (eller måske mere reelt 15 2/3). Dels signalerer decimalerne times nøjagtigt i noget , hvor inputtet var mere end hele dage (der er en uge mellem 8 og 13 dage, og længere imellem 13 og 20 dage), dels ligger det omkring 4 dage under halvdelen af gætterne!

En anden vinkel på det er, at hvis bare en enkelt havde taget et kort, som lå lige ved siden af, så ville det kunne flytte gennemsnittet en dag i hver retning. Et mere reelt resultat havde altså været godt tre uger, eller omkring 16 dage. Har man brug for at kende resultatet mere præcist, så har man enten specificeret storien for grovkornet, eller også er man i gang med at detajlplanlægge.

En godt checkpoint er at spørge alle deltagerne, om de vil kunne acceptere resultatet (igen med specielt fokus på dem, som lægger længst væk). Hvis man gør der, og en af de folk som har vendt f.eks. "20" i virkeligheden vaklede imellem det og så "40", så vil det komme frem!

Hvad snakker vi om?

Når man vurderer på et så uformelt grundlag, som en story og diskussion med udgangspunkt i nogle afklarende spørgsmål, så er det vigtigt at man er enige om, hvad det er, at man vurderer.

Den første fælde er, at de forskellige deltagere i diskussionen løb har dannet sig et forskelligt billede af, hvad løsningen går ud på. Der har sikkert været en livlig diskussion af alternativer og afgrænsninger, og hvis ikke der gøres et grundigt arbejde af moderator med sikre fælles fodslag dels i hovederne på deltagerne og dels som forudsætning for vurderingens validitet efterfølgende, så risikerer man nemt at få svar på noget andet end det, som man spørger om.

Tilsvarende er det vigtigt, at man er enige om, at man kun vurderer gruppens egen indsats. Hvis det er en forudsætning at andre end teamet bidrager, så er det netop en forudsætning - disse andre må selv komme med deres eget bud på, hvad deres del vil andrage, hvis der er relevant. At bede teamet om også at tage dette med, er at tage dem som gidsler på noget, som de dels ikke har forudsætninger for, og dels næppe vil kunne føle ansvar for efterfølgende.

Det stiller også krav om, at teamet består af generalizing specialists - hvis der er for stort spænd i kompetancerne (f.eks. fordi at der er flere, som ikke kan programmere, og opgaverne indeholder betydelige programmeringselementer), så kan det betyde, at vurderingen bliver rent gætværk, simpelthen fordi at folk mangler forudsætningerne for at mene noget fornuftigt. Alternativet med, at lade dele af teamet erklære sig inhabile, er heller ikke godt, dels af hensyn til det fælles ejerskab, dels fordi at man så risikerer at miste et vigtigt input. Under alle omstændigheder, så er det at have et team af generalizing specialists identificeret som en af de afgørende faktorer for at have højt ydende team, så hvis situationen opstår, så skal man overveje om teamet er korrekt sammensat.

Er det så ikke bare noget bras?

Jeg kan ikke fortænke noget, hvis de nu sidder og spørger sig selv, om metoden er noget bras? I så fald, så læs lige om fordelene i indledningen igen - det er et glimrende værktøj, men man skal være sig dets begrænsninger bevist.

Personligt mener jeg, at der er det bedste værktøj til vurdering af opgaver inden sprintplanlægning i et velfungerede scrumteam. Det forudsætter dog stor modenhed fra alle parter - både fra teamet og fra dets omgivende interessenter.

(Opdateret 3. nov. 2007: Der er kommet en fortsættelse med titlen Mere om Planning Poker)

Detailplaner og scrum

I denne uge havde jeg den store fornøjelse at deltage i JAOO konferencen. Det er svært at finde et foredrag på konferencen, hvor man ikke går der derfra med noget at tænke over.

Et af de mange foredrag som jeg hørte, var om scrum (jeg tror at det var Hubert Smiths Planning in Large Companies), og der var der på en af slidene et billede af tavlen fra et sprintplanlægningsmøde. Tavlen var relativt velordnet, med store sedler i en farve til de stories som teamet havde taget ind i sprintet - og under hver story-seddel, en søjle med fine sedler i en anden farve, med de aktiviteter som teamet havde fundet frem til. Så langt, så godt.

Men så var det, at alle deltagere i teamet, ud for hver seddel, havde noteret, hvor lang tid de regnede med at skulle bruge på de enkelte opgaver i dage - og disse tider var, med initialer, overført til sedlerne. Det undrede mig, for i det scrumteam, hvor jeg p.t. deltager, er vi gået væk fra have tider og initialer på opgaverne. Jeg var ikke den eneste som undrede mig, for et af spørgsmålene fra salen var netop til disse tider.

Svaret var, at det var et forsøg på at sikre, at der var en nogenlunde ensartet belastning på alle deltagere i teamet - eller med andre ord en slags ressource leveling. Det er klart at man bør undgå en al for stor forskel imellem opgavernes karakter og teamets kompetencer, så intentionen er god nok (vi har også været præcis der).

Der var flere grunde til, at vi gik væk fra det:

• Når opgaverne allerede er estimeret på storyniveau, så tilføjer det umiddelbart ikke nævneværdig værdi at nedbryde dette estimat på delopgaver. Der kan være en fordel i at kunne måle fremdriften, men det introducerer et administrativt overhead. Hvad værre er, så åbner det en breche overfor andre om, hvorvidt det giver vil give mening at gøre en story halvt eller 3/4-dele færdig for at kunne klemme en anden story ind - and it ain't over 'til the fat lady sings!
• Hvis man under sprintplanlægningen allerede fordeler opgaver på folk, så er der en kedelig tendens til, at denne plan hænger ved - det bliver med andre ord også de folk, som kommer til at lave opgaverne. Man kan sige, at forskellen på papiret ikke er stor, men rent mentalt så er man ikke et team længere, hvis der på forhånd er dine og mine opgaver - den største fordel ved at team går fløjten, hvis opgaverne ikke er "vores opgaver"!

Efter min mening, så er der også andre udfordringer ved at forsøge på at lave ressource leveling, som nok ikke umiddelbart ødelægger sprintet, men som man alligevel skal have for øje:

• Man kan nemt i forsøget på millimeterretfærdighed komme til at overse de dynamiske effekter. Det kan godt være, at der er ligeligt med opgaver til alle, men hjælper ikke noget, hvis der er nogle, som kun har opgaver som naturligt ligger først ... eller til sidst. I et godt team vil teamet arbejde udenom udfordringen, men værdien af forsøget på ressource leveling er gået fløjten.
• Den anden fælde er, at man begynder at tilpasse opgavesammensætningen til teamet kompetencer og ikke omvendt. Teamet skal kunne levere det som giver værdi, og ikke det som det tilfældigvis er bedst til. Det tager selvfølgelig tid at få et godt team op at stå, så for en tid kan det give mening at lade opgaverne tilpasse sig teamet i nogen udstrækning - og på samme måde er det jo ideelt, hvis teamet kan opsøge opgaver, som passer til kompetanceprofilen. Det er bare vigtigt, at der ikke bliver byttet om på årsag og virkning.

Nu kunne man så sikkert godt forledes til at tro, at jeg taler for, at man helt skal ignorere, i hvor høj grad de enkelte deltager kan byde ind i et sprint - eller for at man helt ignorerer opgavesammensætningen. Det gør jeg så langt fra. Det er et vigtigt input til planlægningen at vide, hvordan teamet er sammensat - og det er naivt at ignorere effekten af f.eks. ferier og uddannelse.

Det som er vigtigt er, at teamet kan tro på at planen er realistisk, og hvis det indebærer, at teamet under sprintplanlægning vurderer på delopgaver og mulige ressourcer til dette, så er det helt fint med mig. Det som jeg hæver en solid pegefinger overfor er, dels at give det mere vægt end som input til en "mavefornemmelse" og dels at tage detailplanen med ud fra sprintplanlægningsmødet. Detailplaner er nok nyttige, men også yderst farlige, og skal derfor holdes i meget kort snor - ellers risikerer man at ødelægge mere end man gavner.