Varför agil utveckling är skällsord om tio år

I Le Modulor och Le Modulor 2, en slags tidig blogg i bokform, presenterade Le Corbusier, en av evangelisterna bakom modernistisk arkitektur, 1948 ett måttsystem som så gott som automatiskt skulle ge estetiskt sköna skapelser. I modern, konstruvistisk anda skapades med gyllene snittet, fibonacciserier och medellängden hos fransmän en serie av mått man skulle välja bland för att få goda proportioner. Med hjälp av måttband och enligt samtiden självklart bra och framåtskridande saker som flygplan och båtar, ”bevisades” att måtten var riktiga.

Men eftersom måtten fick olämpliga konsekvenser för standardhöjden i bostäder och var jobbiga att uttrycka i fot togs en ny serie fram, nu lite slumpmässigt baserad på längden hos en typisk amerikansk hjältefigur, sex fot. Lite överraskande visar det sig att även den efter kontrollmätningar var korrekt. Dessutom togs två måttserier fram och man fick välja fritt ur båda. Men argumentationen var passionerad och läsaren bjöds in till kommentarer som senare publicerades med författarens svar i Le Modulor 2.

Reaktionerna, i alla fall de utvalda, är översvallande. Le Corbusier sägs vara Gud på spåren. I efterkrigstidens Europa är slaget vunnet, modernismen har segrat, allt gammalt ska ut och nytt in. Genom Le Corbusiers nöjda svar skiner en viss förskräckelse när han tonar ner kommentarerna. Man anar att fotfästet sviktar. De första modernisterna är gediget klassiskt skolade och de har sin bas i kontrast mot och renodling av, det gamla. När arvet nedvärderas försvinner fundamentet för framtiden och jag kan undra om unset av tvekan är en liten undran om vilken snöboll man har satt i rullning.

Jag kan känna att det är här agila metoder befinner sig idag. Slaget är vunnet. Att hävda fördelarna med agila metoder är att slå in vidöppna dörrar och ve den utvecklare som skamset måste erkänna att de i deras projekt inte använder dem. Agila metoder är main-stream till den grad att vi har svårt att minnas vilka problem de löste.

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

Läser man det agila manifestet utan att komma ihåg den kontext det är sprunget ur är det lätt att hamna fel. Förutom att de antydda motsatsförhållandena är ganska godtyckliga vet alla som suttit med åtta saker att göra som inte har något slut, varav fyra saker är prioriterade, vad som händer med de andra. Den jordmån agila metoder är sprungna ur är mer styrda projektmetodiker. I själva verket undrar jag om de inte är en förutsättning för att agila metoder ska fungera bra. Ju längre bort ifrån den ramen vi kommer, desto större tror jag risken för att agila metoder leder riktigt fel.

För alla som nyligen klivit in i IT-branschen har jag kanske en nyhet: det har genomförts långa rader av framgångsrika, lyckade projekt som inte har använt agila metoder alls. Det är lätt att få intrycket av en silverkula som genom ett trollslag har fått alla projekt på rätt köl, men jag är helt övertygad om att det finns många exempel på agila projekt som är dåliga och underpresterar. Ett av flera problem är att metodiken gör det svårt att kontrollera och följa upp.

Jag är övertygad om att pendeln kommer att svänga tillbaka. Frågan är hur långt.

Profilbild
Jag arbetar som chef över IT-arkitekturgruppen på IT-avdelningen på KTH.

23 reaktioner till “Varför agil utveckling är skällsord om tio år”

  1. En sak som funderade mycket över för ett par år sedan (vet inte om det fortfarande är lika aktuellt) är den amerikanska kulturen som agile kommer i från, och med det menar jag att det handlar om att jämna ut hierarki, skapa grupptryck etc. Kulturella grundförutsättningar som ofta skiljer sig vädldigt mellan USA och Sverige. Det som är så fantasktiskt att man inte har en allsmäktigt chef i USA, är inte lika ovanligt i Sverige. Det är i min värld inte helt otroligt att vi till för hög grad lutar oss mot amerikanska siffor och forskning, för att bevisa den agila storheten.

    Dessutom så är det intressant att vi utvecklare inte litar på metodiker som inte fått godkänt i Silicon Valley. Många av grundläggande agila verktygen som t ex självlärande lag, har ju funnits vetenskapligt bevisade och använda i andra sektorer sedan 50-talet. Lean är ju ett annat exempel där Toyotas tankar var tvungna att ”godkännas” först av Uncle Bob och hans mannar.

  2. Jag har inte funderat så mycket i de banorna faktiskt, däremot utifrån det arbetssätt vi hade på den utvecklingsenhet jag senast jobbade på Ericsson. Det var väl iofs också en enhet som var ganska bra på att leverera på ett pragmatiskt sätt, kulturerna skiftar ganska mycket även inom ett så stort företag, men ifrån det perspektivet tycker jag egentligen inte att agila metoder i sig tillför särskilt mycket. Ett välskött projekt fokuserar på ”rätt” saker och vilken faktisk process man använder för att organisera arbetet är tämligen underordnat.

    Den enda riktigt väsentliga skillnad som jag ser det, det som agila metoder i grunden egentligen fokuserar på, är de inkrementella leveranserna till ”kunden”, som i sin tur egentligen handlar om en enda sak, riskhantering. Men den risk man faktiskt hanterar är inte att projektet går åt skogen, det kan det göra alldeles utmärkt ändå, utan att det går åt skogen på ett sådant sätt att man har bränt allt kapital och inte fått ut någonting användbart alls.

    I den typ av arbete som vi utför på KTH som huvudsakligen handlar om förvaltning tillför det något väsentligt. Pratar man ny- eller produktutveckling är det inte alls självklart att det är det i samma utsträckning. I många fall är det alltihop eller ingenting alls, man måste få ihop ett relativt stort minsta set av funktionalitet för att det ska ha något realiserbart värde.

    Men du har nog en poäng i att agila metoder kanske inte tillfört så mycket i en svensk tradition som redan tidigare ofta har haft ganska lågt i tak och varit ganska flexibel, även om det finns avarter.

    I grunden tror jag att en kombination av ett agilt arbetssätt för den operativa utvecklingen, tillsammans med en mer klassisk modell för projektstyrning, ett område som de agila metodiker jag mött bara berör väldigt svepande om alls, är det bästa. Som av en händelse tycker jag personligen att vi är rätt kassa på just projektstyrning, men det finns en del argument mot mina åsikter.

  3. Hej Fredrik!

    Tack för dina åsikter om agila metoder. Jag har jobbat ett tag med dem så tillåt mig att kommentera några av de påståenden som du gör i din artikel.

    Du nämner i en bisats att ”de antydda motsatsförhållandena [i manifestet] är ganska godtyckliga”. Min mening är tvärtom att dessa fyra rader är ovanligt välformulerade och genomtänkta. Det agila manifestet var mig veterligen det första dokument i sitt slag som ställde upp ett antal saker som alla vill ha mot varandra och tydligt angav vilka man föredrog. Det skänker en helt annan tydlighet än om man bara hade sagt att man t.ex. värdesätter ”människor och interaktioner”. Jämför gärna med någon tidigare metod, låt oss ta RUP. Där var inte ens värderingarna explicita utan fick utläsas mellan raderna (t.ex. ”modellering är viktigare än program”, ”köp våra verktyg”).

    Jag håller med dig när du säger att ”den jordmån agila metoder är sprungna ur är mer styrda projektmetodiker”, men det var som en tydlig /reaktion/ mot dessa. I en värld som de tyckte höll på att styras alldeles fel av människor som faktiskt inte arbetade med systemutveckling ville de erbjuda ett sunt alternativ. Men agila metoder är inte antitesen som kommer att följas av en syntes. Tesen var ”låt oss helt enkelt skriva program”. Det fungerade inte bra när utmaningarna för mjukvara blev allt större. Antitesen blev: ”Låt oss skapa formella metoder med hög grad av explicit kunskap och specialisering och följa dem rigoröst”. Det fungerade aldrig speciellt bra och ännu sämre i en värld där förändring sker allt snabbare. Agila metoder kan helt enkelt ses som syntesen av dessa två. Låt oss vara flexibla på det vi vill ska kunna ändras och ha extremt hård disciplin på sådant vi aldrig vill tumma på (t.ex. en god systemdesign).

    Du skriver vidare att ”det har genomförts långa rader av framgångsrika, lyckade projekt som inte har använt agila metoder alls”. Visst finns det lyckade projekt, men du kan väl inte på allvar mena att andelen framgångsrika utvecklingsprojekt är speciellt lysande? Snarare får vi väl stå i skamvrån allihop, så dåliga som vi är. Det faktum att det finns några som lyckas med undermåliga metoder (som de troligen förbigick många gånger för att nå framgång) är väl inte ett bra skäl att sluta vilja förbättra sig? Det tror jag inte att du menar.

    När du skriver att ”det finns många exempel på agila projekt som är dåliga och underpresterar” så undrar jag om du har läst första värderingen i agila manifestet? Vi som håller på med agila metoder menar att det aldrig primärt är verktygen eller metodernas fel om projekt går dåligt. Ett bra team kan klara sig rätt bra med en olämplig metod att angripa problemet. Ett svagt team med världens bästa metod klarar sig inte alls. Det är den mänskliga faktorn som är skillnaden. Faktum är att agila metoder är de första metoderna som /inte/ sätter sig själva i främsta rummet. En metod bör väl vara ett stöd – inte ett facit?

    Jag förstår alls inte vad du menar med ”ett av flera problem är att metodiken gör det svårt att kontrollera och följa upp”. Agila metoder är nämligen ”empiriska”. Det betyder att de använder lärdomar och erfarenheter som man gör /under projektets gång/. För att göra detta har vi med korta intervall avstämningar där vi /kontrollerar/ var vi är och /följer upp/ vårt arbete. Det kallas t.ex. i Scrum för ”sprintgranskning”, men alla agila metoder har det. Mätningar av olika slag är legio, för att kunna ständigt förbättras. Själva fundamentet i agila metoder är just att kontrollera genom feedback, vilket är enda möjliga vägen när man har så hög grad av förändring som mjukvaruutveckling (jmf reglerteknik). Bra, agil användning ger beställaren verklig kontroll, ner på funktionsnivå

    Jag tror du har fel, Fredrik. Det finns ingen pendel och den kommer inte att slå tillbaka. Organisationer behöver bli och kommer att bli mer och mer lättrörliga. Efter agile kommer Lean med ett flödestänkande och kontinuerlig leverans (i stort sett den logiska ändpunkten av korta iterationer). Trenden är snarare att vrida upp volymknappen ännu högre. Frågan är om du lyssnar?

  4. Hej, Joakim. Jag skrev medvetet lite provocerande och jag antar att ditt svar är det också, annars är retoriken lite intressant. Det var inte så att jag sprang på den första sidan av manifestet igår och skrev en rant.

    Och jag förordar inte RUP, den anti-krist som agile-evangelister skrämmer små barn med. *spökröst* ”Arbetar du inte agilt så kommer RUUUUPP och tar dig, muahahaha…”

    I själva verket tycker jag agila metoder är utmärkta, framför allt i verksamheter som vår egen, som jag skrev i en tidigare kommentar. Och den verkliga essensen, där agila metoder på riktigt tillför något, ligger just i den första principen som du säger. I förvaltande verksamhet som vår är den extremt viktig (i en del andra sammanhang inte lika mycket, men det är en annan historia).

    Men, jag har blivit skeptisk till att agila metoder är så bra att de riktigt står på egna ben i alla lägen och det är väl det som egentligen är min tes. Det finns någonstans ett antagande om att de opererar i ett ramverk där det redan finns andra regler på plats. Vi själva har kanske tappat det och behöver adressera det på något sätt, och jag tror inte att lösningen på det nödvändigtvis är ännu mer agilitet.

    För att ta ett oss närliggande exempel, ”working software over comprehensive documentation”. Har man bara en sådan formulering i ryggen blir det undermålig dokumentation, om någon alls. Det är lätt att se för sig jublet som brer ut sig hos de 99% av utvecklare som avskyr dokumentation och ofta faktiskt på riktigt har svårt att uttrycka sig i skrift, så det är inte så konstigt. Ska det undvikas behövs det ett regelverk, process om man så vill, som i något läge höjer prioriteten för dokumentationen.

    Sedan kan man avfärda min skepsis med att jag inte vet tillräckligt mycket om agila metoder. Men vet du, det gäller i princip alla andra metoder också. De som har arbetat med dem är varken idioter eller skvatt galna. Det är inte heller, tvärtemot populär uppfattning, bara i agila metoder man arbetar med att utveckla metoden i sig.

  5. Finns mycket jag vill skriva här. Måste dock begränsa mig till något.

    ”ett av flera problem är att metodiken gör det svårt att kontrollera och följa upp”

    Håller med om det Joakim skriver, men skulle vilja utveckla lite. Poängen (som jag ser det) med Agile/Lean är att hitta sin egen väg och sin egen process, inte att försöka kopiera vad andra gör. Detta betyder att varje implementation är i viss utsträckning unik och att jämförelser mot en referens implementation saknar relevans.

    Om vi godtar att mjukvaruutveckling handlar i hög grad om att människor ska samarbeta på ett konstruktivt sätt så bör man också välja ett angreppssätt som tillåter anpassningar av samarbetsformer till både sin kontext och de involverade individerna.

    Lite korthugget bidrag till en intressant diskussion. Får återkomma när jag har mer tid.

  6. ”Lean är ju ett annat exempel där Toyotas tankar var tvungna att ”godkännas” först av Uncle Bob och hans mannar.”

    Jag tror knappast att David Andersson, Poppendieck och Ladas med flera bad varandra eller Uncle Bob om lov innan de prövade angreppssätt mer inspirerade av Lean än Agile. Lean Startup boken av Eric Ries är kanske ett annat exempel (http://www.startuplessonslearned.com/).

  7. ”Poängen (som jag ser det) med Agile/Lean är att hitta sin egen väg och sin egen process, inte att försöka kopiera vad andra gör.”

    Mattias, det är väl både rätt och fel. Det är klart att vi kopierar det andra gör, det vore ineffektivt att göra något annat, men det är också givet att vi sedan anpassar det som inte fungerar. Det finns inte en enda projektmetodik jag har stött på som inte innehåller det momentet om man gräver lite djupare i dem och det är ännu en sak som inte uppstod med agila metoder.

    Möjligen kan man argumentera för att agila metoder tonar ner projektledarens roll till förmån för gruppen och därmed minskar risken för att en enstaka idiot kan förstöra projekt genom att envisas med irrelevanta principer. Återigen riskhantering.

  8. Hej Fredrik! Jag fastnade lite för det du skriver om undermålig dokumentation (i en kommentar till bloggen). Är det verkligen så att vi utvecklare struntar i dokumentation när vi jobbar ”agilt”? Den erfarenheten har i alla fall inte jag. Tvärtom, faktiskt. Schyssta principer för att koda, utveckla testdrivet och att visa resultat av arbetet ofta brukar landa i ganska bra dokumentation av produkten man utvecklar.

    Däremot är ”working software over comprehensive documentation” kanske en av de mest missförstådda delarna av de agila idéerna. ”I Scrum hatar man dokumentation” och så vidare. Det var ju inte några poeter som skrev ihop det där manifestet, snarare data-nördar som du och jag.

    Så, jag tror inte att det finns någon pendel som svänger tillbaka till kontrollsamhället. Däremot kanske det behövs en penna och suddgummi, som kan göra idéer och värderingar tydligare och enklare att förstå och använda?

  9. Nej, jag måste nog ärligt säga att jag aldrig har sett bra dokumentation uppstå spontant där det inte har funnits regler, i någon form kring det, kalla det metodik, process eller vad du vill. Det finns dock inget motsatsförhållande mellan det och agil utveckling i sig, men det finns inte ett skvatt som säger att det uppstår ur en agil metodik av sig självt. Regler är ok så länge de heter ”Scrum”, men alla andra regler är ”kontrollsamhälle”?

  10. Hej igen!
    Att dokument skulle skapas per automatik för att man använder agila metoder har jag inte sagt. Jag beskrev mina erfarenheter av ett antal olika it-projekt, där vi lagt till det som behövs för att leverera bra grejer. Dokumentation är inget självändamål, men något som de allra flesta tycker är viktigt. Ibland är det till och med ett krav från beställaren. Det kan se olika ut, därför är det osmidigt att skriva in det i ett arbetssätt.

    Kontrollsamhället: om vi har kontrollsamhället på ena sidan och noll-kontroll på andra sidan, tycker jag att man kan placera agila metoder ganska nära noll-kontroll. Tanken är att lägga till det som behövs, alltså att närma sig kontrollsamhället något. Den andra sidan innebär då 100% kontroll, som i teorin kanske ser rätt ut. Men i praktiken inte genomförbart, eftersom vi är människor. Kanske skulle det fungera för Hubotar?

  11. Kort svar: Du har givetvis helt rätt, agila metoder står inte på egna ben. De förutsätter tänkande människor som kan anpassa dem till sin kontext. Och precis som David säger är de ”additiva”, man förutsätts lägga till det man behöver. Dina tankar om dokumentation låter mer som fördomar, om jag ska vara ärlig.

    Berätta gärna mer om de agila projekt du har varit med om och vad som inte har fungerat. Vad gjorde ni åt det?

  12. Första raden i det agila manifestet lyder:

    ”Individuals and interactions over processes and tools”

    Då är det ju lite konstigt att det finns en massa folk som är experter på agila processer och verktyg (eller agila ”metoder”). När det finns folk som är experter på agil metodik utan att egentligen vara utvecklare själva så är det ett tecken på att man menar något annat när man kallar sig ”agil” (med utvecklare i bred bemärkelse, inte bara ”kodare” utan även kravställare, UX:are etc).

    När agila metoder är något utvecklarna tvingas göra är det dåligt. Bland utvecklare som hamnar i en organisation där chefen har bestämt att man skall följa en på förhand given ”agil” metodik är ”agila metoder” ett skällsord både om tio år, nu och för tio år sen.

    Samtidigt sker utveckling i språk och utvecklingsverktyg, så gränsen för hur stora projekt (i funktionalitet) man kan ”hacka ihop” utan att medvetet bry sig om någon metodik alls flyttas ständigt frammåt. Om man sedan ser det som att agil erfarenhet har bakats in i verktygen eller som att verktygen gör agil erfarenhet obsolete spelar egentligen ingen roll.

  13. Är det: ”Nej, jag måste nog ärligt säga att jag aldrig har sett bra dokumentation uppstå spontant där det inte har funnits regler, i någon form kring det, kalla det metodik, process eller vad du vill.” som du menar är fördomar Jocke, får du gärna utveckla det. Eller var det något annat.

  14. Nej, det som jag avsåg var ”För att ta ett oss närliggande exempel, ”working software over comprehensive documentation”. Har man bara en sådan formulering i ryggen blir det undermålig dokumentation, om någon alls.” Eftersom jag vet att det inte stämmer kändes det mest som en fördom.

    På mig låter det lite som, och rätta mig om jag har fel, att du inte riktigt litar på dina kollegor och medmänniskor och menar att det alltid måste finnas regler och kontrollmekanismer för annars kommer folk att strunta i det tråkiga? Kanske menar du att en av arkitektens viktigaste uppgifter är just att övervaka att reglerna följs?Kan det vara så? Jag kan förstå den synvinkeln även om jag inte håller med. Vad jag försöker göra och har sett i de team som jag har haft förmånen att arbeta med är hur folk växer och tar ansvar när de får chansen – när vi slutar att behandla dem som barn eller mindre vetande ”utförare”. Jag vill bara att du ska känna till att det finns andra sätt, kanske mer humana?

  15. De fall jag har sett bra dokumentation har det funnits en process ikring det, så att det granskades av andra, inklusive personer som inte var insatt på området men bra skribenter osv.

    Det kan naturligtvis uppstå av sig självt i en grupp som arbetar agilt, men det är inte jättetroligt att det gör det bara baserat på grunderna för agila metoder, utan att det finns några andra former av krav med i bakgrunden.

  16. Om dokumentationen faktiskt efterfrågas så kommer det nog att uppkomma ett sätt att åstadkomma den även i en väldigt självorganiserande verksamhet. Och om dokumentationen inte efterfrågas har jag svårt att se att det gör något om den saknas.

    Problemet med det är väl de gånger det faktiskt behövs dokumentation, men den efterfrågas väldigt sällan. Då kan det nog ta väldigt lång tid inan teamet hittar på ett bra sätt att se till att den alltid finns där.

  17. Det är nog ingen som har påstått att den ska skapas bara för att. Men är det verkligen väldigt så sällan? Hur ofta har vi inte läst i Djangos dokumentation? Plays? LPWs? Hur ofta har vi klagat på att LPWs är kass? Eller CAS? Hur ofta klagar driften på vår?

    Interndokumentation av typen hur den här klassen sitter ihop med den här är däremot oftast meningslös. Gränssnitt som någon annan ska använda är en annan sak.

    Det är frågorna kring hur den uppkommer, vem som efterfrågar den och hur man ser till att den uppfyller deras behov som jag inte tror är riktigt så självklara.

  18. Specifikt för oss utvecklare på plan 6 i Q-huset behöver vi nog bli bättre på att lyssna på driftfolket och tillgodose deras behov. Men jag tror det är mer en fråg om prioritering av olika intressenter än en fråga om dokumentation egentligen. Jag tror inte vi saknar dokumentation för att våra metoder resulterar i dålig dokumentaion utan för att vi lyssnar för lite på de som efterfrågar dokumentation (om det nu är ”dokumentation” de efterfrågar, ofta tror jag begripligare logmeddelanden och installationsscript som står högre upp på önskelistan).

  19. Nu var det inte specifikt vår situation jag tänkte på när jag tog just det här som egentligen bara var ett exempel. I realiteten är det mycket vanligare än så.

    Men när vi nu är inne på det. Hittills har våra arbetssätt resulterat i drivor av olika wikis, diverse olika filer som heter och innehåller lite olika saker som bor på olika ställen i olika repositories i olika projekt, i diverse olika format och några andra lösningar till. Hittills har vi knappt frågat driften så värst och har en väldigt diffus idé om vad som behövs och vad som saknas. Och så har vi supporten som vi inte ens har på radarn.

    Och som du säger är problemet att det inte prioriteras. Vilket var precis min poäng.

    Jag har sedan länge tappat räkningen på hur ofta viktiga saker vi har dokumenterat på precis det sätt som de ”skulle”, passerat driften förbi. Våra agila metoder kanske magiskt löser det här, men vi har jobbat agilt ganska länge och track record tyder inte precis på det. Drift och support är inte våra beställare och de som är beställare har ännu mindre aning om deras behov än vi har.

    Det gäller inte bara oss. Det gäller även hur andra grupperingar på ITA hanterar de behov av dokumentation som trots allt finns och det pekas ut som ett av våra största problemområden av alla inblandade. Det saknas all form av samordning för att någon ska kunna hitta något när det behövs. Och det finns ingen kraft i våra metoder som ens lite, lite grann drar åt det hållet av sig själv.

    Den tes jag drev i inlägget ifrån början var att agila metoder behöver ett regelverk att röra sig i, i sig är de för innehållslösa. Hittills har i princip alla projekt haft sådana yttre ramar, men i takt med att agila metoder i sig blir mer och mer centrala riskerar de att luckras upp, och det kommer att finnas fler och fler organisationer som inte har haft någon sådan tradition alls utan startar från scratch med t.ex Scrum som enda bas. Det riskerar att bli ett mindre lyckat resultat, besvikelse, och att agila metoder i sig på sikt kommer att tappa popularitet.

    Vilket vore synd. De är bra på det de är bra på. De är bara inte bra på allt. T.ex behövs förmodligen i varje organisation någon form av regler får lägsta nivåer på de områden agila metoder deklarerar som mindre prioriterade, annars löper de stor risk att falla bort helt. Det är inte ett särskilt kontroversiellt påstående.

  20. Hej!

    Verkligen intressant inlägg och diskussion. Jag kunde skriva sida upp och sida ner om funderingar kring dessa frågor. Jag tyckte Patric Janssons kommentar om kulturskillnader var speciellt intressant. Olika värderingar sätter sin prägel på metoder och arbete, och kanske det finns något i programvaruindustrin som förhärligar de värderingar som härstammar från Silicon Valley-kulturen? Men finns det något som tyder på att det faktiskt är mer än en intuitiv känsla bakom den tanken? Om ni ursäktar så skulle jag vilja tipsa om en undersökning som vi gör på Helsingfors universitet som handlar om precis de här sakerna: http://tinyurl.com/agilesurvey2013.

    Vi kommer utifrån den undersökningen att kunna ge något slags svar på dessa frågor. Kolla gärna in undersökningen och tipsa andra som kunde vara intresserade! Det är en viktig fråga och personligen hoppas jag att vi om tio år vet varför agil utveckling är ett skällsord – eller varför det inte är det.

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *