Design thinking vs lean vs agile vs design sprint: cuál y cuándo

Elige design thinking cuando todavía no entiendes el problema. Elige lean startup cuando tienes una idea y necesitas averiguar, con poco coste, si funciona. Elige agile cuando sabes qué construir y necesitas entregarlo en piezas que funcionen. Elige un design sprint cuando un problema claro e importante necesita una respuesta probada en una semana. No son rivales: cada uno responde a una pregunta distinta, y la mayoría de los proyectos reales usan más de uno, uno detrás de otro.

La confusión viene de que los cuatro hablan de usuarios, iteración y aprendizaje. La diferencia está en lo que cada uno da por sabido al empezar. Para la cuestión más amplia de qué herramienta concreta usar, consulta ¿qué herramienta de innovación usar?.

De dónde viene cada uno

Un poco de historia ayuda, porque cada enfoque sigue cargando con el problema para el que se creó.

• El design thinking nació de la práctica del diseño y se popularizó como enfoque general de resolución de problemas gracias a la consultora de diseño IDEO y a la d.school de Stanford (el Hasso Plattner Institute of Design, fundado en 2005). El Double Diamond del Design Council británico, creado en 2003, describe una forma parecida. Se pensó para problemas en los que la propia necesidad no está clara.
• El lean startup lo formuló Eric Ries en su libro de 2011 The Lean Startup (en español, El método Lean Startup), a partir del desarrollo de clientes de Steve Blank y de la producción lean. Se pensó para fundadores que corren el riesgo de pasarse años construyendo algo que nadie quiere.
• Agile se remonta al Manifiesto por el Desarrollo Ágil de Software, redactado por 17 profesionales del software en Snowbird (Utah) en febrero de 2001. Scrum, creado por Ken Schwaber y Jeff Sutherland, es su marco más conocido. Se pensó para proyectos de software que fracasaban con planes largos y cerrados.
• El design sprint lo desarrolló Jake Knapp en Google y Google Ventures, y lo describieron Knapp, John Zeratsky y Braden Kowitz en el libro Sprint de 2016. Se pensó para llevar a un equipo de una pregunta difícil a un prototipo probado en cinco días.

Lado a lado

Cuándo encaja cada uno

Design thinking, cuando el problema no está claro

Distintas personas describen el problema de maneras distintas. Hay quejas, pero nadie sabe decir qué las causa. Se necesita un servicio nuevo para un grupo al que nunca se ha estudiado. En estos casos, empezar por las ideas o por la ejecución se salta el trabajo más valioso. Empieza con entrevistas a partes interesadas y cierra el encuadre con un enunciado de punto de vista y preguntas ¿Cómo podríamos?. El proceso completo está en design thinking paso a paso.

No lo uses cuando el problema se entiende bien y la organización necesita ejecución. Abrir una fase de descubrimiento sobre un problema que todos entienden pone a prueba la paciencia, no las ideas.

Lean startup, cuando tienes una idea y el riesgo es que nadie la quiera

Tienes un concepto, un patrocinador y cierto entusiasmo, pero ninguna evidencia de que la gente vaya a usarlo, pagarlo o cambiar su comportamiento por él. El pensamiento lean pide identificar el supuesto más arriesgado con un mapa de supuestos, formular una prueba de hipótesis y hacer el experimento más pequeño que podría demostrar que estás equivocado, como un test concierge. Más en cómo probar una idea antes de construirla.

Flojea cuando el propio problema no está claro (pondrás a prueba respuestas a la pregunta equivocada) y en servicios en los que no se pueden hacer experimentos con el público, por motivos éticos o legales, sin mucho cuidado. En la Administración, muchos experimentos requieren una conversación sobre consentimiento y riesgo distinta de la de una startup.

Agile, cuando sabes qué construir

El concepto está validado y el trabajo es sobre todo de ejecución: construir el sistema, el proceso, el servicio. Agile divide el trabajo en incrementos pequeños, redactados como historias de usuario, entrega piezas que funcionan en ciclos cortos y se ajusta mediante retrospectivas periódicas.

Agile no te dice qué construir. Los equipos que lo usan para descubrir suelen acabar entregando muy rápido funcionalidades que nadie necesitaba. Además encaja mal cuando los contratos, las compras o la regulación fijan el alcance de antemano, salvo que se hayan planteado para admitir cambios.

Design sprint, cuando una pregunta importante necesita respuesta esta semana

Un design sprint encaja cuando el reto está definido, lo que está en juego justifica cinco días de agenda de quien decide y el equipo está atascado entre opciones. La estructura clásica: el lunes se mapea el problema y se elige un objetivo; el martes, cada persona boceta soluciones por su cuenta; el miércoles se decide y se hace el storyboard; el jueves se construye un prototipo realista; el viernes se prueba con cinco usuarios.

Encaja mal cuando nadie ha investigado a los usuarios (el sprint se apoyará en supuestos), cuando quien decide no puede asistir o cuando el problema es demasiado grande para prototiparlo en un día.

Cómo combinarlos: la secuencia habitual

Los enfoques funcionan mejor en un orden que sigue a la incertidumbre.

1. Design thinking para comprender y encuadrar. Investigación y un enunciado del problema validado.
2. Un design sprint para converger. La investigación hace que el lunes del sprint sea más rápido y esté mejor fundamentado, y se sale con un concepto probado.
3. Experimentos lean para reducir el riesgo. Se prueban los supuestos que el sprint no resolvió, por ejemplo si la gente seguirá usando el servicio después de la primera semana.
4. Agile para ejecutar. Se construye y se lanza por incrementos, y se sigue probando con usuarios sobre la marcha.

No todos los proyectos necesitan los cuatro. Una pequeña mejora de un proceso interno puede requerir una semana de descubrimiento y luego ejecución. Un producto digital nuevo puede saltar directamente a un sprint si la investigación ya existe. La regla práctica: identifica tu mayor incógnita y usa el enfoque pensado para ella.

Un ejemplo práctico

Ilustrativo. Un operador postal nacional de un país europeo de tamaño medio quiere ofrecer un servicio para pequeños vendedores online.

Design thinking (seis semanas). El equipo entrevista a veinte vendedores y observa a varios de ellos mientras preparan pedidos. El problema esperado era el coste del franqueo. El real: los vendedores pierden horas cada semana gestionando devoluciones, porque los compradores imprimen mal las etiquetas y los paquetes vuelven sin identificar. Se valida el enunciado del problema: «¿Cómo podríamos hacer que las devoluciones no cuesten ningún esfuerzo a los vendedores con menos de cincuenta pedidos a la semana?».

Design sprint (cinco días). Con el responsable de paquetería en la sala el lunes y el miércoles, el equipo boceta, elige y prototipa un código de devolución que el comprador enseña en el mostrador, sin imprimir nada. Cinco vendedores lo prueban el viernes. Cuatro lo quieren, y los cinco preguntan si funciona con su marketplace.

Experimento lean (cuatro semanas). El supuesto más arriesgado que queda es que el personal de mostrador pueda procesar los códigos sin ralentizar la cola. El equipo pone en marcha una versión concierge en tres oficinas, con el personal gestionando los códigos a mano a partir de una lista impresa. Los tiempos de espera se mantienen estables.

Ejecución agile (continua). Un equipo de desarrollo construye el sistema real en sprints de dos semanas, empezando por la integración con un marketplace y el paso de escaneo en mostrador, y prueba cada versión con vendedores.

Cada enfoque hizo el trabajo para el que se creó. Empezar con agile habría producido una herramienta rápida de descuentos en el franqueo. Empezar con un sprint habría pasado por alto por completo el problema de las devoluciones.

Qué hacer y qué evitar

Qué hacer

• Nombrar primero la mayor incógnita y después elegir el enfoque pensado para ella.
• Alimentar los design sprints con investigación. Un sprint construido sobre conocimiento real de los usuarios es mucho más sólido que uno basado en conjeturas.
• Seguir probando con usuarios una vez arranca la ejecución agile.
• Acordar desde el principio quién se encarga del traspaso entre etapas, sobre todo del sprint a la ejecución.

Qué evitar

• Tratar los cuatro como marcas rivales o preguntar cuál es «el mejor». Es como preguntar si un mapa es mejor que un martillo.
• Usar agile para descubrir. Los ciclos cortos de entrega no sustituyen a entender el problema.
• Hacer un design sprint sin quien decide. Tendrás un buen prototipo y ninguna decisión.
• Llamar design sprint a cualquier taller. Cinco días con la estructura definida es una cosa; una sesión de ideación de dos horas, otra.
• Dejar que cada enfoque viva en un departamento distinto con su propio vocabulario. En los traspasos es donde se pierde el aprendizaje.

Preguntas frecuentes

¿Un design sprint es lo mismo que design thinking? No. Un design sprint es un proceso fijo de cinco días que usa varias herramientas de design thinking para responder a una pregunta definida. El design thinking es el enfoque más amplio, y su trabajo de descubrimiento suele ir antes de un sprint.

¿Pueden funcionar juntos el design thinking y agile? Sí, y deberían. El design thinking averigua qué construir y para quién; agile lo construye por incrementos. El patrón habitual es un periodo de descubrimiento seguido de una ejecución agile que mantiene un ritmo regular de pruebas con usuarios.

¿Cuál es mejor para proyectos de la Administración pública? Depende de la incógnita. El design thinking va bien en servicios donde las necesidades de la ciudadanía no están claras; agile, en la ejecución digital una vez que lo están; los experimentos lean exigen un cuidado especial con el consentimiento y el riesgo cuando interviene el público. Muchos estándares de servicios digitales públicos combinan el descubrimiento con la ejecución agile.

Por dónde seguir

Para el descubrimiento, empieza con las entrevistas a partes interesadas. Para reducir el riesgo de una idea, usa el mapa de supuestos. Para el día del prototipo del sprint, consulta prototipo en papel y, para la ejecución, historias de usuario. Todas las guías de método están en el índice de guías.