# Lean vs Agile vs Design Thinking  ## Metadata - Author: [[Jeff Gothelf]] - Full Title: Lean vs Agile vs Design Thinking - Category: #books ## Highlights - Desde la perspectiva del cliente, el equipo de ingeniería se enfocaba en entregar un código libre de errores en ciclos de entrega regulares. Muchos llaman a estos ciclos «sprints), aunque el término «Agile release train» ha aumentado en uso con la creciente popularidad de SAFE-Scaled Agile Framework. (Page 4) - Los Product Managers estaban más interesados en administrar con eficiencia, calidad, y reducción de desperdicios a través de la priorización táctica del Backlog y técnicas de grooming. Las razones detrás de esas prácticas surgen del pensamiento Lean pero en la práctica tienen poco que ver con éste. (Page 5) - El equipo de UX buscaba incluir lo más posible al usuario final a través de la validación del problema-solución con actividades de Design Thinking. Estas se percibían como ejercicios laboriosos de investigación y diseño que sólo retrasaban el lanzamiento del producto. (Page 5) - Tags: [[favorite]] - El problema, los PMs optimizaban los backlogs basados en sus instintos y las preferencias subjetivas de los stakeholders. Ademas sin un entendimiento del cliente, los ingenieros se enfocaban en simplemente entregar características funcionales-mientras más, mejor-sin tener claridad en cuanto a estar realmente ayudando (o no) a resolver una necesidad real del cliente de una manera efectiva. Y, al carecer de cualquier sentido de alineación estratégica de sus soluciones prescritas, los diseñadores producían ideas que nunca tendrían posibilidades reales de ver la «luz del día». (Page 6) - Mientras más fácil sea para una organización liberar nuevo código, con mayor facilidad se puede regresar a desarrollo, hacerle ajustes y lanzarlo nuevamente a producción. (Page 15) - Cualquier proyecto es un experimento. La pregunta que el experimento busca responder no es «¿Podemos construir ésto? Sino, ¿Deberíamos construir ésto? Y si la repuesta es sí, entonces preguntamos «¿Podemos construir un modelo de negocio sostenible alrededor de esa idea? (Page 21) - Tags: [[favorite]] - El MVP 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? (Page 22) - Tags: [[favorite]] - Un Product Manager típicamente debe definir y decidir en qué es en lo que los equipos deben trabajar y en qué orden. Ellos son los responsables de definir el alcance de cada ciclo de entrega y de supervisar al equipo para alcanzar esos objetivos. (Page 24) - Tags: [[favorite]] - Agile nos ayuda a ir entregando trabajo a un ritmo preestablecido. Lean Startup nos ayuda a determinar en qué nos debemos enfocar. ¿Cómo entonces determinamos si eso en lo que estamos trabajando tiene algún valor? Para eso necesitamos Design Thinking (Page 29) - Las prácticas de Design Thinking son para que los equipos las usen de manera continua para asegurar que los proyectos permanezcan en el camino correcto y se vayan ajustando de manera apropiada, a partir del aprendizaje logrado por las prácticas Ágiles. (Page 30) - En el contexto de una organización que busca aprovechar los beneficios de la mejora continua y una oferta de servicios basados en software, tu trabajo es identificar y escoger los elementos específicos de cada práctica que funcionan bien para tus equipos y los valores que estás tratando de comunicar. (Page 35) - Tags: [[favorite]] - Para reducir el riesgo toma pasos pequeños. Toma una nueva idea o práctica e inténtala con un subconjunto de equipos. Esta nueva práctica no debería de manejarse como un cambio permanente. En lugar de eso, presenta esto como un «experimento en proceso». (Page 36) - Deja que el equipo experimente por un tiempo limitado. Si esto falla, el equipo habrá invertido muy poco tiempo y esfuerzo en este cambio, pero (esperamos) habrá aprendido mucho. Si el experimento es exitoso, el equipo mantiene la práctica, la mejora, y luego la organización la transfiere a otros equipos. (Page 37) - Tags: [[product management]] [[favorite]] - Mientras que Lean y Design Thinking se alinean hacía la definición de que el consumidor es «la persona comprando y usando el producto», Agile frecuentemente se refiere a Product Owners como el consumidor. El punto central es que si ellos no están usando el producto entonces ellos no son los consumidores. (Page 40) - ¿Estamos entregando algo que es importante para los usuarios? Esta pregunta rápidamente revelará si tus equipos tienen un buen lazo de retroalimentación con los consumidores. Si no sabes si tus consumidores valoran lo que les estás entregando, entonces has identificado una brecha crítica de la comprensión que tienes sobre tu trabajo. (Page 41) - ¿Cómo investigamos si estamos entregando valor a los usuarios? Esta pregunta enlaza con la brecha en la retroalimentación con el consumidor que identificamos en la pregunta previa. ¿Necesitas hacer trabajo de campo para encontrarte con consumidores? ¿Necesitas implementar un sistema de analíticas? ¿Hay algún evento o lugar en el que tus consumidores se congreguen de manera regular? (Page 41) - ¿Cómo es que lo que valoran los usuarios afecta la forma en como establecemos prioridades? Una vez que está establecido un lazo de retroalimentación, el equipo necesitará contar con un método para incorporar de manera oportuna esta información al proceso de toma de decisiones. Un buen comienzo es llevar a cabo de manera regular sesiones de desarrollo de comprensión sobre el cliente, e integrar los resultados en las sesiones de planeación. (Page 42) - Tags: [[favorite]] - 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. (Page 46) - Tags: [[favorite]] - Por ejemplo, si el riesgo técnico es lo más importante a verificar, quizá un spike técnico -una técnica Ágil que consiste en dar un marco de tiempo a un esfuerzo de investigación técnica-es el enfoque correcto. Si necesitas entender si una idea tiene valor antes que la construyas, puede usar una prueba A/B o una página de destino de prueba (una herramienta clásica de Lean Startup) para aprender sobre esto. Y si no estás seguro de si el problema que estás resolviendo realmente existe para tus clientes, una visita contextual al sitio (una táctica de Design Thinking) podría ser la indicada. (Page 46) - Tags: [[favorite]] - Sobre el user testing frecuente. Muestra el valor del ejercicio, reduce el compromiso de participar, así como el costo, y encontrarás que el nivel de aceptación de parte de la organización se eleva para esta técnica clásica de descubrimiento de producto. (Page 49) - Tags: [[favorite]] - Los equipos balanceados proporcionan la experiencia, perspectivas y habilidades necesarias para todos los aspectos de un proyecto. Los equipos deben ser independientes, autónomos, y empoderados para tomar decisiones basados en la evidencia que su trabajo de descubrimiento de producto va revelando. (Page 51) - Sé claro acerca de lo que implica éxito y asegúrate que todos estén alineados a ese criterio, e identifica como lo medirás. (Page 52) - Tags: [[favorite]] - Publica métricas de éxito (tus avances) en espacios públicos en la oficina, y muestra cómo se está progresando (o no) con respecto a la métricas. (Page 52) - Los equipos optimizarán el trabajo gracias a incentivos: Si tú incentivas velocidad, los equipos trabajarán para liberar más funcionalidad al mercado. Si tú incentivas aprendizaje, los equipos crearán mejores procedimientos para descubrimiento de productos. (Page 54) - Tags: [[favorite]] - El trabajo que se visualiza es el trabajo que se hace. (Page 55) - En mucho casos, lo aprendido revelará huecos en tu backlog o una pobre decisión al priorizar artículos. Cambiar tus planes como reacción a esos aprendizajes es agilidad. Es la razón principal para adoptar esta forma de trabajo y es la clave para construir equipos y organizaciones que responden. (Page 57) - Tags: [[favorite]] - Revisen qué fue lo que funcionó bien durante ese ciclo, qué no funcionó bien, y que se comprometan todos a mejorar una o dos cosas clave antes del siguiente sprint. - Tags: [[favorite]] - Note: Lean vs Agile vs Design Thinking - A medida que se despliegan nuevos procesos, asegúrate que queda claro porqué están intentando algo nuevo. - Tags: [[favorite]]