"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?

Jeff Sutherland om Scrum og lean...

Her er en yderst interessant artikel, som ridser det historiske perspektiv for både Scrum og lean op:

http://jeffsutherland.com/scrum/2007/11/is-it-scrum-or-lean.html

Spændende pointer og uddrag til dem som ikke har lyst til at læse hele artiklen:

Fastest path to appearance of the next feature:

"The reason the first Scrum team called Sprint Backlog items SyncSteps was that developers executed the Sprint Backlog in a carefully chosen order - that order which produced the fastest path to appearance of the next feature from the users point of view. Just as proper ordering of the Product Backlog optimizes revenue, proper ordering of the Sprint Backlog optimizes production of value. It accelerates software evolution and can produce effects seen in biological systems."

Hele tanken om, at arbejde med sprint backloggen på den måde er super interessant. Gad godt høre om nogle af jer har specifikke erfaringer med dette?

Punctuated equilibrium:

"The "punctuated equilibrium" effect is achieved at Toyota using set-based concurrent engineering. As an example, Toyota does not build one radiator for a new car. They build six, and wait to the last possible moment to choose the best radiator to deploy in production. This is similar to competition between biological species in an ecosystem and the species that adapts best to the environment wins. The Scrumcommunity has yet to implement set based concurrent engineering strategies"

Kunne man gøre brug af denne tankegang i software-udvikling? Det er en naturlig konkurrence situation, som jeg i hvert fald føler vi ofte mangler på vores software-projekter.

Scrum failure:

"Less than 10% of the Scrum teams worldwide can pass the Nokia test, primarily because they cannot deliver potentially shippable (fully tested) software at the end of a Sprint."

Skræmmende! Ifølge ovenstående er vi i øjeblikket også temmelig langt fra at have implementeret korrekt Scrum. Vi øver os, men det som oftest viser at spænde ben, er opstarten af projekter, hvor der bruges alt for lang tid på arkitektur upfront.

On teams:

"A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality)."

Jeg har i lang tid syslet med, at der ikke måtte være flere end 4 udviklere på et team. Ovenstående går meget godt i spænd med den tankegang. Men uha. Vi har ikke en eneste QA person tilknyttet teamet fast. Tesen om, at udviklere skal være i mindretal i forhold til testere, fortæller mig et og andet, om at vi også har en del arbejde på den front, der skal gøres før vi er i mål. Hvordan ser jeres teams ud?

Hovedprincipper bag Agile Software Development

Spændende læsning her: 10 Key Principles about Agile Software Development.

Måske man kunne udvide nogle af beskrivelserne for de enkelte principper eller udvide antallet af principper? Eksempelvis sidder jeg og tænker på to væsentlige principper, som jeg ofte selv har svært ved at bringe fornuftigt ud i organisationen:

1. Selvorganisering --> Det er ikke effektivt at mikrostyre det arbejde udviklerne skal udføre for at lukke en given sprint. De ved selv bedst. Men hvordan får man en gruppe af udviklere til at fungere selvorganiserende på det område? Hvordan håndterer man modstand i mod selvorganisering (nogle vil hellere skubbe ansvaret fra sig)?

2. Ethvert projekt har en estimeret produkt backlog! --> hvordan sikrer man dette? hvor skal snittes lægges. skal den gen-estimeres?

Har i nogle erfaringer eller kender i til artikler som uddyber disse områder, så skriv en kommentar.

At være en god leder...

Jeg læste et indlæg her til middag, som beskrev distinktionen imellem at være en chef (manager) eller en leder (leader) på en fantastisk måde.

"Managers use people to accomplish work; leaders use work to grow people".

En traditionel chef bruger folk til at effektuere sin plan for projektet og har dermed fokus på planens outcome mere end de individder, som uddelegeres de opgaver, der kan indkassere planen og produktet. En god leder derimod har fokus på individdet i planen og dets muligheder for at vokse med opgaven. I begge situationer vil individdet blive sat til at løse opgaver inden for rammerne af en given plan. Men som leder sikrer man nødvendig optimisme og motivation til løsningen af opgaverne. Det smitter så sikkert også af på kvalitet og hastighed...

Jeg ved ikke med jer, men ovenstående citat fik i hvert fald mig til at tænke på, hvor mange gange jeg agerer leder vs. hvor mange gange jeg agerer chef - og hvordan kunne jeg måske have gjort tingene anderledes. Indlæggets forfatter har selv følgende forskrift på, hvordan man kan begynde at agere leder fremfor chef:

My take is that we have an obligation to lay an appealing trail of
breadcrumbs to lead people along the path of figuring-out stuff for them
selves.

What the breadcrumbs look like and where they go depends on the
skills and needs of the person but a reasonable starting process would
be:

1. Ask them what they want to do
2. Ask them how they feel about areas for improvement
3. Provide resources (training, books, mentoring) in areas they have an
   interest for
4. Encourage “outsight” (input from people outside the organization) in
   their development Checkpoint regularly about how the process is going and if
   their goals have changed

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?

Hvem arbejder en projektleder for?

Jeg er af den overbevisning, at dem der laver arbejdet er nødt til at have nogen, der arbejder for dem, til at fjerne støj og forhindringer så arbejdet kan udføres.

En projektleder arbejder for projektgruppen, og skal sikre, at den er glad og kan "levere, levere og levere"

Projektchefen arbejder for projektlederne, for at sikre at projektlederne får mulighed for at udføre deres arbejde.

Selvfølgelig er der andre aspekter af arbejdet som projektleder, men det er alt sammen noget der i sidste ende skal give ro til projektgruppen, så holdet kan levere resultater og bundlinie.

Jeg kom til at tænke på dette, da jeg faldt over managinghumans.com - er der nogen her der har læst bogen?

En dygtig projektleder...

har en holdning til rigtig mange områder i driften af en virksomhed, og har utrolig meget indsigt i virksomhederne de arbejder for.

Det betyder de på rigtig mange områder kommer i en rolle hvor de skal "coache" andre - og i den situation, er det sundt at huske på Kirkegaard's vise ord - ihvertfald for mig.

At hjælpe

"At man, når det i sandhed skal lykkes en at føre et menneske hen et bestemt sted, først og fremmest må passe på at finde ham der, hvor han er og begynde der. Det er hemmeligheden i al hjælpekunst. Enhver, der ikke kan det, han er en indbilding, når han mener at kunne hjælpe en anden...

For i sandhed at kunne hjælpe en anden, må jeg forstå det, han forstår. Når jeg ikke
gør det, så hjælper min merforståen ham slet ikke. Vil jeg alligevel gøre min mening gældende, så er det, fordi jeg er forfærdelig stolt, så jeg vil beundres af ham.

Men al sand hjælpen begynder med ydmygelse: hjælperen må først ydmyge sig under den, han vil hjælpe og derved forstå, at det at hjælpe er ikke det at herske, men tjene, at det at hjælpe er ikke at være de herskesygeste, men den tålmodigste, at det at hjælpe er villighed til indtil videre at finde sig i at have uret og ikke at forstå, hvad den anden forstår. "

Det er utrolig svært for mig, at ydmyge mig selv - men det betyder ikke at jeg tror hundrede procent på ordne, det gør jeg - og når man ikke efterlever dem, bliver man ofte selv frustreret, og dem man skal hjælpe, hjælpes meget lidt.

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.