Esta edición del podcast (ahora también en youtube) Deiby Ordoñez y Evelyn Cavajal la dedicaron a conversar generalidades y particularidades sobre Lean Inception con 2 grandes expertos invitados.
Ellos son Paulo Caroli, Consultor principal de Thoughtworks, co-fundador de AgileBrazil y autor del libro “Lean Inception: creando conversaciones hacia un producto exitoso”, y Antonio Gallardo, Consultor en ThoughtWorks, podcaster en Hormigas Agilitas y Certified Lean Inception Trainer en Caroli.org.
¿Qué es? ¿Qué no es? ¿Qué hace? ¿Qué no hace?
Partimos la conversación con esta serie de preguntas que también corresponden a una de las actividades dentro de un Lean Inception.
¿Qué ES Lean Inception? Es un taller colaborativo para alinear a un grupo de personas, identificar cuál es el MVP de su producto y por dónde empezar.
¿Qué NO ES Lean Inception? No es gestión de portafolio, no es para elegir iniciativas, no es una etapa de un descubrimiento para averiguar cuál es el problema que vamos a resolver.
¿Qué HACE Lean Inception? Hace actividades colaborativas que pone juntas personas con perspectivas y puntos de vista distintos (negocio, User Experience, tecnología, etc) para buscar una intersección que permita crear en conjunto un plan para el mínimo producto viable (MVP) para su producto o iniciativa. Lean Inception hace que colaborativamente se construya un plan exitoso para un primer paso. Después seguimos cambiando, aprendiendo y pivoteando si es necesario, juntos.
¿Qué NO HACE Lean Inception? no hace magia, no resuelve todos los problemas de la organización, no es un trabajo individual o donde se toma una decisión unilateral.
¿De dónde nace Lean Inception? ¿Que vivieron para proponerlo?
Para los más curiosos, pueden ver un punteo de las influencias e hitos que marcaron la historia de Paulo Caroli y la creación de Lean Inception.
- Paulo Carolí estudió Ingeniería de Computación desde 1992 hasta 1997.
- Hizo una Tesis de Maestría en Brasil de 1997 a 1999 a partir de algo que le encantaba: la Programación Orientada a Objetos.
- En esos años estaba surgiendo UML. Le encantaba la parte de análisis y diseño de proyectos en los años 90.
- Rational contrató a tres personas de Object Oriented que crearon UML y RUP con 5 etapas para un proyecto de Software, dónde la primera era Inception (comprensión de lo que había que hacer en un proyecto: Release Plan, Arquitectura, Requerimientos).
- Llegó a EEUU en el 2000 y se involucró con Agile.
- Trabajó en una Startup del 2000 al 2006 (tenía mucho interés en el mundo de las Startups).
- En 2006 empezó a trabajar para Thoughtworks que era muy ági. Con la influencia de Martin Fowler y otras tres personas que participaron en los inicios de Extreme Programming cambió el ADN de la organización. Esto influyó en su vínculo con la agilidad.
- Empezó a seguir a Jeff Patton que vivía también en San Francisco. Tenía un estilo de Design Thinking, User Centric Design, las personas, User Journeys: mapeaba todo a historias de usuario.
- En Thoughtworks usaban el nombre Inception. Scrum era famoso y las historias de usuario eran famosas. El objetivo del Inception era comprender todo y al final tener un backlog de historias de usuario.
- Jonathan Rasmusson, ex-Thoughtworks, luego escribió el libro The Agile Samurai (libro de referencia, en especial por su sección “Agile Project Inception”). El seguía mucho Extreme Programming y se involucraba mucho con el negocio. Las actividades que él utilizaba mezclaba lo que necesitaba el negocio y lo que los desarrolladores necesitaban.
- En ese tiempo no era muy colaborativo. Hacían muchas actividades y por mucho tiempo: 2, 3, 4 o 5 semanas. Tomaban una sala de reunión, y personas entraban y salían. Al final tenían una planificación para un proyecto ágil.
- En 2010 fué a vivir a Brasil. Él era facilitador de Inception. Viajaba con el equipo y tenía un buen inception de aproximadamente 1 mes.
- En 2011 se casó y tuvo un hijo. La vida cambió. No podía viajar por 3 o 4 semanas, sino por 1 máximo.
- Él estaba leyendo (por suerte) el libro de Eric Ries de Lean Startup en el primer viaje en el que tenía que facilitar un Inception. Dijo que se iba a quedar una semana porque se iba a enfocar en el MVP y no en todo el producto. No salió bien porque las actividades no estaban diseñadas para el MVP.
- Seguía teniendo la misma restricción de tiempo, y empezó a impulsar cambios. Entre 2013 y 2014 hacía inceptions de 1 una semana incorporando cambios que salieron muy bien. Surge el nombre de “Directo al punto”.
- En 2016, con el Coaching de Martin Fowler generaron un nombre más genérico que hicieran sentido en todas partes. De esa experiencia práctica, viajando mucho a Chile, Argentina, Colombia, Ecuador, sin poder viajar muy lejos. Surge el nombre de Lean Inception con la aplicación en Brasil y los países vecinos.
¿Cómo les ha ido aplicando Lean Inception?
En Chile, en la experiencia de Antonio, al comenzar a aplicar Lean Inception reconoce mucha resistencia de parte de las organizaciones, sin embargo, cuando los equipos han logrado ver el valor de conseguir un MVP colaborativamente, con el resultado de un producto a lanzar, tiene una gran aceptación.
Al presentar un modelo de 1 semana las empresas mostraran mucha sorpresa, usualmente tendiendo a hacer en muy pocos días o incluso horas, pero una vez realizado se va generando confianza en el proceso, entiendo juntos el por qué se hacen las cosas.
Finalmente, el resultado de aprendizaje y el team building que se gesta en los equipos es enriquecedor para los facilitadores y participantes, validar hipótesis y ver resultados a corto plazo.
Casos / Ejemplos
Hospital (Brasil)
Empezó por departamento de tecnología y ahora estan usando Lean Inception con el Covid. Tuvieron que hacer cambios muy rápidos en el hospital; no tenía nada de tecnología pero tenían doctores, enfermeros, personal administrativo y un facilitador que vino de tecnología para ayudar a elegir el MVP para empezar un ala para el Covid. No es solamente de tecnología, es para alinear a las personas y elegir juntos una solución, es para empezar pequeño.
El mejor MVP es lo que el equipo elige como MVP. Lo importante es que elegimos juntos. En general (…) con el MVP (y conozco muchos (…)) vas a pivotear mucho.
Paulo Caroli
Hospital Calvo Mackenna (Chile)
Un proyecto para el area de cuidados paleativos para niños en el Hospital. El objetivo era ayudarlos registrar el cuidado del dolor en los niños de cuidados paleativos. Se hizo una Lean Inception en remoto con personal del hospital y con usuarios. (Puedes ver la publicación del Hospital haciendo click aquí).
Hipótesis: Se definió un MVP que era para personas tutoras, no para los niños. Era para registrar dolor y tener un nivel de medicación adecuado para no tener tantas crisis.
Las hipótesis hay que validarlas. Cuando se lanzó el producto los que más lo usaron fueron los niños, registrando sus dolores, mostrandolo a sus familias, y empezando a ser parte de las decisiones de sus enfermedades. Pusimos otros síntomas aparte del dolor, que era el foco inicial, dándonos cuenta que la gestión de las nauseas era relevante, pudiendo empezar a controlarlas mejor.
No lo podríamos haber descubierto, validado y pivotado sin haberlo lanzado.
Una equivocación más rápida, es un gran éxito
Proyecto Cancelado
El equipo mostró el resultado, el MVP, y luego el proyecto fué cancelado. El equipo no lo podía creer.
Los llamó el gerente. No se sabía si iba a reclamar por algo, pero fué todo lo contrario. Agradeció porque habían invertido y aprobado más presupuesto. Cuando vió el resultado del Lean Inception notó con claridad que no era el rumbo que querían tomar y decidieron cancelarlo, ahorrando mucho dinero. No era ni siquiera necesario ejecutar el MVP.
Esto es un escenario distinto de éxito.
Consideraciones sobre actividades particulares de Lean Inception
Lean Inception tiene influencia de Agilidad, Design Thinking y Lean Start-up.
Personas
¿No se queda corta la técnica al basarse en supuestos? ¿Cómo mejoramos la precisión de estos supuestos?
La actividad es para compartir los conocimientos que tenemos sobre las personas que consideramos importantes. Es un espacio corto dentro del Lean Inception.
Podemos tener conocimiento a partir de acciones previas al Lean Inception:
- Comprender a las personas
- Aprender con ellas
- Hacer entrevistas
El resultado de todas estas actividades se usa en la actividad de personas.
Los participantes pueden tener conocimientos complementarios que compartir:
- Las personas de UX: ejp, resultados de User Research.
- Las personas de negocio: ejp, datos de sus reportes.
- Las personas de ingeniería: ejp, datos del uso del producto.
Traemos las distintas perspectivas y conocimientos.
Si no tenemos conocimientos traemos las suposiciones que tenemos, y el MVP nos va ayuda a validar estos supuestos.
Revisión técnica, de negocio y de UX
La parte técnica y de negocio son usuales, la de UX aún no tanto ¿cómo y porque incluir está revisión de UX de forma diferenciada?
La agilidad empezó integrando solo negocio y tecnología, y no tenía UX, esa es la realidad.
Cuando se empezó a generar el Lean Inception se realizaba la revisión técnica y de negocio solamente. Igual se convocaba a las personas de UX para estar juntos en toda las sesiones. Las personas de UX se aburrían, no participaban.
La reflexión que siguió fue: ¿Por qué no les estamos preguntando su punto de vista? Cuando se hizo el cambio fue increíble, todos participaban y era necesario ese conocimiento/punto de vista.
En otras técnicas también pasa. Por ejemplo, en las historias de usuario se habla de Business Value, pero y el ¿User Value? ¿y qué involucra tecnológicamente?.
Antes esta actividad tenía otros nombres (“Nivelando las features”, “mirando diferentes perspectivas”). Martin Fowler fue el que le dijo a Paulo Caroli que lo que se estaba haciendo era una Revisión técnica, de negocio y de UX, no era necesario inventar otros nombres.
Secuenciador de funcionalidades
¿Qué tan estable es el resultado? ¿Cómo evoluciona esta secuenciación en la práctica después del Lean Inception?
Para llegar al secuenciador hay una serie de actividades previas que permiten enlazar información, hacer una revisión y generar una conversación. Es difícil generarlo sin ese entendimiento común previo. Cuando llegamos ahí ya tenemos radiadores de información de certidumbre, valor que aporta al negocio y al usuario, que tan difícil puede ser o qué tanto esfuerzo va a requerir.
Generalmente el secuenciador ayuda para el primer lanzamiento. Pero después hay mucho feedback, que puede cambiar poco mucho lo señalado en el secuenciador.
El Release Plan por ejemplo estaba en horizontal, más detallado y asertivo con fechas; el secuenciador esta en vertical y menos detallado. Lo que me gusta de la vertical es que te enfocas en la primeras líneas, y no en una sola que te hace siempre todo lo que viene.
Diccionario Agile: MVP
¿Qué es u MVP?
Es la sigla de Minimum Viable Product, Mínimo Producto Viable.
Es lo mínimo posible que puedes hacer que te aporte un máximo de aprendizaje para validar una hipótesis de negocio.
Q&A: ¿Cómo convencer a los líderes/gerencias/jefaturas de aplicar Lean Inception?
No es fácil. Cuando nos llaman es más simple, porque es por pedido, hay una credibilidad previa, aunque las primeras igualmente cuesten.
Sobre cómo convencerlos, va a depender de la organización, de la cultura, su foco en las personas, del momento en el que están.
- Lo mejor es probar, sin llamarlo Lean Inception ir generando esos espacios colaborativos y de entendimiento común. Experimentar.
- Plantear la idea de que si no funciona, se deja de lado. Después de probarlo se empieza a ver el valor.
- Contar ejemplos y casos.
- Hablar de la competencia, y cómo lo están haciendo. Si son líderes en su negocio, tal vez no necesitan cambiar, pero la mayoría necesitan ir cambiando.
Pre-aviso de próximo libro
Paulo Caroli no mencionó en primicia que próximamente estarán publicando un nuevo libro en el que llevan 5 años trabajando: Product Backlog Building.
Cuando sales del Lean Inception tienes un buen plan de MVP, en el libro abordan cómo ahora a partir de él se plantean las primeras User Stories para un sprint.
Se publicará en portugués y posteriormente, rapidamente, en Español.
