**Book name:** Lean vs Agile vs Design Thinking **Author:** Jeff Gothelf **Publication Year:** 2017 **Read:** December 2020 --- ## 🚀 The Book in 3 Sentences 1. Tu deber es detectar el mejor proceso, seleccionando los métodos que te permitan balancear la investigación, ejecución y entrega del producto. Para enfocar los equipos en satisfacer las necesidades del usuario, colaborar efectivamente y lograr mejora continua. 2. Agile nos entrena a entregar algo a un ritmo prestablecido, Lean Startup nos ayuda a determinar en que hay que enfocarse y Design Thinking nos guía a descubrir que valor tiene para el cliente. 3. Pon al usuario en el centro. Pregunta: ¿Que valor entregamos al usuario?, ¿Cómo lo descubrimos? y ¿Cómo eso afecta nuestras prioridades?. Y limita la investigación al alto riesgo, para así entregar funcionalidad mientras el equipo está aprendiendo. Ej: Reto técnico con Agile. Una idea de valor con A/B Testing (Lean). Y un problema incierto con Contextual Inquiry (DT). ## 🎨 Impressions Jeff Gothelf (Lean Startup) hace un análisis de los problemas comunes en equipos de IT y devela como cada metodología ofrece soluciones con enfoques particulares pero al mismo fin: satisfacer las necesidades del cliente. Y que es muy raro leer las traducciones al español de términos que siempre se usan en Inglés en el día a día. Eso creo complica más la comunicación a quienes ya estamos en la industria, mientras puede ser que ayude a comunicar la idea a alguien nuevo. Pero dudo de su efectividad al estar popularizados los términos en inglés. ### How I Discovered It Lo descubrí por su lanzamiento en español. Quería entender mejor las diferencias entre las metodologías, sus fortalezas y cuándo elegir cada una. ### Who Should Read It? Es un libro para leer en una tarde. Es para quienes ya conocen las tres metodologías y buscan integrarlas de la mejor forma a sus equipos. No es para aprender las metodologías ni para quién busca comparar los métodos en una tabla y elegir el que más le guste en cada parte del ciclo de desarrollo. Es para conocer sus similitudes y enfrentar el problema de personalizar un proceso mediante la experimentación que no interrumpa o distraiga el flujo de trabajo. ### How the Book Changed–my life, behavior, thoughts or ideas–Me Entendí que los problemas de comunicación, colaboración y priorización que he presenciado son muy comunes en la industria tecnológica del software. Y que la mejor manera de resolverlo es compartir las similitudes de las 3 metodologías. Además de utilizar sus métodos asociados, de forma situacional para investigar altos riesgos donde generar aprendizaje mientras se alimenta la funcionalidad. ## ❝ Quotes I’d save forever > [!quote] > El equipo de ingeniería se enfocaba en entregar un código libre de errores en ciclos de entrega regulares (sprints). Los PMs estaban más interesados en administrar con eficiencia, calidad y reducción de desperdicios mediante a priorización táctica de un backlog y técnicas de gooming. El equipo de UX buscaba incluir lo más posible al usuario a través de la validación del problema-solución con actividades de Design Thinking. Cada disciplina operaba a través de un grupo distinto de roles, ceremonias y prácticas, persiguiendo y apuntando a un estado ideal de éxito particular. > [!quote] > Sin un entendimiento claro del problema, los PMs optimizaban backlogs basados en sus instintos y preferencias subjetivas de los stakeholders. 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 UX producían ideas que nunca tendrían posibilidades reales de ver la luz del día. > [!quote] > Tu trabajo es identificar y escoger los elementos especifícos de cada práctica que funcionen bien para tus equipos y los valores que estás tratando de comunicar. Recomiendo: > - Trabajo en ciclos cortos > - Haz retrospectivas regularmente > - Pon a los consumidores en el centro de todo > - Ve y observa (_Gembutsu Gemba_) > - Balancea el trabajo de descubrir con el de generar y entregar el producto > - Haz menos investigación, pero más frecuente > - Trabaja (y entrena) como un equipo balanceado > - Transparencia radical > - Revisa tu estructura de incentivos (y los KPI) > - Has al trabajo de descubrimiento "ciudadano de primera clase" en el backlog ## 📒 Other Notes ![[Readwise/Books/Lean vs Agile vs Design Thinking|Lean vs Agile vs Design Thinking]]