Söker man på agila utvecklingsmetodiker för team med utvecklare hittar du en uppsjö med förslag (Scrum och Crystal för att nämna några få). Samtliga evangelister argumenterar för sin personliga favorit, och hål i skrovet pekas snabbt ut bland de andra tillvägagångssätten.

Agila utvecklingsmetodiker, som helhet, verkar dock vara en okej approach för utvecklare och designers att mötas i. Ja, i alla fall att döma av vår mentimeter-fråga på vårt UX-meetup som vi hade i Malmö för någon vecka sen, då 28 av 35 deltagare svarade att ”Agilt funkar bra för design”. Dagens modernare organisationer är långt från det industriella vattenfalls-tänket när det kommer till arbetssätt, även om många av oss är medvetna om att de flesta agila arbetssätt egentligen baseras på ett uppdelat vattenfalls-tänk. Svaret på mentimeter-frågan var inte det jag förväntade mig, och jag undrade om det kan vara så att det är möjligt att få till kreativ och innovativ höjd i en effektiv och agil process?  


Kaos är också system 

Det oförutsägbara är avgörande för en kreativ process, men det är svårt att tidsuppskatta. Konsten är att kunna balansera det otydliga experimenterandet med systemets struktur. Många designers är nog mer tränade i att vara rebellen. Vem vet, kanske är det för att de flesta designutbildningar lägger ett stort fokus på att du ska hitta din egen väg att gå. Designers är i grund och botten riktigt bra på att hitta de där hålen i skroven, att nosa rätt på problem som finns här och nu och i framtiden, och att konkretisera dem till utmaningar att hantera. Jakten på problem är tidskrävande, och hela den agila processen är tänkt att först och främst vara effektiv, det vill säga mindre tidskrävande. 

 

Läs också: Designsystem och nödvändiga skavsår


Output och outcome är två nära besläktade begrepp, men väldigt skilda just när det handlar om agila arbetsmetoder och design
som problemlösning. Den agila processen är i grunden teknikstyrd och framtagen för att effektivisera utvecklingsarbetet. När du tar in designers i en allt för teknikstyrd process riskerar du att tappa avgörande delar av designarbetet. Hela teamet riskerar, kort och gott, att bli en Feature Fabrik vars största uppgift är att pusha ut features. Det kan i och för sig vara toppen, men bara om alla dessa features verkligen gör skillnad. Backloggar bockas av, sprintar stängs och allt går på papper enligt plan. Allt det handlar om output, det vill säga att du pushar ut någonting. Designers med sin problemsökande inställning kommer dock först till sin rätt när deras kreativitet används för att lösa faktiska problem med fokus på vad som ska uppnås, dvs outcome. Att få till rätt fokus, balans och styrning i agil utveckling är naturligtvis främst en uppgift för produktägaren, men ofta är det lättare sagt än gjort.  

 

Bevisa att du har rätt 

I den riktiga världen, när det finns en kund, budget och sprintar att förhålla sig till, kan en helt enkelt inte ta för givet att design ska få ta sin tid. Vi måste bevisa vår tes om och om igen, gärna med hjälp av prototyper och mvps. För att komma rätt in i kärnan på utmaningen är det vi designers som ska vara rebellen som ifrågasätter utmaningen på både makro -och mikronivå. Det är först när den rigida processen blir lite generösare och tillåter att ramverket blir lite suddigt i kanterna som det blir som mest rätt och därmed mest effektivt. Kort och gott är det så du får in innovation i Feature Fabriken. Enligt mig, förstås. 

Dela i dina sociala kanaler

Daniel Mair
Daniel MairStrategic Design Lead