Burn Charts

Jeg bruger ofte tid på at tænke over, hvordan jeg kan synliggøre det arbejde teamet ligger for dagen. Indtil videre bruger jeg kun et simpelt burn chart for hver iteration, hvor en ideal linie viser, hvor mange timer der kunne være skrællet af på opgaver, og en real linie som viser hvor mange timer der stadig er tilbage på opgaverne. Når real linien stiger og ideal linien så akkummuleres der arbejde af den eller den anden grund, når den er under så arbejder teamet hurtigere end forventet eller de har feature-cuttet. Grafen tjener flere formål:

1. Jeg kan bruge den til at forstå fremdriften, og til at vide hvornår jeg skal bryde ind.
2. Teamet kan bruge den til at forstå den samlede mængde af arbejde (en person kan være langt foran på egen opgaver, mens en anden er bagud)
3. Andre kan se udviklingen indenfor iterationen.

Jeg synes ikke selv den er super god, mest fordi den jo tracker timer på task niveau og ikke feature niveau. Det skal jeg have kigget på. Men den hjælper dog specielt teamet med at tage de nødvendige snakke på det daglige scrum, hvis planen er begyndt at skride..

Jeg har læste bogen Crystal Clear (anbefales!) af Alistair Cockburn, og i dag stødte jeg så på et indlæg omkring rapportering i Agile projekter (taget fra bogen) på hans egen blog. Læs indlægget her og brug det som inspiration til at lave dine egne burn charts.

Der findes også andre gode artikler om emnet - bl.a. her og her. De to artikler kommer også ind på styrker/svagheder ved henholdsvis burn-down (bruger jeg) og burn-up charts, samt vigtigheden af at synliggøre den slags data for andre uden for projektgruppen (big visible charts!).

Hvordan tracker i jeres projekter?

Giv magten til dit team #2 - Kulturel interferens

Jeg har besluttet, at næste post i føljetonen omkring at lade udviklingsteamet overtage magten i forhold til styring af udviklingsopgaver handle om et potentielt problem forbundet med lige netop at overlade magten til teamet.

Dansk Projektledelse (DPL) udgiver årligt en række medlemsmagasiner, som jeg læser. Nyeste nummer fokuserer på sælgerkompetencer indenfor projektledelsesdisciplinen. Specielt en artikel fangede min opmærksomhed: "Sælger af kultur" skrevet af Finn Svenning. Artiklen kigger nærmere på begrebet kulturel intelligens, og hvordan kulturel intelligens kan appliceres som værktøj i projektledelse. Definitionen på kulturel intelligens er "even til at skabe et konstruktivt samarbejde på tværs af kulturforskelle". Hvad har det med projektledelse at gøre? Jo se på dit team af udviklere, designere, forretningsudviklere og testere - hvor mange forskellige subkulturer huser du ikke her? Se på organisationen omkring projektet med salgsafdelinger, marketingafdelinger, tekstforfattere, support, kunder - hvor mange forskellige subkulturer eksisterer her? Det geniale ved artiklen er dens operationelle fokus på, hvordan disse kulturkløfter kan anvendes aktivt i ledelsesarbejdet. "Den kulturelt intelligente projektleder sørger for, at gruppen arbejder med deres kulturelle forskelle og ligheder som start på projektforløbet"... hvor mange af jer husker at gøre det? "Det er også vigtigt at aftale spilleregler for samarbejdet i projektgruppen, og her skal man tage udgangspunkt i den kultur, hver enkelt gruppedeltager kommer fra, så reglerne ikke bliver et tandløst kompromis"... hvor mange af jer husker at gøre det? Jeg har i hvert fald noteret mig følgende:

Ved projektkickoff skal

1. Alle på teamet præsentere sig selv, ens baggrund og hvorfor man mener, man er udvalgt som deltager på projektet
2. Teamet skal liste de umiddelbare styrker ved teamets interne forskelligheder og aftale at fokusere på disse
3. Der skal aftales spilleregler for teamets interne struktur (team lead er ok, men i mine øjne skal forummet i teamet være så åbent som overhovedet muligt.

Ok. Så vidt så godt. Men hvorfor er det altsammen væsentligt i forhold til overskriften på indlægget "giv magten til dit team"? Hvis nu man giver magten til sit team, men ledelsmæssigt gør man ikke noget for at skabe et godt og åbent forum, så er der en overhængende stor sandsynlighed for at en i gruppen (den teknisk stærkeste?) blot overtager hele styring og i princippet tryner de andres synspunkter, fordi han ikke tænker på de kulturelle forskelle, der eksisterer. Når testeren eller en anden udvikler ikke melder sig på banen ved en arkitekturændring, er det måske fordi de føler sig underlegne i forhold til en teknisk meget kyndig udvikler... men selv tekniske genier har behov for naturligt modspil, specielt fra andre kulturelle vinkler end lige netop hans egen.

Så tak Finn Svenning! Vi projektledere skal aktivt lede teamets interpersonelle strukturer, så den kulturelle interferens bliver brugt positivt til at skabe åbenhed og belyse problemer fra flere vinkler...

Ydmyghed...

En ting omkring projektledelse, som vi ofte diskuterer her på arbejdspladsen, er, hvordan man sikrer at projektledere tilvejebringer optimal information både til projektet (forretningsviden og -mål) og fra projektet til organisationen (status, fremdrift, issues/impediments).

Min chef sagde på et tidspunkt til mig, at jeg var en type, som havde det naturlige standpunkt at tingene nok kunne løses af mig selv - altså som udgangspunkt har jeg ikke behov for hjælp. Det arbejder jeg på at lave om, sådan at jeg naturligt vil inddrage de rette folk i eventuelle problematikker og derigennem få nødvendig viden og hjælp samtidig med at de rette personer informeres om projekthindringer.

Omkring temaet hjælp og evnen til at spørge om hjælp findes der en interessant artikel her

Estimering - Grafisk Design vs. Programmering

Det er min erfaring, at det er lettere for interessenter at acceptere at grafiske designere ikke kan give estimater, end det er for de samme interessenter at acceptere en udvikler har svært ved at give estimater.

Personligt kan jeg ikke se nogen forskel.

Givet at andre har samme erfaring - hvorfor er det tilfældet?

Dine vigtigste ledelsesværktøjer?

Der er efter min erfaring stor forskel på, hvordan ledelse opfattes. For nogen drejer det sig udpræget om styring af andre mennesker, for andre er ledelse et spørgsmål vision, retning og rammer.

For mig er ’styring’ et utrolig effektivt værktøj på den korte bane, men utroligt ødelæggende hvis det ikke bruges med omtanke. (Mere om hvornår i en en senere artikel)

En projektleders opgave går i høj grad ud på ”ledelse” og anvendelsen af værktøjer til ledelse, men rapportering omkring rammerne og styringsredskaberne er det vi oftes hører om (budgetter, gannt kort, kvalitetsplaner etc).

Hvad er dine vigtigste ledelsesværktøjer?

Definition of done...

Jeg er meget opmærksom på at kunne tracke projektets fremskridt målt som mængden af færdig funktionalitet. Hvorfor? Jo, hvis man nu antager, at projektet skulle stoppes lige nu, hvad nytte havde man så af, at eks. 66% af alle opgaver var løst, hvis denne mængde rent faktisk kun svarede til 2% færdig funktionalitet?

Dette er vist en meget almindelig antagelse for alle agile projekt-process modeller. Der hvor det bliver lidt sjovt er, når talen kommer ind på, hvad færdig egentlig betyder - the definition of done? Der findes mange bud, bl.a. læste jeg et godt et i dag her, men faktisk har jeg selv svært ved at komme frem til en entydig og universel gyldig liste. Efter min opfattelse skal definitionen af færdig forhandles med produktejere og udviklere som en del af opstarten på et projekt, og definitionen skal afstemmes med krav til deadline, kvalitet, genbrugelighed, testabillity osv.

Hvordan ser jeres liste ud?

Reflektion, estimering og vision

Stødte på en sjov betragtning på lifebeyondcode vedrørende finansverdens evige og ukuelige vækstfokus: "I think the financial people have got it. They say "past performance is not an indicator of future results" along with every report"...

Det fik mig til at tænke på, hvordan vi på den blå taler meget om at skulle tage ved lære af vores estimater og tracke tidligere projekters estimater, sådan at disse kan indgå i vores fælles erfaringspool og igen forbedre nye estimater... hvordan hænger det lige sammen med ovenstående citat?

Hvis vi vender tilbage til the planning game - er der nogen som har prøvet spillet jeg refererede til i min sidste post? - så handler spillet lige netop om at skabe en verden, hvor motivation og selvorganisering vil drive estimeringen og eksekveringen af estimerede opgaver op i et hurtigere og hurtigere tempo. Her lærer man af sidste iterations resultat, og planlægger næste ud fra det, men oftest sker der det, at man tilføjer mere til den næste iteration, som så danner grundlag for planlægningen af den næste igen. Samtidig med så ændrer estimaterne hele tiden karakter, da de ikke er baseret på tid, men på kompleksitet. Kompleksiteten fungerer relativt på den måde, at den kommer til at afspejle, hvad man kan nå i en given iteration, og hvad man kan nå ændrer jo sig lige netop... langhåret? hmm, måske lidt. Jeg ser nogle klare fordele i hele tiden at fokusere på estimater som noget relativt, så man lige netop ikke bliver hængende i et bestemt tempo, men konstant tilpasser sig... og nogle gange tror jeg estimater givet i timer, spænder lidt ben for det pga. estimatets direkte relation til noget kendt og meget målbart... en time er en time er en time... eller er det? Hos os taler vi faktisk om estimat-timer og timeforbrug...

Hvad er din holdning til denne estimeringsvirak? Og hvordan lærer din organisation af tidligere estimeringer uden at hænge fast i samme tempo derved?

Planning game - fortsættelse...

I forlængelse af Daniels tidligere post vil jeg godt gøre lidt reklame:

Der findes et færdigt kit man kan anvende til planning game (baseret på XPs principper). Jeg var igennem en øvelse i forbindelse med Scrum Master certificeringen, som anvendte dette kit, og det var en meget lærerig oplevelse... jeg kan på det varmeste anbefale alle projektledere at "lege" denne leg som intro på agile projekter, for ligesom at få folk i denne rette stemning og ånd.. På ganske kort tid lærer man om koncepter som velocity/fart, kompleksitet og story estimering.

Hent kittet her: http://www.xp.be/html/xpgame.zip

Planning Game

Jeg faldt over denne artikel, omkring planning game.

På Den Blå Avis har vi også erfaring med lignende principper. Jeg følger op med et indlæg senere.