olav m.j. christiansen bloghoved olav christiansen

Kan man bygge et hus agilt?

I mit forrige indlæg, gav jeg en kort introduktion til hvordan det agile opstod.

For at forstå det lidt bedre, vil jeg prøve i dette indlæg at give mit bud på hvad man typisk gør i et agilt projekt (a la Scrum) sammenlignet med hvad man gør i en mere ren vandfaldsmodel. Og sidst i artiklen vil jeg så prøve om man kunne bruge de agile metoder andre steder, f.eks. ved bygning af et hus.

Igen: Dette er baseret på min erfaring, som både stammer fra mange forskellige projekter og uddannelser/certificeringer indenfor de forskellige metoder. Men som man siger på udenbysk: Your mileage may vary (på godt dansk: Du kan have andre oplevelser og andre holdninger, så dem vil jeg da gerne høre om).

For at kunne sammenligne metoderne bliver vi nødt til at have en fælles reference, og der kunne man jo prøve at lave en slags skitse af produktet, lige når det er helt færdigt og kunden skal i gang med at benytte sig af det. Sådan en skitse burde jo være uafhængig af hvordan man er kommet frem til slutproduktet. Man kan lave en grov skitse som et hierarki med de forretningsmæssige behov øverst, f.eks. de forventede gevinster koblet sammen med den funktionalitet, der skal levere disse. Under dette har man så den egentlige IT-mæssige implementering af funktionaliteten med den teknologiske stak nedenunder. Det kunne se ca. sådan ud:

Illustration: Olav M.J. Christiansen (grafik)

Ovenstående er en meget grov skitse, og lagene kan have mange andre navne, men forhåbentlig forstår man pointen. Den tykke streg angiver grænsefladen mellem forretningen og selve IT-produktet. Hvis man har anvendt teknikken produktbaseret planlægning, er denne type diagram nok ikke noget nyt, men i princippet kan man lave diagrammet uanset hvordan man fik produceret systemet. Hvis man ville lave et meget detaljeret diagram, skal man forestille sig at man inde i hver af de store kasser har en masse små kasser, der er forbundet på kryds og tværs med afhængighederne vist som linjer. Et rigtigt diagram af denne type ville sandsynligvis ikke være et ægte hierarki, men have afhængigheder, der kører på tværs på forskellige underlige måder.

F.eks. kunne en forretningsmæssig anvendelse af funktionaliteten bestå af et flow, der involverer flere af de udstillede funktioner, sådan at man ikke kan benytte systemet forretningsmæssigt, før al den krævede funktionalitet er leveret. Denne afhængighed ser man dog tydeligst, hvis man har gennemanalyseret de to øverste lag først, og det giver en risiko for at den måske ikke bliver opdaget før ret sent, hvis man anvender en meget agil metode.

Hvis man så prøver at trække en linje tilbage til hvordan hhv. en vandfaldsmodel og en mere agil model som Scrum typisk vil implementere ovenstående, kommer man frem til noget lignende dette:

Illustration: Olav M.J. Christiansen (grafik)

Det er selvfølgelig forsimplet for at fremme forståelsen, men man kan se at man i en vandfaldsmodel arbejder på hvert lag først, inden man går videre til det næste. Fordelen ved det, er at man bør kunne få et overblik over sammenhængene i det enkelte lag. Man kommer dog nemt til at bruge meget tid og opbygge en masse dokumentation, hvis man arbejder med den rene vandfaldsmodel. Samtidig er det måske svært at gennemskue de afhængigheder, der går på tværs af lagene, før man har bygget dele af produktet.

I virkeligheden vil man oftere anvende en variant af v-modellen (i forskellige udgaver også ofte kaldt w-modellen), da man så har hele kvalitets- og testdelen med. Den er ikke vist i ovenstående diagram, men skal ikke glemmes.

Hvordan kunne det så se ud med en mere agil tilgang til det? Ja, vi ønsker jo ikke at bruge for meget tid på analyse og at skabe en masse dokumentation, som måske er unødvendig, så vi prøver i stedet at gribe fat i enkelte dele af den ønskede funktionalitet og så bygge den del til kunden. Det ville måske se sådan her ud, baseret på den første tegning:

Illustration: Olav M.J. Christiansen (grafik)

Vi kan se at vi her skærer produktet på den anden led, hvor vi forsøger at implementere en mindre del af produktet hele vejen igennem. Det har den fordel at kunden har en mulighed for at se på produktet og dermed vurdere om det var den rigtige vej ved simpelthen at afprøve det, frem for at skulle lave en masse beskrivelser først. Men måske får man ikke noget, der helt kan anvendes endnu forretningsmæssigt, selv om det tilsyneladende virker rent teknisk - enten fordi man ikke har bygget det helt rigtigt i den teknologiske stak, fordi man mere anvender en form for prototyping (se bl.a. en af kommentarerne fra sidste artikel for at få et godt eksempel på dette) eller fordi der helt mangler funktionalitet, fordi man ikke har brugt tid nok på den forretningsmæssige analyse. Så begynder man typisk at kigge på hvad man kan levere som det mindste brugbare system (MVP - Minimum Viable Product).

Det kan også være at man fokuserer for meget på den forretningsmæssige brug og glemmer det egentlige formål, nemlig de gevinster man gerne skulle have ud af at gennemføre projektet. Jeg er sikker på at min blog-kollega Martin Ernst her inde ved siden af har en masse at sige i den sammenhæng om brug af Business Case og gevinstrealisering.

Kan man bygge et hus agilt?

Lad os prøve at lave en afstikker til endnu en analogi for at prøve at forstå hvad forskellen er. I stedet for den sædvanlige bil-analogi, så lad os bygge et hus i stedet for. Vi nøjes med en almindelig villa med plads til to voksne og to børn. Det har mange ting fælles med et IT-projekt, så man kan udmærket bruge det som sammenligningsgrundlag.

Et husprojekt vil normalt blive udført af mange forskellige slags håndværkere, f.eks. murere, vvs-folk, elektrikere, kloakmestre, tømrere osv. osv. (et lille tip: Det gælder også IT-projekter)

Normalt vil man lave en tegning først, så man ved hvor stort huset skal være. Man har også en form for tidsplan, så de forskellige håndværkere ved nogenlunde hvornår de skal involveres.

Rækkefølgen er nogenlunde som følger: Først støber man fundamentet. Det skal så helst stå et stykke tid, inden man går videre. Derefter følger væggene, og først når de er på plads, kan man lægge tag på. Ind imellem er der en masse udvendige og indvendige arbejder i form af gulv, vinduer, lofter, døre samt diverse forsyningslinjer. Der er altså nogle hårde bindinger til nogle af aktiviteterne, f.eks. fundament, vægge og tag, mens andre opgaver kan løses lidt mere fleksibelt. Man kan f.eks. godt have nogen i gang med at male i ét værelse, mens andre lægger gulv i et andet. Det er slet ikke ulig hvordan et IT-system normalt bygges op.

Så vi må umiddelbart konstatere at et normalt husbyggeri kører efter en form for vandfaldsmodel. Det betyder dog ikke at man ikke kan ændre på ting undervejs uden at skulle helt tilbage til start hver gang, men man bliver hver gang nødt til at undersøge hvad konsekvenserne er, f.eks. hvis man skulle ønske at flytte et vindue eller en dør, afhængig af hvor langt vi er henne i processen.

  • Vi kan altså konstatere at man godt kan reagere på ændringer, også selv om man bruger en vandfaldsmodel.

Kunne vi så forestille os at bygge et hus på den agile måde? Tja, hvorfor ikke?

De agile tanker handler jo om at få leveret noget så hurtigt som muligt, og man er godt klar over at det så kun er en lille del af produktet, der leveres.

Hvis vi skulle forestille os at bygge et hus agilt kunne vi se hvordan vi kunne nøjes med at levere ét værelse, f.eks. et soveværelse. Det er typisk et værelse, der ikke kræver lige så meget som f.eks. et køkken eller badeværelse. Vi skal godt nok have noget lys og varme, men vi behøver ikke at tænke på rindende vand eller afløb.

Hvad skulle formålet så være med det? Det kunne jo enten være fordi husbyggeren (bygherren) slet ikke har noget at bo i, og gerne vil kunne flytte ind hurtigst muligt. Men det kunne også være fordi man ikke helt ved hvad man vil og gerne vil kunne se hvordan ét værelse tager sig ud, før man bestemmer sig til resten.

Hvordan ville man så gribe det an?

Vi bliver jo stadig nødt til at starte med et fundament, men vi kan nøjes med at støbe det lige der hvor værelset skal være. Hvis vi virkelig går op i at vi skal levere det hurtigt, kan vi overveje at springe op og falde ned på at et fundament skal stå et stykke tid, før man lægger noget ovenpå. Her risikerer vi så at vores agile metode kommer til at påvirke kvaliteten. Vi kan nemt sætte vægge op, og vi kan også montere både dør og vinduer. Lige med døren bliver vi dog nødt til at gøre et eller andet, da det jo normalt skulle være en indendørs dør, der skal monteres, men nu bliver man jo nødt til at sikre døren imod vejr og vind. Vi kan godt lægge gulv og montere loft på værelset, men det kommer til at knibe med taget, da det skulle være med høj rejsning, og det er lidt svært når vi mangler resten af huset. Så vi kommer til at etablere nogle midlertidige foranstaltninger over loftet og ved døren. Mht. lys kan det være vi blot nøjes med at sætte nogle batteridrevne lamper op i første omgang.

  • Men vi har bevist at vi godt kan bygge en del af et hus agilt.

Jeg håber man kan se udfordringerne, og også kan se parallellerne til et IT-projekt. Et IT-system har jo også et fundament, som består af vores valgte arkitektur og f.eks. datamodellen. Så hvad er problemet egentlig?

Tja, vi kan jo se hvad kunden fik ud af det. Et værelse, som egentlig ikke er særlig funktionelt og som man nok ikke reelt har lyst til at bo i. Måske havde kunden været bedre tjent med en midlertidig skurvogn, indtil hele huset var færdigt?

Illustration: Olav M.J. Christiansen (fotomontage)

Og hvad sker der så, når vi skal til at bygge resten af huset? Hvis vi holder fast i at et fundament skal stå et stykke tid, før man bygger ovenpå, har vi nu en forsinkelse af resten af huset sammenlignet med hvis vi var startet på hele fundamentet med det samme. Vi har en risiko for at fundamentet under soveværelset er dårligere end resten (f.eks. at den del af huset har en større risiko for at sætte sig), og vi skal nu bruge ekstra tid på at pille de midlertidige løsninger ned, inden vi f.eks. lægger det rigtige tag på.

Vi kan altså se her at den agile løsning gav os et samlet set dårligere, dyrere og mere forsinket resultat i forhold til hvis vi havde fulgt vores plan.

Er det så også sådan med agile IT-projekter? Det håber jeg bestemt ikke, men jeg har virkelig på fornemmelsen at meget kunne gøres meget smartere, hvis man ikke hele tiden havde fokus på sprintet (dvs. tid).

Den agile måde at udvikle på kan jo både bruges i en forvaltningsmæssig sammenhæng – altså når man laver mindre løbende rettelser til et eksisterende system – og i egentlige projekter.

Et projekt er kendetegnet bl.a. ved at man slutter på et tidspunkt, nemlig når man har leveret det endelige produkt. Derfor mener jeg man bør være ekstremt opmærksom på hvordan man griber det agile an, afhængig af hvad behovet er. Er man i et projekt, bør man aktivt kigge på projekttrekanten og bede kunden vælge hvad der er vigtigst: Tid, produkt eller pris. Jeg vil senere komme mere ind på projekttrekanten, da det er noget der har potentiale til at kunne bruges mere aktivt end det gør i projekter, i forhold til hvordan jeg har oplevet det.

Og så har vi slet ikke snakket kvalitet endnu. Min egen erfaring er at hvis man hele tiden arbejder med meget korte sprint, kommer man ikke udenom at skulle etablere automatiske regressionstest, og det er jo en ekstra investering som måske ikke var nødvendig i samme omfang, hvis man udviklede på en anden måde. Og lige her er der nok meget forskel på om man bygger videre på et eksisterende system eller man er ved at bygge noget helt nyt.

Hvad mener læserne? Er jeres erfaring med agile projekter at de nogle gange kunne være løst smartere, hvis man ikke havde fokuseret på et 14 dages sprint? Hvordan løser man afhængighederne, når man har flere Scrum teams? Hvordan sikrer man en høj kvalitet? Bliver man nødt til at etablere automatiske regressionstest for at kunne arbejde agilt?

Andre interessante spørgsmål:

  • Kan udviklere lide Scrum/agilt, eller tror de bare det er det forretningen gerne vil have?
  • Kan forretningen lide det agile, eller tror de bare det er det udviklerne gerne vil have?
Kommentarer (32)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Troels Liebe Bentsen

Software er ikke som er bygge broer, biler eller huse og minder mere om forskning end om de traditionelle bygge fag.

For det først så bygge man kun ting man ikke har lavet før ellers er det bare copy/paste, så alle projektet vil være noget man gør først gang.

For det andet så er software meget nemt at lave om sammenlignet med at bygge en bro, bil eller huse, i software så er det bare at refactorere koden, det er lidt sværere at flytte broen når man finder ud af at enderne ikke lige passer på midten.

For det tredje så er software under en konstant udvikling hvor værktøjer, platforme og økosystemer hele tiden bliver bedre, på meget kort bane, 6-24 måneder. Uden at vide så meget om bro, hus og bil bygningsindustrien så tror ikke helt vi ser den samme teknologiske udvikling der.

Men det i for øje så giver det meget lidt mening at prøve at mase software ned i de traditionelle modeller man har brugt i andre brancher, heller ikke selvom man er kreativ med navngivning og kalder dem agile.

Jeg er stadig stor fan af "Manifesto for Agile Software Development":

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

http://agilemanifesto.org/

Det er sådan set bare sund fornuft som de flest har en tildens til at glemme når de først har valgt et framework eller en model at køre tingende efter.

Lars Meldgård

Vi har leveret et stykke software hvor vi forsøgte med korte sprints. I starten var der rigtig mange ting der ikke gav mening at afslutte inden for 14 dage. Vi skulle først lære at kode, vi skulle prøve forskellige teknologier, vi skulle lære at arbejde "agilt". At lave det første skud "working software" kan nemt tage lang tid.
Jeg tror man ofte glemmer at det ikke nødvendigvis er det seje team der bare buldrer derudaf som et asfaltsjak der har arbejdet sammen i 10 år.
Hvis man er 10-20 mennesker der bliver sat sammen fra øst og vest så tager det altså rigtig lang tid at få kadencen op.
Nu ca. 1 år efter vi startede, begynder det at føles rigtigt. Der er leverancer, vi ved hvad hinanden kan og estimater lander bedre.
Men en rigtig "leverance" hos os tager stadig 3-4 måneder. Så forretning/udvikler kan endnu ikke tænkte/kode/sætte sammen i et tempo der er hurtigt nok.

Simon Mikkelsen

Jeg har netop fået lavet et køkken efter både vandfaldsmodellen og agilt. Dvs. køkkenfirmaet, hvis navn jeg nøjes med at nævne på Trustpilot ol. var nogle klaphatte. Kæmpe kontrakt, alt dokumenteret i mindste detalje. Men da montøren stødte på første problem kørte han uden at give nogen besked.

Mens køkkenfirmaet ikke var nået længere end til det juridiske slagsmål, rykkede vores agile tømre ind. Han fandt ud af at køkkenfirmaet havde målt forkert, ringede til kunden og vi fik lavet en aftale. Han fik også en VVSer og elektriker ind til at refaktorere installationerne, så det lykkedes at gøre projektet færdigt inden deadline.

Slutteligt har vi fortalt mange om vores mindre renoveringsprojekt i forbindelse med indflytning i vores nye hus. Den kommentar jeg har hørt oftest er: Og det stopper aldrig. Nej. Der er altid noget der skal laves eller ændres.

Man kan bygge huse agilt. Det sker på byggepladser hver eneste dag. Når noget mangler på tegningen, nogen er forsinkede, noget er anderledes end planlagt. Det kan naturligvis koste meget at lave større ændringer, men det kan det også på et softwareprojekt. Noget skal altid vedligeholdes eller også vil man gerne foretage ændringer.

Povl H. Pedersen

Det er svært at bygge et hus agilt. Du skal have byggetilladelse, med energiberegninger etc. Så selve råhuset bliver hurtigt låst. Flytte en vindue kræver muligvis ny byggetilladelse, og muligvis ny energiberegning.

VVS er typisk støbt ned i soklen, så afløb/vand skal man have bestemt sig på forhånd, evt have et par alternativer med i startfasen, så man kan nøjes med at bruge enkelte af mulighederne.

Gulvvarme er out, da det er lavet efter ruminddeling. så det må være radiatorer eller lign. Evt på el. Alternativt plader på gulvet med gulvvarme.

Så konklusionen er, at man kan sagtens bygge agilt, flytte vægge etc efter af yderhuset er færdigt. Men det er dyrt, og man får en række andre begrænsninger.

Nu har jeg bygget hus for ca. 10 år siden, ud fra mere eller mindre mine egne tegninger, som kom forbi en fagmand til rentegning.

Af de få ting der skulle laves om var en skydedør i stedet for 2 terrassedøre, et vindue mere i stuen skulle kunne åbnes for bedre cirkulation. Måske tage en halv meter et sted i huset og flytte til den anden ende. Og så selvfølgelig de ting som ekstra kvadratmeter ville kunne have givet. Huset har været brugt i en fagblad som eksempel på optimal pladsudnyttelse, og spændende arkitektur.

Ligesom med andre ting, så er det vigtigt at komme rundt og se eksisterende løsninger, look and learn. Man kan lære meget ved at se de designbeslutninger der er lavet i sammenlignelige produkter. Men man skal ikke lade sig begrænse. Vi valgte eksempelvis 4 sten ekstra lofthøjde i forhold til standard 238cm. Men plukkede ideer fra mnge forskellige byggerier.

Og så skal man se på sine lokale forhold, om der er noget specielt ved ens egen situation. Vi vurderede faktisk at det var optimalt med 45 grader vinkel på huset for at udnytte grund og lys optimalt, og dette var med til at give os de særlige vinkler inde i huset, som gør huset til noget særligt.

Da først plantegningen var fast, så ligger agiliteten primært i at kunne skifte de løse elementer i resten af processen (armaturer, ekstra lampeudtag etc).

Denny Christensen

Naturligvis er der noget metodik der passer med et husbyggeri og andet der ikke gør. De fysiske afhængigheder, eksempelvis rørgennemføringer og afløb, skal passe sammen fra første hug - i modsætning til eks. it integrationer hvor man kan køre iterativt, bygge lidt af gangen og rette fejl efterhånden som tests påviser dem.

MVP og diverse prototyper er noget man skal oplære sin forretning til at acceptere som netop det og ikke som det færdige produkt. Det kniber det med for rigtig mange ikke IT folk (og desværre også for nogle IT folk...) - testdata der skal fabrikeres til formålet, halve implementeringer af kendte processer, forkerte værdier i en liste, etc.

Eksemplet med tømreren der kommer ind og redder køkkenprojektet skyldes erfaring, overblik og handlekraft. Så er det ikke så meget metoden der redder opgaven, men en enkelt person. En situation som man jo egentlig helst vil være foruden at skulle læne sig op ad...

https://www.version2.dk/blog/lokal-helt-redder-dagen-hvad-med-morgen-108...

Så en god blanding af planlægning, overblik, strategi og så agilitet der hvor det giver mening, blandet med solid sund fornuft ift de mennesker der er involveret - det kan ikke gå galt.

Klaus Enevoldsen

Nedenstående er venligt ment og med stor respekt for forfatterens erfaringer.

Når jeg læser debatindlægget sidder jeg tilbage med en hel masse tanker og spørgsmål, men mest af alt: hvad er det forfatteren forsøger at fortælle? Jeg savner en klar konklusion.

Jeg vil forsøge at redegøre for mine tanker.
Jeg har mest erfaring med Scrum, så det vil være den metode jeg henviser til.

Nej, det giver ikke nødvendigvis mening at bygge et hus med agile. Bygger man typehuse giver det overhovedet ikke mening; man ved hvad man skal bygge, man kender resultatet og kan mere eller mindre bruge samme tidsplan som sidste gang.

Det virker på mig som om forfatteren tager et eksempel på noget, hvor det ikke giver mening at benytte agile, til at argumentere mod agile.

Jeg kommer til at tænke på det gamle citat:

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

(Abraham H. Maslow (1962), Toward a Psychology of Being)

Det er selvfølgelig forsimplet for at fremme forståelsen, men man kan se at man i en vandfaldsmodel arbejder på hvert lag først, inden man går videre til det næste. Fordelen ved det, er at man bør kunne få et overblik over sammenhængene i det enkelte lag. Man kommer dog nemt til at bruge meget tid og opbygge en masse dokumentation, hvis man arbejder med den rene vandfaldsmodel. Samtidig er det måske svært at gennemskue de afhængigheder, der går på tværs af lagene, før man har bygget dele af produktet.

I virkeligheden vil man oftere anvende en variant af v-modellen (i forskellige udgaver også ofte kaldt w-modellen), da man så har hele kvalitets- og testdelen med. Den er ikke vist i ovenstående diagram, men skal ikke glemmes.

Hvordan kunne det så se ud med en mere agil tilgang til det? Ja, vi ønsker jo ikke at bruge for meget tid på analyse og at skabe en masse dokumentation, som måske er unødvendig, så vi prøver i stedet at gribe fat i enkelte dele af den ønskede funktionalitet og så bygge den del til kunden.

I Scrum skal man lave nøjagtigt den dokumentation som er nødvendig, hverken mere eller mindre.

Jeg har arbejdet i et meget reguleret miljø, hvor vi brugte Scrum og V-modellen. Det tog lidt tid, men vi fandt en løsning, hvor test-kravene blev skrevet sammen med vores User Stores og testet undervejs og i forbindelse med afslutningen af sprintet. Det var fantastisk at arbejde med, fordi udviklerne vidste præcist hvordan testerne ville teste den aftalte funktionalitet.

De agile tanker handler jo om at få leveret noget så hurtigt som muligt, og man er godt klar over at det så kun er en lille del af produktet, der leveres.

Det er en stor misforståelse at hvert sprint nødvendigvis skal rulles ud. Scrum taler om "potential shippable increment". Særligt i starten af et projekt er dette svært.

Hvis vi skulle forestille os at bygge et hus agilt kunne vi se hvordan vi kunne nøjes med at levere ét værelse, f.eks. et soveværelse. Det er typisk et værelse, der ikke kræver lige så meget som f.eks. et køkken eller badeværelse. Vi skal godt nok have noget lys og varme, men vi behøver ikke at tænke på rindende vand eller afløb.

Hvad skulle formålet så være med det? Det kunne jo enten være fordi husbyggeren (bygherren) slet ikke har noget at bo i, og gerne vil kunne flytte ind hurtigst muligt. Men det kunne også være fordi man ikke helt ved hvad man vil og gerne vil kunne se hvordan ét værelse tager sig ud, før man bestemmer sig til resten.

Jeg er fundamentalt uenig i denne argumentation: agile skal ikke benyttes fordi man vil levere et produkt hurtigere. Benyt agile fordi du vil minimere risici i dit projekt. Brug prototyper og halve løsninger, der verificerer at du er på rette vej. Prøv at google: "Risk Management in Agile Projects".

Hvad mener læserne? Er jeres erfaring med agile projekter at de nogle gange kunne være løst smartere, hvis man ikke havde fokuseret på et 14 dages sprint?

Nej, det tror jeg ikke. Men i bagklogskabet ulideligt klare lys ville jeg, i alle de projekter jeg har deltaget i, have løst dem anderledes i dag, hvis jeg skulle gøre dem om. :-)

Hvordan løser man afhængighederne, når man har flere Scrum teams?

Der findes et framework, der hedder SAFe - Scaled Agile Framework.

Hvordan sikrer man en høj kvalitet?

Benyt dygtige håndværkere. :-) Hvad ville du gøre i et vandfaldsprojekt?

Bliver man nødt til at etablere automatiske regressionstest for at kunne arbejde agilt?

Det er en god idé uanset hvilken udviklingsmetode man benytter.

Andre interessante spørgsmål:
Kan udviklere lide Scrum/agilt, eller tror de bare det er det forretningen gerne vil have?
Kan forretningen lide det agile, eller tror de bare det er det udviklerne gerne vil have?

Fisk, det kommer nok an på...

Per Larsen

Det engelske ord Agil er på mode i IT sammenhæng.
Det bliver måske af same årsag misforstået af nogle, der ikke ved hvad det betyder!

Hvorfor burger man ikke det danske ord adræt, som er den direkte oversættelse af det engelske Agilt.
Lyder det pænere med Agilt?

Mvh.

Olav M.J. Christiansen Blogger

Software er ikke som er bygge broer, biler eller huse og minder mere om forskning end om de traditionelle bygge fag.

Hvis du ikke kan lide mine analogier, så skal du nok ikke læse flere af mine blog-indlæg, for der vil komme mange flere - og nogle af dem væsentligt mere flyvske end denne her :-)

Jeg tror måske du misforstår formålet med at bruge en analogi, men jeg vil komme ind på det i et senere blogindlæg.

For det andet så er software meget nemt at lave om sammenlignet med at bygge en bro, bil eller huse, i software så er det bare at refactorere koden, det er lidt sværere at flytte broen når man finder ud af at enderne ikke lige passer på midten.

Det er jo et godt eksempel på en misforståelse, som jeg vil godt prøve at gøre op med.

Mange (måske især udviklere) mener jo at vi her taler om 'blødvare' (altså software), så det er jo nemt lige at rette en linje hist og pist - i hvert fald sammenlignet med hvis man skal bygge et nyt hus eller en ny bro.

Men er det jo nu så let igen? Et IT-system består jo ikke bare af noget kode, der kører på en maskine et sted. Det består jo også af de mange brugere og forretningsprocesser samt data, der er afhængige af at systemet hele tiden virker.

Et godt aktuelt eksempel på hvad der sker, når nogen tror at software da er nemt at pille ved:

(kommer senere, da jeg desværre løb tør for tid)

Olav M.J. Christiansen Blogger
Olav M.J. Christiansen Blogger
Olav M.J. Christiansen Blogger

Selvfølgelig er analogien forkert, men den synliggør nogle afvejninger man ellers let kan komme til at feje ind under gulvtæppet.

Tak for det og for at du har set hvad jeg ville med det. Jeg kommer til at benytte mig af en række ret skæve analogier, dels for at simplificere nogle komplicerede problemstillinger og dels for at gøre stoffet en smule mere underholdende. Projektmetoder kan hurtigt gå hen og blive meget tørt stof.

Og så kan jeg i øvrigt godt lide hvis det kan lykkes mig at stimulere de små grå lidt ...

Olav M.J. Christiansen Blogger

en konkrete slicing af stories er noget af det svære i et agilt projekt.

Hvis jeg skulle bygge et hus agilt, ville jeg støbe fundament og bygge ydervægge + tag først.

Så kan man godt bo i huset; måske med ret meget takeaway og bad på jobbet...

Ja, meget god pointe.

Nu har jeg jo lidt provokeret sagt at man nøjes med at bygge et enkelt værelse, men det var faktisk mest for at tydeliggøre den store forskel mellem at køre rent vandfald og rent agilt (jeg tror i øvrigt de fleste organisationer finder et sted midt imellem).

Jeg tror egentlig også at selve opstarten af et projekt nogle gange er det sværeste.

Olav M.J. Christiansen Blogger

Nedenstående er venligt ment og med stor respekt for forfatterens erfaringer.

Når jeg læser debatindlægget sidder jeg tilbage med en hel masse tanker og spørgsmål, men mest af alt: hvad er det forfatteren forsøger at fortælle? Jeg savner en klar konklusion.

Tak for det :-)

Jeg har ikke nogen klar konklusion. Jeg har efterhånden en hel del års erfaring med projekter der har brugt topstyrede vandfaldsmodeller og ekstremt agile modeller og mener der er noget godt i begge typer modeller.

Du vil ikke finde nogen skjult dagsorden, der handler om at alt agilt er dårligt eller lignende. Noget af det jeg prøver at finde frem til er jo netop hvad vi egentlig mener når vi bruger ordet 'agilt'. Og jeg kan allerede nu høre at folk mener noget meget forskelligt.

Jeg er faktisk glad for at du har en masse tanker og spørgsmål, for så har mit blogindlæg vel rørt ved noget. Så må vi se om vi også kan finde frem til nogle gode svar :-)

Allan Ebdrup Blogger

Jeg synes Mike Long, CTO i Praqma, havde en god historie om hvorfor DevOps (og agil software udvikling?), netop handler om et paradigmeskift, hvor vi går fra at tænke på softwareudvikling som traditionel arkitektur og husbygning, til at tænke på det som en bilfabrik. Og hvordan der efterhånden er god evidens for at dette giver meget bedre resultater:
https://www.youtube.com/watch?v=bu-9LGIip6E

Derudover vil jeg efter den meget snak om sprints fremhæve dette tweet:
https://twitter.com/zachbonaker/status/1034249197497667584

No, agile doesnt have to be sprints, story points, scrums, user stories, backlogs, jiras, 3 questions, agile coaches, scaling, velocities, burndowns, stickies, and consultants. It does have to be customer-focused, team-centric, w/ frequent working SW, and humane. Cool, right?  

I min optik kan det ikke siges mange gange nok, at Scrum ikke er synonym med agil udvikling, at der er andre måder end Scrum, der kan være meget meget bedre, og at du ikke behøver køre sprints for at være agil.

Olav M.J. Christiansen Blogger
Olav M.J. Christiansen Blogger
Lars Meldgård

Tak for at dele det med os. Jeg synes det ligner noget jeg har hørt før. Jeg vil gerne spørge dig: Er det primært forvaltningsopgaver (altså en række løbende rettelser til et kørende system) eller er det et projekt med et veldefineret mål og et forventet sluttidspunkt?

Vi skulle lave en greenfield applikation. Så alle muligheder lå åbne - det betød at alle muligheder skulle undersøges inden der blev valgt. Så siger det sig selv at man ikke koder fra dag et, selvom forskellige forsøg blev prøvet. Så laver man en masse om og leverer noget der ser ud som det samme som du leverede for tre sprints siden - men nu med en ny database (f.eks.)
Veldefineret mål ja. Slutdatoer... det går faktisk OK med ikke at sætte for ambitiøse slutdatoer, selvom nogen stadig har brug for noget at styre efter. Der bruger vi den agile metode til at justere prioriterings parametre (kvalitet, indhold, tid).
Med tiden bliver det forvaltning, men kun fordi at "you build it, you run it". Og det har vi det sådan set fint med :-) Det føles godt ikke at aflevere til nogen.
Men vi bruger overraskende meget tid på at organisere os. Sætte teams sammen på en måde - og så en anden måde. Retrospektives hele tiden som tvinger en til at overveje om det man gør nu også er det rigtige.

Lars Meldgård

Jeg er udmærket bekendt med SAFe og vil omtale det på et senere tidspunkt. Men du mener altså at for at være mere agilt i en større sammenhæng bliver man nødt til at indføre et nyt framework?

Det er jeg enig i. Man bliver selvfølgelig nødt til at kunne samarbejde med andre agilt kørende teams. Jeg antager at SAFe hjælper lidt med den tværgående koordinering. Jeg er dog ikke specialist i SAFe.
Dit lille pizza-team kan kun gøre deres egne få ting før pipelinen propper til.

Thomas Ziegler Larsen

Hej Olav

Jeg har med stor interesse læst dine to indlæg. Jeg har arbejdet som Scrum Master i lidt over 3 år i 2 forskellige virksomheder. Pt. både med Scrum og SAFe. Jeg kan godt lide din nysgerrighed, og det er også derfor jeg vælger at svare. Selvom jeg har arbejdet meget med det agile, deltaget i netværk, og løbende uddanner mig, så er der stadig meget at lære om det agile for mig.

Jeg vil dele lidt erfaring fra virkeligheden, og så krydre med lidt teori :)
Jeg genkender det billede du tegner af virkeligheden. Mange steder kører man en kombination af vandfald og scrum, f.eks. når du snakker projekter.

Virkelighed:
I store virksomheder vil man være gennemsyret at tanken om projekter, det forstår alle inkl kunder, og det er ikke alle der kan koble 14 dages sprint til en deadline om 6 måneder. I teorien planlægger man 14 dage af gangen, i virkeligheden styrer man efter en projektplanen, som så bliver justeret løbende. Det kan virke agilt, men har ikke noget med den agile tankegang at gøre.

Teori:
Med et agilt mindset vil man slet ikke have projekter, fokus er i steder på produkter. Et team vil som udgangspunkt have ansvaret for et produkt, dvs både udvikling og support. I Scrum er det fremhævet ved at man har en Product Owner i stedet for en projektleder. Teamet har nu ansvaret for at sikre at produktet kan det det skal, og hele tiden er opdateret. Dette sker ved at Product Owner og resten af teamet snakker med kunderne løbende.
Nogle gange vil et team kunne have ansvar for flere produkter, og nogle gange er produkter så store så man har teams der arbejder sammen. Har vil jeg anbefale LeSS eller Nexus hvis man skal bruge noget (et alternativ er god kommunikation), min erfaring er at SAFe er for tungt et rammeværk.

Mht gevinstrealisering, så er det også et moving target. I stedet for business cases, så har man hypoteser man afprøver. Nogle er der kød på, andre lukker man ned igen. Man kan både bruge prototyping, pretotypoing og andre værktøjer i den proces.

I din analogi om huset, så vil alle håndværkere være til stede hele tiden. Elektrikkeren vil hjælpe til med at støbe fundamentet, maleren vil hjælpe med at lægge murstenene osv. Man er et team, og ikke en række specialistfunktioner.

Olav M.J. Christiansen Blogger

Det engelske ord Agil er på mode i IT sammenhæng.
Det bliver måske af same årsag misforstået af nogle, der ikke ved hvad det betyder!

Hvorfor burger man ikke det danske ord adræt, som er den direkte oversættelse af det engelske Agilt.
Lyder det pænere med Agilt?

Godt spørgsmål. Jeg omtalte nu allerede i mit første blogindlæg, at det var en ret dårlig oversættelse, men jeg tror desværre ikke vi lige nu og her slipper af med ordet 'agil' på dansk - uanset hvor danglish det end lyder.

Men alt det med sprog vender jeg i øvrigt tilbage til i et senere indlæg.

Olav M.J. Christiansen Blogger

Tak for input.

I din analogi om huset, så vil alle håndværkere være til stede hele tiden. Elektrikkeren vil hjælpe til med at støbe fundamentet, maleren vil hjælpe med at lægge murstenene osv. Man er et team, og ikke en række specialistfunktioner.

Er der nogen der kan se hvilken påvirkning denne metode vil have på omkostningerne?

Ideen er god nok, men man risikerer faktisk at flere af håndværkerne må vente på de andre i lang tid ad gangen. Det ser vi også i IT-projekter, hvor forskellige specialister bliver nødt til at være standby, for det tilfældes skyld at man får brug for dem. Men udnyttelsesgraden af arbejdsstyrken kommer nemt til at lide under det.

Olav M.J. Christiansen Blogger
Olav M.J. Christiansen Blogger

I din analogi om huset, så vil alle håndværkere være til stede hele tiden. Elektrikkeren vil hjælpe til med at støbe fundamentet, maleren vil hjælpe med at lægge murstenene osv. Man er et team, og ikke en række specialistfunktioner.

Hov - lige en ny kommentar til dette. Jeg misforstod muligvis din hensigt.

Der er jo den mulighed at man har alle håndværkere til stede, så man kan reagere hurtigt hvis der er problemer, og det var den jeg svarede på.

Men hvis du mener at alle håndværkere umiddelbart kan hjælpe hinanden, så er det jo noget helt andet. Det er faktisk én af de essentielle ting i f.eks. Scrum og faktisk også noget der jævnligt bliver kritiseret. Man prøver at ignorere at der i det virkelige liv rent faktisk er brug for specialister, og at ikke alle kan udføre en hvilken som helst opgave.

Jeg har mødt udviklere, der ikke kan lide at teste og testere, der ikke vil udvikle (eller ikke kan) osv. osv. Faggrænser kan man nu ikke ignorere, selv om det lyder smukt at vi alle er i samme båd og skal hjælpe hinanden.

Olav M.J. Christiansen Blogger

Med et agilt mindset vil man slet ikke have projekter, fokus er i steder på produkter.

Det interessante er at det ikke er noget de agile har patent på. De gamle vandfaldsmodeller havde ret meget fokus på produkterne, og PRINCE2 anbefaler at man anvender en teknik, der hedder produktbaseret planlægning.

Langt hen ad vejen tror jeg det handler om en definition af hvad produktet egentlig er.

Derudover er det naivt at tro at man kan lade som om der ikke skal nogle processer til at skabe produktet, så man kan ikke bare glemme dem. Men jeg kan godt se at jeg har en del at følge op på :-)

Log ind eller Opret konto for at kommentere