olav m.j. christiansen bloghoved olav christiansen

Mange ambitioner om agilt ender med interessante bastarder

Hvad mener vi egentlig, når vi bruger ordet 'agilt'?

Analogier kan være en sjov måde at præsentere en pointe på, så vi kunne jo starte med den evigt populære bil-analogi – dog nok en smule anderledes end man plejer:

Lad os sige at vi skal fra A til B, og vi kører i en bil. Vi kender ikke vejen, så vi benytter os af en GPS-baseret navigator og indtaster adressen på destinationen. Hvad er noget af det første, navigatoren beder os om at vælge imellem:

Find den hurtigste vej eller:

Find den korteste vej

(og som regel også andre muligheder)

Illustration: Privatfoto

Aha. Den hurtigste vej er ikke altid den korteste – og vice versa. Den lader vi lige stå lidt.

(Et tip: Det samme gælder IT-projekter, og nogle gange ved man først når man er fremme om man egentlig tog den bedste vej)

Skulle vi så ikke også prøve at kigge på nogle fordomme om IT-projekter?:

  • I de gode gamle dage hed det sig at en IT-chef ikke kunne gå galt i byen ved at vælge IBM.
  • Senere blev det til at man ikke kunne vælge forkert ved at vælge Microsoft.
  • I dag kan man ikke gå galt i byen ved at vælge agilt. Det er simpelthen gået hen og er blevet det nye sort.

Lidt provokerende?

Måske, men jeg har i mange situationer fået det indtryk at ledelsen i en organisation går den agile vej – ikke nødvendigvis fordi man er kommet til den konklusion at det er det rigtige for lige den organisation, men mere fordi det er 'in' lige nu, og så får man i hvert fald ikke ballade med topledelsen.

Agilt er mange ting

Så hvad er det der agile egentlig for noget? Jeg har på fornemmelsen at hvis man spørger ti forskellige mennesker om det, så vil man få mindst elleve forskellige svar.

Jeg har i hvert fald hørt følgende, når jeg taler med andre om agile projekter og især Scrum:

  • Agilt er det samme som Scrum
  • Agilt er når vi fyrer projektlederen
  • Scrum er en projektstyringsmetode
  • Scrum er bare en fremstillingsmetode, der kræver et styringsniveau over det
  • Agilt er selvstyrende grupper
  • Agilt er når vi ingen processer har
  • Agilt er når vi ikke udarbejder dokumentation
  • Agilt betyder at det hele sejler
  • Agilt betyder at vi har bedre styr på det hele

Det siger måske sig selv at ikke alle ovenstående udsagn kan være korrekte :-)

For at opklare mere om den agile tankegang, så lad os lige se hvor udtrykket stammer fra – og især hvornår.

I 2001 mødtes sytten mennesker med baggrund i IT-verdenen på et skisportssted i USA i tre dage, og ud af det møde kom bl.a. betegnelsen 'agile', som så er blevet (dårligt) oversat til dansk som 'agilt'.

Man havde på et tidligere møde forsøgt at finde et fælles ord for mange af de nye udviklingsmetoder (eks. Extreme Programming og Scrum) og arbejdede bl.a. med udtrykkene 'Light' og 'Lightweight', men endte altså i 2001 med begrebet 'agile' som et fællesbegreb for en masse metoder, som ellers i princippet var udviklet stort set uafhængigt af hinanden.

Det agile manifest

Det vigtigste, der kom ud af mødet i 2001, var nok det agile manifest, som man kan læse her.

Her er mit forsøg på en dansk oversættelse:

'Manifest for agil softwareudvikling'

Vi opdager bedre måder at udvikle software på ved at gøre det og hjælpe andre med at gøre det. Igennem dette arbejde er vi kommet frem til at værdsætte:

Individer og interaktioner frem for processer og værktøjer

Fungerende software frem for omfattende dokumentation

Kundesamarbejde frem for kontraktforhandlinger

Ændringsparathed frem for at følge en plan

Det skal forstås sådan at selvom der er værdi i tingene til højre, værdsætter vi tingene til venstre mere.

Man kan læse videre på hjemmesiden om de tolv principper om agil udvikling, som bl.a. omtaler hurtige leverancer, tættere samarbejde mellem forretning og udviklere samt selvstyrende grupper.

Interessant nok er der stort set ingen omtaler af begreber som f.eks. projektledelse eller kvalitetsstyring, men man har i hvert fald anført at den højeste prioritet er at tilfredsstille kunden ved hjælp af tidlig og kontinuerlig levering af værdifuld software.

Hvad vil kunden have?

Her kan man altså læse noget meget interessant, nemlig at tidlig og kontinuerlig levering er en del af løsningen.

Har disse 'agilister' spurgt deres kunder om netop 'tidlig og kontinuerlig levering' er vigtig?

Hvad nu hvis en kunde hellere vil have en samlet leverance, hvor ting virker som de skal og hænger sammen? Kan den kunde så ikke benytte sig af agile metoder?

Spørgsmålet er skam ikke bare teoretisk. Eksempelvis i Danmark har rigtig mange organisationer taget det agile til sig – typisk Scrum eller Kanban (eller en blanding) – uden at man nødvendigvis har fastlagt at tidlig og kontinuerlig leverance er det vigtigste i netop den organisation eller det enkelte projekt.

Da man samtidig har mange andre interesser (og interessenter) er man dog sjældent gået hele vejen med 100% selvstyrende grupper (eller kontinuerlige leverancer for den sags skyld). Ofte ser man noget der populært kaldes 'ScrumBut', som skal forstås som at 'det er Scrum …. men så alligevel ikke helt'.

Scrum kræver f.eks. at man holder et dagligt kort møde, et såkaldt Daily Scrum, oftest stående. Hvis man ikke holder det møde hver dag, bruger man ikke ægte Scrum:

Her bliver jeg nødt til lige at indskyde: Hvad blev der af det der med at vi værdsætter 'Individer og interaktioner frem for processer og værktøjer'? Hvis Scrum kræver at man holder et dagligt møde, er metoden så selv særlig 'agil'? Det vil jeg overlade til læseren at tænke over.

Rettelse: Hvad er ikke agilt?

Hvis man skal forsøge at forstå hvad det agile er, skal man måske i virkeligheden forstå hvad det ikke er. Som jeg selv opfatter det, er det først og fremmest en slags protestbevægelse mod store monolitiske metodikker og især mange store vandfaldsmodeller, der ellers var god latin igennem flere år.

Det interessante er at der lang tid før 2001 var mange andre metoder til at løse udfordringerne i IT udviklingsprojekter, f.eks. prototyping, rapid application development og case-værktøjer (for bare at nævne nogle få).

Og parallelt med 'agilisternes' projekt, har andre i IT-verdenen forsøgt at komme med deres bud på hvordan man løser problemerne i IT-projekter. Eksempelvis blev PRINCE2 født i England i 1996 som en generel projektstyringsmetode, baseret på tidligere metoder, der stammer tilbage fra 1980'erne. Og den ind imellem udskældte vandfaldsmodel blev i 1980'erne i USA og Tyskland suppleret med kvalitetsstyring og blev til det, vi nu kender som V-modellen.

De sande 'agilister' bryder sig ikke hverken om de topstyrede modeller, såsom PRINCE2, PMI og IPMA og heller ikke om de kvalitetsfokuserede V-modeller, som bl.a. bliver udbredt via ISTQB og ISO.

Men i virkelighedens verden er der mange organisationer, som gerne vil forsøge at køre agilt, samtidig med at forretningsområdet kræver stor fokus på kvalitetsstyring og styring af fremdrift og budget.

Dette afstedkommer forskellige interessante bastarder, som f.eks. når man i et erklæret Scrum-projekt starter med at skrive en tætskrevet teststrategi på 20-30 sider!

Eller når en projektleder kører alle projekter agilt, så en stor gruppe på 15-20 mennesker hver eneste dag er tvunget til at stå i en halv time i halvcirkel og fortælle om hvad de brugte dagen på i går (også selv om status fremgår af et Kanban-panel, som er fuldt opdateret).

Vi kan altså se at der stadig er en del modsætninger mellem forskellige måder at gøre tingene på – også i 2018.

Har læserne input?

Her er i øvrigt et helt friskt debatindlæg fra en fortaler for den agile vej, som er interessant at læse:

I mit næste indlæg vil jeg prøve at dykke en smule længere ned i hvordan jeg mener et agilt projekt adskiller sig fra vandfaldsmodellen, og så håber jeg at få lidt input fra læserne som sikkert har masser af erfaringer med både agile projekter, topstyrede projekter og de blandede.

Jeg håber at få nogle interessante kommentarer med på vejen og at jeg har skabt lidt basis for en sund debat.

Relateret indhold

Kommentarer (20)
Jan Larsen

Jeg sidder i øjeblikket i et projekt der kører "agilt", men mængden af leverancer på dette projekt er den samme som på andre projekter jeg har været med på, hvadenten projektet kører agilt eller ej.

Forskellen er, nu har brugernes set hvad vi forestiller os projektet skal munde ud i - en prototype uden fejlhåndtering og uden database - og nu forstår brugerne så ikke at der stadig er lang vej for at strukturere data, hærde systemet, få styr på processer og dokumentere systemet til drift, fremtidige ændringer og opdateringer.

Jeg kan godt lide tanken i det agile univers, fordi der er basis for meget robuste systemer og løsninger brugerne forstår. Men det vil kun skære i udviklingstiden, hvis der bliver skåret i leverancerne.

Magnus Jørgensen

Pointen er vel ikke at det skal være hurtigere.
Pointen er at brugerene og udviklerne har en forståelse for det ønskede produkt, før det meste af arbejdes er udført.
På den måde undgår man at levere noget som brugerene slet ikke vil have.

host host Sundhedsplatformen.

btw.. være opmærksom på at at kunden og brugerene ikke nødvændigvis er de samme.

Ivan Skytte Jørgensen

Man kan nogle gange få den tanke at fortalerne for metode <x> er det fordi de kan tjene penge på at udstede certificeringer. Modtagerne er for det meste også glade for at være Certified <x>. Det pynter på CVet, og nogle tror at det betyder noget. Alle metoder er ramt af dette.

Nogle underområder er specielt hårdt ramt. Jeg stiftede bekendtskab med SAFe, og fik en kraftig mistanke om at det var ren pengemaskine, og certificeringerne ikke var meget værd. Jeg endte med at løbe bort.

Olav M.J. Christiansen Blogger

Er agil udvikling hurtigere?

Nej, agil udvikling er ikke altid hurtigere. Men det ser hurtigere ud - og det er måske derfor mange bruger det.

Det lyder som om dit projekt er grebet forkert an. Det lyder som et prototyping-projekt, der er solgt som 'agilt'. Forskellen er at man med prototyping godt ved at man måske skal droppe sin prototype helt, når man skal bygge det rigtige system, mens man ved f.eks. Scrum forventer at det er det 'rigtige' system man er i gang med at bygge.

Det er et klassisk eksempel på misbrug af det agile.

Olav M.J. Christiansen Blogger

Pointen er vel ikke at det skal være hurtigere.

Godt set. Men kigger man på de oprindelige 17 'agilisters' manifest osv. er det helt klart at det har været det, der har været den primære bevæggrund bag den agile tankegang: At bygge systemer hurtigere.

Men vi kan godt blive enige om at det er ikke altid det, der giver de bedste systemer.

Olav M.J. Christiansen Blogger

Man kan nogle gange få den tanke at fortalerne for metode <x> er det fordi de kan tjene penge på at udstede certificeringer. Modtagerne er for det meste også glade for at være Certified <x>. Det pynter på CVet, og nogle tror at det betyder noget. Alle metoder er ramt af dette.

Helt enig. Men jeg tror ikke vi slipper for certificeringerne. De beviser jo overfor din potentielle arbejdsgiver at du har været i stand til at sætte dig ind i et stofområde, som et 'rigtigt' eksamensbevis jo også gør.

Men der er meget forskel på certificeringerne. Nogle af dem er faktisk ret svære at komme igennem.

Ivan Skytte Jørgensen

Hvad blev der af det der med at vi værdsætter 'Individer og interaktioner frem for processer og værktøjer'?

Det var det problem, som jeg stødte ind i på mit tidligere arbejde. Jeg skrev en kort svada her på version2. Man kan ikke både prioritere individer/interaktioner over processer/værktøjer, og så samtidig insistere på at følge en bog slavisk. Medmindre man er certified SAFe <x> 😉

Jeg tror at den fejl skyldes at folk forveksler midlet med målet; eller at de tror at agile-værktøj/proces Y er det bedste uanset scenariet.

Olav M.J. Christiansen Blogger

Det var det problem, som jeg stødte ind i på mit tidligere arbejde. Jeg skrev en kort svada her på version2. Man kan ikke både prioritere individer/interaktioner over processer/værktøjer, og så samtidig insistere på at følge en bog slavisk.

Det er nok desværre et af de store problemer med den måde man forsøger at implementere de agile metoder. Den agile tankegang er jo opstået, fordi man synes man var oppe imod et meget tungt apparat med mange processer og meget (unødvendig) dokumentation. Og så tror man at løsningen er at implementere en ny metode, hvor man - som du siger - følger en bog slavisk.

Det er ikke det, der skal til.

Jeg vil komme ind på en del af de problemstillinger i kommende blogindlæg. Jeg tror der er stof til lang tid desværre.

Lars Christensen

Som autodidakt projektleder med +30 års hands on erfaring, er det rigtig rart, at se andre vende spanden på hovedet og stille spørgsmål ved åhhr agile, scrum, P1 og P2 samt alle de firkantede regelsæt der pr. definition kun forsinker og dræber den innovative proces.
Om så investorerne tør slippe seler og livrem, er en anden sag.
Før årtusindskiftet krævede investorerne altid at vi havde en PhD med i højteknologiske projekter, selvom de fleste af dem, ikke anede hvad vi lavede - måske vi engang når frem til færre firkantede regelsæt hvor kontrollen er for kontrollens skyld

Jacob Sparre Andersen

Forskellen er, nu har brugernes set hvad vi forestiller os projektet skal munde ud i - en prototype uden fejlhåndtering og uden database ...

Det lyder ikke som det jeg opfatter som "agil" udvikling.

Som jeg har lært det og brugt det, så skal hver leverance i princippet være klar til at sætte i drift. (Ikke at jeg ikke også har været med til at "snyde" lidt, og definere ikke-køreklare leverancer inden den første principielt driftsklare leverance.)

Jeg opfatter ikke "agil" udvikling som hurtigere end andre metoder. Der hvor jeg ser forskellen er at man kan levere noget brugbart tidligere (og dermed gøre kunden glad), og at man hurtigere kan finde ud af om man er på vildspor (og dermed spare kunden for rigtigt mange penge).

Det er min erfaring at det er væsentligt at have en arkitekt der løbende holder styr på det overordnede design, og hvordan det hænger sammen med kundens ønsker.

Jeg har oplevet mange forskellige (mere eller mindre tilfældige) tilgange til at prioritere leverancer i agile projekter. Generelt foretrækker jeg at man opprioriterer risikofyldte og værdifulde leverancer. Jeg har oplevet at folk ikke er meget for at man opprioriterer de risikofyldte leverancer, men fordelen ved at tage dem tidligt er at man undgår at være langt inde i projektet før man opdager at hele systemet skal omdesignes for at kunne håndtere en alternativ løsning på et problem.

(Er den virkelige betydning af "agil softwareudvikling" ikke "sådan som jeg udvikler software"? :-)

Denny Christensen

Nogle gange kan lidt mundtlig kommunikation og et par streger være nok til at starte en opgave med og så løbende kontakt til slutbruger.

Andre gange er det de store nagler med diverse arkitekter (som jeg selv), forretningsfolk og skarp finansiel opfølgning.

Og konstant leverance af halvfærdig software der fejler, med data slutbrugeren ikke kan forstå, i test miljøer med dårlig performance og tilgængelighed, det kræver et abstraktionsniveau som ikke alle er med på. 'Min kode er færdig' betyder nogen gange at den kører ca som den skal på den lokale pc...

Agilt kan være godt og skidt, det samme kan vandfald og alt andet der er prøvet i tidens løb, blot skal man huske at de mennesker der skal aftage produktet har andet at lave end at lege med halvfærdig kode og konstante ændringer i deres applikationer - og til andre tider venter i måneder på at få rettet hvad der for dem er en helt basal fejl.

Jeg er enig med Jacob Sparre Andersen at en arkitekt er nødvendig, enten en løsningsarkitekt der indenfor rammerne af virksomheden kan sætte en løsning sammen eller andre der kan bidrage til det baggrundsmateriale der gør agil udvikling mulig. Og når det er på plads er der også plads til agil sw udvikling.

Jeg fik i tidligere ansættelse et spørgsmål fra en udvikler: 'Hvad laver I arkitekter egentlig? For vi udviklere styrer jo hvad der bliver lavet af rigtigt arbejde'. Et par min senere forstod han så fødekæden fra behov til emne i en backlog der så kan plukkes fra. Og al respekt i øvrigt for alle i den lange kæde der skal til før og inklusive agil udvikling kan være effektiv.

Olav M.J. Christiansen Blogger

En kommentar

Ganske vist en kommentar af ældre dato, men jeg tror der er en del rigtigt i det (som også andre kommentarer her har antydet):

http://steve-yegge.blogspot.dk/2006/09/good-agile-bad-agile_27.html

God og stadig aktuel læsning. Tak for linket. Men jeg kunne nu godt tænke mig mere end bare at konstatere at der er 'god' og 'dårlig' agile. Jeg vender snart tilbage med et ny blogindlæg.

Torben Mogensen Blogger

Edsgar Dijkstra (som er god at citere) kaldte softwareudviklingsmetoder for "snake oil", og sagde bl.a.

What our immediate industrial environment overwhelmingly seems to ask for is different brands of snake oil, Software Engineering, of course, being one of them.

og

As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."

Groft sagt er hans holdning, at succesen af et IT-projekt har meget lidt at gøre med de metoder, man bruger, men meget at gøre med de personer, der udfører arbejdet. Ligesom den erfarne tømrer i et svar på dit næste blogindlæg kom ind og reddede et køkkenprojekt, der sejlede. Dijkstras holdning var, at man skulle koncentrere sig om at lære programmører at programmere i stedet for at fokusere på "metoder", der stort set kun virker, når de involverede faktisk ikke behøver dem. Jeg giver ham i en vis grad ret, men anerkender behovet for projektstyring og kommunikation med slutbrugerne. Men at tro, at selve udviklingen af software sker hurtigere og bedre ved at bruge "metoder", hvad enten det er Scrum, Prince2, eller noget helt tredje, er noget af en tilsnigelse.

P.S.
Velkommen som blogger, kære fætter.

Christian Nobel

Men at tro, at selve udviklingen af software sker hurtigere og bedre ved at bruge "metoder", hvad enten det er Scrum, Prince2, eller noget helt tredje, er noget af en tilsnigelse.

Bingo!

Der er alt for megen brug at diverse bull-shit banko ord, men i bund og grund kan det koges ned til:

Forretningsforståelse og god (og løbende) dialog med kunden.
God projektledelse og kommunikation.
Godt håndværk og tydeligt forklarede opgaver.
Delmål og løbende kvalitetstest.
Evt. prototype/mock up.
Dokumentation.

Og så er det ellers flintrende ligegyldigt hvilke oppe-it-tiden-smarte-ord der hæftes på, og sådan set også om det programmeres i det ene eller andet sprog (hvor det vigtigste er de håndværksmæssige evner og dokumentation).

Olav M.J. Christiansen Blogger

Hej Torben

Jeg har meget stor respekt for Edsger W. Dijkstra, og jeg tror bestemt vi ville have været et andet sted, hvis det ikke havde været for sådan nogle som ham.

Groft sagt er hans holdning, at succesen af et IT-projekt har meget lidt at gøre med de metoder, man bruger, men meget at gøre med de personer, der udfører arbejdet.

En meget god pointe, men metoder er der jo for at de personer har de bedste vilkår for at kunne arbejde sammen. Men du har fat i noget væsentligt, og jeg vender tilbage om noget af dette ved en senere lejlighed.

P.S.
Velkommen som blogger, kære fætter.

Tak skal du have. Nu har jeg jo siddet og luret i mange år, så jeg må hellere se om jeg ikke kan give lidt igen :-)

Olav

Olav M.J. Christiansen Blogger

Dijkstras holdning var, at man skulle koncentrere sig om at lære programmører at programmere i stedet for at fokusere på "metoder", der stort set kun virker, når de involverede faktisk ikke behøver dem.

Jeg glemte lige en ting, da jeg godt lige ville kommentere dette også.

Hvis man følger tanken fuldt ud, skulle man bare sørge for at have nogle kompetente og erfarne udviklere. Så ville vi ingen problemer have.

Men nu har jeg de sidste mange år arbejdet på en hel del halv- og helstore projekter hos nogle af landets største virksomheder og også offentlige myndigheder. Jeg møder stort set kun meget kompetente udviklere og andre fagfolk.

Alligevel hører vi jo jævnligt om kuldsejlede projekter, men det er altså yderst sjældent det skyldes at man ikke kan finde ud af at programmere. Det skyldes ofte en helt masse andre ting, der bl.a. kan tilskrives metoderne og måske især anvendelsen af dem.

Torben Mogensen Blogger

Alligevel hører vi jo jævnligt om kuldsejlede projekter, men det er altså yderst sjældent det skyldes at man ikke kan finde ud af at programmere. Det skyldes ofte en helt masse andre ting, der bl.a. kan tilskrives metoderne og måske især anvendelsen af dem.

Dijkstras citater er fra 1970'erne, så det er givet, at ting har ændret sig. De kuldsejlede projekter skyldes nok ikke overdrevet brug af specifikke metoder, men snarere mangel på fokus og kommunikation med slutbrugerne. Nogle metoder har kommunikation i centrum, men i mange tilfælde er det ikke slutbrugerne, men deres ledere, der snakkes med. Og det kan ofte give systemer, der er bøvlede for slutbrugerne at arbejde med, eller som ikke løser de problemer, slutbrugerne sidder med til hverdag.

Olav M.J. Christiansen Blogger

Dijkstras citater er fra 1970'erne, så det er givet, at ting har ændret sig.

Jeg er forholdsvis sikker på at hans udtalelser ikke er evidensbaseret. Men man kunne formodentlig godt finde noget statistik, der siger om udviklere er blevet bedre eller dårligere siden 1970'erne (KU må vel have noget, f.eks. gennemsnitlige beståelsesprocenter i visse fag), men jeg er ikke sikker på at vi ville kunne bruge det til noget. Eksempelvis er det helt andre programmeringssprog og frameworks, man bruger i dag. Og systemerne er også vokset i kompleksitet.

De kuldsejlede projekter skyldes nok ikke overdrevet brug af specifikke metoder, men snarere mangel på fokus og kommunikation med slutbrugerne. Nogle metoder har kommunikation i centrum, men i mange tilfælde er det ikke slutbrugerne, men deres ledere, der snakkes med. Og det kan ofte give systemer, der er bøvlede for slutbrugerne at arbejde med, eller som ikke løser de problemer, slutbrugerne sidder med til hverdag.

Det er desværre ikke helt enkelt. Jeg skal nok hen over det næste stykke tid komme med nogle af mine observationer. Så må vi se om andre kan genkende det.

Chris Bagge

Et af de store problemer er at at agile og Scrum 'lover' tidlig leverance.

Det er blevet sagt mange gange at kunden ikke ved hvad han vil have før han har fået leveret det. Derfor skal vi hurtigt levere noget til kunden. Det store problem er kvaliteten. Der er alt for mange 'prototyper' der bliver lappet på i uendelighed for at få noget der kan bruges i produktion. Det skaber masser af problemer.
Kundens ledelse får et et urealistisk billede af hvor langt man er nået de ser en prototype. Det at blive ved med at lappe på en prototype giver ikke et godt produkt, men et kludetæppe.
En mere reelt løsning er for at citere Frederic Brooks "Build one to throw away". Her havner vi bare i et psykologisk problem. "Er det nu nødvendigt, vi har jo noget der næsten virker". Hvorefter der kastes en masse ressourcer efter lapperiet i stedet for.

Så snart systemer har en vis størrelse er der brug for at de har en ordentlig arkitektur. En ordentlig arkitektur er en forudsætning for et godt produkt. Det kan til gengæld godt være en en iterativ process, men der er et ordentligt forløb for det enkelte gennemløb. En væsentlig del af et sådant gennemløb er "requirement scrubbing" hvor man får fjernet alt det der ikke er brug for.

Log ind eller Opret konto for at kommentere