El desenfoque entre Design Thinking y Agile

¿Cuál es el mejor? ¿Cuál deberías usar? ¿Cuáles son las diferencias? ¿Y por qué hay tanta discusión sobre la línea borrosa entre las dos metodologías?

Una cadena de correo electrónico interna reciente en IDEO discutió la cuestión de Design Thinking vs. Agile en IDEO.

La pregunta: ¿cómo diferencia IDEO el proceso de Design Thinking de Agile?

A continuación se muestra mi respuesta, que estoy publicando aquí para referencia futura y con la esperanza de que pueda ser útil para otros.

[lo siguiente es copiado / pegado de nuestro hilo de correo electrónico, con algunas imágenes y enlaces agregados para enfatizar puntos]

"Hola Greg

En primer lugar, totalmente de acuerdo con los pensamientos de Juho, Kam y Peter. En IDEO Design Thinking vive en el mundo estratégico donde usamos métodos de diseño para encontrar la pregunta correcta y comenzar a responderla. Agile vive en el mundo del software, donde una vez que se hace una pregunta, los equipos iteran hacia una solución.

Vale la pena profundizar en las historias de origen de Design Thinking and Agile, ya que, aunque ambos convergen en los mismos desafíos hoy, provienen de lugares muy diferentes:

El pensamiento de diseño

Design Thinking es el desacoplamiento del diseño de cualquier conjunto de herramientas específico (diseño industrial, arquitectura, diseño gráfico) y reconocer que el proceso puede aplicarse a cualquier espacio problemático.

Design Thinking también se ha convertido en sinónimo de Human Centered Design; Este vínculo se debe en gran parte al trabajo de las personas dentro de Stanford e IDEO a fines de los años 80 / principios de los 90. El diseño en este contexto es el proceso cíclico de definir un estado futuro y luego trabajar hacia atrás para conectarse al estado actual (de ahí que los términos como "ingeniería inversa" y "racionalización posterior" sean tan comunes en el diseño).

Este salto hacia adelante y hacia atrás entre lo que es posible, lo que se quiere y lo que hace dinero es la esencia del diseño. Utilizo la palabra 'saltar' aquí deliberadamente, ya que no importa cuántos diagramas de tres vías, líneas onduladas o metáforas usemos, es esencialmente un proceso brumoso, donde el consenso y la confianza solo surgen saltando hacia adelante (creación de prototipos, lluvia de ideas, bocetos) y luego saltando hacia atrás (síntesis, narración de cuentos, informes).

Ágil

Agile es una metodología para desarrollar software, y sus propiedades se basan en el software mismo. Para muchos, es el antídoto para el desarrollo de Cascadas (o Ingeniería como se le conoce). El proceso Waterfall / Engineering es completamente apropiado para la producción de hardware, pero resulta ser casi completamente incorrecto para el software.

Con el hardware, el costo de hacer cambios se vuelve cada vez más caro a medida que te acercas a la producción; con el software, o específicamente el software orientado a objetos (básicamente todo el software desde la década de 1970), la implicación de cambiar elementos es menos costosa. Esto se ve ampliado aún más por la conectividad a Internet "siempre activa", lo que significa que las actualizaciones de software ahora se pueden enviar a los usuarios tan a menudo como lo desee el desarrollador de software.

El Manifiesto Ágil adopta esta noción de beta perpetua y que el software debe desarrollarse con un ciclo continuo de necesidades de los clientes que entran y que sale un software "suficientemente bueno".

Este estado de refinamiento continuo es, en última instancia, el mismo que el proceso de diseño de saltar hacia adelante y hacia atrás. La única diferencia es que con el diseño permanecemos en este estado durante la duración del proyecto, mientras que en Agile permanecemos en este estado durante toda la vida útil del software.

Apoyarse

También vale la pena hablar sobre Lean y Lean Startup (que son cosas diferentes).

Lean se basa en Agile.

Donde Agile promueve la autonomía de los equipos y el proceso continuo, Lean enfatiza aún más la eficiencia en el camino (menos desperdicio, muévase rápidamente, tenga conciencia del panorama general). Estos son conceptos familiares para los equipos de diseño que conducen a un desenfoque entre Lean y Design Thinking.

Lean Startup toma la metodología y la aplica a las empresas de construcción. Es de donde proviene el infame bucle Build / Measure / Learn y esencialmente toma prestados paradigmas de software y los usa en el mundo de los negocios. Funciona muy bien porque:

  1. Todas las nuevas empresas son empresas de software.
    (ver Software está comiendo el mundo)
  2. y
  3. Las herramientas de software están cada vez más democratizadas. Naturalmente, esto significa que los diseñadores tienen acceso a las herramientas que antes solo eran accesibles para los ingenieros de software, lo que significa que las personas de software, de diseño y de negocios están utilizando las mismas herramientas.

[Entonces, para responder la pregunta original: ¿cómo IDEO diferencia el proceso de Design Thinking de Agile?]

Similitudes (entre Design Thinking y Agile)

  1. Ambos procesos buscan aportes de más allá del equipo que hace el trabajo. Para los diseñadores, esto es investigación de usuarios, necesidades comerciales y posibilidades tecnológicas. Para el desarrollo de software, esto se parece más a un retraso, historias de usuarios y métricas de éxito.
  2. Ambos procesos también abarcan la iteración y el refinamiento continuo. Personalmente, creo que el diseño se trata más de saltar hacia adelante y hacia atrás donde el software es el ciclo continuo de desarrollo, pero ambos hablan de la misma noción de refinamiento continuo.
  3. Menos obvio, pero igualmente importante, es el fuerte llamado a una cultura saludable de empatía y empoderamiento en el equipo. Llama la atención lo similares que son los valores del Manifiesto Ágil a los valores de IDEO:

Ágil "Individuos e interacciones sobre procesos y herramientas"
IDEO "Tomar posesión"

Ágil "software de trabajo sobre documentación completa"
IDEO "habla menos, haz más"

Ágil "Colaboración del cliente sobre negociación de contrato"
IDEO "Colaborar"

Ágil "Responder al cambio sobre seguir un plan"
IDEO "Abrace la ambigüedad / Aprenda del fracaso"

Diferencias (entre Design Thinking y Agile)

  1. El desarrollo de software en general no tiene una etapa de "síntesis". A menudo, los aprendizajes de la última iteración son la entrada directa para la siguiente iteración. Es común que los requisitos se recopilen y luego, en el mejor de los casos, se prioricen antes de que comience el trabajo. Design Thinking es mejor para aprender y luego detectar patrones para dar un salto informado a algo nuevo. Este misterioso proceso de síntesis es posiblemente más exclusivo de IDEO de lo que creemos.
  2. El legado del diseño significa que todavía pensamos a menudo en términos de proyectos con un comienzo, un medio y un final. Agile definitivamente tiene estas puertas de implementación (alfa, beta, lanzamiento), pero el proceso de diseño tal vez necesite estos puntos para forzar una salida coherente, donde el desarrollo de software posiblemente sea mejor para poder implementar una solución en cualquier momento.
  3. Quizás la diferencia más interesante es la separación del diseño del software. Si bien utilizamos software en nuestras actividades diarias, tenemos una gama mucho más amplia de herramientas para hacer el trabajo. Desde cosas simples (como bolígrafos y papel) hasta herramientas más complejas (como Business Model Canvas), me gustaría pensar que tenemos un cinturón de herramientas más grande que los equipos de software.

Borroso (entre Design Thinking y Agile)

  1. Según mi punto anterior, quizás la mayor causa de desenfoque es el uso de software en todas las etapas de pensamiento ágil y de diseño. No solo nos sentamos en las mismas computadoras portátiles y usamos el mismo software, es cada vez más fácil para las personas no técnicas realizar tareas de ingeniería de software. Al igual que el software Desktop Publishing hizo posible que cualquiera pudiera hacer el trabajo de un diseñador gráfico, los marcos de software significan que los diseñadores de hoy pueden desarrollar software muy avanzado. Igualmente, diseñar patrones y bibliotecas como el Diseño de materiales de Google facilita a los desarrolladores la producción de interfaces visuales avanzadas. La diferencia entre un prototipo de alta resolución y un código listo para producción es, en algunos casos, ahora cero. Si construyo con herramientas escalables basadas en la nube como AWS, no hay nada que detenga la escala de 10 usuarios a 10,000. (Aparte de mi saldo bancario ).
  2. Otro factor en juego son los equipos cada vez más diversos. En IDEO, obviamente, valoramos esto altamente, pero con más y más compañías fundadas en diseño (como Airbnb) es común encontrar equipos de diseño con ingenieros de software y equipos de software con etnógrafos. Cuando diversos equipos combinan sus procesos, el desenfoque es inevitable.
  3. Finalmente, la gran velocidad de los puntos anteriores hace que todo se vea un poco borroso. Amazon actualmente implementa el código aproximadamente cada 10 segundos. Lo que significa 60 veces desde que comenzaste a leer esto. Imagínese si Ford actualiza un automóvil 60 veces en 10 minutos. (De hecho, Tesla ya está haciendo esto, así que imagínelos en su lugar). Cuando esta es una característica fundamental del material con el que estamos trabajando, las cosas se volverán borrosas ".

Epílogo

El final de mi correo electrónico original pedía que si alguien llegaba al final, me avisara. Así que volveré a preguntar lo mismo, si lograste atravesar esta diatriba bastante larga, avísame.

O simplemente presiona el botón .

Gracias a Greg por hacer la pregunta y a Sera por animarme a publicar esto.

Diseñador de interacción futura

Para cualquier diseñador de interacción interesado en más artículos como este y otras publicaciones inspiradoras, publico un correo electrónico quincenal con 10 artículos sobre cosas como ágil, ligero, inteligencia artificial, escritura y liderazgo.

Registrate aquí.