Agile vs Design Thinking vs Lean:¿cuál es el "approach" correcto? ó ¿cómo los integro?

victormgonzalez.me

Agile vs. Design Thinking vs. Lean: ¿cuál es el "approach" correcto? ó ¿cómo los integro?

24demayo2017

VíctorM.GonzálezHumanExperienceResearcher,ConsultantandProfessor@ITAM

creado

porVíctorM

.Gon

zález-victor.g

onzalez@

acm.org-licen

ciaCreaMveCo

mmon

sANrib

uMon

-Non

Commercial

victormgonzalez.me

Las organizaciones modernas enfrentan grandes retos para el diseño y la creación de productos digitales

Entre muchos retos, los métodos para la creación de productos

digitales, pareciera ser uno de los más complejos

“Nuestros equipos técnicos están aprendiendo métodos ágiles. Nuestros equipos de producto están aprendiendo lean, nuestros equipos de

diseño están aprendiendo pensamiento de diseño. ¿Cuál es el correcto?” JG

2

El Contexto

victormgonzalez.me 3

El Contexto

AGIL

LEANDESIGNTHINKING

Fuentedelaimagen:hNp://kt.liangtou.com/arMcle/10011817402

victormgonzalez.me

Siguiendo Agile: - Los equipos de ingeniería se enfocan a entregar código libre de errores en ciclos de entrega regulares Siguiendo Lean: - Los equipos de diseño/gestión de producto están interesados en administrar con eficiencia, calidad, y reducción de desperdicios enfocados en experimentos y MVPs Siguiendo Design Thinking: - Los equipos de diseño están abogando por incluir al cliente a través de la validación del problema y las soluciones.

4

El contexto

victormgonzalez.me

Sin embargo ... - Cada disciplina opera a través de un grupo distinto de ceremonias y prácticas y apunta a una idea de éxito que es única para cada una de ellas. - Por ningún lado se ve la colaboración, comprensión y productividad que prometen las tres disciplinas. ¿Cómo pudo pasar esto?

5

El Contexto


Fuente

Lean vs Agile vs Design Thinking: What you really need to know to build high-performing digital product teams Jeff Gothelf Enero 2017 ISBN 1541140036

victormgonzalez.me

■ Breve descripción de: ■ Agile (Scrum) ■ Lean (Startup) ■ Design Thinking (UCD)

■ Prácticas centrales para integración ■ Retos particulares en el contexto LATAM ■ ¿Dónde aprendo más?

7

Agenda

victormgonzalez.me

Agile valoramos la respuesta ante el cambio sobre seguir un plan

8


Agile: enfoque -  Agile nació como respuesta ante la frustración causada

por la incertidumbre

-  “Valoramos más responder al cambio que seguir un plan” Manifiesto Ágil

-  Para lidiar con la incertidumbre: trabajo en ciclos cortos, y pausar al final del ciclo para reflexionar sobre lo logrado/aprendido y los siguientes pasos


Agile: retos -  Velocidad: DevOps y Continous Delivery han elevado la

velocidad con la que el software se pone en las manos de los usuarios

-  Escala: Retos para implementación a gran escala

-  ¿Quién sirve a quién?: Agile asume que las otras disciplinas son apoyo para los ingenieros: esto incluye a los gerentes de producto, diseño, marketing, etc.

victormgonzalez.me

Lean Startup ¿deberíamos construir eso?

11


Lean Startup: enfoque -  Lean Startup postula que cualquier proyecto es un

experimento: -  ¿”Deberíamos” vs “Podemos” construir esto? -  Si deberíamos, entonces: ¿podemos construir un

modelo de negocio sostenible alrededor de esa idea? -  Ciclos cortos son usados para los experimentos donde se

prueba conductas y reacciones de clientes/usuarios. -  ¿Hay evidencia que clientes/usuarios necesitan esa

funcionalidad? ¿Pagarían por ella?


Lean Startup: enfoque -  Un MVP (Minimum Viable Product) sirve para contestar

un par de preguntas: -  1. ¿Qué es lo más importante que debemos aprender

primero acerca de nuestro proyecto? -  2. ¿Cuál es la menor cantidad de trabajo que debemos

hacer para aprender eso? -  Un MVP es es un intento de hacer el menor trabajo

posible antes de comprometerse a construir de manera completa una característica o funcionalidad


Lean Startup: retos -  MVP no es la versión 1.0: “¿cuál es el menor número de

características con las que podemos salir y liberar el producto?”

-  No hay continua experimentación: Cualquier experimentación del tipo que propone Lean Startup es frecuentemente hecha al principio, una sola vez, y entonces tomada como prueba de que el equipo deberá ejecutar el plan como está escrito.

-  Laboratorios de Innovación Aislados: separación del pensamiento creativo de las capacidades de producción.

victormgonzalez.me

Design Thinking ¿estamos resolviendo un problema real, para un cliente real, de una forma significativa?

15


Design Thinking: enfoque -  Design Thinking le enseña a los equipos a tomar una

perspectiva empática del cliente para el cual están construyendo productos de forma tal que se puedan entender las necesidades principales que se están tratando de cubrir

-  A través de una serie de sesiones de tormentas de ideas, el equipo genera un grupo de soluciones que no solamente satisfacen las necesidades pero son tecnológicamente posibles de implementar y viables para el negocio.


Design Thinking: retos -  En el mejor de los casos las sesiones de DT ayudan a los

equipos a construir un lenguaje compartido y un sentido común de propósito para el futuro del proyecto.

-  En el peor de los casos, estas sesiones son percibidas como una pérdida de tiempo que pudo haberse utilizado para escribir código.

-  Sin embargo, la mayoría de los equipos al fallar y no lograr una epifanía durante su primera sesión de lluvia de ideas, raramente emplean las prácticas de Design Thinking durante todo el ciclo de vida del proyecto.

victormgonzalez.me

Entonces, ¿qué proceso es el correcto?

18

victormgonzalez.me

Tu trabajo consiste en identificar y escoger los elementos específicos de cada práctica que se acoplan mejor a tu equipo y a los propósitos del producto y lo que éste intenta comunicar.

19


Practicas centrales de Integración 1.  Trabajo en ciclos cortos 2.  Retrospectivas regulares 3.  Usuarios en el centro de todo 4.  Ir, Observar, Adaptar 5.  Balance entre descubrir y construir 6.  Menos pero más frecuente investigación 7.  Equipo Balanceado 8.  Revisa Incentivos


1. Trabajo en Ciclos Cortos q  El software es complejo e impredecible. q  Para reducir el riesgo, toma pasos pequeños q  Manejar “experimentos en proceso” vs. cambios

permanentes q  Ejemplo: Cada dos sprints, todo el equipo sale a una

excursión, a observar a los consumidores usando su producto. La meta es lograr que los miembros del equipo, quienes no tienen normalmente contacto directo con los consumidores, puedan hacerlo regularmente.


2. Retrospectivas regulares q  Las reuniones de retrospectiva son el corazón de la

mejora continua. q  Mucho equipos que dicen practicar Agile no llevan a

cabo reuniones de retrospectiva de forma regular. q  Al final de cada sprint, alienta a tus equipos a reunirse

por una hora, revisar qué fue lo que funcionó bien durante ese ciclo, qué no funcionó bien, y comprometerse a mejorar una o dos cosas clave cada vez.


3. Usuarios en el centro de todo q  Agile, Lean y Design Thinking proclaman a gran voz la

supremacía del consumidor en todas sus actividades. q  Sin embargo, cada metodología ofrece una definición

diferente con respecto a quién es el usuario. q  El punto central es: si ellos no están usando el

producto entonces ellos no son los usuarios.


3. Usuarios en el centro de todo (cont…) q  Si estás batallando para encontrar alineación en el

equipo para enfocarte en entregar valor al usuario, considera plantear las siguientes preguntas regularmente: o  ¿estamos entregando algo que es importante y de

valor para los usuarios? o  ¿cómo investigamos sobre el valor que damos a los

usuarios? o  ¿cómo ese valor afecta nuestras prioridades?


4. Ir, Observar, Adaptar q  Ir de manera regular a donde se hace el software,

hablar con los equipos, y preguntar cómo van las cosas, que está funcionando bien, y en qué podrían estar estancados.

q  Buscar patrones en prácticas que están dando buenos resultados, independientemente si vienen de Agile, Lean o Design Thinking: amplifícalos y explótalos.

q  No rechaces patrones de prácticas exitosos simplemente porque no encuadran perfectamente con una de las recetas definidas por una metodología.


5. Balance entre Descubrir y Construir q  Frecuentemente, el trabajo de descubrir qué es lo que

debe ser el producto es percibido como una barrera para generar el código de ese producto.

q  Descubrir implica revelar el riesgo: de que un elemento en el backlog carezca de valor para el usuario/negocio

q  Establece prioridad para validar/evaluar basado en el riesgo percibido y en el valor percibido.

q  Los artículos que califican como de alto riesgo y de alto valor son los únicos que deberían ser punto de interés para esfuerzos de descubrimiento del producto.


6. Menos pero más frecuente investigación q  Hacer investigación de usuarios implica que el

propósito indicará la herramienta y el esfuerzo. q  Sin un propósito claro muchos esfuerzos de

investigación son sólo pérdida de tiempo. q  La mejor práctica es hacer menos con más frecuencia:

o  En lugar de probar a doce personas, prueba con tres. o  Toma lo que aprendas de esto, y entonces has la prueba

nuevamente la siguiente semana. o  Reduce costo y compromiso de participar. o  Difunde tus hallazgos ampliamente y de forma inmediata

después de la prueba y muestra el valor del ejercicio.


7. Equipo Balanceado q  Síntoma de problemas: Los equipos, una vez

capacitados, continúan trabajando en silos q  Reconsidera cómo asignas gente a los proyectos. q  La unidad atómica para planeación de cualquier

proyecto es el equipo: En su expresión básica, el equipo se forma con diseñadores, ingenieros de software, y gerentes de producto.

q  Los equipos balanceados escogen las mejores partes de Lean, Agile, y Design Thinking y lo aplican como sea necesario en una estrecha colaboración.


8. Revisa Incentivos q  Los equipos optimizarán el trabajo gracias a incentivos:

o  Si incentivas velocidad, los equipos trabajaran para liberar más funcionalidad por entrega.

o  Si incentivas aprendizaje, los equipos crearán mejores procedimientos para descubrimiento de productos.

q  Si quieres fomentar colaboración y aprendizaje, los empleados deben ser evaluados con respecto a la eficacia de su colaboración y su habilidad para crear oportunidades de aprendizaje continuo en el trabajo.

victormgonzalez.me

En resumen: Al final del día, a tus clientes/usuarios no les importa si practicas agile, lean o design thinking. Lo que les importa son los buenos productos y servicios que de forma efectiva resuelven problemas significativos para ellos

30

victormgonzalez.me

And… One more thing

31


Retos particulares al entorno LATAM a.  Tímidos avances para una orientación de servicio al

cliente y otros cambios a nivel organización b.  Mensaje parcial y poco integrado por las voces de Agile,

Lean, DT c.  Falta establecer roles (Product Manager / Diseñador) d.  Limitadas formas de entrenamiento formal e.  La innovación no es un área: Cultura f.  Diseño de la Organización orientada al Diseño


Conclusión Integrar lo mejor de Agile, Lean y Design Thinking es en sí mismo un proceso de innovación en el que un enfoque a la necesidad, al estado del arte del conocimiento y lo que haga sentido al negocio son nuestros puntos de partida.

victormgonzalez.me

¿Dónde aprendo más?

34

creado

porVíctorM

.Gon

zález-victor.g

onzalez@

acm.org-licen

ciaCreaMveCo

mmon

sANrib

uMon

-Non

Commercial

hNp://www.jeffgothelf.com/

victormgonzalez.me

¿Dónde aprendo más?

35

creado

porVíctorM

.Gon

zález-victor.g

onzalez@

acm.org-licen

ciaCreaMveCo

mmon

sANrib

uMon

-Non

Commercial

hNp://desarrolloejecuMvo.itam.mx/

victormgonzalez.me

Agile vs. Design Thinking vs. Lean: ¿cuál es el "approach" correcto? ó ¿cómo los integro?

VíctorM.GonzálezHumanExperienceResearcher,ConsultantandProfessor@ITAMDatosdecontacto:[email protected]@vmgyghNps://victormgonzalez.me/

creado

porVíctorM

.Gon

zález-victor.g

onzalez@

acm.org-licen

ciaCreaMveCo

mmon

sANrib

uMon

-Non

Commercial