olav m.j. christiansen bloghoved olav christiansen

WISCY

Bag overskriften dækker sig ikke gyldne dråber fra det skotske højland, og der er heller ikke tale om en forvansket udgave af WYSIWYG. Forklaring følger sidst i artiklen.

Victoria og Anton

Lad os først lige vende tilbage til sidste blogindlæg, som jo var en dårlig analogi. Dem kommer jeg sandsynligvis til at have flere af i den tid denne blog kører, så forrige gang var nok ikke nogen undtagelse.

Lærte vi noget som helst af historien om Victoria van Fal, der skulle løbe om kap mod Anton Agil?

Vi lærte i hvert fald at det kunne være svært på forhånd at vide hvem af dem der vandt.

Selv om vi vidste lidt om opgaven på forhånd og stod udenfor og kiggede på det, kunne det faktisk være lidt svært at vide hvem man skulle satse på. Og det er måske der problemet ligger i en nøddeskal: Når først projektet er overstået, er det nemt nok at se hvad man skulle have gjort. Men i starten af et projekt kan det være ret svært at vælge fremgangsmåde og om man f.eks. skal vælge en mere agil tilgang til opgaven eller skal gå efter den mere afprøvede vandfaldsmodel.

Jeg fik ikke så mange input til min dårlige analogi, som jeg havde håbet, men der var da flere kommentarer som antyder at folk godt kan se hvad problemerne er. Og en af de sidste kommentarer fortæller jo tydeligt at domæneviden kan ændre på alt (jeg har også selv løbet en del orienteringsløb i min tid i forsvaret, så jeg kender det godt).

Der var ingen som forsøgte at lave en simulering af opgaven, så måske er der alligevel ikke så mange rigtige nørder her på version2, som jeg troede? ;-)

Det gør heller ikke noget, for vi kan sagtens simulere at vi har lavet en simulering. Det viser sig jo alligevel at 67,24% af al statistik er opfundet på stedet!

Hvis vi lavede en simulering af det beskrevne scenarie og kørte den flere gange, ville vi komme frem til at der er følgende mulige udfald:

A. Tante Victoria kommer først.

B. Fætter Anton kommer først.

C. De kommer ca. lige hurtigt frem.

Den præcise fordeling mellem de tre forskellige udfald vil afhænge af mange ting, f.eks.:

  • Hvor lang tid skal tante Victoria bruge på at læse og forstå kortet?
  • Hvor stor er skoven?
  • Hvor langt væk er målet?
  • Hvor hurtigt bevæger de sig hver især?

Konklusionen er vist at den gode løsning ligger et sted imellem den rene agile løsning og vandfald (selv om der er folk derude, der forsøger at overtale virksomheder til at køre 100% agilt - det vender jeg tilbage til).

Lad mig opsummere på de spørgsmål, jeg stillede og prøve at besvare dem så godt som muligt. Her kommer først de oprindelige spørgsmål:

  1. Kan man sige om én af deltagerne at vedkommende bevæger sig hurtigst og derfor tilsyneladende har den største fremdrift på opgaven?
  2. Kan man sige om én af deltagerne at vedkommende på et tidspunkt konstant nærmer sig målet?
  3. Kan man om én af deltagerne på et tidspunkt estimere hvornår vedkommende er i mål?
  4. Hvem sætter du dine penge på - og hvorfor?
  5. Kan man ændre på reglerne en smule, så deltagerne ved at samarbejde tilsammen kan opnå en bedre tid end hver for sig?
  6. Kan man overhovedet lære noget som helst af disse langt-ude analogier?
  7. Hvornår kommer der noget mere kød på denne elendige blog?

Og her kommer så mine forsøg på at besvare dem:

  1. Ja, det er jo uden tvivl Anton Agilt. Udefra ser han ud til at løbe vældig hurtigt, så nogen vil helt sikkert satse på ham. Og det er vel den egenskab, der er mest tiltrækkende ved de agile metoder.
  2. Det må så til gengæld være tante Victoria. Når hun har brugt noget tid på at studere kortet, bevæger hun sig jo derefter direkte mod målet.
  3. Og på grund af dette, er det også forholdsvis enkelt at estimere hvornår hun er i mål, ud fra hvornår hun startede, hendes hastighed og afstanden hen til målet.
  4. Svært at sige. Måske vil jeg sætte mine penge på tante Victoria, men jeg kan sagtens risikere at tabe.
  5. Hvis nu tante Victoria lader Anton kigge med på kortet, så opnår de to ting: Hun får hurtigere fundet ruten, og han kender nu også vejen til målet. Det burde afstedkomme at de begge kommer hurtigere i mål.
  6. Det er helt op til læseren :-)
  7. Snart.

Tilbage til virkeligheden

Mange organisationer har været nødt til at have fokus på ting som sikkerhed og kvalitet i leverancerne. Nogle brancher og nogle typer projekter har større fokus på eksempelvis kvalitet end andre. Og alligevel går det sommetider galt.

I nogle brancher og organisationer har man derfor betalt dyre rådgivningsfirmaer millioner af kroner for at finde ud af hvad løsningen er, og langt hen ad vejen har svarene handlet om at gøre processerne mere modne. Vejen dertil har typisk været noget der ligner v-modellen, hvor man altså foruden at vælge en faseopdelt metode til projektet også har fokus på kvalitet helt fra starten. Der er eksempler på at den type projekter isolerer IT fra resten af organisationen på en måde, så forretningen ikke længere har tillid til at IT kan levere løsningerne hurtigt nok. Især i kommercielle organisationer vil man gerne have en kort Time to Market, og det kan være svært at leve op til hvis hvert eneste lille projekt skal igennem hele møllen med lange analysefaser og udfærdigelse af krævede dokumenter, som nogle måske synes man kun skriver for processens skyld, inden man kommer i gang med at levere noget.

Jeg talte på et tidspunkt med én, som ikke kunne lide PRINCE2, og det viste sig at vedkommende netop havde været i et projekt, hvor man havde været tvunget til at udfylde en masse dokumenter, som ingen alligevel brugte til noget. Mit svar på det var (og er) at nogen helt har misforstået hvad PRINCE2 går ud på. PRINCE2 er ikke i sig selv en vandfaldsmodel, men en generel styringsmodel for projekter, som i øvrigt skal tilpasses den enkelte organisation og det enkelte projekt.

Hvad er så det der WISCY?

Illustration: Olav M.J. Christiansen

En af de ting, der netop sker, når der går for lang tid før man går i gang med at levere noget i projektet, er WISCY-syndromet. Forkortelsen dækker sædvanligvis sætningen: "Why Isn't Sam Coding Yet", altså: "Hvorfor er der ikke nogen der er i gang med at kode endnu?". Vandfalds- og v-modellerne har faktisk været god latin til at sikre gode systemer igennem mange år, men det betyder bl.a. at forretningen synes det går for langsomt. Man bruger meget lang til på f.eks. analyse, og der går typisk ret lang tid fra forretningen har fået en idé til de kan se noget som helst færdigt.

WISCY-syndromet handler altså om en slags utålmodighed hos især forretningen med at IT stadig ikke har leveret noget som helst, selv om de har været i gang i måske månedsvis.
Det er jo nok bl.a. den slags oplevelser, der har afstedkommet alle mulige alternativer til de mere rene vandfaldsmodeller, f.eks. prototyping og agile modeller.

Er det agile så løsningen?

Sommetider. Det kommer an på. Her er to eksempler ude fra den virkelige verden:

  • A. En organisation, hvor man igennem en periode forsøgte sig med Scrum, men man fik det aldrig til at virke helt, så man endte med at gå tilbage til en mere traditionel tilgang til opgaverne og projekter.
  • B. En anden organisation, hvor man havde forsøgt sig med vandfaldsprojekter igennem længere tid, men tilsidst måtte opgive det, og derfor i stedet forsøger med Scrum.

Uanset hvilken rammemodel, man tager udgangspunkt i, skal man (som jeg vist har skrevet nogle gange nu) huske at tilpasse den situationen, dvs. organisationen og projektet. Det farlige opstår når en organisation med hovedet under armen siger at 'nu bruger vi den model', og så kører derudaf med en model, der ikke passer til virkeligheden. Man bliver nødt til at forstå hvorfor man har den og den proces. Selve det at indføre en ny projektmodel er jo et projekt i sig selv, der vil kræve meget forandringsledelse for at lykkes.

De fleste af os vil jo reelt gerne bare have lov til at passe vores arbejde, uden at en bureaukratisk model står i vejen for det, men ude i den virkelige verden har det vist sig at det ikke altid er så nemt igen, når man skal forsøge at tage hensyn til alle interessenter.

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Olav M.J. Christiansen Blogger
Chris Bagge

Det er muligt at undgå det store papirbjerg især hvis man er alene eller en ganske lille gruppe. Det er derimod straks vanskeligere når der er grænseflader ud mod andre. Så bliver man ikke populær hvis man ændrer på det hele tiden.
Problemet er at forretningssiden tro at den prototype der kommer frem er det endelige produkt fordi det ligner jo. Derefter bliver man ved med at kaste masser af ressourcer efter det i stedet for at sige STOP for det er jo næsten færdigt. Der mangler bare lige ... Poul Henning Kamp er inde på det i sin blog:
https://ing.dk/blog/lille-hammer-stort-soem-214829

Der er ingen bygværker, det være sig software, hardware eller huse der opnår kvalitet med mindre de har et ordentligt fundament., og det at fundamentet ikke er i orden viser sig ofte på et meget sent tidspunkt.

Chris Bagge

Scrum er ikke den agile model. The Agile Manifesto udtaler sig om nogle præferencer. Det giver ikke en firkantet model man kan implementere. Det giver til gengæld en masse retningslinjer. Retningslinjer der, som jeg ser det, mange gange giver fornuft.

Til gengæld er ren Scrum, efter min mening, afkoblet fra den virkelige verden. Når man sidder med blandet udvikling og drift er det meget svært på forhånd at sige hvor meget tid der bruges på drift, og drift bliver ikke skudt til næste sprint ;-).

Samtidigt tror jeg det er meget vigtigt at de udviklingsforløb vi fremmer er indstillet på at håndtere den evolutionære udvikling. En meget stor del, den største måske, er den der går ud på at vedligeholde / udvide et eksisterende system, med det eksisterende systems bindinger. Her er der ikke tale om at "starte fra et stykke blankt papir".

Det er nok også værd at huske at Kent Beck berømte projekt hos Chrysler - C3 aldrig kom i fuld drift.

Log ind eller Opret konto for at kommentere