Lean, taylorisme, XP, paradigme the works

Jeg læste en interessant kronik i Berlinske tidende her i morges. Den handlede om lean eller nærmere om hvor lean kommer fra (http://www.berlingske.dk/kronikker/) af Kim Leck Fischer.
Jeg kunne ikke rigtig se hvad forfatteren ville med artiklen, men han havde dog nogle pointer som jeg blev lidt inspireret af. Han nævnte at Leans baggrund eller filosofi kan føres tilbage til gode gamle taylor og hans ideer om bl.a. "de dovne arbejdere". Samtidig er jeg gået i gang med en bog "Balacing Agility and Discipline" af Barry Boehm og Richard Turner. Det er lidt interessant at følge diskussionerne vedrørende agili metoder, lean, CMMI, etc. etc.
De har hver deres paradigme som de er udsprunget af og vurderer også hverandre ud fra det paradigme så jeg synes en gang imellem at det er lidt svært at få fod på hvordan de rent faktisk skal anvendes. Problemet bliver jo hvis man blot anvender en metode ukritisk forstået som lad os være agile, men vores syn på systemudvikling er baseret på taylorisme ell. den mekanistiske verdensopfattelse. Samtidig er det også svært at forklare de forskellige metoder/teknikker, hvis man ikke har paradigmet med. Jeg syntes selv at det er svært at huske hele tiden at have andres paradigme med når jeg diskuterer og så bliver det nemt; "Jamen du er jo dum" agtigt.
Derfor Lean, CMMI, plan-drevent, XP, RUP, etc. de er jo alle kommet ud af nogle forudsætninger og nogle antagelser om konteksten (det er vel et paradigme?). Derfor skal de også vurderes som de er. Samtidig siger de alle sammen at man skal bruge os rent ellers virker vi ikke. Jeg tror bare at man bliver nødt til at være lidt pragmatisk og så blande tingene lidt? Eller er det sådan at man skal køre ren XP for at de overhovedet giver mening (jeg ved godt hvorfor det hedder Extreme), men der er jo mulighed for at være agile i sin anvendelse af metoder og teknikker. Det er bare vigtigt at man husker de grundlæggende forudsætninger for teknikken/metoden. f.eks. for XP at programmering er et håndværk som bygger på erfaring og en masse implicit viden hos de enkelte programører, at kunden har ret til at blive klogere etc. etc. Hvis man ikke har disse forudsætninger med så tror jeg ikke at man høster frugterne. De forskellige måder at gøre ting på bliver jo let forvansket og brugt som forklaring på alt mulig andet. XP har jo haft/har ry for at være "license to hack", hvilket jo ikke kan være mere forkert mens lean har ry for at være stærkt begrænsende for kreativitet.
I et tidligere indlæg har jeg skrevet om Ralph Stacey. Kronikkens forfatter henviser også til Ralph Stacey i sin kritik af lean. Det betyder jo et eller andet sted at hvis man er i områder med enighed og lav teknologisk usikkerhed så er lean sikkert en god idé men hvis man ønsker
1) kreativitet/innovation
2) medarbejdere der går en ekstra mil
3) medarbejdere der udvikles
så kan de være at man skal se om man ikke kan komme op i det komplekse felt. Da jeg første gang læste om lean gav det jo fin mening. Det gør det i og for sig stadigvæk, men lean/CMM/.... er ikke løsningen på alle problemer ligesåvel som agile metoder, process kontrol metoder heller ikke er løsningen. Nu kan jeg mærke at klicherne står på spring så her er det. Det handler om ikke at skyde gråspurve med kanoner, at bruge en hammer til søm, ikke at presse en firkant ned i en cirkel etc. etc.
Det er jo bare lidt svært fordi vekslen mellem forskellige paradigmer kræver megen refleksion og evnen til at se problemer fra forskellige perspektiver. Og hvis man så endelig er i stand til det så skal man have overbevist andre folk som egentlig ikke gider tage stilling fordi det er meget nemmere blot at blive i den verdensopfattelse man har. Det kræver energi at flytte sig. Samtidig er det jo også frustrerende at skifte mellem perspektiver fordi jeg så hele tiden skal forsøge at se ting fra en anden vinkel og dermed risikerer ikke at få taget et standpunkt.
Når man for at nå en eller anden form for konklusion så må det jo være
1) at man hele tiden skal være opmærksom på hvilket paradigme man vurdere ud fra
2) at man skal forsøge at gå ind på paradigmets præmisser
3) at man ikke skal bruge en hammer til at save med
4) at respektere hvor man kommer fra.

Endelig som egentlig var det jeg ville med dagens indlæg. Synet på indere, østeuropæere etc. indenfor min branche synes jeg et eller andet sted er arogant. Det er rent taylorisme der ligger til grund for vurderingen af deres evner. Endvidere synes jeg også, at man skal huske hvorledes man selv ville have det hvis man fik den samme vurdering :)

Why systems development is different than building a bolt

but more is like a chemical process'.
In the book "Software development with Scrum" by Ken Schwaber and Mike Beedle they say
"I wanted to understand the reason that my customers' methodologies didn't work for my company, so I brought several systems development methodologies to process theroy experts at the DuPont Experimental Station in 1995. These experts, led by Babatunde "Tunde" Ogannaike, were the most highly respected theorists in industrial process control. They knew process control inside and out. Some of them even taught the subject at universities. They had all been brought in by DuPont to automate the entire product flow, from forecasts and orders to product delivery.
They inspected the systems development processes that I brought them. I have rarely provided a group with so much laughter. They were amazed and appalled that my industry, systems development, was trying to its work using a completely inappropriate process control model. They said systems development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as "empirical". They said that this was nothing new, and that all complex processes that weren't completely understood requiered the empirical model. They helped me go through a book that is the Bible of industrial process control theory. Process Dynamics, Modeling and Control to understand why I was off track."

Risiko ved scrum

Kom lige til at tænke på en interessant ting ved Scrum. Man kan rent faktisk ricikere at man ikke får noget ud af projektet. Tilgengæld giver scrum mulighed for hurtigt at opdage det så man ikke spilder tiden. Derudover er der jo det ved Scrum at man sådan set lukker teamet ind i en hule med deres mandat og se hvad der kommer ud af det. Man sørger så løbende for at fjerne forhindringer på teamets vej.

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.

Ralph Stacey's agreement & certainty matrix

En af de teoretiske baggrund/forklaringsmodeller til hvorfor XP og Scrum virker findes hos Ralph Stacey i hans beskrivelser af komplekse adaptive systemer. En god intro. I Scrum og XP handler det om at fyre op under teamet/projektgruppen således at man fremelsker innovation og kreative løsninger. Projektgruppen skal op i det komplekse felt.

Rysteribs og indførelse af Scrum

Det er fantastisk. Det er første gang at jeg har en have. Har ellers altid boet i lejligheder. Jeg kan svagt huske noget med min mormors fantastiske have med masser af frugt og blomster. Jeg har også en masse frugttræer og ligger i stærk konkurrence med fuglene om at spise kirsebær for tiden. Men jeg har også en ribs busk og i går måtte jeg bare høste. Det blev til omkring 2 liter ribs som jeg så prøver at lave til rysteribs (put en masse sukker over og lad det "smelte"). Jeg kan rigtig godt lide ribsbusken fordi den er fyldt med bær så man kan se at der sker noget. Har også lige høste nogle selv plantede gulerødder. Det er rart.
Med hensyn til indførelsen af agile metoder og Scrum i organisationen har jeg første prøvekørsel af en præsentation om Scrum i dag. Det bliver sjovt at høre kommentarer til præsentationen. Skal senere præsentere for nogle udviklere samt deres leder som også er lydhøre. Det bliver mere interessant når plandrevne folk skal overbevises. Organisationen har gang i et stort projekt som naturlig vis er forsinket og kunne bruge lidt mere faktisk styr på udviklingen. Det er faktisk lidt sjovt/skræmmende. Man fjerner i nogle dele ansvaret for estimater for den enkelte person. Det medvirker bl.a. til at fjerne folks ansvarsfølelse for det stykke arbejde som de leverer. Hvis man ikke er commitet til det man laver så bliver kvaliteten også derefter. Det der nemt sker når man bliver detail styret er at man mister sit engagement og blot vil "overleve". Overleve betyder her "Så skal det bare blive færdigt så jeg ikke får tæsk".

Måske skyldes dette at man ser software udvikling i et socio-teknisk perspektiv eller nærmere mekanistisk. I bogen Computers in context er der rigtig mange forskellige perspektiver på software udvikling. Det der er interessant med den er 1) at få beskrevet forskellige perspektiver og 2) at få øjnene op for at verdenen skal fortolkes udfra den kontekst vi er i. Jeg volder lige den tidlige wittgenstein men han siger noget som 'man kan ikke stille spørgsmål som man ikke kan besvare'. Min fortolkning af dette bruger jeg til at forklare hvorledes professionel systemudvikling i meget høj grad handler om at kunne veksle mellem perspektiver men samtidig erkende at man ikke kan skifte grundlæggende perspektiv, dvs. fortolkning af verdenen.
Men tilbage til organisationens projekt og indførelsen af Scrum.
Jeg vakler lidt mellem at vælge
1) lad dem brænde op og selv erkende at det ikke holder
2) Introducere Scrum til disse folk men så lade dem prøve selv og gøre vold på det.
3) ??????

Det svære har jeg oplevet er at få folk til at forstå at man sagtens kan have sine ben i naturvidenskaben, humanioren og samfundsvidenskaben. Det passer ikke ind i folks skabeloner. Hvordan får man folk til at hoppe ud af skabelonerne? Hvordan forklarer man folk med en ophøjet tro på "planen" at det ikke altid holder. Specielt troen på at man kan detail planlægge 12 måneder frem er lidt naivt. Der findes ikke mange decipliner hvor man detail planlægger så lang tid frem på nyt konstruktions arbejde.
Når men hvad har indførelsen af Scrum og rysteribs så tilfælles. Tja det er to ting der optager mig for tiden. Derudover skal jeg måske lade mig inspirere.
Jeg tror jeg vil udbrede ordet om Scrum til så mange som muligt. Det skal foregå med fuld hammer. Derefter vil jeg være lidt som sukkeret i rysteribsen, nemlig være tilstede men lade tingene udvikle sig stille og roligt.

Så er wolle på bloggen

Efter mange lange overvejelser er jeg nu i blogspace. Først og fremmest sker det som en måde at komme af med overvejelser vedrørende software udvikling. Jeg har lige været afsted på Scrum master certificering med Joseph Pelrine. Det var vældigt interessant.
se bl.a. http://www.scrumalliance.org og http://www.contralchaos.com
Har lige læst en spændende artikel om wicked problems hos Dr. Dobbs http://www.ddj.com/dept/architect/184414851. Se dette entry http://en.wikipedia.org/wiki/Wicked_problems
Det spændende ved wicked problems er for mig ikke så meget eksistensen men mere at man får sat nogle ord på ting som jeg selv har observeret. Det giver redskaber til at kunne overbevise/oplyse folk om software udvikling og dens natur.
Er igang med at kigge på indførelsen af Scrum i en større dansk virksomhed. Det gør at jeg er ved at genopdage min teoretiske interesse for datalogien (RUC). Den har ellers været lidt ude at svømme siden jeg blev færdig for 8-9 år siden. Der har været spæde tiltag til at bibeholde den teoretiske baggrund men det går hurtigt op i politiske kampe og besserwissen. Så er det sgu nemmere at knalde noget kode.
Jeg kan bare ikke holde det tilbage. Kvalitet i software eller måske mere præcist den gruppedynamik som kan findes i software udvikling er noget af det der får mig til at juble. Skal snart igang med et projekt hvor der skal bruges udenlandske ressourcer. Det bliver spændende at se hvorledes (og om) man kan benytte Scrum samt XP processer i asien. Rygterne siger jo at man ikke kan, men det tror jeg ikke på. Det er jo ikke idioter, men folk som laver software og som et eller andet sted også føler kicket ved det.
Hmmm skal måske til at stoppe. Bliver interessant om jeg kan holde gejsten oppe når vi kører, men jeg vil forsøge at bruge wollesplace til
1) Få afløb for frustrationer
2) Dagbog for erfaringer med Scrum og alt muligt andet.
3) udveksling af erfaringer med andre som tænker som jeg?

lad os se