De vervaging tussen Design Thinking en Agile

Welke is het beste? Welke moet u gebruiken? Wat zijn de verschillen? En waarom is er zoveel discussie over de wazige scheidslijn tussen de twee methoden?

Een recente interne e-mailketen bij IDEO besprak de kwestie van Design Thinking versus Agile bij IDEO.

De vraag: hoe onderscheidt IDEO het Design Thinking-proces van Agile?

Hieronder is mijn antwoord, dat ik hier publiceer voor toekomstige referentie en in de hoop dat het nuttig kan zijn voor anderen.

[het volgende is gekopieerd / geplakt uit onze e-mailthread, met een paar afbeeldingen en links toegevoegd om punten te benadrukken]

"Hallo Greg

Ten eerste, helemaal eens met de gedachten van Juho, Kam en Peter. Bij IDEO Design Thinking leeft in de strategische wereld waar we ontwerpmethoden gebruiken om de juiste vraag te vinden en beginnen deze te beantwoorden. Agile leeft in de softwarewereld waar teams die eenmaal een vraag hebben gesteld, naar een oplossing zoeken.

Het is de moeite waard om in de oorsprongsverhalen voor Design Thinking en Agile te duiken, want hoewel ze vandaag allebei dezelfde uitdagingen aangaan, komen ze uit heel verschillende plaatsen:

Ontwerp bedenken

Design Thinking is de ontkoppeling van Design van elke specifieke toolset (Industrial Design, Architecture, Graphic Design) en erkent dat het proces op elke probleemruimte kan worden toegepast.

Design Thinking is ook synoniem geworden met Human Centered Design; deze link is grotendeels te danken aan het werk van mensen binnen Stanford en IDEO in de late jaren 80 / vroege jaren 90. Ontwerp is in deze context het cyclische proces van het definiëren van een toekomstige status en vervolgens achteruit werken om verbinding te maken met de huidige status (vandaar dat termen als ‘reverse engineering’ en ‘postrationalisatie’ zo vaak voorkomen in het ontwerp).

Dit vooruit en achteruit springen tussen wat mogelijk is, wat gewenst is en wat geld oplevert, is de essentie van ontwerp. Ik gebruik het woord 'springen' hier bewust, ongeacht hoeveel drieweg venn-diagrammen, kronkelige lijnen of metaforen we gebruiken, het is in wezen een mistig proces, waar consensus en vertrouwen alleen naar voren komt door vooruit te springen (prototyping, brainstormen, schetsen) en vervolgens achteruit springen (synthese, verhalen vertellen, rapporteren).

Behendig

Agile is een methodiek voor het ontwikkelen van software en de eigenschappen ervan worden door software zelf gedragen. Voor velen is het het tegengif voor de ontwikkeling van Waterfall (of Engineering zoals het anders bekend is). Het Waterfall / Engineering-proces is volledig geschikt voor de productie van hardware - maar het blijkt bijna helemaal fout te zijn voor software.

Met hardware worden de kosten van wijzigingen steeds duurder naarmate u dichter bij de productie komt; met software, of specifiek objectgeoriënteerde software (eigenlijk alle software sinds de jaren 1970), is de implicatie van veranderende elementen minder kostbaar. Dit wordt verder vergroot door de ‘altijd-aan’ internetverbinding, wat betekent dat updates voor software nu zo vaak naar gebruikers kunnen worden gepusht als de softwareontwikkelaar wenst.

Het Agile Manifesto omarmt dit idee van eeuwigdurende bèta en dat software moet worden ontwikkeld met een continue lus van klantbehoeften die binnenkomen en software die 'goed genoeg' is.

Deze staat van voortdurende verfijning is uiteindelijk hetzelfde als het ontwerpproces van achteruit en vooruit springen. Het enige verschil is dat we met het ontwerp in deze status blijven gedurende de duur van het project, terwijl we in Agile gedurende de levensduur van de software in deze status blijven.

Leunen

Het is ook de moeite waard om over Lean en Lean Startup te praten (wat verschillende dingen zijn).

Lean bouwt voort op Agile.

Waar Agile de autonomie van teams en het continue proces bevordert, benadrukt Lean verder de efficiëntie onderweg (minder verspilling, snel bewegen, zich bewust zijn van het grotere geheel). Dit zijn opnieuw bekende concepten voor ontwerpteams die leiden tot vervaging tussen Lean en Design Thinking.

Lean Startup neemt de methodiek en past deze toe op bouwbedrijven. Het is waar de beruchte Build / Measure / Learn-lus vandaan komt en het leent in wezen softwareparadigma's en gebruikt ze in de zakelijke wereld. Het werkt zo goed omdat:

  1. Alle nieuwe bedrijven zijn softwarebedrijven
    (zie Software Is Eating The World)
  2. en
  3. Softwaretools worden steeds meer gedemocratiseerd. Dit betekent natuurlijk dat ontwerpers toegang hebben tot de tools die voorheen alleen toegankelijk waren voor software-ingenieurs - wat betekent dat softwaremensen, ontwerpmensen en zakenmensen allemaal dezelfde tools gebruiken.

[Dus, om de oorspronkelijke vraag te beantwoorden: hoe onderscheidt IDEO het Design Thinking-proces van Agile?]

Overeenkomsten (tussen Design Thinking en Agile)

  1. Beide processen zoeken input van buiten het team dat het werk doet. Voor ontwerpers zijn dit gebruikersonderzoek, zakelijke behoeften en technologische mogelijkheden. Voor softwareontwikkeling lijkt dit meer op achterstanden, gebruikersverhalen en successtatistieken.
  2. Beide processen omvatten ook iteratie en voortdurende verfijning. Persoonlijk heb ik het gevoel dat design meer te maken heeft met achteruit en vooruit springen waar software de continue loop van ontwikkeling is - maar beide hebben hetzelfde idee van voortdurende verfijning.
  3. Minder voor de hand liggend, maar even belangrijk, is de sterke roep om een ​​gezonde cultuur van empathie en empowerment in het team. Het is opvallend hoe vergelijkbaar de waarden van het Agile Manifest zijn met de waarden van IDEO:

Agile ‘Individuen en interacties over processen en tools’
IDEO ‘Eigenaar worden’

Agile ‘Werk software over uitgebreide documentatie’
IDEO ‘Praten minder, meer doen’

Agile ‘Klantensamenwerking boven contractonderhandelingen’
IDEO ‘Samenwerken’

Agile ‘Reageren op overstappen volgens een plan’
IDEO ‘Embrace Ambiguity / Learn from Failure’

Verschillen (tussen Design Thinking en Agile)

  1. Softwareontwikkeling kent in het algemeen geen ‘synthese’. Vaak zijn de lessen van de laatste iteratie de directe input voor de volgende iteratie. Het is gebruikelijk dat eisen worden verzameld en vervolgens op zijn best worden geprioriteerd voordat het werk begint. Design Thinking is beter in het leren en vervolgens patronen ontdekken om een ​​geïnformeerde sprong naar iets nieuws te maken. Dit mysterieuze syntheseproces is mogelijk unieker voor IDEO dan we ons realiseren.
  2. De erfenis van Design betekent dat we nog steeds vaak denken in termen van projecten met een begin, midden en einde. Agile heeft zeker deze inzetpoorten (alpha, beta, lancering), maar het ontwerpproces heeft misschien deze punten nodig om een ​​coherente output af te dwingen, waarbij softwareontwikkeling mogelijk beter is om op elk moment een oplossing te kunnen inzetten.
  3. Misschien wel het meest interessante verschil is de scheiding van design en software. Hoewel we software gebruiken in onze dagelijkse activiteiten, hebben we een veel breder scala aan tools om de klus te klaren. Van eenvoudige dingen (zoals pennen en papier) tot complexere tools (zoals het Business Model Canvas), ik zou graag denken dat we een grotere gereedschapsgordel hebben dan softwareteams.

Vervaging (tussen Design Thinking en Agile)

  1. Zoals eerder gezegd, is de grootste oorzaak van vervaging misschien het gebruik van software in alle fasen van zowel Agile als Design Thinking. We zitten niet alleen op dezelfde laptops en gebruiken dezelfde software, het is voor niet-technische mensen steeds eenvoudiger om software-engineeringtaken uit te voeren. Net zoals Desktop Publishing Software het voor iedereen mogelijk maakte om het werk van een grafisch ontwerper te doen, betekent softwarekaders dat ontwerpers tegenwoordig zeer geavanceerde software kunnen ontwikkelen. Evenzo ontwerppatronen en bibliotheken zoals Material Design van Google maakt het eenvoudiger voor ontwikkelaars om geavanceerde visuele interfaces te produceren. Het verschil tussen een prototype met hoge resolutie en productieklare code is in sommige gevallen nu nul. Als ik met schaalbare cloudgebaseerde tools zoals AWS bouw, stopt niets de schaal van 10 tot 10.000 gebruikers. (Afgezien van mijn banksaldo ).
  2. Een andere factor in het spel is meer en meer diverse teams. Bij IDEO waarderen we dit overduidelijk, maar bij steeds meer op design gebaseerde bedrijven (zoals Airbnb) is het gebruikelijk om ontwerpteams te vinden met software-ingenieurs en softwareteams met etnografen. Wanneer verschillende teams hun processen samenbrengen, is vervaging onvermijdelijk.
  3. Ten slotte maakt de enorme snelheid van de bovenstaande punten alles een beetje wazig. Amazon implementeert momenteel code ongeveer elke 10 seconden. Dat betekent 60 keer sinds je dit begon te lezen. Stel je voor dat Ford een auto 60 keer in 10 minuten heeft bijgewerkt. (In feite doet Tesla dit al - stel je ze in plaats daarvan voor). Wanneer dit een fundamenteel kenmerk is van het materiaal waarmee we werken, wordt het wazig. "

Nawoord

Aan het einde van mijn oorspronkelijke e-mail werd gevraagd of iemand het zou halen om het te laten weten. Dus ik zal hetzelfde opnieuw vragen, als je het door deze nogal lange situatie hebt gehaald, laat het me dan weten.

Of druk op de -knop.

Dank aan Greg voor het stellen van de vraag, en Sera voor het aanmoedigen van mij om dit te publiceren.

Toekomstige interactie-ontwerper

Voor interactie-ontwerpers die geïnteresseerd zijn in meer artikelen zoals deze en andere inspirerende berichten, publiceer ik elke twee weken een e-mail met 10 artikelen over zaken als agile, lean, AI, schrijven en leiderschap.

Registreer hier.