Agila missförstånd

1. Jobbar man agilt skriver man inte några dokument

Kort svar

Jodå, bara inte lika många onödiga dokument.

Förklaring

Ett av de bästa sätten att bli mer effektiv är att eliminera onödigt arbete. Tyvärr är många dokument som skrivs idag just... onödiga. De skrivs mest för formens skull, är tämligen fattiga på innehåll, blir snabbt föråldrade och/eller läses aldrig. De är ofta av karaktären arbetsdokument. Dokument som är missvisande är ofta värre än dokument som inte finns. Kostnaden för underhåll av dokument glöms ofta bort. Kan vi identifiera dokumentation som inte är värda arbetet det kostar att ta fram och underhålla dem kan vi bli mer effektiva.

2. Att jobba agilt är för riskabelt, vi måste faktiskt veta tid och budget innan vi börjar.

Kort svar

Du kan aldrig "veta", men det går lika bra att estimera med agila metoder som med alla andra.

Förklaring

Sanningen är att vi kan uppskatta tid och budget precis som tidigare. Det går till exempel utmärkt att driva agila projekt till fast pris. Men vi undviker helst att lägga ned onödigt mycket tid på det då precisionen inte kan ökas utan återkoppling från faktisk erfarenhet. Agile handlar mycket om flexibilitet och om en part åtar sig något omfattande och detaljerat till ett fast pris har man bundit händerna bakom ryggen på sig. Vi vill undvika sådana situationer. Agila metoder är optimerade för att du ska få ut maximalt värde för pengarna du väljer att investera, detta i motsats till att få en trisslott för en känd insats.

3. Agila projekt verkar mest vara kaos och helt sakna styrning och kontroll

Kort svar

Innovation kräver ett visst kaos, men även i lätt kaos måste det finnas disciplin. Agila arbetssätt kräver ibland mycket disciplin. Kontroll är inte samma sak som disciplin och kan bara erhållas genom att kontinuerligt mäta verkliga framsteg, till exempel testad, nyttig, fungerande mjukvara.

Förklaring

För en utomstående kan ibland ett väl fungerande, sammansvetsat lag se ut som kaos. Hur ser rugby ut för någon som inte är insatt i sporten? Men speciellt i en lätt kaotisk, innovativ miljö måste det också finnas disciplin och det finns många exempel i agila projekt. Att följa en process utan att tänka själv kräver ingen disciplin, bara lydnad. Men försök att leverera till produktion varannan vecka utan disciplin. Arbetssätt som testdriven utveckling och korta iterationer kräver likaså disciplinerade utvecklare.

Kontroll är inte disciplin. Vad innebär kontroll när det gäller systemutveckling? Kontroll kommer av att veta var man faktiskt är och vart man är på väg. Agila metoder ger stora möjligheter att mäta verkliga framsteg i stället för imaginära. Ett verkligt framsteg anser vi det vara när en liten funktion fungerar och är tillgänglig för en användare som verkligen har behov av den och vet hur man använder den. Den har ett värde för organisationen. Ett exempel på ett imaginärt framsteg är när ett användningsfall är fullständigt beskrivet.

4. För att kunna arbeta agilt krävs att systemutvecklarna är väldigt duktiga

Kort svar

Tvärtom. Vi samarbetar i produktiva team där vi hjälper och lär av varandra.

Förklaring

Bra resultat ges främst av bra och duktiga människor som samarbetar mot ett gemensamt mål. Detta är ett ofta förbisett faktum som vi envist fortsätter att hävda. Observera att detta gäller oavsett vilken metod du råkar använda. Agila metoder gör detta till en central tes och lämnar utrymme till teamen att göra ett bra jobb. Men inte nog med det. Med fokus på samarbete, t.ex. via parprogrammering och att sitta tillsammans, blir de mindre erfarna snabbt duktigare. Dina utvecklare blir aldrig så bra som i agila projekt.

5. Agila team hoppar över arkitektur och design

Kort svar

Agila team eftersträvar en enkel men utbyggbar design som smidigt följer behoven. För att skapa denna krävs en kontinuerlig uppmärksamhet på systemets inre struktur.

Förklaring

I början av ett projekt är den tidpunkt när de inblandade vet minst om vad projektet kommer att innebära. Ändringar är en del av verkligheten. I agila projekt får därför både krav och design växa till sig organiskt vartefter arbetet fortskrider. För design innebär detta att teamen försöker undvika den spekulativa formen av designarbete som görs i en "designfas" i början, generell nog att täcka de krav man känner till då. Designen kommer sannolikt inte vara helt rätt givet de kända kraven eftersom design är svårt. Värre är att helt säkert representerar inte kraven de verkliga behoven.

Istället försöker agila team att få systemets design att i varje ögonblick motsvara precis de krav som har implementerats hittills. Denna design försöker de implementera så klart och enkelt som möjligt. Ofrivillig komplexitet kostar och ska elimineras. Därefter använder de refaktorisering för att ständigt omarbeta vår design och arkitektur i takt med behoven. Detta angreppssätt leder till en både enkel och hållbar design.

Design och arkitektur är för viktigt för att lämnas åt sitt öde under projektet. Vi behöver inte sluta att tänka bara för att vi har börjat programmera, eller hur?

6. Agil metodik är för hackare, inte professionella systemutvecklare

Kort svar

Agilt tänkande handlar inte om att inte tänka efter före, utan om att våga fortsätta tänka. För att göra det strävar vi efter att bygga högpresterande, sammansvetsade lag av kunniga, engagerade och ansvarstagande individer som är enkla att samarbeta med. Vad kan vara proffsigare?

Förklaring

Grundbudskapet i denna kritik är att agila arbetssätt på något sätt skulle vara slarviga. Att agila experter skulle förorda att vi ska sätta igång att programmera utan att tänka efter. Det är inte det vi säger.

Det vi vill göra är att upphöra med vårt slöseri med resurser och i stället maximera vår nytta och anpassningsförmåga genom att inte låsa fast vårt tänkande för tidigt. Vi förordar till exempel att upphöra med alltför tidiga och alltför detaljerade krav. I stället bör detta arbete fördelas över hela utvecklingsperioden. Vi lär oss alldeles för mycket under arbetet för att inte dra nytta av det.

Agila arbetssätt tar hänsyn till att det är människor som ska utföra jobbet och försöker inte omforma oss till komponenter i en stor maskin. Dessa vanor stöttar oss där vi som människor är svaga och utnyttjar våra styrkor. Ett exempel på det är att det lätt slinker in slarvfel vid programmering. Genom att programmera i par upptäcks dessa fel snabbt och billigt.

Vi vill få människor att växa genom interaktion med andra. Vi vill bygga tvärfunktionella lag som ständigt blir bättre. Agila lag har alltid full kontroll på systemet som växer fram och hur fort det går, något som möjliggör verklig kontroll hos produktledningen.

7. Agila metoder undviker planering och estimering

Kort svar

Tvärtom, planering och estimering ingår i en agil utvecklares vardag. Det är alldeles för viktigt för att bara göras i början.

Förklaring

Agila metoder menar att planering är viktigt, men att resultatet av planeringen, det vill säga en plan, inte är lika viktigt. Med det menar man att det är viktigare att vi får en gemensam bild av den närmaste framtiden än att vi får en perfekt plan. Planer förväntas ändras. Planer måste reflektera verkligheten så nära som möjligt för att inte bli missvisande. Då verkligheten är föränderlig måste alltså även planer vara det.

Planering är så viktigt att vi inte enbart bör göra det i början av ett större arbete utan även i början av varje iteration, dag och uppgift. Ju kortare tidsperiod desto fler detaljer i planen är lämpligt. I början av ett arbete vet vi som minst och därför är just början den minst lämpliga tiden att planera. Lösningen är alltså att göra en högnivåplan i början och fylla ut med detaljer och anpassningar vartefter.

Eftersom planen förväntas ändras ofta behöver vi då inte lägga ned själ och hjärta på själva formatet av planen utan bygga planer som är synliga och kan ändras av många. Ett antal handskrivna registerkort på en tavla är ur samarbetssynpunkt bättre än det allra finaste ganttschema. Även estimering sker oftare med agila metoder, åtminstone inför varje ny iteration.