Scrum og klassisk projektledelse

Som respons på et indlæg havde jeg en kort messenger snak som jeg paster ind i det følgende: Claes siger: hvad er forskellen på scrum og klassisk men GOD projektledelsE? wollesplace.blogspot.com siger:
Klassisk projektledelse? bygger et eller andet sted på evnen til at forudse konsekvenser af handlinger. I komplekse adaptive systemer er det ikke muligt at forudse konsekvenser af en handling blot kan man konstatere at der vil være en konsekvens.
wollesplace.blogspot.com siger:
Og scrum handler om produktudvikling og dermed et eller andet sted et ønske om innovation. Claes siger:
jeg er sat måske er det varmen, men hedder det ikke planlægning?
wollesplace.blogspot.com siger:
Hvad hedder planlægning?
Claes siger:
"det ikke muligt at forudse konsekvenser af en handling blot kan man konstatere at der vil være en konsekvens."
Claes siger: det er for varmt i dag vi må tage snakken en anden gang.
wollesplace.blogspot.com siger:
Hmmm planlægning. Scrum handler naturligvis også om planlægning, men det handler lige så meget om at fyre op under et team således at de er istand til at komme ind i den innovative zone.
På wikien http://en.wikipedia.org/wiki/Scrum_(in_management) er der en dejlig kort def. af scrum som stort set siger det hele.

Jeg kommer til at tænke lidt på hvad god projektledelse er?
For mig at se er der ihvertfald to dele af dette.
1) Det vigtigste er at sørge for projektet er succesfuldt.
2) Balancering af følgende fire elementer:
Scope
Ressources
Time
Quality

Specielt den sidste bliver som regel glemt. Man antager at man kan lave den samme kvalitet ligegyldigt hvor man skærer? Det er naivt.
Man kan fastholde tre af disse men den fjerde vil bevæge sig som en funktion af de andre.

3) En masse ceremoni vedrørende ledelsesaktiviteten. Denne ceremoni kan have samme formål som enhver anden cerimoni nemlig at fjerne det personlig engagement eller fjerne ansvar.
Der skal naturligvis være projektledelse. Spørgsmålet er mere centralt vel, hvad er det man leder og hvorledes gør man det.
Svaret på det første spørgsmål giver måske en idé om hvilke teknikker man har tænkt sig at anvende. Hvis man leder nogle aber som ikke kan tænke selv og hele tiden skal hjælpes så er det vel sådan man gør. Hvis man derimod antager at de fleste folk faktisk er i stand til at udføre deres arbejde professionelt så er det sådan man planlægger.

SPM: Hvad er formålet med hele tiden at måle fremdrift mod en gammel plan som er baseret på gammel viden og punke i forhold til denne.


Indenfor software udvikling får man tit fornemmelsen af at det vigtigste er at levere det der blev aftalt i starten og ikke så meget det der virker.
Det er igen (hypotese) fordi man tror at man kan lave ceteris paribus på verdenen og at man kan forudse alle konsekvenser til at starte med. Fortolkning og "design" af software projekter handler om flere ting:
1) Hvilket perspektiv man anlægger på software udvikling (se computers in context)
2) Hvilke interesser man søger at tilfredsstille. Jeg var en gang på et IBM salgskursus hvor jeg bl.a. blev introduceret til "The pain chain" som salgsmetode. Her forsøger man ikke at løse et specifikt "rationelt" problem når man sælger løsninger, men derimod forsøger man at løser de forskellige interessenters problemer. Et typisk salg går sådan her:
Man kommer ind i virksomheden på et eller andet niveau. Man finder ud af hvem der har nogle penge. Den der har nogle penge har et personligt mål/problem. Det forsøger man at løse. Man finder også lige ud af hvem der bestemmer over denne person og har flere penge. Så forsøger man at løse denne persons problem. og så videre og så videre. Til sidst præsenterer man en løsning som løser de forskellige interessenters problemer således at de kan fortsætte som succeser i virksomheden. Denne løsning har sjældent noget at gøre med en eller anden form for rationalitet (med hensyn til at løse et problem for virksomheden).
Man kan selvfølgelig så indvende "Jamen wolle du har jo selv sagt at alt afhænger af perspektivet" og det er selvfølgelig korret. Det er bare rart at vide at man kan vurdere løsningssalg på denne måde.

Et interessant indlæg om pain chain og solution selling.