Hvor er agile er vi?
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.
En blog om projektledelse og produktudvikling og alt, hvad det fører med sig. Bloggere er fra Den Blå Avis og i øjeblikket arbejdes der med agile procesmetoder, så derfor vil mange indlæg nok bære præg af dette "projektsyn". Inspiration hentes fra Scrum, Crystal Clear, Agile Unified Process, Rational Unified Process, Blogs om ledelse, hverdagen, hukommelsen, nettet i sin helhed og sidst men vigtigst: fra jer som svarer på vores indlæg

Etiketter: mødekultur, spas
Etiketter: certificering, ipma, job, ledelse, MUS, NCB, projektlederrollle
"...evne og vilje til via eget initiativ at beslutte og gennemføre opgaver i
arbejdet i overensstemmelse med virksomhedens strategier."
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:
Et godt link til danske artikler om selvledelse og teams kan findes her"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."
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: teori