22. januar 2008

Hvor er agile er vi?

Prøv at gå igennem score-arket her med jeres teams:

http://kw-agiledevelopment.blogspot.com/2008/01/how-agile-are-you-take-this-42-point.html

Den er god til indikation af indsatsområder, omend lidt for "værktøjsorienteret" i mine øjne.

Etiketter: ,

17. januar 2008

Mødekultur....

Half-Hour Meetings

Jeg faldt over denne på Bug Bash - Godt spottet...

Et andet hint: Indkald mødet til 2 minutter i, og slut fem minutter før... så er der mulighed for at folk husker at komme til tiden, og i har en lidt skarpere deadline ;-)

Etiketter: ,

"Er IPMA en metode?"

Jeg faldt over indlægget "Er IPMA en metode i projektledelse? " på Finn Svennings blog om projektledelse.

Jeg er helt enig i Finn's betragtninger - jeg vil dog gøre opmærksom på hvad NCB'en (National Competence Baseline) fra IPMA (måske) også kan bruges til.

I vores projektorganisation, har jeg lige talt med en af projektlederne om, at vi kan bruge NCB evalueringen som udgangspunkt i den faglige kompetence udvikling, som ved os foregår i dagligdagen.

Man tager simpelthen udgangspunkt i en selv- eller fælles evaluering af projektlederen, finder frem til forbedringsområder - og kan så finde frem til værktøjer, metoder eller adfærd der kan hjælpe til den personlige faglige udvikling.

Det kan da være en måde at gøre MUS arbejdet mere nærværende... vi har ikke afprøvet det endnu, men hvad siger i?

Etiketter: , , , , , ,

15. januar 2008

Teams #3 - Selvledelse

Selvledelse er i følge Det nationale kompetenceregnskab (s.12) en kompetence baseret på
"...evne og vilje til via eget initiativ at beslutte og gennemføre opgaver i
arbejdet i overensstemmelse med virksomhedens strategier."

Selvom definitionen er lidt stiv, så kan jeg godt lide dens fokus på, at det både er et spørgsmål om evne og vilje. Selvledelse kommer ikke af sig selv. Det er en kompetence, som individerne på et givent team skal opøve og ikke mindst ville.

Det enkelte individ skal være indstillet på at bryde med vaner og hele tiden udfordre sig selv og sit eget standpunkt, men samtidig også turde stille samme krav til andre. Det kræver både evne og vilje. Først når alle på et team gør det, vil teamet blive reelt selvledende og selvorganiserende.

Som leder er dit job, som jeg ser det, at opstille de rigtige rammer for ovennævnte kan ske. Ledelsesarbejde skal baseres på

  • tillid fremfor kontrol
  • motivation fremfor ordrer
  • uddelegering af ansvar fremfor uddelegering af opgaver

Der er sikkert også mange andre ting, men det er i hvert fald et godt sted at starte, og husk på, når man uddelegerer ansvaret, så kan man faktisk også tillade sig at stille spørgsmål ved planlægning og løsning af opgaver, hvis planerne skrider, for nogen har jo taget ansvar for planlægningen og løsningen. At modtage og acceptere ansvar er lig med at bevæge sig væk fra ansvarsfraskrivelse, som efter min opfattelse er det største problem ved projektledelse baseret på command-and-control tankegangen.

Jeg slutter med et godt team-citat hentet fra en fantastisk god historie om transitionen mod Agile:

"The first thing we learned was that we needed to make open and honest
commitments as a team to produce high quality software every iteration. It’s not
as easy as it sounds. You need to check your ego at the door. There are no
heroes on our team….our team is the hero. There are no goats on team…our team is the goat. We sink or swim together."

Et godt link til danske artikler om selvledelse og teams kan findes her

Etiketter: ,

4. januar 2008

Velocity.... fart hvad kan man bruge det til?

Hvis i har tid så læs følgende artikler med hver deres perspektiv på, hvad konceptet velocity kan tilføre en agil projektproces:

Velocity er et ret simpelt koncept, som bygger på Mike Cohn's ide om at man skal estimere i størrelse og uddrive farten igennem udførelse - estimate size, derive duration - og på den måde opnå en empirisk kontrolleret forståelse for den fart, hvormed et givent projektteam kan eksekvere en given opgave (eller user story).

Den del som tiltaler mig er, at eksekveringen af "estimat-timer" (som Cohn ynder at kalde story points for at undgå forvirringen med kalender-timer) adskilles fra estimatet selv. I alt for mange år har man talt om at estimater aldrig stemmer overens med de faktiske timer, og så har man brugt ligeså lang tid på at udvikle metoder til at foretage beregninger på estimater up-front for at gøre dem mere præcise osv. Hvorfor?

For mig at se er det temmelig indlysende, at et estimat givet på et tidspunkt, hvor viden om projektet og de konkrete projektopgaver er lavest (=dvs i begyndelsen af et projekt), aldrig kan indfri et ønske om 100% præcision. Det gør dog ikke estimater ubrugelige. Estimater fortæller jo stadig om et projekts størrelse og kompleksitet i grove træk, og det er faktisk meget værdifuldt i forhold til planlægning af projektet, og måske endnu vigtigere: porteføljeplanlægning..

Hvad synes i? Bruger i velocity på jeres projekter? I givet fald hvilke erfaringer har i gjort jer med det?

Etiketter: