wollesplace - a nice and flurry feeling

Lean and Scrum

2011-07-06T09:14:00.002+02:00

I just read this entry about adding more pull to scrum. I think I will try out some of the ideas very soon.
http://leansoftwareengineering.com/ksse/scrum-ban/

hay i'm back and now with .Net

2009-05-20T13:02:00.003+02:00

Hi
I been through a interessting year since last post. I've joined a new company and is now working as a socalled domain manager where i'm strategic responsible for connectivity tools in the whole product which is a investment management suite.
I'm still preaching scrum but now on the other side as product owner.
But that's not what i want to blog about. I have just come home from microsoft teched 2009 which was a very inspiring visit. The dark side of computing is getting brighter. Some of the really interessting stuff that i'll be looking into is the workflow support that is coming in .Net 4.0 which will be XAML based. Also the project named velocity looks promising. it's a distibuted memory cache that will come with the 2008 server rel.2
Other interessting projects are
Oslo with the m language for defining grammars
Dublin for having better server behavior :)
and azure which is microsofts cloud computing solution

Status

2008-05-23T12:10:00.004+02:00

ja så har mine piloter kørt i omkring 2 måneder og det er interessant at det ikke er svært at få team medlemmerne til at arbejde sammen og få produktivitet og synlighed. Den store udfordring herude er at få skabt ejerskab hos produktejerne. Der er flere problemer, et er tror jeg at man for at være produktejer skal have nogen indflydelse. Måden man har opnået denne indflydelse er tilsyneladende ikke ved at være engageret i det arbejde der rent faktisk udføres og ved at tage ansvar. Derfor når man afkræves ansvar (som produktejer) er det nemmere at stikke hovedet i busken og forsvinde. Jeg synes det er så tyndt at jeg har et team som knokler derudaf og som virkelig gør en forskel og så forsvinder deres produktejer og viser ikke interesse for produktet. Jeg bliver så sur. Det er fandme ikke for teamets skyld at de udvikler.
Sure lure. Derudover har jeg lavet en masse scrum salgsarbejde, men "gider" ikke flere piloter. Scrum virker så lad os komme igang.

Indtryk fra en IT arkitekts hverdag

2008-01-14T07:34:00.000+01:00

Har lige gennemført et kanon projektleder kursus. Det mest interessante for mig var de bløde elementer og de indadvendte. Jeg opdagede at jeg rent faktisk evner at coache hvilket kommer lidt som en overraskelse for mig. Jeg har altid gået efter mine løsninger, men måske er det et element i at blive voksen. Derudover har jeg "taget" en meyers briggs type indikator. Der er ikke de store overraskelser i min profil (ENTJ), men det interessante er noget af den teori der ligger bagved. Specielt ens såkaldte inferiøre funktion. Det er den funktion der kommer til udtryk når man er stresset/presset. Det er ret interessant for min er såkaldt introvert følen, hvilket betyder at jeg lukker mig inde og ikke stoler på mig selv mere. Der var en masse andet godt (og nogle pm teknikker, men de har ikke udviklet sig væsentligt siden roderkonge). Jeg fik også samlet lidt krudt til kampen mellem det plandrevne og det empirisk baseret. Når men tilbage til en it arkitekts hverdag. Det ene øjeblik skal man udvikler web baseret funktionalitet til vores SCM værktøj, Dimensions. Det andet øjeblik skal man forholde sig til LEAN i it afdelingen samt forsøge at provokere vores ledelse. Så skal der udvikles en prototype i Eclipse EMF/GMF således at jeg kan vise hvorledes man kan benytte meta modellering til forskellige løsninger. Så ringer der en bruger af Serana Dimensions som ikke kan checke-in. Hmm jeg har jo ikke produktions passwordet. Hvem har det? Find en... :) Og så er det tid til at lave en præsentation af Scrum tilpasset et ikke kendt publikums specifikke behov :-) 2 timer uden vand men med fuld hammer på mundtøjet og lytterbøfferne for at finde vejen. (Gik iøvrigt godt. Jeg elsker det). Når så skal man forholde sig til overordnede styringsprincipper, hvor man ikke lige har fået noget information, men ens Scrum implementering er ret afhængig af det.... Og hvem kan lige lege med mig og hvordan laver vi et roadmap etc. etc. Så skal man også lige forholde sig til integrationsarkitektur samt brug af Spring.
Forholdsvis divers arbejdsdag og jeg elsker det et eller andet sted. Kunne være fedt hvis der var en enkelt person som man kunne køre parløb med men sådan er det nok ikke ...

Scrum i vedligehold

2008-01-04T07:23:00.000+01:00

hmm så er vi endelige ved at være fremme ved at der skal bruges lidt tid på at indføre Scrum. Jeg skal indføre Scrum i forskellige typer af teams og projekter. En udfordring er i forbindelse med teams der har vedligeholdelsesansvar og support ansvar. Vedligeholdelsesopgaverne ryger bare ind i backlog'en (kræver lige lidt gymnastik, men ...) I forbindelse med support opgaver er jeg lidt mere i tvivl om hvorledes det skal håndteres. Der er ihvertfald to måder som jeg ser det p.t. Enten "nedskriver" man teamets kapacitet med en eller anden faktor. Og tager folk ud til de "vigtige" support opgaver der kommer. Det vil nok være den traditionelle måde at gøre det på, men jeg ser flere problemer med den tilgang. Et er at man fjerner synlighed af teamets arbejde, en anden er at man risikerer at supportopgaverne ikke ses som en del af teamets ansvarsområde og dermed opnår man ikke potentielle fordele ved at kunne sprede evne til løsning. Derudver er der en risiko for at man tilsidesætter prioriteringsarbejdet og "tvinger" teamet til at nå det de har commitet sig til selv om de rent faktisk laver andet.
Dvs. Synlighed og gruppedynamik kan lide skade ved denne måde at gøre ting på.
En anden måde som jeg lige skal har styr på er at inddrage de akutte support opgaver i backlog'en og skabe en synlighed på eksempelvis en kanban tavle. Man kunne bruge en anden type eller farve kanban. Man vil stadigvæk tilsiddesætte sprint planlægningen, men til gengæld vil der være synlighed og der vil være mulighed for scrum masteren til at kommunikere løbende. any ideas?

Asien og situationsbestemt ledelse - De kan mere end S1

2007-11-28T08:21:00.000+01:00

Jeg har lige været på noget kursus noget hvor vi bl.a. kiggede på situationsbestemt ledelse. Den ledelsesstil som benyttedes i Asien var den meget instruerende og lidt støttende (S1). Brugen af scrum og de ting jeg prædikede forsøgte at bevæge ledelsesstillen fra S1 til S4. Enkelte kunne ledes vha. S4 og S3. Der interessante i denne situation er hvorledes min mere støttende ledelsesstil kunne co-eksistere med en organisation hvor S1 er den dominerende måde at styre og lede på. Nogle af de konflikter der optrådte kan forklares vha. denne model, eller ihvertfald give et perspektiv.
Jeg blev lidt provokeret af underviseren da han sagde at alle asiater "elskede" S1 og kun var istand til at modtage denne form for ledelse. Jeg føler, at jeg har set det modsatte ske i Asien så denne fordom holder ikke. Derimod er der en del af deres kultur, hvor man skal se på gruppen i forbindelse med sin ledelse og forsøge at overføre denne ledelsesstil til grupper. Udfordringerne i Asien handler bl.a. om at skabe evnen til at stille spørgsmål og et eller andet sted kræver dette selvtillid. Denne selvtillid kan man opbygge igennem en bevidst brug af gruppen og skabelsen af gruppe helte.

Long time no see - en masse forskelligt

2007-11-28T07:48:00.000+01:00

Yes så er det ved at være et godt stykke tid siden sidst. Der har bådet være en barsel og så en masse finde sig til rette og profilere sig i organisationen efter at jeg er kommet tilbage. Der er dog sket en masse interessant. Jeg er blevet involveret i LEAN (til at starte med som rådgiver), skal højst sandsynligt til at starte nogle piloter med brug af agile metoder sikkert Scrum. Piloterne bliver interessante fordi de ikke skal håndtere projekter i traditionel forstand men derimod bundles af mindre opgaver. Umiddelbart virker det jo lige til højrebenet for kunne man ikke organisere det efter produkter? Jo da, det virker som en god ide, men det betyder jo at vi skal til at se på vores systemportefølje som bestående af produkter og dermed skal vi til at identificere en person (evt. proxy) der kan tage det forretningsmæssige ansvar for en sådan sag. Derudover skal vi også til at have en synlig prioritering af de forskellige features/opgaver. Min umiddelbare bekymring er dog et helt andet sted. Nemlig hvorledes får jeg skabt forståelse for at god systemudvikling starter med at man lader folk tage ansvar og at man acceptere fejl som en del af læring.
Har iøvrigt været på LEAN software development med ægteparret Poppendieck. De er meget amerikanske men det var interessant og udemærket. Det giver lidt stof til eftertanke specielt er det meget sjovt at se JIT principperne anvendt på software. Store produkt backlogs med 1 år gamle features, der endnu ikke er prioriteret giver måske ikke den store mening og bruges mere som en parkeringsmekanisme.
Iøvrigt så er projektet i asien afsluttet og til manges overraskelse er det blevet en succes :) Det er en fornøjelse at have være med til at starte noget op og skabe basis for læring. Se næste post om Situationsbestemt ledelse og Scrum/CMMI.
Som man kan læse er det masser at gå i gang med så det vil jeg forsøge at dele her over de kommende måneder.
P.t har jeg valgt at være på en stort Software Configuration Management projekt for at få trænet mine evner til forandringsledelse. Der er nogle udfordringer i forbindelse med ældre udviklere som efter 20-30 år skal forandre deres måde at arbejde på. Endvidere er det et stærkt projektteam. Vi benytter Serena Dimensions primært fordi det er det eneste (?) SCM værktøj der understøtter både mainframe og decentrale platforme (med processer).

Eclipse stuff

2007-09-03T08:02:00.000+02:00

Just went to a eclipse.dk gathering. Heared some interessting stuff about eclipse (and some not). There was a director from the eclipse foundation (Ralph Mueller) who talked about stuff but also talked about modelling in Eclipse and would see if he could bring me in contact with the european eclipse modelling community. That could be cool. There are some interessting eclipse projects that i have to look at. For instance a project called mylyn that's about integrating your tasks into your IDE. It looks like it also tries? only to show what's in your change set aka only makes sense for the task at hand.
Eclipse maintains a site with a lot of live demos, webcasts etc

Currently i'm trying not to think DSL every time i see a problem. So it's about thinking out of the box but it's funny to observe how you (at least i) always tend to solve every problem with the tool you currently have in your hand. It's difficult to step back and look down in the toolbox to see if there are other possible tools that could do the trick.

Software giver tilbage til produktionen

2007-06-27T13:47:00.000+02:00

Har lige læst om en lean gut der har hyret en scrum master til at hjælpe med et projekt. Det ser interessant ud og jeg glæder mig til at høre mere om resultaterne.

Nu skal jeg også have læst noget lean :)

2007-06-18T22:46:00.001+02:00

Har lige læst en kort artikel om lean og xp, mest interview referater. Fik mig lige til at tænke at nu skal jeg også have læst poppendieck og se om jeg er enig eller ej. Jeg aner jo ikke hvad det går ud på andet end at det er en måde at forbedre produktionen. Det centrale spm for mig er hvorvidt lean handler om at optimere eksisterende processer (forudsigbare resultater) eller "blot" er en måde at stoppe op og stille nogle spørgsmål. For mange år siden læste jeg geografi og såvidt jeg husker skrev jeg lidt om TQM, JIT, Kaizen, Kaizan? Hmmm er Lean det samme? Glæder mig til at læse lidt om det.
Har ellers en god og ikke fagligt stimulerende barsel så ....

Det ser sørme ud til at virke

2007-06-17T10:29:00.000+02:00

Har lige hørt seneste nyt fra filipinerne og der er naturligvis udfordringer men det ser sørme ud som om scrum virker :) Det er temmelig rart at de stadigvæk gør det selv om jeg ikke er der mere. Teamet er begyndt at føle rytmen, der er minimalt spildover til næste sprint, deres estimater bliver bedre og de implementerede features er mere komplette. Det er fedt at have haft en stor hånd med i denne forandring. Skal snart derned for at hilse på; det bliver interessant.

closed for maintainance

2007-06-01T12:48:00.000+02:00

Currently i'm on paternaty leave and focusing on child care. It's nice. I'll be back in august/september with a retro spective on the project. In july i have a short visit to the philipines to see how they're doing. I'm looking forward to see if the things i started have been continued and giving value.

Lidt retrospektiv

2007-04-17T19:44:00.000+02:00

Ja så har jeg været hjemme i dannevang i 1 1/2 uge efter at have vendt op og ned på nogle filipineres arbejdsliv og metode. Det er ikke gået som jeg havde håbet men jeg er nok lidt for ambitiøs.
Til gengæld er det en rar tanke at have fået forandret 15-20 mennesker fra at være nok-sagte Yes sir vandfaldsfolk til rent faktisk at arbejde iterativt, stille kritiske spørgsmål (ikke så mange som jeg gerne så), og til at håndtere usikkerhed lidt mere kritisk.
Det er altid svært at vurdere hvor meget indflydelse man har haft og hvor meget man har forandret, men jeg tror dog at der er sket mere med de her udviklere på tre måneder end der vil ske med dem på 1-2 år i deres traditionelle forløb så her skal der kippes lidt med min egen hat. Jeg har gjort en forskel, basta.
Nu er jeg væk og de næste par måneder skal de køre helt uden mig og min "coaching". Jeg skal hellige mig den hellige barsel. Vi er død-heldige i dette land, basta.
Jeg er meget spændt på hvormeget der fortsætter uden mig. Det er altid svært at spå om, da det et eller andet sted ligger i de asiatiske kulturer at føje så man ved aldrig helt hvor meget de tror på og hvor meget der er "skuespil".
Men lad mig se hvormeget der kommer igennem
1) Iterationer
2) fokus på funktionelle enheder. Ting der virker, sashimi
3) Daglig rundesang
4) så så opdatering af ETC, både beregning af etc og opdateringsfrekvens
5) kommunikation mellem team medlemmer
6) Test først som princip (lad os kigge på)
7) Continuous integration
8) Code coverage tools, 100 % Unit test (cirka :))
9) Checkstyle og automatisk kontrol
10) Fokus på kvalitet
11) Brug af eclipse frameworks/API'er istedet for at kode møget selv
12) Brug af en grundlæggende arkitektur
13) Log4j (ja, men det er åbenbart svært)
14) Deklarative løsninger i stedet for at kode selv. Eksempelvis brug af ECore mapninger
15) Brug af forskellige lag / Sub-systemer
16) mere end kun projektledere, der estimere (dog ikke hele teamet)
17) Baniliteter såsom man checker kun ting ind der virker DOH, eksternt byg (se 7), junits skal kunne køre på andres workstations, mere DOH etc.
Det var dog alligevel en sjat så det har måske ikke været helt forgæves.

Produkt ejeren som mere aktiv

2007-02-28T07:45:00.000+01:00

I dette projekt har jeg været meget aktiv i hele processen. I følge scrum er en produktejer en kylling og skal ikke være specielt aktiv. Jeg tror dog at jeg vil anbefale at man gør produktejeren mere aktiv for på den måde at få skabt et tættere forhold og dermed mere identifikation. Samtidig giver det også en bedre mulighed for at få uddannet begge parter. Derfor inddrag Produkt Ejeren og kald hende Produkt referencepersonen :)

Hmm it's not working

2007-02-28T06:02:00.000+01:00

Så hastigheden er for lav og vi får ikke leveret så vi bliver nødt til at lave nogle tilpasninger med hensyn til hvordan vi scrum'er. Det her er
1) De daglige scrum's bliver nu, hvad lovede du i går, hvad vil du love til i morgen
2) Der vil bliver daglige opfølgninger på fremdrift og identifikation af problemer (impediments).
3) Der vil blive etableret et afhængighedsoverblik.
Den sidste kommer lidt som en overraskelse for mig :) Det er ligesom givet at man kigger på prioriteringerne samt skaber sig et overblik over afhængigheder.

Symptomer på at der er noget galt, men ikke nødvendigvis panik.
1) Ingen proaktivitet på de daglige scrum møder med hensyn til at idenficere Impediments
2) Ingen aktiv commitment på de daglige scrum møder.
3) Impediments bliver identificeret for sent.
4) Selvorganisering og team identifikationen kan nok blive bedre.
5) Hastigheden er ikke så god, men det er forståeligt når man tænker på teamets kompetencer.
6) manglende opdatering af etc'er i ScrumWorks.
7) Der bliver ikke tilføjet tasks til implementering af produktfeatures
8) Estimaterne "ejes" ikke af de involverede team-medlemmer.
9) Alle grisene deltager ikke i scrum møderne.
10) Opgaver/Task bliver uddeligeret af team leads.
11) Der er flaskehals personer.

Scrum smells eller er det noget andet

2007-02-28T02:03:00.000+01:00

Så er vi ved at være ved enden af 2 sprint. Det er en helt anden oplevelse end 1. sprint. Der er noget galt med vores process eller også er det ... Jeg kan ikke rigtig sætte en finger på det, men hastigheden er ikke god.
Men jeg tror at det skyldes at opgavens alvor er ved at gå op for teamet. Det betyder at nu skal der leveres noget funktionalitet og de er ikke i stand til det. Vi har allerede fjernet features fra iterationen, men ... Det er ikke så meget at der ikke bliver leveret men mere at der ikke bliver gjort opmærksom på at selv de commitede features ikke bliver leveret. Jeg (som produktejer) skal selv lede og grave i backloggen for at finde det.
Men jeg tror stadigvæk på at Scrum virker og faktisk bliver jeg mere og mere overbevist. Selv med vores implementering af den og en asiatisk tilgang til vidensdeling så kommer problemer op til overfladen hurtigere end i en staged containment process. Så Scrum virker med hensyn til synlighed, men jeg får ikke mine lovede features :(

Sprint retrospektiv - det rå materiale

2007-02-20T01:35:00.000+01:00

Jeg lovede nogle resultater fra vores sprint retrospektiv. Det er interessant at observere forskellige gengangere i kommentarerne. 1) Det er tydeligt at teamet er uerfarent med hensyn til prof. sys.udvikling (Eks. lad en anden end dev. teste :)).
Og noget andet er "ja det sagde jeg til jer ... (Eks. baser estimater på kompleksitet og kompentence. Det er det der hedder dragfaktorer). Eller okay så det er derfor scrum siger det skal vi så ikke gøre det? Fast mødetidspunkt for daglig scrum, brug daglig scrum til at rapportere impediments etc.
Det følgende er det rå resultat fra retrospektiven.
Vi holdt den som en start, stop og forsæt seance hvor vi benyttede nogle standard process-elementer som start guide line.
A/D start
- Brainstorming with Architects before start of stages (White Board Sessions)
- Use of Class Diagrams
- establish template for each deliverable
- Start creating smaller and quicker deliverables (1 whole cyle) for analysis and design
- pair programming and walthroughs for critical areas
- During Sprint planning identify which items should have Analysis and Design documents compaired.
A/D Stop
- minimize the number of review handovers by preventing comments (through walkthrough)
- See if it is possible if we don't go back to analysis and design documents if modifications are made during build.
- See if we can combine analysis and design documents
A/D Forsæt
- informal walkthrough of Team Lead, Architect and Customer
- checklist
Build start
- Junit Brownbag
- Junit sit down sessions with Architect and customer
- FAQ
- Revisit Checklists to remove items covered by checkstyle.
Build stop
- Stop limiting yourselves in the design; raise to lead/Architect if there are additional items/updates which makes sense
Build fortsæt
- Test Driven Approach
- Checkstyle
- Checklists
- Continue compliance to standards (ie. Test Driven approach)

Testing (Plan and Execution) start
- Add checklist for Junit
- Brownbag session for creating Test Conditions and scripts
Testing (Plan and Execution) fortsæt
- Execution is done by the person who did not develop

Estimation start
- Estimate base on complexity and skills
- Revisit Estimates after after analysis
- Establish estimation guidelines
- create fixed budget for the walkthrough
Estimation stop
- stop unplanned walkthroughs
Estimation fortsæt
- involve team in estimation

Issue Håndtering Start
- Brownbag Issue Management Tool
- SLA or turnaround time in resolving issues
Issue håndtering stop
- Do not wait for the weekly Issue Meeting raise impediments ASAP
Issue håndtering fortsæt
- Continue Issue Management on a daily basis (red. daglige Scrum møder)

Project Planning & Tracking start
- Delete af red. skab sammenhæng mellem tidsregistreringsværktøjer
- Start learnings from Sprint 1
- spike first before doing unexplored stuff
- Brownbag tidsregistering (red. del)
Project Planning & Tracking fortsæt
- more vocal in saying impediments
- move daily scrums to 9:30AM
- delinquency list or monetary penalty

Review start
- Revisit Dev Process and Update
- Re-rollout Development Process
- Peer review before teamlead Review
- Start more review walkthroughs with architect and client
- Perform Peer Reviews as an alternative for teamlead Reviews
Review fortsæt
- continue all levels of review

Training start
- FAQ or Index List of Links for References
- Værktøj (red.) brownbag before moving to værktøj (red.) Team
- ask questions
- share discoveries during Daily scrums
Training fortsæt
- Lunch and Learn
- Quick sharing of learnings and discoveries of new stuff (ie. Brownbag for spikes)
- Continue being resourceful (use Værktøjer der er til stede, Eclipse)

Velocity et glimrende tool

2007-02-19T09:43:00.000+01:00

Ja så er jeg tilbage fra ferie og meget spændt på at opleve hvorledes det er gået med mit produkt mens jeg har været væk. Inden jeg forlod teamet var det rimelig klart hvilke items der skulle laves og hvorledes sammenhængen mellem dem var. Teamet commitede og alt var fryd og gammen :) Okay tilbage. For det første er der lavet om på min prioritering og fjernet ting fra den commitede produktbacklog. For det andet går det laaaaannggsomt, men det er jo fair nok da teamet ikke har de nødvendige kompetencer og det ligesom ikke er gået op for nogen endnu.
Jeg fik lige lavet et meget simpelt regnestykke med hensyn til velocity fra den foregående sprint.
Oprindelig ETC - slut ETC - divideret med antal dage. Det giver en hastighed pr. dag sammenholdt med så meget er der lavet.
Det giver en velocity som godt nok har nogle enhedsproblemer men viser meget tydeligt at med den aktuelle hastighed går det ikke. Det være sig om man benytter ideal eng.days, vingummi, stories etc. som backlog item enhed. Vi har ikke rigtig været dygtige nok til at estimere oprindelig kompleksitet så det eneste der er at arbejde med er de oprindelige tidsestimater og så sammenholde med det sidste. Jeg tror jeg vil introducere nogle kompleksitetsenheder eller noget. Problemet er at vores domæne er meget ukendt og det er lidt svært at etablere en fornuftig enhed.
Vorom al ting er så viser denne meget simple beregning sig at være et glimrende værktøj til at vise potentielle problemer som burndown'en også viser. I morgen skal jeg lave noget trends etc. samt enhedstrylleri måske ...
bliver interessant.

Xp practices

2007-02-07T02:00:00.000+01:00

Hejsan
I al min scrum iver glemmer jeg helt at jeg også forsøger at indføre lidt extreme programming practices såsom
1) gruppeestimering estimeringspoker (er vel egenligt ikke xp)
2) pair programing i en ikke så ekstrem grad
3) continous integration med en berto the carpentero bygge maskine, der kører cruisecontrol, checkstyle, junit og bygger etc. Kræver at build.xml'erne er i topform.
4) test-drevet udvikling, den kræver godt nok tilvending så jeg tror at jeg skal være test-driver i de følgende uger hvor jeg vil vise hvordan man kan lave td udvikling.
5) Kunden er altid til stede :) yes sir det er jeg
6) koden bliver skrevet i overensstemmelse med standarderne, vi bruger eclipse/java standarder og sørger for de bliver overholdt mha bl.a. checkstyle
7) Vi itererer og laver små releases (håber jeg).
8) ingen overtid tja den kører ikke helt men næsten
Vi gør sikkert også andre ting som jeg ikke helt lige kan huske. De fleste ting med hensyn til kodning og test gør vi, men design og planlægningen er mine næste fokuspunkter.
til lidt inspiration er her et link til et xp site

Den filipinske eller asiatiske scrummaster

2007-02-06T01:19:00.000+01:00

En lille hurtig indskyldelse. Som Scrum Master siger teorien jo at man ikke skal deltage som svin på det daglige scrum møde. (Fordi man ikke er en del af teamet).
Vores scrum master hernede deltager med sine siden sidst og til i morgen. Og jeg tror faktisk at det er en rigtig god idé fordi man på den måde får nedbrudt nogle barrierer samt få skærpet følelsen af at vi er i samme båd. I øvrigt lige et lille billede af hvordan man rigtig powernapper når man er filipiner.

Scrum virker :)

2007-02-06T00:54:00.000+01:00

Det kommer vel ikke som den store overraskelse, men Scrum virker. I går havde vi den første rigtige sprint afslutning med demo og hele svineriet. Udover at filipinere har lidt svært med tidspunkter så var det en opløftende oplevelse. Demoerne var som demoer nu engang er. Udviklerne var nervøse og der skete interessante ting. Og endelig så stillede kunden (mig) dumme check spørgsmål.
Den anden del af seancen, nemlig sprint retrospektiven? (På dansk?) var virkelig en fornøjelse. Vi delte
1) der var gruppe arbejde med stop, start og continue elementer til processen (skal se om jeg kan poste den).
og
2) Ting jeg lærte i den sprint og ting jeg vil i den næste.

Ad 2: Rigtig mange af indlæggene handlede om
1) Det teknologisk udfordrene
2) Team og det at arbejde i team.
3) produktfokus
Kender i følelsen hvor man bare sidder og jubler med armene i vejret. Det var virkeligt godt at se at team fokus var en fed ting for de fleste af dem (vi har mistet en i processen). Endvidere var der min. en der sagde at det var fedt at man så hurtigt får lavet noget som man kan se virke. Yes sir.
I lessons learned seancen var der blandt andet kommentarer vedrørende vores daglige scrum.
Hernede har jeg ikke ville blande mig for det er ikke mig der er scrum master. Den daglige scrum har været sådan hen ad formiddagen med de folk som nu har været der. Det har faktisk virket så det er vel et tegn på at ugentlige statusmøder ikke virker når sådan nogle daglige nogle er bedre. Nå men de foreslog at vi indførte en mødeliste hvor man bliver hængt ud hvis man ikke deltager. Endvidere ville vi overveje at indføre en bødekasse, hvor pengene går til vores sikkerhedsvagter hernede.

Der var mange andre gode ting som blev sagt, men det var virkelig fedt at se de her folk selvorganisere, være begejstret og vokse mere og mere.

Lidt gode nyheder

2007-02-02T02:07:00.000+01:00

Her i manila er jeg overraskende nok kommet pænt langt med at benytte Scrum sammen med Konsulent firmaets CMMI-5 process. Og det er ikke fordi udviklerne er specielt bevidste om systemudviklingsprocesser samt top notch i domænet og/eller arkitekturen. Det er snarere fordi vi har
1) Et overordnet mål og en vej der hele tiden bliver visualiseret
2) ting der kan testes og vises frem ofte
3) En engageret kunde som er til stede og viser interesse
4) Prædiken og evangelering samt
5) massiv opfølgning
6) masser af reviews
Der er stadigvæk udfordringer såsom
Det daglige scrum møde afholdes kl. 9:00 manila tid hvilket betyder cirka 9:30-40 tiden og de fleste folk er til stede.
Scrum og specielt gruppearbejde kræver evne og selvstændighed til at kommunikere. Udviklerne her er meget unge og uerfarne så deres selvtillid er ikke i top.
De har faktisk noget fremskridt på denne her lille måned. så på den måde må det siges at være en succes, men jeg er åbenbar svær at gøre tilfreds oppe i hovedet. Jeg vil have det spiller derudaf.
De har virkelig knoklet derudaf så selvom alt ikke er helt godt så er de dog på vej. Derfor tror jeg at jeg bliver nødt til at lave noget motiveringsshow. Så jeg har forberedt en lille "sjov" præsentation med nogle billeder fra deres arbejdsdag. Lad os se om de synes om den.

Dagens sjove

2007-01-30T05:07:00.000+01:00

Fik lige en mail med denne quote
"Managers like the waterfall model for the same reasons that touristslike real waterfalls, they are simple and powerful and beautiful tolook at. They are much less fun when you go down one." - Kevin Barnes
Tja, det er vel lidt det der er problemet i en nøddeskal. Har lige haft en masse polemik vedrørende scope og udvidelse af en sprint længde. Nul putte. Istedet for så har i ikke leveret.

Scrum, Philipines and CMMI. Uhh hit by reallity

2007-01-25T01:45:00.000+01:00

Ohh
Since the beginning of january we have been working on this asignment. I'm the customer so i'm kind of the productowner in Scrum terms. I'm also trying to create a atmosphere of openness, proactiveness and responsibility plus architecting, reviewing, etc. It's almost before i'm doing the actual production myself. Damn..
The combination of the CMMI implementation and Scrum is a really interesting thing down here. We have wrapped the delivery into sprints (iterations). That's all fine. We have contained stages (Ana./design/build/test) etc. Thats also fine, but.....
We have a big number of formal review points. Let me give your example.
One delivery of a analysis document requires the following reviews:
1. teamlead with a formal pointsheet.
2. Architects office with a formal pointsheet.
and then finally
3. Customer review with a formal pointsheet.
The turn-around time for this is yeah...
Okay so i'm trying to shortcut the process. I'll do informal reviews as soon as possible, but it's a challenge.
And furthermore which is really sad it seems that it takes away the resposibility from the actual producers of the product. And then we'll not have the productivity gains that scrum promises.
But it's a different culture and the people the consultancy recruites are not taking for the ability to ask questions and stand up for them self. So the team self-organising is so-so. A lot of organising is put on the shoulders on the teamleads and actually me the client.
Okay let's see. We have done some sort of sprint planning sessions, but that was a bit of a challenge because the team didn't have any idea about the technology, the domain etc.
So we planned for them. First mistake.
okay we're having the daily scrums. That's good, but it's like statusreporting to somebody else than the team. We are updating the burndown so that's good.
But the big problem is that the velocity is low.
Hmm but i don't think it has anything to do with Scrum. It's a knowledge thing.
The good news is that the concept of a potentially shippable product really "screws" things up down here and catches mistakes really quick so we are benefitting.

Globalisation, CMMI and Scrum

2006-12-05T07:01:00.000+01:00

Uh the joys of globalisation. Had a conferencecall yesterday with Indians, Americans, Philipinos and Danes. It's really interesting and fun to "observe" the different cultures, and they're ways of communicating. The philipinos have a really nice and wellspoken english so that's easy to understand but i have troubles understanding the indians. You also have the feeling that they rather would be somewhere else than in the conference call. But it really gives you a feeling of globalisation.
Still have challenges with combining Scrum and the big consultancy company CMMI processes. The trouble is to have fixed dates in the iteration for metrics. Like now we have a analysis phase that ends after day 3. And then have a issue management process to handle changes to the analysis but that's not the way systems development work. You do a constant mix between understanding (analysis), finding a solution (designing) and implementing.
It's should be so that Scrum is just one of the delivery methods that you can choose from, but the Waterfall and plandriven approach keeps creeping in. I think i'll try to talk to the Auditors because the way it's going right now is like two steps forward and then 1 1/2 backward. I think that we may have a situation where the PM thats going to implement/combine the CMMI process doesn't really know the CMMI process. Will be interessting.
BTW we had our first sprint retrospective, friday and the first sprint planning yesterday. In this project i'm the customer (Architect/PM ....) but i'm spending a lot of time driving the process. It's good for the quality of the project and my resume but it kind of should be the other way around. I'm also using a lot of time on qualifying the development process which shouldn't be the case.
In a weeks time we're going off-shore. That will be interessting. I'm looking forward to se my project participants in their natural habitat :) Hopefully there will be more proactivness.
But on the other side we're having tremendous fun and the atmosphere is really nice. But i haven't played my customer card yet. I have a review session today where i will have to tell a developer that there are a lot of better if's in his document. Lets see how that goes.
Oh BTW in my quest for Scrum in the big company i was invited to the IT management yearly get to gether to preach Scrum and methods but i'm off-shore so that's kind of a drag.
But just to give you an idea of the timing and progress in the financiel industry my CIO responded when i said that i was willing to do it an evening or something but couldn't make the gettogether. Oh lets just do it in april then :) So we're getting there but it's a long ride.

Hvordan går det?

2006-11-28T10:24:00.000+01:00

tja
Nu ruller projektet. Det er interessant at se hvorledes man kan få entutiasme ud af folk ved at give dem mulighed for at påvirke. Projektet laver snart en transition off-shore og her er et dejligt billed som kan varme en grå novemberdag. Jeg håber virkelig at der er wireless adgang til I-nettet :)
Nu har vi kørt en måneds tid og vi har fået lavet en masse ting. Vi har bl.a. fået adgang til nogle af IBM's eclipse udviklere så der er håb for projektet.
Nu tror jeg dog at det er ved at være på tide med en opfrisker til Scrum. Vi kører de daglige scrums, men opfølgningen med hensyn til sprints og etc'er har det ikke så godt. Der skal strammes lidt op. Jeg tror en af grundene til at det ikke bruges så godt er at produkt backloggen ikke er i så god en stand som den kan være. Derudover mangler der også noget facilitering som jeg desværre ikke har været i stand til at give. Og så forfalder man meget nemt til gamle vaner. Men tilgengæld så virker det som om min prædiken i organisationen er ved at skabe lydhørhed for en forandring af arbejdsformer i it afdelingen.
jeg var i øvrigt på et IBM kursus der omhandlede OOA/D the RUP way. Udover at underviseren ikke var den bedste jeg har oplevet var det rart lige at få opfrisket sin UML og se at man faktisk godt kan bruge det :)
Det har dog også haft som konsekvens at jeg er begyndt at stille nogle UML krav til vores projekt. Dog har jeg det stadigvæk sådan med RUP'en at dens store fokus på roller er lige i overkanten. Jeg har dog fået læst lidt op på mine foredomme vedrørende RUP og kan se at der er agile support.
Er iøvrigt lige gået i gang med en bog om hvorledes man leder Agile projekter. Det er interessant læsning.
Et vigtigt element som det er rart at få opdateret er det store produktfokus og brugen af iterationer. Enhver iteration skal afsluttes med et produkt. Det er vigtigt for at bevare energien i projektet. Det er nemt at glemme. Jeg tror at jeg skal være mere obs på det og tage noget mere styring så mine outsourcing venner kan se lyset.

What are we doing? MDD/EMF/GEF/JET/GMF/UML2 etc

2006-11-13T07:27:00.000+01:00

The tla's in the title kind of says it all :) Currently we have an development environment based on IBM's WSAD and XDE where we do model driven development. The current implementation have some charateristics that makes us want to have a new implementation.
1) it's based on XDE which 1) isn't a world class product and 2) goes out of IBM's support cycle
2) the current implementation isn't what i would say based on a sound and best practice way of implementating functionality in Eclipse.

So we will be trying to migrate from WSAD/XDE to IBM's RSA. We will try to use as many open source (Eclipse) technologies as possible.
There are some challenges in this project.
1) RSA 7 is still a beta
2) We have a huge model in XDE that needs to be migrated to RSA. The current IBM supplied importer doesn't quite make it
3) The knowledge of the developers around Eclipse is low
4) The knowledge of the developers around model traversing and manipulation in RSA is low
5) The stability of the APIs are unknown

So that's really interesting.

So far so good?

2006-11-13T07:16:00.000+01:00

Yeah we are now up and running. I'm just reviewing management process documents for our project and hay Scrum is part of the process' now. Thats kind of interessting because their current process doesn't support Scrum out of the box. Systematic (a danish software company) does that. It's like they have a selection of different pm frameworks to choose from where Scrum is one of them.
I have tried doing scrum for a little month now and it's actually interessting to see what goes wrong. We have our daily Scrums and thats fine. But we are in a process of planning the project so the tasks are very loosely defined which means that the burndowns doesn't get used. We also don't have a Scrum Master so there is nobody preaching and facilitating. We are all caught up in doing stuff so we are focused on that instead of scrumming. I have a hope that as part of the going offshore we will be able to do scrum. Our team will grow from 4 persons to 10 where 2-3 of us will have external roles (Product Owner, Scrum Master and ?).
So i'll try doing it for the actual delivery project.

Struggles

2006-10-26T07:22:00.000+02:00

Day 4 disappointment
I had this idea about agility and flexibility. I now seems that I have to struggle to fight off the heavy weight of pinning requirements down and just focusing on them instead of the value that the functionality will bring.
I will try to manage but it will take some struggling and powertripping. I could also be that I see ghosts and that there isn't any problems. I find out in a couble of months.

We now have liftoff

2006-10-25T07:14:00.000+02:00

Finally did the people from the philipines arrive. Thanx to the danish immigrations they are only 1 month delayed :)
Anyway it will be interessting and a challenge to start this project because i want to use agile methods and they have never heard about agile methods. But they think it interessting so let's see how it goes.
The first couple of days have been exciting. A lot of presentations and trying to learn about each other. I can be a bit disturb that I as the customer will have to make a lot of architectural choises on my own but hell lets have a lot of fun doing the project and see how it goes.
Besides that i have spend a lot of time planning the temporary move offshore.
For those of you that are technically interested the project is about migrating a MDA type development environment developed in WSAD/XDE to a newer version of Eclipse preferably based solely on eclipse technologies but it could also include RSA (IBM's development environment).
Currently we're are looking (starting) to look at pros and cons against making our own Domain Specific Language (DSL) implementation with the help of EMF, GEF etc. or basing the migration on UML2 and IBM's UML2 editors.
The challenges are many but mainly there are coming from the fact that the existing environment is developed as a prototype some would even say POC. I'll keep you all posted. Also regarding integrating the vendors CMMI level 5 processes and Scrum.

A quick post

2006-10-05T14:31:00.000+02:00

http://www.waterfall2006.com/
Today I read a interessting blogentry about outsourcing. http://www.journalhome.com/codecraft/13920/

Yes sir

2006-09-28T10:28:00.000+02:00

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

2006-09-21T09:51:00.000+02:00

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

2006-09-19T12:51:00.000+02:00

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

2006-09-19T09:00:00.000+02:00

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

2006-09-15T07:42:00.000+02:00

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

2006-09-12T07:16:00.000+02:00

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

2006-09-04T06:58:00.000+02:00

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

2006-09-04T06:44:00.000+02:00

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

2006-09-01T08:29:00.000+02:00

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.

Tilbage fra ferie

2006-08-29T08:19:00.000+02:00

Så er jeg tilbage fra ferie og møder igen det pulserende erhvervsliv... Er p.t. i gang med at læse en bog der hedder noget med balancing agile and discipline. Den prøver at sammenstille forskellige karakteristika for de to "tilgange" til systemudvikling. Samtidig har den også som ambition at skabe et grundlag for andre end de rene fanatikere til at benytte og tilpasse de forskellige tilgange.
En ting der er lidt interessant men nok ikke så overraskende er
1) Des bedre folk jo bedre produkt. Samtidig er der forskel på folks evner til at tilpasse og forandre sig. ...
Igen er det jo ikke så interessant, men i forbindelse med mit tidligere indlæg vedrørende lean etc. har de den påstand at man med plandrevne processer/projekter er bedre i stand til at levere succesfulde projekter med mindre kompetente folk. Så det passer jo perfekt til den opfattelse man har af off-shoring og specielt deres folk.
Jeg fik et interessant svar på mit indlæg vedrørende taylorisme fra en af mine venner der p.t. sidder i Dubai som udviklingsdirektør ell. noget. Han har bl.a. en del indere ansat og han mener bl.a. at taylorismen eller fordisme er ved vinde indpas indenfor softwareudvikling. Den kultur disse udviklere har minder mere om det Thomas Højrup kalder lønarbejderlivsformen i "Det glemte folk". I øvrigt en meget interessant bog (dog lidt hardcore teoretisk, men dens antropologiske beskrivelser af de forskellige livsformer er guld.). I denne livsform er arbejdet et middel til at opnå adgang til fritid/frihed. Det er faktisk en interessant tanke fordi hver gang jeg læser om agile processer og andre processer etc. har jeg en tendens til at vurdere metoder/processer udfra min egen tilgang og livsform. Jeg tilhører nok den livsform der hos Thomas Højrup kaldes den karrierebundne livsform. Her er et job ikke et middel til at leve i fritiden men en naturlig del af ens liv. Jeg har det også sådan at jeg interessere mig for mit fag udover hvad man kræver arbejdsmæssigt. Denne interesse er lidt svære at finde hos en del af mine nuværende kollegaer. Samtidig er der også en tendes til at man i hirakiske virksomheder fjerner ansvaret fra den enkelte. Der var en artikel for nogle måneder siden i weekend avisen om forskellige ledelsesformer samtidig har jeg også læst en artikel om situationsbestemt ledelse hvor man opererer med forskellige typer af personer og deres behov for forskellige "ledelsesstile".
Det er interessant at se at i de virksomheder jeg har oplevet hvor man knytter sig meget til skyld med skyld på og plandrevne projekter samt politisk ageren findes der også en ledelsesstil der er meget instruerende og meget lidt støttende. Denne ledelsesstil har en tendens til at fjerne ansvarsfølelsen fra folk og skabe grobund for handling og ageren der har til formål at minemere personlig tab. Dette reaktionsmønster passer ind til Ralph staceys 'Anarchy: Far From Agreement, Far From Certainty' analysemodel. Man skulle jo umiddelbart tro at man befinder sig i den politiske ageren, men jeg tror måske det skyldes at der er usikkerhed om hvad der egentlig er mål og visioner samt retninger. Sidestillet med stor uenighed kan dette føre til anarki. Der er naturligvis stadigvæk regler der følges, men overholdelsen af disse regler sker mere som en nødvendighed. Samtidig har jeg også observeret en mangel på konsekvens samtidig med at man fokuserer meget på fejl. Jeg kan ikke umiddelbart se sammenhængen, men det er måske nogle af jer læsere der kan bidrage med.
Jeg ville egentlig have skrevet lidt om nogle af de problemer der kan opstå i store projekter, hvor man kører plandrevent, udskyder deadlines hele tiden, bruger en meget instruerende og lidt inspirerende ledelsesstil samtidig med at man har fokus på kontrakt overholdelse. Men det må vente lidt :)
Det må nok siges at være bloggens mest rodet post, men man skal jo lige i gang igen. Og der er da ihvertfald nok at tage fat på i dette indlæg.

Lean, taylorisme, XP, paradigme the works

2006-07-31T07:07:00.000+02:00

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

2006-07-27T12:09:00.000+02:00

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

2006-07-27T11:08:00.000+02:00

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

2006-07-27T10:33:00.000+02:00

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

2006-07-26T12:22:00.000+02:00

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

2006-07-26T07:01:00.000+02:00

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

2006-07-25T12:16:00.000+02:00

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