{"id":13365,"date":"2017-11-06T11:09:33","date_gmt":"2017-11-06T11:09:33","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=13365"},"modified":"2020-09-03T12:41:59","modified_gmt":"2020-09-03T11:41:59","slug":"blurring-design-thinking-agile","status":"publish","type":"post","link":"https:\/\/shopjessicabuckley.com\/blog\/blurring-design-thinking-agile\/","title":{"rendered":"The Blurring Between Design Thinking and\u00a0Agile"},"content":{"rendered":"

A recent internal email chain at IDEO discussed the question of Design Thinking vs. Agile at IDEO.<\/p>\n

The question: how does IDEO differentiate the Design Thinking process from Agile?<\/em><\/p>\n

Below is my response, which I\u2019m publishing here for future reference and with the hope that it might be useful for others.(The following is copy\/pasted from our email thread, with a few images and links added to emphasise point).<\/p>\n

Hi Greg,<\/p>\n

Firstly, totally agree with Juho<\/a>, Kam<\/a> and Peter<\/a>\u2019s thoughts. At IDEO Design Thinking lives in the strategic world where we use design methods to find the right question and begin to answer it. Agile is lives in the software world where once a question is asked teams iterate toward a solution.<\/p>\n

It\u2019s worth digging into the origin stories<\/a> for Design Thinking and Agile as, although they are both converging on the same challenges today, they come from quite different places:<\/em><\/p>\n

Design Thinking<\/h2>\n

Design Thinking is the decoupling of Design<\/em> from any specific toolset (Industrial Design, Architecture, Graphic Design) and recognising that the process can be applied to any problem space.<\/p>\n

Design Thinking has also become synonymous with Human Centred Design; this link is largely due to the work of people inside Stanford and IDEO in the late 80s \/ early 90s. Design in this context is the cyclical process of defining a future state and then working backwards to connect to the current state (hence why terms like \u2018reverse engineering\u2019 and \u2018post rationalisation\u2019 are so common in design).<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

This jumping forwards<\/strong> and backwards<\/strong> between what\u2019s possible<\/em>, what\u2019s wanted<\/em>, and what makes money<\/em> is the essence of design. I use the word \u2018jumping\u2019 here deliberately as no matter how many three-way venn diagrams<\/a>, squiggly lines<\/a> or metaphors<\/a> we use it\u2019s essentially a foggy<\/a> process, where consensus and confidence only emerges by jumping forward (prototyping<\/a>, brainstorming<\/a>, sketching<\/a>) and then jumping backward (synthesis<\/a>, storytelling<\/a>, reporting<\/a>).<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

Agile<\/h2>\n

Agile is a methodology for developing software, and its properties are borne of software itself. To many it\u2019s the antidote to Waterfall development (or Engineering<\/em> as it\u2019s otherwise known). The Waterfall \/ Engineering process is entirely appropriate for the production of hardware \u2014 but it turns out to be almost entirely wrong for software.<\/p>\n

With hardware, the cost of making changes becomes increasingly expensive as a you move closer towards production; with software, or specifically object oriented software (basically all software since the 1970s) the implication of changing elements is less costly. This is further magnified by \u2018always-on\u2019 internet connectivity which means that updates to software can now be pushed to users as often as the software developer desires.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

The Agile Manifesto<\/a> embraces this notion of perpetual beta and that software should be developed with a continuous loop of customer needs going in and \u2018good enough\u2019 software coming out.<\/p>\n

This state of continuous refinement is ultimately the same as design\u2019s process of jumping backward and forward. The only difference is that with design we stay in this state for the duration of the project<\/strong>, whereas in Agile we stay in this state for the lifetime of the software<\/strong>.<\/p>\n

Lean<\/h2>\n

Its also worth talking about Lean<\/a> and Lean Startup<\/a> (which are different things).<\/p>\n

Lean builds on Agile.<\/p>\n

Where Agile promotes autonomy of teams and continuous process, Lean further emphasises efficiency along the way (less waste, move quickly, have awareness of the bigger picture). These are again familiar concepts for design teams which leads to blurring between Lean and Design Thinking.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

Lean Startup takes the methodology and applies it to building companies. It\u2019s where the infamous Build\/Measure\/Learn<\/a> loop comes from and it essentially borrows software paradigms and uses them in the world of business. It works so well because:<\/p>\n

    \n
  1. All new businesses are software businesses\u00a0
    (see     Software Is Eating The World<\/a>)<\/li>\n
  2. Software tools are increasingly democratised. Naturally this means that designers have access to the tools previous only accessible to software engineers \u2014 which is means that software people, design people and business people are all using the same tools.<\/li>\n<\/ol>\n

    (So, to answer the original question: how does IDEO differentiate the Design Thinking process from Agile?<\/strong>)<\/p>\n

    Similarities (between Design Thinking and\u00a0Agile)<\/h2>\n
      \n
    1. Both process seek input from beyond the team doing the work. For designers this is user research, business needs and technology possibilities. For software development this looks more like a backlogs, user stories and success metrics.<\/li>\n
    2. Both processes also embrace iteration and ongoing refinement. I personally feel that design is more about jumping backwards and forwards where software is the continuous loop of development \u2014but both talk to the same notion of ongoing refinement<\/em>.<\/li>\n
    3. Less obvious, but equally important, is the strong call for a healthy culture of empathy and empowerment in the team. It\u2019s striking how similar the Agile Manifesto\u2019s values are to IDEO\u2019s values<\/a>:<\/li>\n<\/ol>\n

      Agile<\/strong> \u2018Individuals and interactions over processes and tools\u2019
      IDEO<\/strong> \u2018Take ownership\u2019<\/p>\n

      Agile<\/strong> \u2018Working software over comprehensive documentation\u2019
      IDEO<\/strong> \u2018Talk Less, do more\u2019<\/p>\n

      Agile<\/strong> \u2018Customer collaboration over contract negotiation\u2019
      IDEO<\/strong> \u2018Collaborate\u2019<\/p>\n

      Agile<\/strong> \u2018Responding to change over following a plan\u2019
      IDEO<\/strong> \u2018Embrace Ambiguity \/ Learn from Failure\u2019<\/p>\n

      \"\"<\/a><\/p>\n

      <\/p>\n

      Differences (between Design Thinking and\u00a0Agile)<\/h2>\n
        \n
      1. Software development in general doesn\u2019t have a \u2018synthesis\u2019 stage. Often the learnings from the last<\/em> iteration are the direct input for the next<\/em> iteration. It\u2019s common for requirements to be collected and then, at best, prioritised<\/strong> before work commences. Design Thinking is better at taking learnings and then spotting patterns to make an informed leap<\/strong> to something new. This mysterious process of synthesis is possibly more unique to IDEO than we realise.<\/li>\n
      2. The legacy of Design means that we still often think in terms of projects with a beginning, middle and end. Agile definitely has these stage gates of deployment (alpha, beta, launch) but the design process perhaps needs these points to force a coherent output, where software development is possibly better at being able to deploy a solution at any point in time.<\/li>\n
      3. Perhaps the most interesting difference is design\u2019s separation<\/em> from software. While we use software in our day-to-day activities we have a much broader range of tools to get the job done. From simple things (like pens and paper) to more complex tools (like the Business Model Canvas<\/a>), I\u2019d like to think we have a bigger tool-belt than software teams.<\/li>\n<\/ol>\n

        Blurring (between Design Thinking and\u00a0Agile)<\/h2>\n
          \n
        1. As per my previous point, perhaps the biggest cause of blurring is the use of software in all stages of both Agile and Design Thinking. Not only do we sit at the same laptops and use the same software, it\u2019s increasingly easy for non-technical people to carry out software engineering tasks. Much like Desktop Publishing Software<\/a> made it possible for anyone to do the job of a graphic designer, software frameworks means that designers today can develop very advanced software. Equally design patterns and libraries like Google\u2019s Material Design<\/a> makes it easier for developers to produce advanced visual interfaces. The difference between a high resolution prototype and production ready code is, in some cases, now zero. If I build with scaleable cloud based tools like AWS there\u2019s nothing stopping the scale from 10 users to 10,000. (Apart from my bank balance ? ).<\/li>\n
        2. Another factor at play is more and more diverse teams. At IDEO we obvious value this highly, but with more and more design founded companies (such as Airbnb<\/a>) it\u2019s common to find design teams<\/strong> with software engineers and software teams<\/strong> with ethnographers. When diverse teams bring their processes together blurring is inevitable.<\/li>\n
        3. Finally, The sheer speed of the points above makes everything look a little blurry. Amazon currently deploys code roughly every 10 seconds<\/a>. Which means 60 times since you started reading this. Imagine if Ford updated a car 60 times in 10 minutes. (In fact, Tesla is already doing this \u2014 so imagine them instead). When this is a fundamental characteristic of the material we\u2019re working with things will get blurry.\u201d<\/li>\n<\/ol>\n

          Epilogue<\/h2>\n

          The end of my original email asked that if anyone made it to the end, to let me know. So I\u2019ll ask the same again, if you made it through this rather lengthy diatribe, please let me know.<\/p>\n

          This article was originally published on Matt's Medium page<\/a>.<\/em> <\/p>\n","protected":false},"excerpt":{"rendered":"

          A recent internal email chain at IDEO discussed the question of Design Thinking vs. Agile at IDEO. The question: how does IDEO differentiate the Design Thinking process from Agile? Below is my response, which I\u2019m publishing here for future reference and with the hope that it might be useful for others.(The following is copy\/pasted from our email thread, with a… Read More ￫<\/a><\/p>\n","protected":false},"author":182,"featured_media":13381,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[485],"tags":[],"class_list":["post-13365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-design-thinking"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n