Jag tror att första gången jag hörde citatet i titeln var det antingen Jeff Patton eller Jeff Gothelf som yppade det, men det är säkerligen äldre än så.

Jag har egentligen endast jobbat i ett regelrätt vattenfallsprojekt (dvs. hårt strukturerad produktframtagning uppdelad i diskreta enheter) så jag har svårt att uttala mig om hur produktledningsspelet såg ut före den agila rörelsen klev in på banan. Baserat på min lilla erfarenhet, en massa läroböcker samt vetskapen att de flesta tog Winston Royce beskrivning av en trasig modell som en rekommendation, så tänker jag mig att förbättringsarbete pågick inom varje versionsarbete och man lade till funktionalitet för varje funktion. Det som förbättrades var att man eliminerade buggar. Jag tror att fas 2 verkligen fanns, om än bristfälligt.

När bl.a. Agile äntrar banan, en massa år efter Royce essä, ligger fokus på att få till en kontinuerlig feedbackcykel med så kort tid mellan varje steg som möjligt. Detta ger upphov till att det faktiskt kan och får ske förbättring även mellan versioner. Man får en möjlighet att ha en mer kreativ och utforskande process där det är helt okej (nåja) att sikta fel i första versionen för att det går att sikta mer rätt i efterföljande versioner. Man brukar säga att man inte tänkte på UX när det agila manifestet togs fram, men man möjliggjorde ett tätare samarbete mellan designavdelningen och utvecklingsavdelningen som var få förunnat innan dess.

Jag hittade ett par bilder på Internet, som jag inte vet var de kommer ifrån. Den första illustrerar varför man bör iterera.

Men ett antal år senare försvinner fas 2. När de gamla projektledarna inser att de med agil metodik (inte nödvändigtvis med agilt tänk) kan snabbare leverera funktionalitet, blir utvecklingen rent inkrementell. Man bygger på det man tidigare gjort och kallar det förbättring, fastän man egentligen inte rör redan färdigbyggda funktioner om de inte är uppenbart funktionellt trasiga. Om de inte matchar målgruppen eller marknaden, well, då lägger man till fler funktioner för att råda bot på det problemet. Ju snabbare man jobbar i kortare och kortare sprintar, desto mindre hinns det med någon typ av iterativt arbete varken under tiden eller mellan versioner. Man tappar fullkomligt den egentliga styrningen och kreativiteten.

Den andra bilden visar var bristen ligger i det som vanligtvis går under namnet agile, men definitivt inte är det.

Här råder en stor frustration och ilska mellan designers och utvecklare.

Här är vi idag.

Eller rättare sagt igår, för med Lean Startup-metodik i allmänhet och LeanUX i synnerhet, har vi fått ett verktyg som mer matchar agilisternas gamla slagdänga om iterativ och inkrementell utveckling.

Nu gäller det bara att vi lär de gamla projektledarna detta också.

14

6