Teams og Gandhi

Tyvstjålet fra et indlæg på lifebeyondcode kommer her et Gandhi-citat:

"A small group of determined spirits with an unquenchable thirst for their mission, can alter the course of history".
- Mahatma Gandhi

Rajesh Setty (bloggeren på lifebeyondcode) bruger citatet til at filosofere over sin personlige indstilling til livet, men jeg tænkte selvfølgelig straks på projekter og teams.

"..determined spirits with an unquenchable thirst for their mission" - dette er for mig at se kardinalpunktet for ethvert projekt. Hvis man sikrer at teamet arbejder mod samme og meget nøje defineret målsætning, og at alle individder i teamet kan se deres funktion i opnåelsen af målsætningen, så kan man sku "...alter the course of history"! Så lad det blive en god notabene til alle projektledere...

Giv magten til dit team #1 - Medbestemmelse

På det seneste har ideen om motivation af projektteamet fyldt mit sind meget. Derfor har jeg tænkt at starte en føjleton på området, som sikkert kunne skabe lidt sund debat :)

Grundlæggende bygger mange agile processdiscipliner på en antagelse om at motivation og empowerment af projektteamet er væsentligt for at kunne skabe gode resultater, og indenfor softwarebranchen dermed god software. Eksempelvis har Scrum sit udgangspunkt i at projektteams/udviklingsteams skal være selvorganiserende for at kunne levere fremragende software tilpasset kundens, produktejerens, ønsker og behov.

Jeg kunne godt tænke mig at dykke lidt ned i, hvad der gør et super team, og her tænker jeg specielt på, hvad man som leder kan gøre gøre for at sætte scenen i den forbindelse.

Første ting jeg har tænkt mig at skrive lidt om er noget som ligger mig meget nært i mit ledelsesarbejde: medbestemmelse, så her kommer det...

#1 Medbestemmelse
I modsætning til traditionel management tankegang, hvor projektlederen udstikker opgaver og får projektteamets medlemmer til at løse dem, så tror jeg på, at teamet selv skal lede og fordele det stykke arbejde, som de udfører. Projektlederen skal blot fascilitere at dette bliver gjort og bistå med gode indspark til processen, hvor nødvendigt. Dette er væsentligt af flere grund, men vigtigst er dog, at man som projektleder skal befri sig fra kontrolcenter-metaforen, hvor man kan sidde i sit eget skønne elfenbenstårn og styre sine projekter via flotte charts og reports. Teamet skal deltage i centrale beslutninger for projektet. På den måde får man også flere perspektiver på en given problematik, end man ellers ville have gjort. Som projektleder bør du

1. Involvere dit team i beslutningsprocesser, som omhandler teamet eller det produkt, som der arbejdes på
2. Sikre at teamet er klar over sit ansvar
3. Gøre det klart for teamet, at de har de kompetencer, der skal til for at kunne træffe de rigtige beslutninger
4. Sikre at der altid følges op på de beslutninger, der træffes (dvs. får dem omformet til planer, kommunikeret til stakeholders etc.)

Hvad får du ud af at gøre det? I mine øjne er der nærmest kun gevinster at hente (hvis det rigtige setup etableres):

1. Du får adgang til en meget bredere, og multi-perspektiveret, vidensbase (som i tekniske henseender er langt mere kompetent end du nogensinde kan være)
2. Ved at spørge teamet nedarves der konsensus for forslaget, som skal vendes. Teamet kommer op med løsningsforslag, som bliver til planer, og disse planer vil i sidste ende være produktet af løsninger tænkt af teamet selv og ikke af dig
3. Når mennesker adspørges om deres mening, så arbejder de hårdt for at komme op med gode ideer. Dette er et kæmpe plus, når man står midt i en kritisk situation i sit projekt og skal træffe vigtige beslutninger, om hvilken retningen arkitekturen eksempelvis skal tage

Medbestemmelse betyder dog ikke, at du kan læne dig tilbage og lade andre beslutte alt for dig. Du skal skabe det forum, hvori medbestemmelsen opstår, men som ordet medbestemmelse også ligesom indikerer, så er du også selv en deltager i processen. Måske beslutter du ikke noget om teknikken, men måske har du gode retningslinier for tænkningen eller scopet af diskussionen.

Sidst vil jeg lige nævne, at medbestemmelse også stiller store krav til projektlederens rolle som leder. Projektlederen skal være den toneangivende og altid gå foran som det gode eksempel. Hvis man som projektleder lader teamet træffe beslutninger på halvt grundlag, hvad lærer man så sit team? - At det er ok at træffe beslutninger på ufuldstændig information.. osv.

Modstand mod forandring

Kan du huske det? Noget med at medarbejdere generelt ikke kan lide forandringer og kæmper imod.

Det er jo ikke så rart for os, når projekter jo netop skal drive forandringer.

Men hvad med dig selv, ville du ændre adfærd? Kunne du motiveres til at ændre adfærd? Ja ?

Lad os antage nej? Hvad nu hvis det galt liv eller død? Tjah, 9 ud af 10 vil ikke ændre adfærd, det ved vi.

Hvordan sikrer vi så at vi arbejder med forandringer, og flytte projektet og organisationen omkring projektet? Tine Brødegaard rammer emnet en smule i denne artikel, hendes konklusion er blandt andet – lyt til medarbejderne, find frem til hvad de forsøger at fortælle dig.

(Måske er det dig som leder der har modstand mod forandring?)

Der har vi jo nogle gode værktøjer i form af interessentanalyse og en god kommunikationsplan.

Hvornår har dit team fejlet sidst? Og hvad fik i lært?

Hvis du ikke fejler betyder det at du ikke laver fejl, hvis du ikke laver fejl presser du ikke dig selv.

Når du presser dig selv laver du fejl, for at forbedre dig selv, skal du presse dig selv endnu mere, og du risikerer at fejle.

Jo mere du presser dig selv, jo hurtigere bliver du bedre, og jo hurtigere kommer du i mål.

"Fail often to succeed sooner"

Hvad skal man lave først?

Når man skal bestemme hvilke opgaver der skal laves først, er der to strategier som begge på overfladen virker meget fornuftige.

1) "Gå efter quick-wins"
Få de hurtige succeser, lav så meget der kan laves så hurtigt som muligt, og gem det svære til senere.

Ulempe: Du skubber, de tunge opgaver til senere, og det kan være svært at estimere dem
Fordel: Du vinder viden om projektet mens du arbejde med dine "quick wins", kunderne bliver klogere
Fordel: Dit team bliver motiveret.

2) "De største risici først"
Er der noget der har en risiko for projektet? Få det ud af verden med det samme.

Ulempe: Der kan gå lang tid før ens team præsenterer resultater
Fordel: Risikominimering naturligvis

Alistair Cockburn omtaler tilgangene Worst Thing First og Easiest Thing First, Hardest Thing Second. Hvor første tilgang kan sammenlignes med "De største risici først", når det kommer til tekniske risici, så kan anden tilgang ikke helt sammenlignes med "Quick wins", fordi ideen er at man laver én utrolig nem ting først, og dernæst det svære. På den måde motiveres projektteamet ved en tidlig "sejr", og denne faktor bør nærmest indgå i en hver projektleders repetoir for risikominimering: Har du et motiveret team, er der næsten ikke grænser for, hvad der kan laves til tiden (næsten da..).

BrainScrum

Jeg stødte på en blog, som jeg ikke kendte, i dag. Den handler om agility og Scrum. Meget interessant og dybdegående læsning, som jeg varmt kan anbefale til alle, som søger ny inspiration. Jeg har tilføjet bloggen i listen af links her på bloggen.

Friktion

Har lige læst en spændende artikel om usability eller mangel på samme. Udgangspunktet for artiklen er, at man som designer bør forsøge at undgå user interface friction, hvor brugen af systemet opleves som unødvendig kompleks eller ude af trit med den handling, brugeren forsøger at foretage sig. Ifølge artikelen er friktion "... the number of steps that the user thinks are unnecessary". Måden man undgår friktionn på er ved at forholde sig til domænet, som brugeren af systemet lever i, og sikre sig at koncepter og interfaces er bygget op omkring entiter, objekter og metaforer hentet fra domænet selv. Det er for mig en interessant pointe, som implicit også peger på, hvor væsentligt det er for en projektleder at sikre fuld forståelse for domænet ikke kun hos udviklerne, men også hos designerne. Måden jeg gør det på er ved at inddrage designerne meget tidligt i forløbet og (jeg øver mig konstant på at gøre dette bedre) ved at demonstrere softwaren efter hver iteration, hvor folk fra domænet har mulighed for at kommentere på systemet og dets udformning..

Læs artiklen her: http://ifacethoughts.net/2007/05/19/the-user-interface-friction/

"Kære dagbog"

Vi er igang med at lave evaluering på et projekt, som jeg har været projektleder på. I den forbindelse har vi haft et møde, hvor en gruppe projektdeltagere i fællesskab udfærdigede en timeline med væsentlige begivenheder for projektet. Arbejdet var spændende og gjorde, at man fik vendt projektet og dets begivenheder en ekstra gang. Det er altid sundt for en projektleder! Men det fik mig også til at tænke over væsentligheden af at føre projektdagbog. Der var flere begivenheder jeg ikke kunne huske, hvornår fandt sted... ikke godt. Jeg har derfor besluttet at føre en dagbog på mine kommende projekter. Detaljeniveauet er jeg stadig ikke helt afklaret med. På et stort projekt bør man i hvert fald være påpasselig med at blive for detaljeret, for så drukner man i information, men på et lille projekt skal man være mere detaljeret, ellers bliver dagbogen ligegyldig. Hvad er dine erfaringer med den slags?

Inspiration til hvordan man kan føre den slags projektdagbøger kan bl.a findes her:

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=5988

Kliche, floskel eller ej - teambuilding uden for kontoret er godt!

Vi har i dag spenderet en hel dag i Ebeltoft Zoo, eller rettere Ree Park, på både at diskutere værdier i IT-organisationen og løse praktiske fysiske opgaver i teams. Det er efterhånden en fortærsket kliche, at den slags virker, men alligevel vil jeg nu gerne have lov til at råbe det lidt igen: at lave noget sammen udenfor kontorets rammer, det booster sku team-spirit, korpsånd og venskab! Jeg tror mange har tendens til at tilsidesætte den slags tiltag, fordi de virker floskelagtige og "set før"... men måske er der en grund til at de virker som "set før"? Jeg er sikker på, at IT afdelingen vender tilbage på mandag med forfrisket ånd og styrke. Mere af den slags, tak.

Ønsker man at basere sin organisation på team-arbejde, så bør aktiviteter som nævnt i dette indlæg ikke forbigås. Der må også meget gerne følges op på den slags aktiviteter, så man som team og organisation kan forbedre sig og lære af sine erfaringer.

Forretningen, domænet & udvikling

Et stort problem for agile udviklingsproces er, som jeg ser det, at sikre fremskridt og konstant levering. Mange bøger beskæftiger sig ikke rigtigt med, hvordan man sikrer, at hver iteration producerer noget færdig funktionalitet, som principielt set skulle være deployment-klar.

Crystal Clear taler om walking skeleton strategien, som går ud på at man først får et simpelt arkitekturskelet op og køre, og dernæst fylder kød på det. Scott Ambler med Agile Unified Proces (som er den processmetode der ligger til grund for projekterne her på Den Blå Avis) taler om requirements-driven architecture og modeling in small increments. Lidt samme ide igen: man opbygger arkitekturen i små bidder, dog krydret med at arkitekturen skal udspringe fra forretningens/kundens krav. Men det store spørgsmål forbliver, hvordan gør man egenligt?

Belært af tidligere projekter er jeg blevet meget påpasselig med at tage domænet for givet. Vi opererer med en arkitektur, hvor de grundlæggende forretningslogikker og -objekter afspejles i en domænemodel. For mig at se er det essentielt at få domænet på plads tidligt i projektet, før udviklingen af krav starter. Det betyder at

• Krav skal være tilpas detaljerede
• Kravstiller skal kunne stå inde for kravene
• Kravene skal mappes til domænet
• Domænet skal afspejle løsningen af kravene

Dette arbejde er interessant af flere grunde. Det skaber en kontakt imellem kravstiller og udviklere som er helt nødvendig for at få kravstiller til at tage et aktivt ansvar i udviklingsprocessen og for at få udviklerne til at tage et aktivt ansvar i kravene. Med andre ord de bringer de to verdner tættere sammen. Kravstiller og udvikler kan diskutere krav på en måde, som de begge hver især forstår: Kravstiller taler ud fra forretningen, udvikleren ud fra domænemodellen. Gode eksempler kunne være:

Udvikler: Jamen skal kunden kunne få den rabat hver gang han handler?
Kravstiller: Øh, ja... Kunden får rabatten, fordi han handler for mere end 3000 kr om året hos os.
Udvikler: Ok, så man skal altså logge den samlede sum en kunde handler for?
Kravstiller: Ja det vil jeg da klart mene
Udvikler: Og hvis den samlede sum overstiger 3000 kr, så får kunden en rabatsats?
Kravstiller: Ja på 2%. Hvis kunden handler for over 10000 så stiger rabatten til 5%
Udvikler: Så det er en slags konfigurerbar trappesats? Skal i selv kunne vælge procentsatserne og beløbene?
Kravstiller: Det ville da være at foretrække, så skal vi jo ikke belemre nogen fra udviklingsafdelingen hver gang vi skal have det ændret!

Udvikler sidder her og kigger på det domæne, hun har tegnet op. Sikkert bestående af nogle ordrer, kunder og varer. Men ved at diskutere rabat med kravstiller ud fra domænet lærer udvikleren hurtigt at der skal tilføjelser til domænet for, at rabatten kan virke som forretningen ønsker det. Pointen her er, at hvis man i de tidlige faser får vendt domæment med kravstiller og de krav, der er registreret, så får man et mere stabilt udgangspunkt for udviklingsfasen. Det er min påstand, at dette arbejde i et eller andet omfang er nødvendigt for at kunne levere færdig funktionalitet efter hver iteration i udviklingsfasen, ellers skal der bruges for megen tid på undersøgelse af krav og ændring af domæne efterfølgende.

Vi arbejder med fire faser (hentet fra Agile Unified Proces & Rational Unified Proces): inception, elaboration, construction og transition. Inception er projektfødsel, hvor man definerer overordnede rammer for projektet, elaboration er der hvor man fordyber sig i projektet, construction der hvor kravene udvikles og transitition er udrulningen af projektet. Vi arbejder på Den Blå Avis med en kravsprocess, som definerer krav som værende 10% færdige efter inception og 80% færdige efter elaboration. De sidste 20% kommer i løbet af construction, når kravene udvikles (man kan ikke vide alt up-front!). På samme måde foreslår jeg egentlig at man går til både domæne og arkitektur...