Uklarheden mellem Design Thinking og Agile

Hvilken er bedst? Hvilken skal du bruge? Hvad er forskellene? Og hvorfor er der så meget diskussion om den uskarpe linje mellem de to metoder?

En nylig intern e-mail-kæde hos IDEO drøftede spørgsmålet om Design Thinking vs. Agile hos IDEO.

Spørgsmålet: hvordan adskiller IDEO designtænkningsprocessen fra Agile?

Nedenfor er mit svar, som jeg offentliggør her til fremtidig reference og med håb om, at det kan være nyttigt for andre.

[det følgende kopieres / indsættes fra vores e-mail-tråd, med et par billeder og links tilføjet for at understrege punkter]

”Hej Greg

For det første er jeg helt enig med Juho, Kam og Peters tanker. Hos IDEO Design Thinking lever i den strategiske verden, hvor vi bruger designmetoder til at finde det rigtige spørgsmål og begynde at besvare det. Agile er liv i softwareverdenen, hvor holdene, når de først stilles et spørgsmål, gentager sig mod en løsning.

Det er værd at grave i oprindelseshistorierne for Design Tænkning og Agile, da selvom de begge konvergerer over de samme udfordringer i dag, kommer de fra ganske forskellige steder:

Designtænkning

Designtænkning er afkoblingen af ​​design fra ethvert specifikt værktøjssæt (Industriel design, arkitektur, grafisk design) og anerkender, at processen kan anvendes til ethvert problemrum.

Designtænkning er også blevet synonymt med Human Centered Design; dette link skyldes stort set arbejdet for mennesker i Stanford og IDEO i slutningen af ​​80'erne / begyndelsen af ​​90'erne. Design i denne sammenhæng er den cykliske proces med at definere en fremtidig tilstand og derefter arbejde baglæns for at oprette forbindelse til den aktuelle tilstand (derfor hvorfor udtryk som 'reverse engineering' og 'post rationalisering' er så almindelige i design).

Dette hopper frem og tilbage mellem hvad der er muligt, hvad der er ønsket og hvad der tjener penge er essensen af ​​design. Jeg bruger ordet 'hoppe' her bevidst, uanset hvor mange tre-vejs venndiagrammer, knuste linjer eller metaforer, vi bruger, er det hovedsageligt en tåget proces, hvor konsensus og tillid kun fremkommer ved at hoppe frem (prototype, brainstorming, skitsering) og derefter hoppe bagud (syntese, historiefortælling, rapportering).

Adræt

Agile er en metode til udvikling af software, og dens egenskaber bæres af selve softwaren. For mange er det modgift mod vandfaldsudvikling (eller teknik, som det ellers er kendt). Vandfald / Engineering-processen er helt passende til produktion af hardware - men det viser sig at være næsten helt forkert for software.

Med hardware bliver omkostningerne ved at foretage ændringer stadig dyre, når du bevæger dig tættere på produktionen; med software eller specifikt objektorienteret software (stort set al software siden 1970'erne) er implikationen af ​​skiftende elementer mindre omkostningskrævende. Dette forstørres yderligere med 'altid-på' internetforbindelse, hvilket betyder, at opdateringer til software nu kan skubbes til brugere, så ofte som softwareudvikleren ønsker det.

Agile Manifesto omfavner denne opfattelse af evigvarende beta, og at software skal udvikles med en kontinuerlig løkke af kundebehov, der går ind og 'god nok' software kommer ud.

Denne tilstand af kontinuerlig forfining er i sidste ende den samme som designens proces med at hoppe bagud og fremad. Den eneste forskel er, at vi med design forbliver i denne tilstand i projektets varighed, mens vi i Agile forbliver i denne tilstand i softwarens levetid.

Læne

Det er også værd at tale om Lean and Lean Startup (som er forskellige ting).

Lean bygger på Agile.

Hvor Agile fremmer autonomi for teams og kontinuerlig proces, understreger Lean yderligere effektivitet undervejs (mindre spild, bevæg dig hurtigt, har opmærksomhed om det større billede). Dette er igen kendte koncepter for designteam, som fører til sløring mellem Lean og Design Thinking.

Lean Startup tager metoden og anvender den til bygningsfirmaer. Det er her den berygtede Build / measure / Learn loop kommer fra, og den låner i det væsentlige softwareparadigmer og bruger dem i forretningsverdenen. Det fungerer så godt, fordi:

  1. Alle nye virksomheder er softwarevirksomheder
    (se Software spiser verden)
  2. og
  3. Softwareværktøjer demokratiseres i stigende grad. Naturligvis betyder det, at designere har adgang til de forudgående værktøjer, der kun er tilgængelige for softwareingeniører - hvilket betyder, at softwarepersoner, designfolk og forretningsfolk alle bruger de samme værktøjer.

[Så for at besvare det originale spørgsmål: hvordan adskiller IDEO designtænkningsprocessen fra Agile?]

Ligheder (mellem designtænkning og smidig)

  1. Begge processer søger input fra uden for det team, der udfører arbejdet. For designere er dette brugerundersøgelser, forretningsbehov og teknologimuligheder. Til softwareudvikling ligner dette mere efterslæb, brugerhistorier og succesmålinger.
  2. Begge processer omfatter også iteration og løbende forfining. Jeg personligt føler, at design handler mere om at springe baglæns og fremad, hvor software er den kontinuerlige løkken af ​​udvikling - men begge taler til den samme opfattelse af løbende forbedring.
  3. Mindre indlysende, men lige så vigtige, er den stærke opfordring til en sund kultur for empati og empowerment i teamet. Det er slående, hvor længe Agile Manifestos værdier er som IDEOs værdier:

Agile 'Enkeltpersoner og interaktioner mellem processer og værktøjer'
IDEO 'Tag ejerskab'

Agile 'Working software over omfattende dokumentation'
IDEO 'Tal mindre, gør mere'

Agile 'Kundesamarbejde om kontraktforhandling'
IDEO 'Samarbejd'

Agile 'Reagerer på at ændre sig efter en plan'
IDEO 'Omfavne tvetydighed / Lær af fiasko'

Forskelle (mellem designtænkning og smidig)

  1. Softwareudvikling har generelt ikke en 'syntese' fase. Ofte er læring fra den sidste iteration det direkte input til den næste iteration. Det er almindeligt, at krav indsamles og derefter i bedste fald prioriteres, inden arbejdet påbegyndes. Designtænkning er bedre til at tage læring og derefter opdage mønstre for at give et informeret spring til noget nyt. Denne mystiske synteseproces er muligvis mere unik for IDEO, end vi er klar over.
  2. Arven fra Design betyder, at vi stadig ofte tænker med hensyn til projekter med en begyndelse, midten og slutning. Agile har bestemt disse sceneporte til implementering (alfa, beta, lancering), men designprocessen har måske brug for disse punkter for at tvinge en sammenhængende output, hvor softwareudvikling muligvis er bedre til at kunne implementere en løsning på ethvert tidspunkt.
  3. Den måske mest interessante forskel er designens adskillelse fra software. Mens vi bruger software i vores daglige aktiviteter, har vi en meget bredere vifte af værktøjer til at få arbejdet gjort. Fra enkle ting (som kuglepenne og papir) til mere komplekse værktøjer (som Business Model Canvas), vil jeg gerne tro, at vi har et større værktøjsbælte end softwareteam.

Sløring (mellem designtænkning og smidig)

  1. I henhold til mit tidligere punkt er den største årsag til sløring måske brugen af ​​software i alle faser af både Agile og Design Thinking. Vi sidder ikke kun på de samme bærbare computere og bruger den samme software, det er stadig lettere for ikke-tekniske personer at udføre software-engineeringopgaver. Meget ligesom Desktop Publishing Software gjorde det muligt for enhver at udføre jobbet som en grafisk designer, betyder software-rammer, at designere i dag kan udvikle meget avanceret software. Lignende designmønstre og biblioteker som Googles Materialedesign gør det lettere for udviklere at fremstille avancerede visuelle grænseflader. Forskellen mellem en høj opløsningsprototype og produktionsklar kode er i nogle tilfælde nu nul. Hvis jeg bygger med skalerbare skybaserede værktøjer som AWS, er der intet, der forhindrer skalaen fra 10 brugere til 10.000. (Bortset fra min banksaldo ).
  2. En anden faktor ved spillet er mere og mere forskellige hold. Hos IDEO værdsætter vi åbenlyst dette meget, men med flere og flere designbaserede virksomheder (som f.eks. Airbnb) er det almindeligt at finde designteam med softwareingeniører og softwareteam med etnografer. Når forskellige hold bringer deres processer sammen, er sløring uundgåeligt.
  3. Endelig får den rene hastighed på ovenstående punkter alt til at se lidt sløret ud. Amazon udsætter i øjeblikket kode omtrent hvert 10. sekund. Hvilket betyder 60 gange, siden du begyndte at læse dette. Forestil dig, at hvis Ford opdaterede en bil 60 gange på 10 minutter. (Faktisk gør Tesla allerede dette - så forestil dig dem i stedet). Når dette er et grundlæggende træk ved det materiale, vi arbejder med, vil det blive sløret. ”

epilog

I slutningen af ​​min originale e-mail blev det bedt om, at hvis nogen gjorde det til slutningen, ville jeg vide det. Så jeg vil spørge det samme igen, hvis du har gjort det gennem denne temmelig lange diatribe, så fortæl mig det.

Eller bare tryk på knappen .

Tak til Greg for at have stillet spørgsmålet, og Sera for at have opmuntret mig til at offentliggøre dette.

Fremtidig interaktionsdesigner

For alle interaktionsdesignere, der er interesseret i flere artikler som denne og andre inspirerende indlæg, udgiver jeg en hver uges e-mail med 10 artikler om ting som agile, lean, AI, skrift og lederskab.

Tilmeld dig her.