Yes sir

Hejsan så kører vi. Holdt lige en scrum intro til "Den Store Projektleder". DSP'en ville have den for sig selv inden vi ruller ud så formålet for mig var naturligvis at sælge budskabet. Og det er først og fremmest for at få lov til præsentere for "Mini projektlederne" så de også kan se lyset (bliver større udfordring fordi de kommer til at opleve at deres magt fjernes) men det klarer vi nok også. Nå - tilbage til præsentationen:
DSP'en startede med at præsentere sine problemer. Mens han ridsede op måtte jeg simpelthen klappe i mine små hænder. For sjældent har jeg lavet en præsentation som er så tæt på at præsentere en løsning uden at kende alle problemerne på forhånd. På den anden side kan man selvfølgelig lige sige at problemerne med store plandrevne projekter ligesom ikke er så svære at gennemskue. Specielt ikke i en stafet orienteret organisation hvor vi ligger i feltet anarchy eller mere præcist "Massic avoidance" fra Ralph Stacey kompleksitets analyse model.
Nå men anyway Manden købte Scrum. Ville endda starte en pilot stort set med det samme på et lille projekt. Derudover skal jeg sælge møget til "Mini projektlederne" og forsøge at facilitere en lille diskussion.
Målet med dette salgsmøde må være følgende:
1) Få skabt begejstring hos min. 75% af mini projektlederne.
2) Få skabt basis for at jeg skal facilitere efterfølgende diskussioner
3) Få sat mig selv på banen som "Scrum evangelisten".
Det bliver interessant.
Det er sgu sjovt. Det er der her jeg kan. Skabe begejstring for ting :)

Michael som Forandringsagent

Så kører vi.
Scrum præsenteres for alle mulige mærkelige folk i organisationen. Det bliver ret interessant. Har præsenteret for den største udviklergruppe og de var positive, men det er vel ikke så svært at forstå.
Så er der arkitekturafdelingen. Der var lidt mere lunken modtagelse primært fordi gruppearbejde ikke umiddelbart virker som noget der tiltaler.
Så skal jeg snart præsentere for ledelsen i "det store projekt". Det bliver interessant fordi det er her alle mellemlederne befinder sig og de skal have deres tanker "flipped".
Så er der også udsigt til at skulle præsentere for IT ledelsen, men her er der tale om en interessant konflikt. Umiddelbart ser det ud til at min chef ikke har lyst til at slippe mig løs foran denne gruppe.
Der kan så være et par grunde til dette.
1) Han tror ikke på mine evner
2) Han tror for meget på mine evner
3) Han vil selv tage æren ell. have initiativretten.

Spændende
Men lige nu løber jeg rundt og spreder ordet. Det er interessant hvorledes jeg som person lader mig begejstre i en grad så det virker smittende. Det hænger ikke rigtig sammen med emnet så ...
Jeg kommer helt sikkert til at træde nogle folk over tæerne, komme til at få skabt nogle fjender men forhåbentligt også skaffer nogle allierede.
Det er ihvertfald cool. Fuld fart fremad og lad os se hvad der sker. Idéer idéer idéer det er hvad wolle er om.

So right so right

The quote of the day from Balancing Agile and Discipline, Barry Boehm & Richard Turner
"Most software people do not do well at expectations management. They have a strong desire to please and to aboid confrontation, and have little confidence in their ability to predict software project schedules and budgets. This makes them a pushover for aggressive customers and managers trying to get more software for less time and money."

Udviklingsstandard

Hmm
Har ellers lige lavet en række meget lækre powerpoints med visioner og guidelines for udvikling af eclipse plugins....
Næ nej det er sørme ikke detaljeret nok. Filipinske programmører er tilsyneladende ikke i stand til at tænke så det skal udpensles hvad de skal gøre.
Det bliver noget i stil med følgende:
1) Lav en testcase hvor du extender dk......testcase før du gør noget andet
2) Kode den ønskede funktionalitet til din test kører
3) husk at overholde kode standarden
4) lav javadoc
5) kør test
6) check kun ind hvis testen kører
osv. osv.

Det er lidt tankevækkende at vi forsøger at køre en agil projektstyringsramme (Scrum) og så skal der detaljeres i den grad, men hvad det skal nok gå alt sammen.
p.s. nogen der har flere detaljer til ovenstående?

Symptomer på en nedbrudt proces. Der kom LEAN igen

Er ved at forsøge at finde symptomer på en proces med fejl i eller nærmere bestemt en proces der er brudt sammen. Prøver at formulere symptomerne så scrum kan løse dem :)

Venter du ofte på at få lov til at gøre noget?
Venter du på at modtage et svar der får dig videre?
Er det svært at få adgang til ressourcerne?
Er det svært at føle ansvar for opgaverne?
Er det svært at måle fremdrift?
Bruger du for meget tid på at skifte mellem opgaver?
Er det uklart hvem der gør hvad?
Spilder du tiden på at finde ud af hvem der gør hvad og så få dem til at vedkende sig ansvar?
Har I brug for produktivitetsforbedringer?
Spilder du tid på at give statusrapporter, holde statusmøder etc. til ledelsen som ikke bidrager til at skabe produktet?
Er du fløjtende ligeglad med hvad der sker?
Er der en mistroskultur eller er vi en lærende organisation?

KSMF eller kom selv med flere.
Det lyder meget som oplagte kandidater for en LEAN optimering? Det handler altså om følgende
Hvad har dette at gøre med at levere software? -- I LEAN termer undgå muda :)
Samtidig handler Scrum (og de andre agile "metoder") om at tro på det enkelte individ og dets kompetencer. Det gør det jo også i LEAN (se tidligere indlæg "mandag morgen surhed - eller ingen muda til mig ").

Off Topic -PADI Advanced Open Water

Hey I'm now a PADI advanced open water diver. It's me on the left :) This is the visibility on 22 m.
This weekend i went to Kullen with two colleages and got my first deep water dive. Man I use air. We went down to around 22 m in 5-6 meters of visibility. Hmm that means that you're not able to see the surface. Interesting. It was really nice. I saw a salmon and a lot of starfish. We did a descent without any visual references. This means that the only thing you have is your buddy.

update on lean,scrum, taylorisme etc fra min udsendte i arabiens land

Fik en meget interessant mail fra min ven der har gemt sig i arabiens land, hvor han hundser med indere. Han har følgende observationer til min post om lean etc.
Har klippet den ud

Da jeg startede hernede og hoerte alle historierne om hvor uduelige, ugidelige og uansvarlige (eller hvad det nu heder, naar man ikke vil tage ansvar for sit arbejde) indere er, troede jeg ikke paa et ord af det, efter seks maaneder troede jeg paa hvert et ord af det, efter to aar tror jeg at jeg forstaar hvor det gaar galt.
Her min opfattelse. Naar vi i Europa og maaske isaer i norden, ser paa ansatte i vores branche, saa ser vi normalt paa folk der naermest arbejder med deres hobby, de er for det meste motiverede, foeler et stort ansvar for det de laver - de lever og taenker software udvikling selv naar de ikke er paa arbejde. Hvis du ser paa andre brancher, lad os fx sige en fabrik der laver stiger, hvor mange at de ansatte paa den fabrik taenker stiger naar de
gaar hjem? Jeg vil sige ca. 0% medmindre de skal skifte en paere i en lampe der sidder for hoejt til at naa, og selv er der en paen stor sandsynlighed for at de taenker stol, bord eller stol paa bord foer de taenker paa stiger. Du har nok gaettet hvor jeg er paa vej hen. Lang stoerstedelen af de indere jeg har arbejdet med, taenker som samlebaandsarbejdere og det er der for saa vidt ikke noget galt med, men det giver en klar indikation af hvor vi er paa
vej til - software er bare en anden industri og industrialiseringen kommer. Selvtaenkene, ansvarlige, kvalitetsbevidste, stolte software folk vil lide samme skaebne som andre haandvaerkere - nogle faa vil blive ansat paa software fabrikker, saa de kan designe produkter, maale kvaliteten eller i langt mindre grad i ledelses stillinger. Resten vil forsvinde. Hvis du er i tvivl om hvorvidt dette er rigtigt, saa se paa outsourcing boelgen, har du vaeret i et indisk outsourcing software firma? Det er en fabrik, medarbejdere bliver behandlet som fabriksarbejdere. De ansaetter typisk dobbelt saa mange folk som de har brug for og saa er der masse afskedigelser efter en eller to maaneder. Kvalitetssikring og processer er
typisk groft tilpasset fra fabriks processor, det er en tendens vi ser hele tiden, se bare paa TPS der nu bliver brugt i software.
Det er interessante tanker. Jeg ved ikke helt om jeg er enig eller ... Jeg kom lige til at tænke på følgende:
Lad os antage at min gode ven har ret. Software industrien er igang med at foretage en industrialisering. Inderne, filipinerne, kiniserne etc. (Inderne outsourcer p.t. til kina ;)) opretter sweatshops. Disse udkonkurrerer håndværksmestrene (ihvertfald de dårlige). Dernæst kommer den 2 industrielle revolution, hvor kvaliteten af de udviklingsmiljøer etc. som udviklere benytter til at udvikle software forbedres. Samtidig er det stadigvæk nødvendigt at lave programmering i massive mængder fordi vi stadigvæk benytter den strukturerede tilgang til udviklingen i mange situationer selvom vi "claimer" objektorientering. Kom til at tænke på to personer som den udsendte i arabiens land og jeg mødte på JAOO tilbage i 2003. De præsenterede "Naked objects" hvor man laver sin objektmodel og dernæst sørger frameworket for at give dig (brugeren) mulighed for at manipulere med objekterne. Dette kunne være næste skridt i retningen af mere produktiv programmering således at det er muligt at konkurrere med software fabrikkerne.
Fik lige en skræmmende tanke. Grunden til at outsourcing af kodning aldrig helt vil erstatte inhouse programmører er fordi vi er så dårlige til at programmere at ingen kan forstå hvad man har lavet og det er forbundet med for store omkostninger at eksternalisere denne viden (den lægger jo i koden, men...). Samtidig er mange programmer også karakteriseret ved at benytte sig af mange forskellige mønstre som ikke er blevet fælles eje. Det svarer vel lidt til at hver enkelt tømrer bygger sine spær på hver sin måde, med hvert sit type træ etc.
Design mønstre indenfor software udvikling er et skridt henimod bedre mulighed for forståelse af programmer og mulighed for at gøre software til fælles konstruktioner. Spørgsmålet er så om det er en vej vi vil?

mandag morgen surhed - eller ingen muda til mig

HVAD sker der med jer? Hvem fanden har bildt jer ind at software udvikling er en gentaget proces? Hvis der er folk der udvikler det samme stykke software mere end 1 gang burde de stilles op på væggen når revolutionen kommer. Men hvis formålet ikke er at levere et stykke succesfuldt software, der gør hvad det skal og har styr på interessenterne men derimod at lave noget software som nogenlunden lever op til de krav der blev strikket sammen en gang i tidernes morgen så værsgo.
Hvorfor er der ikke nogen der har fortalt mig at LEAN i sin filosofi giver rigtig meget til Scrum? Prøv at se følgende fra wikipedia

By eliminating waste (muda), quality is improved, production time is reduced and cost is reduced. Lean "tools" include constant process analysis (kaizen), "pull" production (by means of kanban) and mistake-proofing (poka-yoke). Lean, as a management philosophy, is also very focused on creating a better workplace through the Toyota principle of "respect for humanity."
Key lean manufacturing principles include:

• Perfect first-time quality - quest for zero defects, revealing & solving problems at the source
• Waste minimization – eliminating all activities that do not add value & safety nets, maximize use of scarce resources (capital, people and land)
• Continuous improvement – reducing costs, improving quality, increasing productivity and information sharing
• Pull processing: products are pulled from the consumer end, not pushed from the production end
• Flexibility – producing different mixes or greater diversity of products quickly, without sacrificing efficiency at lower volumes of production
• Building and maintaining a long term relationship with suppliers through collaborative risk sharing, cost sharing and information sharing arrangements.
• Lean is basically all about getting the right things, to the right place, at the right time, in the right quantity while minimizing waste and being flexible and open to change.

Så LEAN i mit software univers; "Hvad har dette at gøre med at levere software? Intet - okay så gør vi det ikke vel?" Iøvrigt får jeg grimme flashbacks når jeg læser om Kaizen, just in time, tqm etc. Er sgu glad for at køre toyota. Støtter tilsyneladende udviklingen af software metodiker ved at bruge deres produkt.

Så lige en præsentation af CMMI fra carnegie mellon (dem med cmmi :)).

En af foredelene ved at benytte CMMI i forbindelse med Software

Extend SW-CMM benefits to the total project & organization

hmm er det godt

Ha en god mandag

Integrating CMMI and Scrum

I'm going to do a project off-shore (will be onshore when i go :)). The delivery center is CMMI level 5 (of course).
That gives me a interesting challenge. I have to integrate the delivery center CMMI process' into Scrum (or the other way around).
That means that not only should i master scrum but also the delivery centers implementation of CMMI.
Joseph Pelrine and others says that Scrum is CMM level 3, that is there is a description (level 2) and the process is characterised (for the organisation) and proactive.
What i miss is then :)
Level 4: defined "enough" measure so that we can measure and control (are the burndowns and backlogs enough?) and to reach
Level 5 we just need to define continuous process improvements.
As i see it - the existing process just have to include Scrum and then we'll use the existing process' for reaching 4 and 5.
If any of you have some thoughts on this one I would appriciate them.
I'll keep this post updated as i get wiser.
Just found a interesting blog entry on cmmi.
It will be interessting to see the process they're using.