El bloc de notas de un Agilista Jedi
-
Scrum, Kanban
¿Tablero Scrum o tablero Kanban?
¿Te has preguntado si es lo mismo un tablero Scrum que un tablero Kanban? La respuesta corta es: "Sí, pero No". La respuesta a más detalle es algo como esto: Ambos tableros son herramientas visuales que permiten fomentar la transparencia y representar un flujo de trabajo, hasta ahí vamos bien. El tablero utilizado en equipos (link: https://scrumguides.org/ text: Scrum) se conoce como **Tablero Scrum (Scrum Board)**, y lo más común de ver este tipo de tableros con las columnas: Por hacer (To do), Haciendo o En Proceso (Doing), y Hecho o Terminado (Done). Sin embargo, se puede personalizar el tablero al contexto de tu equipo y agregar las columnas que necesiten (En pruebas, En Aprobación, etcétera). Esto no se contrapone en absoluto con Scrum (si te interesa profundizar un poco más en Scrum, puedes leer (link: https://leonelzapien.com/blog/que-es-scrum text: aquí ) un artículo en mi Blog sobre este tema, o bien, al final del artículo te comparto unos enlaces a un par de videos donde hablo sobre Scrum). (image: leonel-zapien-lopez-agile-scrum-board-guadalajara-mexico.webp) # "Kanban" y "kanban" no son lo mismo La palabra **kanban** tiene dos significados: - En Hiragana o alfabeto japonés: かんばん. Se forma por kan que significa “visual”, y ban que significa “tarjeta”. - En Kanji o caracteres chinos: 看板. Significa “señal” o “Gran tablero visual”. Entonces, un tablero que nos puede ayudar a visualizar, en el estricto sentido puede ser considerado un **tablero kanban**. Y aquí viene una gran nota, como siempre digo que dicen mis amigos chilenos: ¡Ojo al piojo! No es lo mismo <**kanban**> que <**Kanban**>, ya que Kanban (con “K” mayúscula”) es un método creado por David J. Anderson en 2010, para gestionar el trabajo de conocimiento, que busca equilibrar la demanda de trabajo a realizarse con la capacidad disponible para comenzar un nuevo trabajo. (Si te interesa profundizar un poco más en el (link: https://kanban.university/kanban-guide/ text: Método Kanban), al final del artículo te comparto unos enlaces a un par de videos donde hablo sobre Kanban). Entonces, siempre que se habla de la eterna comparativa entre Scrum y Kanban, se refiere a Kanban con “K” mayúscula, es decir, al Método Kanban, y no al kanban (con “k” minúscula) del Sistema de Producción Toyota y Lean (por cierto, si quieres profundizar un poco sobre Lean y el Sistema de Producción Toyota o TPS, puedes leer en mi BLOG un artículo que escribí al respecto haciendo (link: https://leonelzapien.com/blog/esto-es-lean text: clic aquí)). (image: leonel-zapien-lopez-tableros-visuales-visual-management-lean-guadalajara-mexico-02.webp) Ahora, un tablero Kanban tiene mucha más información que un tablero Scrum, ya que el Método Kanban menciona que se debe de visualizar en el flujo de trabajo o workflow, además de algunos elementos como: Punto de Compromiso, Punto de Entrega, Políticas Explícitas, entre otras cosas… pero, de nuevo ¡Ojo al piojo!, lo más importante para que sea un sistema Kanban es que cuente con **Límites de Trabajo en Proceso o Límites WIP**. Sin esto, aunque tenga todo lo demás, no estamos haciendo Kanban. # Conclusión Entonces, un tablero Scrum es un gran tablero visual, por lo cual es un tablero "kanban" (con "k" minúscula), pero un tablero Scrum no es lo mismo que un tablero Kanban (con "K" mayúscula, que se refiere al Método Kanban). ¿Conocías estas similitudes y diferencias?, ¿Qué opinas al respecto? ### Material complementario: Enlace a videos de webinars o talleres que he facilitado sobre Scrum y Kanban: (link: https://www.youtube.com/watch?v=2q6zqHeHn8s text: Video: ¿Qué rayos es Scrum?) (link: https://www.youtube.com/watch?v=X7S4aR2gDFc&t=38s text: Video: De gestión de Proyectos a Agile) (link: https://www.youtube.com/watch?v=DK9H5ofoHbY text: Webinar: Si Scrum hablara.) (link: https://www.youtube.com/watch?v=GYw4koPCL4E&t=524s text: Taller de Scrum + Kanban (sesión 1 de 2)) (link: https://www.youtube.com/watch?v=YmaHVnH27uk text: Taller de Scrum + Kanban (sesión 2 de 2)) (link: https://www.youtube.com/watch?v=XdTOUSebjLM text: Webinar: Certiprof Learning Lab: Scrum, The rules of the game.) (Este último video es en inglés, o al menos ese soy yo intentando hablar en inglés xD)
31 de mayo de 2025 -
Project Management, Agile, Scrum
¿Gestión de Riesgos en Agile?
En agile no se gestionan riesgos, eso es muy de “waterfall”… ¿Te suena? Se dice mucho que el Scrum Master se enfoca en remover impedimentos o bloqueos del equipo Scrum, esto es cierto, pero esto en un es sentido reaccionar a algo que ya sucedió, muchísimo aporta que se puedan gestionar estos impedimentos antes de que sucedan. Por cierto, (link: https://scrumguides.org/ text: La Guía Scrum ) en este sentido menciona que el Scrum Master debe: “Procurar la eliminación de impedimentos para el progreso del Scrum Team.” En una reunión que tuve hace unas semanas con un equipo surgió el tema de los riesgos (como comentario, fue en mi segunda reunión del día, a las 6:30 a.m.), y es por esto que pensé en traer el tema a la mesa. (image: precaucion.webp) # Primero lo primero, ¿Qué es un Impedimento, un Bloqueo y un Riesgo? Si nos vamos a la definición de diccionario, de acuerdo con la Real Academia de la Lengua Española o RAE, un (link: https://www.rae.es/diccionario-estudiante/impedimento text: impedimento) es: “Cosa o persona que impiden algo” Un (link: https://dle.rae.es/bloqueo text: bloqueo), también, de acuerdo con la RAE, lo define como un sinónimo de “obstrucción o atasco”. Para definir un riesgo, lo veremos de dos maneras, desde una definición genérica que nos brinda la RAE y de la que nos brinda una fuente específica como el (link: https://www.pmi.org/ text: Project Management Institute o PMI). • (link: https://www.rae.es/diccionario-estudiante/riesgo text: Riesgo) (de acuerdo con la RAE): “Posibilidad de que ocurra algo malo”. • (link: https://www.pmi.org/learning/library/es-desmitificando-el-enfoque-practico-de-la-planificacion-de-riesgos-7331 text: Riesgo) (de acuerdo con el PMI): “Un riesgo en proyectos es un evento o condición incierta que, en caso de que ocurra, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, que puede ser tiempo, costo, alcance o calidad.” Si un equipo está trabajando y de pronto se topa con que están detenidos porque se ha terminado un determinado número de parte (materia prima), porque no cuentan con un requerimiento que aún no ha sido confirmado por el cliente, o porque ha fallado un servidor en producción, entonces el equipo está bloqueado, tiene un impedimento que no le permite continuar. En este sentido, una forma de ver un impedimento es como un riesgo que ya ha ocurrido. Por eso la importancia de actuar con un enfoque preventivo por medio de la Gestión de Riesgos. # No nos casemos con una metodología Como siempre lo he dicho: No nos casemos con una metodología, marco de trabajo o método. Todas son simplemente herramientas y, como todo en la vida, debemos de utilizar la herramienta adecuada para cada situación. Claro que, si tengo que clavar un clavo y solo tengo a la mano unas pinzas, seguro que puedo darle de golpes para clavarlo, tal vez le voy a batallar un poco más, pero no hay como utilizar un martillo. En “la vida real” enriquece mucho utilizar distintas herramientas, y como fui primero Project Maganer ((link: https://www.pmi.org/certifications/project-management-pmp text: PMP)) que Scrum Master y Agile-Lean Coach (si te interesa leer más sobre el Agile Coach, puedes leer un artículo que escribí sobre el tema haciendo clic (link: https://leonelzapien.com/blog/scrum-master-o-agile-coach text: aquí)), confieso que desde el inicio he utilizado Gestión de Riesgos (con un enfoque ágil), y funciona de maravilla 😀 # Gestión de Riesgos (Risk Management) Un riesgo puede ser positivo o negativo (esto, cuando lo leí por primera vez hace como 12 años, me voló la cabeza), ya que solo concebía el concepto de un riesgo como algo negativo que puede suceder. Un **riesgo positivo* *es una oportunidad y solo en caso de ocurrir generaría un impacto positivo al equipo. Un **riesgo negativo** es del tipo que comúnmente conocemos, una amenaza que, en caso de ocurrir, tendría consecuencias negativas. **Los riesgos se evalúan por su probabilidad de ocurrencia y su impacto.** (image: riesgo-probabilidad-impacto-explicado-risk-management-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp-2.webp) Crédito de imagen: BrainUp Co. . ### Un ejemplo: Si voy a hacer un viaje por carretera de 4 horas a la playa, el impacto de que se ponche una llanta o neumático del coche es alto, ya que no podría continuar el viaje con solo 3 llantas. Pero, ¿Qué tan probable es que suceda? Digamos que en condiciones “normales” (neumáticos en buenas condiciones, camino en buenas condiciones) la probabilidad de que suceda es baja (tan baja que, con 1 sola llanta o neumático de refacción hacemos el viaje, sin necesidad de llevar 4 llantas de refacción en la cajuela del coche). Este podría ser un riesgo de impacto alto con probabilidad de ocurrencia baja. En este ejemplo, quizá quiera mitigar aún más este riesgo y decido llevarme en la cajuela una segunda llanta o neumático de refacción. Ese es mi plan para mitigar este riesgo. ¿Es demasiado?, tal vez sí o tal vez no, dependerá del contexto, ¿Qué tal si ese viaje a la playa es para casarme allá y el llevar dos neumáticos de refacción me da paz mental, porque no quiero ninguna sorpresa en el trayecto? Ahora, voy a exagerar con el ejemplo, pero qué tal si considero que el viaje a la playa se puede poner en riesgo por un meteorito que caiga en la carretera. El impacto sería claramente alto (demasiado alto), pero y ¿la probabilidad de que esto ocurra?, ¿Valdrá la pena o es siquiera posible hacer un plan para mitigar este riesgo? Con este último ejemplo quiero enfatizar el hecho de que no podemos centrarnos en todo, por esto debemos de **enfocarnos en los riesgos con la adecuada combinación de impacto y probabilidad de ocurrencia.** (image: gestion-de-riesgos-risk-management-dragon-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp.webp) Crédito de imagen: Esta imagen la tomé de un post que me encantó de mi amiga de Ciudad de México (link: https://www.linkedin.com/in/carolina-loperena/ text: Carolina Loperena), quien es toda una Jedi como Project Manager (en el link en su nombre puedes encontrar su perfil en LinkedIn). . Se deben de tener las conversaciones adecuadas con las personas adecuadas para **cocrear** una identificación de riesgos, después hacer un análisis de cada riesgo identificado, definir un plan de respuesta (y aquí no solo es mitigar o evitar, ahorita lo vemos más a detalle), para después llevar a cabo las acciones identificadas, y de manera continua permanecer evaluando si alguno de los riesgos ha cambiado su probabilidad de ocurrencia o su impacto, o si surgen nuevos riesgos. Es un proceso continuo, y si se aborda con** Transparencia, Inspección y Adaptación**, ¡Es una combinación poderosa! Al definir un posible plan para cada riesgo, es importante saber que un riesgo se puede: ### 1.Mitigar: Disminuir la probabilidad de que se presente y/o el impacto en caso de que suceda. ### 2.Evitar: Eliminar la causa raíz para que no ocurra el riesgo (“cortar de tajo”, como decimos acá en México). ### 3.Transferir: Una tercera parte es responsable del riesgo, tal vez no se puede evitar, pero la otra parte absorbe el impacto (en parte o en su totalidad), por ejemplo, el contratar un seguro contra accidentes automovilísticos no evita la probabilidad de chocar, pero si ocurre, se transfiere el impacto del riesgo a alguien más (en este caso a la aseguradora, claro que a cambio de un correspondiente pago). ### 4.Aceptar: Dependiendo la situación, lo más adecuado (o posible) sería dejar que ocurra. Como decimos acá en México: “No hay de otra y bebemos de apechugar”. (image: riesgo-estrategias-risk-management-leonel-zapien-lopez-guadalajar-mexico-pmi-pmp.webp) Como punto final sobre la gestión de riesgos, me gustaría agregar algo que me ha compartido un muy buen amigo, (link: https://www.linkedin.com/in/jorgesanchezlopez/ text: Jorge Sánchez López), de Valencia, España (en el link en su nombre puedes encontrar su perfil en LinkedIn), a manera de cultura general, y es que la gestión de riesgos viene de la **ISO 31000**. # El ingrediente final: Transparencia Con todo lo que hemos conversado el día de hoy, para cerrar la idea, y ya que hemos visto que los riesgos se clasifican en cuanto a su probabilidad de ocurrencia y a su impacto, para asegurar que esta información esté disponible para todas las partes interesadas y surjan las conversaciones adecuadas, los riesgos se visualizan en una **Matriz de Riesgos** como la de la imagen, la cual ayuda a esta Transparencia que he mencionado 3 veces hasta el momento en este artículo. (image: matriz-de-riesgos-risk-management-gestion-leonel-zapien-lopez-guadalajara-mexico-pmi-pmp.webp) Como dicen mis amigos chilenos: ¡Ojo al piojo! Ten en cuenta que esta matriz sirve de poco si no se revisa y actualiza de manera regular. Y me gustaría cerrar un mensaje final: **Lo poderoso no es esta Matriz, sino las conversaciones que surgen.** ¿Qué opinas de este tema?
30 de abril de 2025 -
Scrum, Agile, Project Management
Scrum NO es una metodología… 30 años después
Scrum cumple 30 años este 2025, y aún es común encontrar montones de post y artículos que lo llaman metodología. Scrum **NO es una metodología**, es un marco de trabajo o framework, la Guía Scrum lo llama un “marco liviano”. ¿Cuál es la diferencia con una metodología y por qué no lo es? ### Metodología La definición “by the book” de metodología nos dice que es un conjunto estructurado de principios, procesos y prácticas que deben seguirse para lograr un objetivo. Una metodología brinda** pasos claros y detallados **para llevar a cabo algo en específico, y esto se resume en que es necesario seguir estos pasos detallados, lo cual deja poco margen para adaptaciones. ### Marco de Trabajo Por otro lado, un marco de trabajo es mucho más flexible, proporciona una serie de **guías generales** y, como no dicta a detalle cómo deben realizarse los puntos que abarca, fomenta la colaboración y la creatividad dentro de sus límites. ### Y eso en Scrum, ¿Qué quiere decir? Es por esto que (link: https://scrumguides.org/ text: La Guía Scrum), que es la fuente oficial de Scrum, **consta de solo 16 páginas** (incluyendo la portada, el índice y los agradecimientos 😂), y por esto la propia Guía menciona que “El marco de trabajo Scrum es incompleto de manera intencional"… por lo tanto, si quieres implementar Scrum con tus equipos te vas a dar cuenta de que La Guía menciona muchos puntos que deben de cumplirse, pero no te dice cómo hacerlo, por lo que es necesario complementarlo con otras técnicas, herramientas, métodos, y etcétera y etcétera. Por ejemplo, La Guía Scrum menciona que se deben de ordenar los elementos del **Product Backlog**, pero no dice cómo o con cuáles técnicas de priorización. Menciona que se inculca la calidad al adherirse a una **Definición de Terminado o DoD** (si te interesa profundizar en este concepto, puedes leer el artículo que escribí sobre la Definición de Terminado (link: https://leonelzapien.com/blog/scrum-calidad-5-1-tips-para-una-poderosa-definicion-de-terminado text: aquí)), más no te dice cómo hacerla. Menciona también que en las **Retrospectivas** el Equipo Scrum identifica formas de aumentar la calidad y la efectividad, pero de igual manera no habla de técnicas de facilitación ni de herramientas para identificar causa raíz. ### La Complejidad está en el aire ¿Y por qué Scrum no brinda un paso-a-paso detallado? La respuesta es por la complejidad, la volatilidad y la incertidumbre (entre otros elementos) que hacen prácticamente imposible que se pueda definir un procedimiento a detalle para cada posible situación Si hablamos de complejidad (si te interesa profundizar un poco sobre complejidad y Sistemas Adaptativos Complejos o CAS, puedes leer un artículo que escribí sobre este tema es (link: https://leonelzapien.com/blog/organizacion-sistema-adaptativo-complejo text: aquí)), tiene que ver con múltiples variables que pueden influir en una situación, de las cuales a veces ni siquiera somos conscientes de que existen o de sus relaciones, así que no se pueden modelar ni predecir. Por esto **Scrum funciona muy pero muy bien para entorno complejos** (por cierto, si te interesa leer un poco más sobre qué es Scrum, puedes leer un artículo que escribí sobre el tema(link: https://leonelzapien.com/blog/que-es-scrum text: aquí), y puedes ver un video que hice sobre Agile (link: https://www.youtube.com/watch?v=X7S4aR2gDFc&t=4s text: aquí)). ### Conclusiones En resumen, una metodología es como un manual detallado, mientras que un marco de trabajo podría ser más como una** caja de herramientas** que puedes usar según el contexto. ¿Qué opinas de este tema?
4 de abril de 2025 -
Product Management
Técnicas de Priorización: Si todo es urgente, nada es urgente
Ya que nuestros recursos, tiempo y capacidad son finitos, es importante que nos enfoquemos que lo que realmente importa. Y aquí viene entonces “la gran pregunta”: ¿Cómo podemos priorizar el trabajo, las iniciativas de proyectos, los requerimientos, funcionalidades o atributos de un producto a fin de enfocarnos en lo que realmente importa? El día de hoy te comparto un compendio de técnicas de priorización, imprescindible para todo Scrum Master, Agile Coach (si quieres profundizar un poco sobre este rol, puedes leer un artículo que escribí sobre el marco de competencias del Agile Coach (link: https://leonelzapien.com/blog/scrum-master-o-agile-coach text: aquí)), Project Manager, Product Owner, Product Manager, y etcétera y etcétera: Como dicen mis amigos españoles: Vamos al lío con esto (vamos al punto, al grano, como decimos acá en México). # 1. MoSCoW (image: moscow-must-should-could-wont-metodo-priorizacion.webp) Es un acrónimo que nos ayuda a definir qué atributos, características o iniciativas son un Must (Debe de hacerse), Should (Debería hacerse), Could (Podría hacerse), y Won't (No se hará, o no en este momento). • **Must (Deben de estar): **Requerimientos o características absolutamente críticas e imprescindibles, deben de ir. • **Should (Deberían estar): **Aspectos que son importantes también, pero no imprescindibles. Deben realizarse de ser posible, o en futuras entregas (próximos sprints, o próximas liberaciones o releases). •** Could (Podrían estar): **podrían incluirse si no se afecta nada más de lo que es Must o Should, o si alcanzamos con la capacidad, tiempo o presupuesto que tenemos. • **Won’t (No estarán): **Se pueden excluir por no ser relevantes, no merecen la inversión, no aportan beneficio o no son necesarios en este momento (se podrían considerar más tarde). # 2. Método RICE (image: rice-metodo-priorizacion.webp) RICE un acrónimo que establece cuatro criterios para obtener un índice de prioridad numérica, a mayor alto el índice, mayor la prioridad del elemento que se está evaluando. • **Reach (Alcance):** El alcance que tendrá si se lleva a cabo esta característica, funcionalidad o iniciativa (número de personas que utilizarán nuestra funcionalidad o producto, o personas a las que se alcanzará). • **Impact (Impacto):** El valor que se estima tendrá nuestra funcionalidad o producto (bajo/medio/alto, o bien una escala numérica de menor a mayor). • **Confidence (Confianza): **Grado de certeza de que nuestra funcionalidad, producto o iniciativa tendrá éxito (bajo/medio/alto, o escala numérica de menor a mayor). • **Effort (Esfuerzo para realizarlo o construirlo): **El trabajo que se estima será requerido para realizarlo, dependiendo de su complejidad (bajo/medio/alto, small/medium/large o S/M/L). Índice RICE = ( R * I * C ) / E A un índice más alto, mayor la prioridad. **Nota:** Para esta técnica, al igual que varias que revisaremos más adelante que tienen un factor numérico, el definir una escala, por ejemplo, del 1 al 10, o alto/medio/bajo, para un elemento, es en realidad una estimación, por esto la importancia de definir de manera conjunta y bajo consideraciones cocreadas el cómo definir este número, escuchando a todas las voces de acuerdo con el contexto correspondiente (a los especialistas en el tema, al área de negocio, al área técnica, a quienes tienen trato con el cliente y/o usuario, etc.). Es cierto, a final de cuentas es una estimación, por lo cual debemos de apoyarnos en información necesaria y no olvidar el trabajar en ciclos cortos de inspección y adaptación para obtener retroalimentación lo más rápido (y barato) posible. # 3. Valor de Negocio vs Esfuerzo (image: valor-de-negocio-vs-esfuerzo-metodo-priorizacion.webp) Proporciona un índice numérico de manera sencilla, dividiendo el valor estimado de negocio que proporcionará una determinada funcionalidad, característica o iniciativa, entre el esfuerzo de realizarla (este esfuerzo puede ser un número proporcional definido por el equipo, por ejemplo: bajo/medio/alto, una escala numérica, o bien puntos de historias de usuario). El valor esperado de negocio debe ser definido por el Product Owner / Product Manager, especialistas del área de negocio. El esfuerzo estimado lo define el área técnica que va a realizar el trabajo. Valor de Prioridad = Valor de Negocio / Esfuerzo A un índice más alto, mayor la prioridad. Ejemplo: (image: ejemplo-valor-de-negocio-esfuerzo.webp) # 4. WSJF (Weighted Shorted Job First) (image: wsjf-weighted-shorted-job-first-safe-tecnica-priorizacion-product-development-flow.webp) WSJF es un acrónimo que significa algo como “El trabajo más corto ponderado primero” (Weighted Shortest Job First, en inglés). Aunque WSJF es ampliamente utilizado en marcos como (link: https://scaledagile.com/ text: SAFe (Scaled Agile Framework)), fue popularizado por Donald Reinertsen en su libro (link: https://www.amazon.com/-/es/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?__mk_es_US=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3E042CQEK3E1M&dib=eyJ2IjoiMSJ9.q13iir53VvwNucBi1JIKpgA-PBXMglGvtroO321F8KAcKCYRwXg_9y1QR8zj9gUEUWSYuysIMteJeazccOpqPUpDvw9e_Cf7zw-HVpWm7TIRF2S5WLAdP02uhZXa9C4ZbMTO6wct_yUwRYrKr7X3D9-qtPuBgU8IlVsJAWrwLL4s9Mz0wHc8cah7gTsYHfoHnTvrdjnOsr01aiTiPhebACfNfJQ9R36LUtk5sa3gpcY.bEV3NWySRJgPfMwapzkT8qqgchkI3rSwa0gyZPbzwnU&dib_tag=se&keywords=The+principles+of+Product+Development+Flow&qid=1741144879&sprefix=the+principles+of+product+development+flow%2Caps%2C185&sr=8-1 text: “Los principios del Flujo de Desarrollo de Productos (The principles of Product Development Flow)). WSJF estima varios elementos, y se calcula resultando en un índice numérico (similar a las técnicas 2 y 3 anteriores), solo que considera más elementos, por lo que el resultado es una matriz un poco más compleja que las anteriores, pero también más completa. Considera para el cálculo de este índice de prioridad: • Valor de negocio • Criticidad en el Tiempo para entregarlo • Riesgo de no hacerlo u Oportunidad de hacerlo • Tamaño del trabajo Índice WSJF = ( Valor + Tiempo + Riesgo|Oportunidad ) / Tamaño del Trabajo. A un índice más alto, mayor la prioridad. Ejemplo: (image: ejemplo-wsjf.webp) # 5. Matriz de Lean Inception (image: matriz-lean-inception-paulo-caroli-product-discovery-priorizacion.webp) (link: https://caroli.org/es/lean-inception-5/ text: Lean Inception) es un taller colaborativo, creado por (link: https://www.linkedin.com/company/caroli-org-en-espanol/posts/?feedView=all text: Paulo Caroli), para alinear a un grupo de personas sobre una propuesta de solución a construir, finalizando con una secuencia de prioridades para un **Producto Mínimo Viable (MVP)**, y comprende una secuencia de actividades de varios días para promover la alineación, estrategia y el alcance del producto. A manera de contexto y cultura genera, Lean Inception toma sus bases en **Design Thinking** y en la filosofía **Lean**, principalmente en el enfoque de la reducción de desperdicios y en la definición de un Producto Mínimo Viable (MVP), lo cual es un aspecto fundamental de Lean Startup (si quieres profundizar un poco sobre **Lean Startup**, puedes leer un artículo que escribí sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Esta tabla de priorización que comparto es solo una de las actividades realizadas durante un taller de Lean Inception, prioriza en base a Valor de negocio, esfuerzo y experiencia del usuario (User Experience o UX), los cuales se evalúan en una escala de 1 a 3 o bajo/medio/alto: (image: ejemplo-lean-inception.webp) Personalmente, me encanta lo poderosos y encantadores que resultan los talleres Lean Inception, siempre surgen conversaciones sumamente enriquecedoras. El cómo realizar este tipo de talleres los explica Paulo Caroli en su libro: (link: https://caroli.org/es/livro/lean-inception-creando-conversaciones-hacia-un-producto-exitoso/ text: Lean Inception: Creando conversaciones hacia un producto exitoso.) # 6. Modelo de Kano (image: modelo-de-kano-tecnica-priorizacion-product-management.webp) El modelo Kano para el desarrollo de productos y satisfacción del cliente, creado por el profesor Noriaki Kano, nos ayuda a comprender la satisfacción del cliente con las características del producto y depende del nivel de funcionalidad que proporciona. Ayuda a priorizar las características, atributos del producto o funcionalidades, con respecto a la satisfacción del cliente. Este modelo clasifica las características de un producto en: **• Factores atractivos o de entusiasmo: **Generalmente son atributos que no se esperan los clientes, por lo que cuando están presentes lo que se busca es crear una sorpresa de agrado en el consumidor. **• Factores lineales o normales: **Las características principales del producto, por las cuales el cliente elige una u otra marca. **• Factores imprescindibles, básicos o que “deben estar”: **Se da por sentado que están presentes, y si no lo están crean insatisfacción en el consumidor. Suelen ser las características básicas inherentes del producto y si están no me producen satisfacción (ya que damos por hecho que están incluidas), pero si no están, generan insatisfacción. **• Factores indiferentes: **Se refiere a los atributos que no son percibidos como ni buenos ni malos, se pueden eliminar (para reducir costos). **• Factores de rechazo: **Cuando están presentes el cliente los percibe como negativos, además del costo que implica implementarlos. # 7. Dinero de Monopoly (Comprar una funcionalidad o “Buy a Feature”) (image: monopoly-money-buy-a-feature-tecnica-priorizacion.webp) Para esta técnica se presentan las funcionalidades, características (también pueden ser las Historias de Usuario) que se tienen en consideración, y a los principales interesados o stakeholders se les proporciona dinero ficticio (o del famoso juego Monopoly), que representa el presupuesto total disponible. Enseguida, se le asigna un “precio” a cada funcionalidad o historia y una cantidad de dinero determinada a cada stakeholder para que, con este dinero, cada uno decida cuánto “invertir”. (image: buy-a-feature-monopoly-money-game-priorizacion.webp) Una clave de esta técnica es que un stakeholder no pueda comprar todas las funcionalidades (se debe determinar adecuadamente los precios y el presupuesto), con esto, las conversaciones y la priorización entran en juego basándose en el valor percibido y prioridad de cada funcionalidad (lo cual es muy similar a la realidad, con recursos finitos). Las funcionalidades o elementos que más dinero “hayan recaudado”, es decir, aquellas que compraron más stakeholders, son las más prioritarias. P.D. Acá en **México**, hace ya unas décadas, fueron muy famosos unos billetes ficticios de un personaje llamado (link: https://www.chocomilk.com/es-us/conoce-a-pancho-pantera/ text: “Pancho Pantera”) (personaje de la marca (link: https://www.chocomilk.com/es-us/ text: ChocoMilk)), y estos billetes se llamaban “Pancholares”. También se podrían utilizar los Pancholares en esta técnica de priorización, sería un estilo muy mexicano. (image: monopoly-dinero-pancholares-01-chocomilk-pancho-pantera-02.webp) # 8. Técnica de los 100 puntos (image: 100-puntos-tecnica-priorizacion-dean-leffingwell-02.webp) Esta técnica fue creada por (link: https://framework.scaledagile.com/about text: Dean Leffingwell) (el mismísimo creador de (link: https://scaledagile.com/ text: SAFe)) y Don Widrig, y la esencia es la misma que en la técnica anterior: Priorizar recursos finitos a funcionalidades o elementos en base a su valor percibido. Se otorgan al cliente un total de 100 puntos, y a cada funcionalidad, historia de usuario o elemento a priorizar se le asigna un costo en puntos. La idea es que cada stakeholder al tener una cantidad de puntos asignados proporcione una clara visualización de sus prioridades, y no solo seleccionar todas las características como importantes. Las funcionalidades o elementos que más puntos obtengan son las más prioritarias. # + Bonus: Método de Priorización Spice Girls Aclaro desde este momento que esta técnica “bonus” es una broma, se trata de una sátira muy creativa del equipo de (link: https://www.linkedin.com/in/thevisualagilecoach/ text: Olina Glindevi), de Estocolmo, cofundadora de (link: https://www.linkedin.com/company/the-visual-agile-coach/posts/?feedView=all text: The Visual Agile Coach), que dice lo siguiente: - ¡He tenido suficiente de luchas con modelos de priorización!, ahora simplemente uso el Método Spice Girls. - Oh, ¿Cuál es ese? - Solo les pregunto “So, tell me what you want, what you really really want” (aquella famosa canción de las Spice Girls: “Dime lo que quieres, lo que realmente realmente quieres”). (image: prioritization-spice-girls-tell-me-what-you-want-visual-agile-coach.webp) Imagen de Olina Glindevi, puedes ver el post original en LinkedIn (link: https://www.linkedin.com/feed/update/urn:li:activity:7161632788746649601/ text: aquí.) # Conclusiones Un punto importante que debes tener en cuenta que **hablamos de complejidad, así que no existe una fórmula mágica para priorizar**. Pero dos puntos súper relevantes que puedo compartirte y que son imprescindibles para que estas técnicas funcionen, son los siguientes: • Las matrices, escalas de estimación, índices numéricos y todo lo que se captura en un tablero físico o virtual, no son la respuesta, ya que a final de cuentas hablamos de estimaciones e hipótesis en un determinado sentido (por cierto, si te interesa profundizar sobre este tema de cómo formular **Hipótesis de Negocio**, puedes leer un artículo que escribí sobre este tema (link: https://leonelzapien.com/blog/innovacion-mvp-disenar-y-probar-hipotesis-de-negocio text: aquí)). Lo verdaderamente enriquecedor son las conversaciones que surgen. • Ya que lo enriquecedor son las conversaciones, como menciono en el punto anterior, es un requisito imprescindible (ahora sí que es un elemento “MUST”, si habláramos de la técnica MoSCoW), es que estos espacios donde se realiza la priorización sean **cocreados**, que todas las voces sean escuchadas y haya la diversidad mínima necesaria, es decir, que haya personas de todas las áreas involucradas (especialistas tanto de negocio como del área técnica). • Finalmente, no nos olvidemos de la importancia de adoptar un enfoque experimental:** Inspeccionar y Adaptar **continuamente, obtener retroalimentación lo más pronto (y rápido) posible. ## ¿Conocías estas técnicas de priorización?, ¿Cuáles vas a comenzar a probar con tus equipos?
7 de marzo de 2025 -
Agile, Scrum
¿Scrum Master o Agile Coach? Evolución y competencias del Agile Coach
¿Sabes cuál es la diferencia entre un Agile Coach y un Scrum Master? Veamos primero las referencias, de acuerdo con (link: https://scrumguides.org/ text: La Guía Scrum): "El **Scrum Master **es responsable de establecer Scrum como se define en la Guía de Scrum", así que su alcance "en teoría" se limita a Scrum a nivel equipo y en la organización. Menciono "en teoría" porque la misma Guía Scrum menciona que "Scrum es incompleto de manera intencional", por lo cual en la "vida real" es necesario complementar con otras herramientas. El **Agile Coach**, por otro lado, tiene una perspectiva más amplia y trabaja en toda la organización para fomentar una cultura ágil ((link: https://agilemanifesto.org/ text: principios Agile) y (link: https://www.pmi.org/learning/library/lean-project-management-7364 text: Lean)), esto incluye Scrum, pero va más allá del uso de solo Scrum. El día de hoy voy a hacer doble clic y profundizar un poco en el Agile Coach. # Comencemos con la definición: Agile Coaching Es una colección de habilidades y técnicas que se utilizan para servir a personas, equipos y organizaciones con el fin de habilitar la agilidad organizacional para crear más y mejor **valor**. La práctica del coaching ágil abarca diversas áreas: 1. Una base sólida **Agile y Lean**, apoyado de otras prácticas y marcos. 2. Navegar por múltiples posturas dependiendo de la situación, o, como decimos acá en México: **“Ponernos distintas cachuchas”**, una para cada situación. Algunas de estas “cachuchas” incluyen, entre otras: coaching, enseñanza, facilitación y mentoría. # El Marco de Competencias del Agile Coach El término de Agile Coaching fue acuñado por (link: https://lyssaadkins.com/ text: Lyssa Adkins), autora del libro “Coaching Agile Teams”, quien desarrolló lo que se conoce como el “Marco de Competencias del Agile Coach” (Agile Coaching Competency Framework), en este modelo se definen de cada una de las posturas o “cachuchas” del Agile Coach que mencionamos antes, veamos un poco cada una a detalle: (image: lyssa-adkins-coaching-agile-teams-libro-book-leonel-zapien-lopez-guadalajara-mexico-consultor-cursos.webp) **Coach:** Guía a individuos y equipos en un proceso creativo que les permita alcanzar sus objetivos basándose en sus propios conocimientos y experiencias, en esta perspectiva de Coach, no se brindan “consejos” al equipo, se les guía para ayudarles a alcanzar sus objeticos en base a lo que ya conocen. **Facilitador:** Guía a individuos y equipos de manera neutral para ayudarles a identificar soluciones y tomar decisiones. Un ejemplo aquí sería, cuando ayudamos a un equipo en una retrospectiva a identificar patrones y definir accionables, pero sin “intervenir”, ya que de manera neutral les apoyamos a guiar las conversaciones, moderar las intervenciones, proporcionar herramientas o dinámicas para que surjan las ideas y converjan hacia conclusiones. **Enseñanza:** Proporcionar el conocimiento adecuado en el momento adecuado. En esta “cachucha” sí intervenimos directamente, directamente enseñamos al equipo compartiendo nuestro conocimiento para brindar al equipo nuevas herramientas. **Mentor:** Habilidad para proporcionar conocimiento y perspectivas basado en la experiencia. Bajo esta “cachucha” también intervenimos, aquí proporcionamos guía, perspectivas, conocimiento desde nuestra experiencia, en un sentido es un complemento a la enseñanza “by the book” o “en teoría”. Así mismo, Lyssa Adkins menciona que un Agile Coach debe contar con **maestría en un área** (ella menciona que cada coach debe de enfocarse en un área, a fin de poder mantener el enfoque y desarrollar su "expertise"), para con esta maestría complementar su enfoque como coach. Estas tres áreas son las siguientes: ** 1. Técnica 2. De negocio 3. En Transformaciones Organizacionales.** (image: marco-de-copetencias-agile-coaching-competency-framewrok-lyssa-adkins-leonel-zapien-lopez-guadalajara-mexico-lean-agile-coach.webp) Imagen: El marco de competencias del Agile Coach (por Lyssa Adkins) # ¿Y de qué depende cuándo tomar cada una de estas posturas? Para esto no hay una respuesta específica, depende totalmente del contexto. Algunas consideraciones pueden ser la cultura organizacional, la apertura de la organización al cambio, así como la apertura a la experimentación, el grado de madurez del equipo, entre una infinidad de variables. Ahora, volviendo un poco a lo que comentábamos al inicio sobre el Scrum Master, actualmente (y más que nunca), la importancia de **aportar valor va más allá de limitarnos solo a Scrum**. # Unas notas finales Considero que este término de **“Scrum Master” debe de evolucionar **a incorporar más herramientas a su **baticinturón de Agilista y practicante Lean**, además de incorporar posturas que complementan el rol, como precisamente facilitador, coach, mentor, removedor de impedimentos, agente de cambio, líder servicial, y manager (personalmente para este contexto, prefiero el término "gestor"). Esto lo hemos abordado en otros artículos a futuro. (Aquí, a manera de adelanto, te menciono que estas posturas que acabo de mencionarte sobre el Scrum Master, se basan en un paper escrito por para Scrum.org que se llama precisamente así: “Las 8 posturas de un Scrum Master” (The 8 stances of a Scrum Master), si te interesa, en el sitio de (link: https://www.scrum.org/ text: Scrum.org) puedes leer este paper, (link: https://www.scrum.org/resources/8-stances-scrum-master text: te comparto el link aquí)). (image: 8-stances-of-scrum-master-barry-overeem-leonel-zapien-lopez-guadalajara-mexico-consultor-cursos.webp) Imagen: The 8 stances of a Scrum Master (del paper de Barry Overeem). De igual manera, considero muy personalmente que el rol del Agile Coach debe de evolucionar a un enfoque aún más amplio, ya que, de entrada, el propio nombre de “Agile Coach” suena limitante, tal vez algo como **“Agile-Lean Coach”** pueda ser más amplio, aún a pesar de que en el Marco de Competencias que acabamos de revisar, se menciona una sólida base es Agile y Lean. ¿Conocías el Marco de competencias del Agile Coach?, ¿Qué opinas sobre las posturas del Agile Coach y del Scrum Master? P.D. Si te interesa leer un poco más sobre el pensamiento Lean, puedes leer el artículo aquí en mi Blog que escribí sobre este tema haciendo (link: https://leonelzapien.com/blog/esto-es-lean text: clic aquí). ### Referencias: • Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Lyssa Adkins. • The 8 stances of a Scrum Master. Barry Overeem.
17 de febrero de 2025 -
Agile, Scrum
La paradoja del Agile purista vs Agile pragmático
Soy un ferviente evangelizador de que tanto agile como lean funcionan y tienen un tremendo potencial… y aquí viene el “pero”, y es que dentro de la comunidad de practicantes agile-lean existe una dualidad, los puristas y los pragmáticos. Esta paradoja, desde el origen de los tiempos, ha sido fuente inagotable de controversia y debates. # Los Agile Puristas: Guardianes de la fe Este lado de la moneda son los agilistas que abrazan Agile con ciego fervor. Los principios y prácticas de agile son sagrados, y cualquier desviación de estos es una herejía. Una forma de ser purista, por ejemplo, es apegarnos con punto y coma a** La Guía Scrum**, y cualquier cosa que no se mencione en la guía es visto como un sacrilegio. Para dar un ejemplo concreto, La Guía Scrum menciona que en los Daily Scrum (ese evento que se lleva a cabo todos los días del Sprint y tiene una duración de hasta 15 minutos), se debe de conversar cómo vamos hacia el objetivo del Sprint, y es “contra la guía” responder las **“clásicas tres preguntas”**: 1. ¿Qué hice ayer’ 2. ¿Qué voy a hacer hoy? 3. ¿Tengo algún impedimento? ### Nota #01: Menciono “clásicas preguntas” porque en La Guía Scrum más actual, de noviembre de 2020, esas tres preguntas fueron removidas porque los autores de Scrum mencionas que son muy prescriptivas y limitan la creatividad del equipo y el enfoque hacia el objetivo del Sprint. Entonces, si ves que algún libro por ahí las menciona, probablemente sea un libro que **ya tenga sus años**, ya que es una práctica que se considera** "obsoleta”** (pero esto último lo pongo entre comillas, porque en el siguiente punto lo conversamos a mayor profundidad). (image: lector-en-las-nubes.webp) (Imagen de: https://depositphotos.com) # Los Agile Pragmáticos: Practicantes realistas de la vida Son el otro lado de la moneda. Un pragmático es alguien que entiende los principios y valores de agile, pero entiende que en la **“vida real**” muchas cuestiones dependen del contexto. Continuando con el ejemplo anterior, para un pragmático, Scrum es una herramienta, claro que debe conocer la Guía Scrum, pero entiende que, como todo en la vida, depende del contexto. (image: pragmatico-01.webp) (Imagen de: https://esaludmental.es/pragmatismo) Aquí confieso que en los últimos años he sido un pragmático y **no he respetado la Guía Scrum**, ya que en pleno 2025 he fomentado que los equipos respondan las “clásicas tres preguntas” … ¡Herejía! (si estuviéramos en una caricatura o cartoon, este es el momento en el que llueven tomatazos). …Pero, como he dicho, depende del contexto: Si un equipo es nuevo en Scrum, nuevo en Agile en general, y de reciente formación, ¿Cómo esperamos que desde el día 1 del Sprint 1 tengan en claro el objetivo del Sprint y cómo su trabajo suma a este objetivo?, Aquí es donde debemos dejar de lado el ser puristas y reconocer que las “clásicas tres preguntas” pueden servir como guía para que el equipo vaya dando sus primeros pasos (haciendo sus **“pininos”**, como decimos acá en México), y como líderes serviciales del equipo debemos de acompañarlo en su camino hacia la experimentación y la mejora continua, con vistas a dejar de utilizar eventualmente estas tres preguntas, estas “ruedas auxiliares de la bicicleta” que en este momento necesita el equipo novato, es decir, con vistas a dejar de lado las “tres preguntas” en un lapso de tiempo,** conforme el equipo vaya madurando** y ya no sean necesarias, y ahora sí, nos enfoquemos en el objetivo del sprint. Como pragmáticos debemos de **cuestionar lo que funciona o no funciona**, y qué podemos hacer al respecto, no solo leer La Guía Scrum o el Manifiesto Ágil como un script. # La Paradoja en Acción La verdad es que tanto los puristas como los pragmáticos tienen sus méritos,** la clave está en el balance**, y no en tomar posturas extremistas o fanáticas en cualquiera de los dos casos: Llevar al pie de la letra lo que dice el libro sin evolucionar la práctica, sirve de poco, así como el ser totalmente prácticos o empíricos y no fundamentar con teoría de los libros, puede llevarnos a que nuestras prácticas tal vez no sean del todo sólidas ni sostenibles. (image: conversacion-euqilibrio-01.webp) (Imagen de: https://www.unir.net/revista/educacion/pragmatica-lenguaje) # Conclusiones Entonces, una vez más, la clave está en el equilibrio. Ahora sí que, como Obi Wan Kenobi le dijo a Anakin Skywalker en la batalla final del Episodio III de Star Wars: **“Se suponía que ibas a traer el equilibrio a La Fuerza”**. (image: star-wars-episodio-iii-batalla-final.webp) (Imagen de: Star Wars, Lucasfilm Ltd. LLC. Disney) Tanto si te consideras un purista como un pragmático, al final del día todos estamos en el mismo equipo, trabajando para lograr el mismo objetivo. **Busquemos pues, ese equilibrio, y nunca dejemos de experimentar.** ### ¿Te consideras purista, pragmático, o equilibrado?
31 de enero de 2025 -
Trabajo en Equipo
Una organización como Sistema Adaptativo Complejo
Una organización es un sistema adaptativo complejo **(CAS por sus siglas en inglés, Complex Adaptive System)**, ya que es diverso, conformado por múltiples elementos interconectados (personas) que forman un sistema (equipos, departamentos, divisiones, que a la vez forman parte de un sistema mayor que es la organización), que muestra un comportamiento complejo mientras se adapta a un entorno cambiante y dinámico. Son adaptativos porque tiene la capacidad de cambiar de acuerdo con las condiciones y aprender de la experiencia. Sí, todo eso… :S (image: redarquia-organizacion.webp) # Pero esto no aplica solo a una organización Esta definición de CAS no es exclusiva de las organizaciones: Comunidades de bacterias, de hormigas, de personas, el sistema inmune, colmenas, ciudades, la bolsa de valores, células, países... son todos ejemplos de sistemas adaptativos complejos, ya que todo lo que mencionamos en el primer párrafo aplica también para ellos. (image: cas-ejemplos.webp) Ok, mucho rollo… y ¿Por qué es importante conocer esto y cómo aplica a mi equipo? Porque entender las propiedades de un CAS nos puede ayudar a abordar las iniciativas y formas de trabajar de nuestros equipos y organizaciones. Aquí te comparto un ejemplo: En un CAS, las fuertes **interconexiones e interdependencias** entre sus elementos provocan que un cambio o evento que se puede presentar en un elemento, tenga una gran influencia en otros elementos y eventos posteriores. # Vamos asentando un poco más este rollo con un ejemplo Imagina que en tu equipo quieren eficientar o modificar un proceso, implementar nuevas métricas, introducir **scrum, kanban o una nueva forma de trabajar**. Pues bien, el abordar esta iniciativa solo a nivel de equipo sin considerar las interacciones en la organización, puede impactar en una suboptimización en otro equipo o área. Por ejemplo, si implemento cierto tipo de métricas en un equipo, como número de elementos de trabajo X terminados por mes, haciendo que este equipo se enfoque en entregas y entregas para cumplir su métrica, esto pudiera posiblemente afectar al proceso siguiente, al proceso que está “aguas abajo” del equipo que está haciendo entregas al por mayor, tal vez incrementando el trabajo encolado y consecuentemente el tiempo de entrega, o el número de defectos que llegan, o tal vez el número de elementos que vuelven a manera de retrabajo (en este ejemplo estamos midiendo solo la tasa de entrega, no ligando la entrega con la tasa de defectos o retrabajo). Es un ejemplo muy simplista, pero lo que quiero compartirte es la importancia de una perspectiva más amplia, sistémica, no solo en partes aisladas de un CAS. Un **CAS tiene otras muchas propiedades**, como la adaptación, comunicación, cooperación, emergencia ante situaciones específicas, etcétera. Pero una muy importante es la **autoorganización** (y después, con mayor madurez, la **autogestión**), ya que esta propiedad permite la sobrevivencia de un CAS. (image: equipos-cas.webp) # Conclusiones Dentro de la complejidad de una organización, el permitir y fomentar las interacciones y resolución de problemas de manera local (a nivel equipos, por ejemplo), lo que se conoce como control descentralizado, aumenta la rapidez de la toma de decisiones, y consecuentemente la capacidad de ese equipo o sistema de ajustarse, auto repararse, pivotar, adaptarse, y, finalmente, **maximizar la probabilidad de sobrevivir como organización.** Al final del día, como dice (link: https://www.linkedin.com/in/jurgenappelo/ text: Jurgen Appelo) (escritor, creador de (link: https://management30.com/ text: Management 3.0) y de (link: https://unfix.com/ text: unFIX)), “No podemos controlar un sistema complejo, pero tenemos muchas opciones para guiarlo”. Continuemos inspeccionando, adaptando, gestionando las condiciones del Sistema Adaptativo Complejo, siempre poniendo en el centro a las personas.
19 de enero de 2025 -
Agile, Project Management
La Amalgama del PMI + Agile Alliance
El pasado 3 de enero de manera oficial se confirmó una gran noticia: El Project Management Institute (PMI) ha firmado un acuerdo para integrar a Agile Alliance. El comunicado oficial puedes leerlo (link: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ text: aquí), entre otras cosas menciona: “El futuro de la gestión de proyectos, centrado en el éxito del proyecto impulsado por el valor entregado, no puede depender de distinciones rígidas entre los enfoques de entrega. La integración de Agile Alliance dentro de PMI solidifica aún más el liderazgo de PMI en la transformación de la profesión de proyectos. PMI Agile Alliance se beneficiará del alcance y los recursos globales de PMI, mientras que los miembros de PMI obtendrán un mayor acceso al liderazgo intelectual, las herramientas y los recursos de Agile, mejorando su desarrollo profesional y permitiendo un mayor éxito de los proyectos.” Para encuadrar un poco más de qué va todo esto: # El origen del PMI El PMI, fundado hace más de 50 años, el 3 de octubre de 1969 para ser exactos, ha sido la autoridad y referente a nivel mundial en gestión de proyectos. Durante décadas, la forma (ahora llamada “tradicional”) de gestionar proyectos de manera metodológica ha sido dictada por el PMI. (image: pmi-logo-1998-2024.webp) Es la casa de la prestigiosa certificación (link: https://www.pmi.org/certifications/project-management-pmp text: PMP o Project Management Professional), y un montón de certificaciones más… en gestión de riesgos, del cronograma o de tiempo, gestión de programas, de portafolios, etcétera. Además de incluir en años más recientes, certificaciones en Agilidad. **Nota #01:** El enfoque tradicional o **enfoque predictivo**, se refiere a la manera secuencial y por etapas de gestionar un proyecto, lo que se conoce de manera no oficial pero ampliamente difundida como** “Waterfall” o “Cascada”** (si te interesa conocer un poco más a profundidad sobre Gestión de Proyectos en Cascada, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: aquí)). # El origen de Agile Alliance (link: https://www.agilealliance.org/ text: Agile Alliance), por otro lado, organización sin fines de lucro, fue fundada en 2001 después de la creación del (link: https://agilemanifesto.org/ text: Manifiesto Ágil ) por algunos de los firmantes del propio manifiesto (si te interesa conocer un poco más a profundidad sobre el Manifiesto Ágil, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)), y fue creada “para personas que desarrollan software y ayudan a otros a desarrollar software para explorar, compartir ideas y experiencias”, con el propósito de propagar la adopción del mindset o mentalidad ágil, es decir, de un **enfoque adaptativo**. (image: agile-alliance-logo.webp) Al contrario del (link: https://www.pmi.org/ text: PMI), o de otras instituciones como (link: https://www.scrumalliance.org/ text: Scrum Alliance), (link: https://www.scrum.org/ text: Scrum.org), (link: https://www.scruminc.com/es/ text: Scrum Inc.), y una larga lista de etcéteras… **Agile Alliance no ofrece ninguna certificación**, y, de hecho, en un sentido promueve la experiencia en Agile sin necesidad de obtener una certificación necesariamente. (Si te interesa conocer un poco más a profundidad sobre Agile, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/que-es-agile text: aquí)), # La evolución del PMI y de Agile Por un lado, la gestión de proyectos tradicional evangelizada por el PMI no funciona muy bien que digamos en cierto tipo de proyectos (en entornos volátiles, inciertos, complejos, ambiguos, frágiles, que generan ansiedad, no lineales e incomprensibles… sí, todo eso). Por el otro lado, un hecho innegable es ante el crecimiento del movimiento Agile, el PMI se vio en la necesidad de incorporar también la perspectiva ágil a su catálogo. En su momento agregó la certificación (link: https://www.pmi.org/certifications/agile-acp text: PMI-ACP (Agile Certified Practitioner)), y en 2019 adquirió (link: https://www.pmi.org/disciplined-agile/ text: Disciplined Agile), con lo cual amplió su portafolio y profundizó en el enfoque ágil con certificaciones como Scrum Master, Agile Coach y Value Stream. **Nota #02:** Por cierto, como parte de la reestructuración y evolución que el PMI está haciendo, para este primer y segundo cuarto del 2025, estará liberando el **nuevo path de certificaciones de Disciplined Agile**, entre los cambios es reajustar la certificación de Scrum Master… pero una cosa a la vez, en cuanto haya novedades sobre este tema, pasaré por aquí con un artículo al respecto. El caso es que el entorno llevó al PMI a evolucionar, lo cual está en realidad bien. Por el otro lado, un movimiento que está tomando fuerza es el que plantea **“Agile is dead” o “Agile ha muerto”**. Muy personalmente no considera que sea así ni que no lo sea, sino todo lo contrario, simplemente que es necesaria una evolución para Agile también. Agile debe de evolucionar, al igual que el PMI, y también está tremendamente bien. Por un lado, **se tergiversó el tema con certificaciones para todo, al “por mayor”**, y por el otro lado, se ha logrado desviar un poco del enfoque en el mindset, en aportar valor, Agilidad no solo es mover post-its por un tablero y hacer retrospectivas temáticas de Harry Potter o los Avengers. Entonces, la evolución es más que necesaria. Es bonito y está bien. # La verdad es que no todo es Agile Pero siendo muy abiertos y evitando ser puristas, tampoco todo funciona con Agile o enfoque predictivo, es decir, con entregas incrementales y de manera iterativa… aquí me encanta poner un ejemplo que mi buen amigo (link: https://www.linkedin.com/in/sebastian-lopreto/ text: Sebastián Lopreto), desde Bariloche, Argentina, siempre menciona: “Cuando vos vas al dentista porque te van a extraer una muela (presuponiendo que el diagnóstico está hecho y no ha de otra opción), ¿le dices que te la quite de un tirón, o que te la quite de a poco, de manera incremental y cada dos semanas, hasta que tengas toda la muela fuera de tu boca?” Así que, aunque muchos “agilistas extremistas o puristas” pudieran decir que algo es agile o no lo es, muy personalmente soy un apasionado Agilista y practicante Lean, pero también soy PMP (de hecho, primero fui PMP antes que Scrum Master. De verdad. Hace casi 12 años que obtuve la certificación de PMP, y unos meses después la de Scrum Master de Scrum Alliance), así que siento que puede aportar bastante el conocer a profundidad ambas perspectivas, y, por lo mismo, siempre he dicho que debemos de utilizar la herramienta más adecuada a cada contexto. Volviendo al punto de si algo es agile (adaptativo) o es cascada (predictivo), el PMI pone sobre la mesa además el **“enfoque híbrido”**, en el cual conviven el enfoque predictivo con elementos del enfoque adaptativo, combina trabajo predictivo o en cascada con ágil.… Pero ¿No va esto contra toda la naturaleza del Manifiesto Ágil?… De nuevo: tal vez sí, tal vez no, tal vez todo lo contrario. (image: hibrido-01.webp) La verdad es que, como siempre digo, todo depende del contexto: Ser Agile no significa utilizar (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum) o Extreme Programming, en esencia es un conjunto de valores y principios que, si se viven y se aplican, no importa que sea con un marco de trabajo, método o cualquier otra herramienta. He visto de primera mano los enfoques híbridos, y la verdad es que aportan muchos beneficios. Considero que se puede abordar conociendo ampliamente ambos enfoques, contextualizando con respeto cada herramienta, y de nuevo: Funcionan muy bien. # Ok, lo inimaginable ha ocurrido y se han unido el PMI y Agile Alliance… entonces, ¿ahora qué sigue? He escuchado opiniones muy encontradas. He escuchado a algunos puristas del PMI decir que están sumando a unos “hippies” al instituto. He escuchado a algunos puristas Agile darse de topes en la cabeza y decir que va contra la esencia Agile. Muy personalmente, veo mucho potencial en esta unión. En la “vida real”, siendo un apasionado Agilista y practicante Lean, aplicaba varias herramientas del mundo del PMI en mi día a día. Respetando sus formas, claro. Y funciona de las mil maravillas. (image: pmi-agile-alliance-01.webp) Así que, aunque solo el tiempo dirá si este movimiento ha sido acertado… algunos posibles “pros” y “contras” (dependiendo de cómo lo veas) pudieran ser: ### Posibles Pros: **1. Expansión a otros sectores.** El PMI tiene amplia presencia en industrias donde Agile no ha llegado (o no ha sobrevivido). Este apalancamiento podría ayudar a llevar Agile a esos recónditos lugares. (**Por ejemplo, el PMI acaba recientemente de sacar una certificación específica para la industria de la Construcción,** ¿sabías de esto?, ahora tomemos este ejemplo y consideremos las posibilidades en industrias que requieren cierta especialización). **2. Flexibilidad para la ocasión (¿Certificaciones híbridas?):** Como ya hemos mencionado, no todo es predictivo, no todo es adaptativo. También está lo “híbrido” justo a la mitad. Tal vez pueda ayudar esta amalgama. **3. Impulso (a través de recursos):** El PMI tiene una estructura sólida, esto quizá pudiera brindar de cierta formalidad a la Agilidad. **4. Mayor catálogo (¿En toda la industria?):** En última instancia, si hay oferta hay demanda. El catálogo de productos y servicios del PMI se va a reestructurar (vienen cambios en Disciplined Agile, como ya he mencionado), y esto posiblemente lleve a un cambio completo en la industria entera, recordemos en gran poder de apalancamiento del PMI, y tal vez acaben sumándose otras casas certificadoras a la ola. La clave no es un mayor catálogo, sino un catálogo más adecuado al contexto, y reitero que una certificación no garantiza la habilidad, solo tómalo en cuenta. **5. Poder con Infinity (La IA del PMI):** El poder de la IA es innegable, pues bien, **el PMI tiene una IA particular llamada Infinity** (no es genérica como ChatGPT, Gemini, Claude, etc.), esto pudiera ser una catapulta si se hace específica incorporando Agile y enfoques híbridos. ### Posibles Contras: **1. Burocratización:** El 3er Pro, la estructura sólida del PMI, bien podría ser un elemento en contra pues es una posibilidad que se vuelva rígida, lenta e inflexible a la agilidad. **2. Pérdida de la esencia:** El tan mencionado y ambicionado mindset ágil ¿Podrá sobrevivir dentro de la esencia del PMI sin perder a su vez su esencia?, ¿Podrá emerger algo como una esencia combinada, y es esto posible? **3. Disolución:** Una posible línea de certificaciones nuevas del PMI, pudiera diluir el enfoque, como he mencionado anteriormente, vienen cambios este 2025 en Disciplined Agile. # Otros dicen que ambos ya han muerto Una postura satírica y que la verdad me ha dado mucha risa, es la de (link: https://www.comicagile.net/ text: Comic Agile) (famosa empresa conocida a nivel mundial por hacer tiras cómicas que satirizan todo… (link: https://leonelzapien.com/blog/que-es-agile text: Agile), (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum), (link: https://scaledagile.com/ text: SAFe), (link: https://less.works/ text: LeSS), al propio (link: https://www.pmi.org/ text: PMI), etc.), que ha hecho un post (puedes leerlo (link: https://www.linkedin.com/posts/comicagile_agile-projectmanagement-pmi-activity-7281237516727275520-dizk?utm_source=share&utm_medium=member_android text: aquí)), donde menciona que no solo Agile ha muerto, sino que también el PMI. Aquí te comparto su tira cómica al respecto, la cual dice: - Agile Alliance y el PMI uniendo fuerzas es un trato (o un partido) hecho en el cielo - ¿Por qué? - Porque ambos están muertos. (image: comic-agile-pmi-agile-alliance.webp) **Aclaración: Esta es una sátira de Comic Agile y no refleja para nada mi punto de vista**, solo estoy compartiendo la información desde la perspectiva de distintas fuentes de la manera más objetiva posible. Finalmente, Pierre Le Manh, actual presidente y CEO del PMI hace el anuncio oficial sobre esta unión, si te interesa, puedes leerlo (link: https://www.linkedin.com/posts/pierre-le-manh-3a4158_agile-projectmanagement-leadership-activity-7280964881137242112-Dt0c/?utm_source=share&utm_medium=member_android text: aquí). # Conclusiones Pues bien… el hecho es que la unión entre el PMI y Agile Alliance ha ocurrido. Hay muchísimas preguntas sobre lo que podría venir, nuevas… ¿perspectivas, certificaciones, puntos de dolor?, aún estamos en una etapa muy inicial como para saberlo. Personalmente veo esta unión como algo positivo, considero que nunca se ha tratado de **“PMI vs Agile”**, sino de centrarnos en las personas, aportar valor, adaptarnos y utilizar las herramientas adecuadas a cada contexto. **Las expectativas son muy altas y las posibilidades infinitas.** Ahora, veamos lo que está por venir. ### ¿Qué opinas sobre esta unión?
6 de enero de 2025 -
Innovación, Trabajo en Equipo, Cultura Organizacional
La importancia de un entorno de alta Seguridad Psicológica
En el mundo competitivo actual, y particularmente en el mundo de la **Agilidad** hablamos de equipos autogestionados y empoderados, de experimentación e innovación como piezas clave para el alto de desempeño y lograr organizaciones adaptativas. Sin embargo, no es nada sencillo llevarlo a la práctica, no podemos llegar con nuestros equipos y decirles: “A partir del lunes son autogestionados e innovadores”. Sin importar nuestro rol, bien seas un **Scrum Master, Agile Coach, Project Manager, Product Manager, o cualquier posición de liderazgo**, si queremos que las personas experimenten, primero que todo, deben de sentirse seguras para opinar, respaldadas para tomar decisiones y saber que realmente pueden experimentar (dentro de las restricciones adecuadas de cada organización), sin temor a ser castigadas, reprendidas, señaladas o marginadas. # ¿Qué es la Seguridad Psicológica? Esto que te menciono tiene nombre y apellido, se llama **Seguridad Psicológica,** término que fue acuñado por Amy C. Edmondson, quien define la Seguridad Psicológica como "la creencia en la cual una persona siente que no será castigada o humillada por hablar y compartir sus ideas, preguntas, inquietudes, o errores.” Hay otra definición que también me parece muy adecuada, personalmente me gusta mucho porque va por “niveles” y ayuda a llevarnos de la mano en este camino hacia un entorno de alta seguridad psicológica. En esta definición el Dr. Timothy R. Clark menciona que la Seguridad Psicológica “es una condición en la cual la persona se siente (1) incluida, (2) con seguridad para aprender, (3) seguridad para contribuir, y (4) seguridad para retar al status quo. Todo esto, sin ser castigado, avergonzado o marginado de alguna manera.” (image: seguridad-psicologica-oficina-02.webp) # ¿Y qué tiene esto que ver con mis equipos? Bueno, pues resulta que en diversos estudios llevado a cabo para identificar los factores que explican el alto desempeño de los equipos, la Seguridad Psicológica fue calificado como el elemento más importante. Empresas como Google han sido reconocidas por un entorno de alta Seguridad Psicológica. La Seguridad Psicológica es el cimiento de los equipos de alto desempeño, si las personas no se sienten seguras para cuestionar el Status Quo, la forma en la que se realizan actualmente las cosas en la organización, jamás habrá mejoras reales o sostenibles, jamás habrá creatividad ni innovación. (image: seguridad-psicologica-oficina.webp) # Las 4 etapas de la Seguridad Psicológica Timothy R. Clark nos menciona que existen cuatro etapas de la Seguridad Psicológica, lo cual es una manera muy sencilla de “medir” el nivel en el que se encuentran nuestros equipos. De acuerdo con Clark, las cuatro etapas son las siguientes: 1. Seguridad de Inclusión. 2. Seguridad para Aprender. 3. Seguridad para Contribuir. 4. Seguridad para Desafiar el Status Quo. (image: seguridad-psicologica-4-etapas.webp) Veamos un poco más a detalle cada etapa. # 1. Seguridad de Inclusión Formamos parte de un grupo de dos maneras: la formal y la informal. La manera formal es cuando tenemos un contrato, estamos contratados, o nos asignan a un equipo. Pero esto no quiere decir que seamos aceptados en el mismo más allá del “papelito”. La aceptación por los miembros del equipo es la **“aceptación informal”**. Pues bien, esta etapa se refiere a la percepción de sentirnos aceptados y respetados, con igual trato que todas las demás personas del equipo. # 2. Seguridad para Aprender Sin seguridad para aprender, las personas nos mantenemos pasivas debido al riesgo de actuar, y aquí entra justo lo que mencionaba al inicio, si las personas ven que hay represalias y señalamientos por errores, si no se sienten respaldadas, no habrá experimentación y las personas “experimentarán a la segura”, algo así **como-que-hago-que-experimento**, pero no asumo riesgos y pruebo solo lo que sé que va a funcionar. En esta etapa, las personas nos sentimos seguras para descubrir, para hacer preguntas y experimentar. # 3. Seguridad para Contribuir En esta tercera etapa, las personas nos sentimos invitadas y respaldadas para participar de manera activa y con pleno derecho a contribuir de manera genuina, sin filtros, sin temor a ser aislados o marginados por nuestras ideas y contribuciones. Aquí abro un paréntesis muy importante, ya que como dicen mis amigos argentinos y chilenos: **¡ojo al piojo!** Contribuir sin filtros no quiere decir que tenemos derecho a ser irrespetuosos, nada de eso, se refiere a que podemos expresar abiertamente lo que sentimos, desde la asertividad. # 4. Seguridad para Desafiar el Status Quo Primero lo primero, ¿Qué es el Status Quo? A manera de contexto, esta expresión viene del latín y significa ”en el estado en que” y su definición es el estado de las cosas de un determinado momento. Es decir, se refiere al famoso **“Aquí se han hecho las cosas siempre así”**, ¿Te suena familiar? (image: status-quo.webp) Sin un desafío al Status Quo jamás habrá mejoras reales o sostenibles, jamás habrá creatividad ni innovación. Pues bien, dicho lo anterior, la última etapa de la Seguridad Psicológica permite a las personas sentirnos confiadas para cuestionar y proponer opciones que reten el Status Quo actual, sin temor a cualquier tipo de represalia, castigo, o daño a su reputación personal. # Límite de la innovación Timothy Clark menciona que antes de esta etapa está el límite de la **innovación**, y se refiere a que la innovación, ese oscuro objeto del deseo al que aspiran todas las organizaciones, solo puede alcanzarse si se han cubierto las primeras 3 etapas de la Seguridad Psicológica. En este sentido, es similar a la pirámide de necesidades de Maslow: No podemos pasar a los niveles superiores (al menos de manera sostenible), si no hemos cubierto los niveles de la base. Por ejemplo, **Google**, ese gran referente en tema de innovación, públicamente ha mencionado que realiza miles de experimentos al año. Sí, no fue error de dedo: Miles, así con tres ceros. Pues bien, el mismo Google ha mencionado también que la gran mayoría de sus experimentos fallan (personalmente no me gusta decir que un experimento falló, prefiero verlo como que no resultaron conforme a lo esperado. Lo cual no es una falla, ya que estamos obteniendo “Aprendizaje validado”, como menciona Eric Ries en su libro (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: “El Método Lean Startup”, artículo que por cierto puedes leer aquí)). (image: google-logo.webp) Pero si la mayoría de los experimentos que ejecuta Google no resultan conforme a lo esperado, ¿Tiene sentido continuar experimentando?, bueno, pues con los experimentos que sí han funcionado conforme a lo esperado, de ahí han surgido productos como Gmail, Google news, Sky map, entre una larga lista de etcéteras. # Conclusiones Si las personas nos sentimos escuchadas y respaldadas, si sentimos que podemos opinar y experimentar sin señalamientos, represalias ni marginaciones, solo entonces, puede emerger de forma sostenible la autogestión, el empoderamiento y la experimentación. Como líderes, es necesario que fomentemos un **entorno de alta seguridad psicológica** para nuestros equipos, donde puedan estimar, proponer mejoras, levantar la mano si hemos cometido un error, probar nuevas prácticas o herramientas, todo esto lleva gradualmente a la mejora continua, a equipos de alto desempeño, a organizaciones que aprenden y que son capaces de responder rápidamente para adaptarse. Pero** ¡ojo al piojo!** otra vez, esto no quiere decir que la Seguridad Psicológica por sí sola sea lo que se necesita en las organizaciones para la innovación y el alto desempeño, se requieren más engranes para desarrollar un ecosistema de innovación, pero la Seguridad Psicológica es uno de los pilares que cimentan este entorno y sin Seguridad Psicológica no podemos avanzar ni siquiera un pasito hacia la innovación. **¿Qué opinas de este concepto?, ¿En cuál de estas cuatro etapas consideras que está tu equipo?** # Referencias • La organización sin miedo: Crear seguridad psicológica en el lugar de trabajo para el aprendizaje, la innovación y el crecimiento. Amy C. Edmondson. • Las 4 etapas de la seguridad psicológica: El camino de la innovación a través de la inclusión. Timothy R. Clark.
15 de noviembre de 2024 -
Management 3.0, Gestión del Cambio
El "Método Mojito" en Gestión del Cambio: Change Management 3.0
Ya lo había mencionado anteriormente en otro artículo, pero es súper crítico, así que abrimos con esta estadística de nueva cuenta:** De acuerdo con diversos estudios, más del 70% de las iniciativas de cambio fracasan**. Las razones principales de este fracaso van desde la resistencia de los empleados hasta la falta de un modelo de liderazgo. En resumen… las iniciativas de cambio fracasan debido que no consideraron y obviaron cuestiones de lo más complejo e importante de las organizaciones: Las personas. El día de hoy vengo a poner este tema sobre la mesa: El modelo de Gestión del Cambio que propone Jurgen Appelo: **Change Management 3.0.** # Pero primero lo primero: ¿Qué es un cambio organizacional? Cambio organizacional es el proceso en el cual una empresa modifica un elemento importante de su organización, por ejemplo: Un modelo nuevo de negocio, un cambio tecnológico que modifica la forma de operar, o sus procesos internos. Estos cambios organizacionales tienen un impacto en la organización ya que pueden implicar cambios en los objetivos de la empresa, en los productos o servicios que ofrecen, o en sus operaciones… pero lo realmente complejo de estos cambios es que implican un cambio en las personas, en la manera en que venían trabajando. Así, cuando en tu organización ha habido alguna reestructuración que modifica o crea un departamento o división nueva, modifican su modelo de negocio, implementan una nueva forma de trabajar (por ejemplo, la adopción la Agilidad o Agilismo a través de Scrum, Kanban, Management 3.0, entre otros, o la implementación de programas de Mejora Continua, 5s, Manufactura Esbelta, etcétera), cuando ha habido implementaciones de nuevas herramientas tecnológicas como sistemas ERP, herramientas de colaboración en la nube, automatizaciones, o cualquier otro cambio tecnológico… todos estos son ejemplos de cambios organizacionales. ¿Te suena familiar esta situación? # Importancia de la Gestión (o acompañamiento) del Cambio La gestión del cambio es la aplicación de un proceso estructurado y un conjunto de herramientas para abordar el lado humano de los cambios, se centra en las personas, en cómo ayudarlas a no temer, reducir la resistencia, a participar, y adoptar un cambio en su trabajo diario. # Ahora sí, vamos al punto: Change Management 3.0 El modelo de Gestión de Cambio de Management 3.0, que es parte del kit de herramientas de Management 3.0, propone 4 aspectos: 1) Bailar con el sistema con el modelo Planear-Hacer-Verificar-Actuar (PDCA). 2) Centrarnos en las personas con el modelo ADKAR. 3) Estimular la red con la Curva de Adopción Tecnológica. 4) Gestionar el ambiente con el modelo de las 4 "i" + 1. (image: leonel-zapien-lopez-change-management-3.0-gestion-del-cambio-consultor-curso-guadalajara-mexico.webp) Este “super modelo”, como lo describe Jurgen Appelo, lo llama así porque se forma a su vez de otros modelos. Es lo que Jurgen llama el **“Método Mojito”**: Tomar partes que ya de por sí son buenas (como la hierbabuena, el agua mineral, el limón), para crear algo que combinado es aún mejor. Veamos cada uno de estos cuatro elementos: # 1) Bailar con el sistema con el modelo Planear-Hacer-Verificar-Actuar (PDCA) El modelo Planear-Hacer-Verificar-Actuar (PHVA en español, o en inglés PDCA por sus siglas) es un modelo iterativo de 4 pasos creado por Walter Shewhart y popularizado por Edwards Deming, utilizada ampliamente en el mundo de la Calidad para la mejora continua (y de ahí llevada a diversas industrias y sectores), pero que por que puede ayudar a una iniciativa de gestión del cambio. El ciclo PHVA es un ciclo que nunca termina: (image: leonel-zapien-lopez-ideas-agilidad-ciclo-pdca-mejora-continua-lean-kaizen-guadalajara-mexico.webp) **Planear:** ¿Cuál es el propósito del cambio?, las personas necesitan tener claro por qué es necesario cambiar, cuál es la meta, y transmitirla. **Hacer:** Partiendo de la visión inicial del cambio, avanzar paso a paso hacia la dirección deseada, que todas las personas vean y entiendan cómo se está avanzando (siempre manteniendo un enfoque experimental, por eso viene el siguiente paso del modelo). **Verificar:** Recabar retroalimentación o feedback de manera rápida, en ciclos cortos, medir cómo va respondiendo el sistema (en este caso el sistema puede ser mi equipo, departamento u organización) a los pasos que hemos avanzado hasta el momento. **Actuar:** Ya que hemos medido resultados, determinar qué ajustes son necesarios hacer en la iniciativa de cambio: ¿Qué ha funcionado bien que debemos de mantener y reforzar?, ¿Qué experimentos no funcionaron como se esperaba y debemos ajustar? Recuerda que debemos de experimentar, pues estamos tratando con complejidad. Una organización es un “organismo vivo”, un **Sistema Adaptativo Complejo **(CAS por sus siglas en inglés). # 2) Centrarnos en las personas con el modelo ADKAR El Modelo ADKAR® (creado por Prosci®), es un modelo orientado a resultados, con enfoque en las personas, para acompañar un proceso de cambio. ADKAR es un acrónimo en inglés, significa que para un cambio debemos de fomentar en las personas: • Awareness: Consciencia • Desire: Deseo • Knowledge: Conocimiento • Ability: Habilidad o Capacidad • Reinforcement: Reforzar (image: leonel-zapien-lopez-ideas-agilidad-adkar-change-management-gestion-del-cambio-curso-guadalajara-mexico.webp) Revisemos cada uno de los elementos del modelo ADKAR **((link: https://leonelzapien.com/blog/gestion-del-cambio-organizacional-modelo-adkar text: si quieres conocer a mayor profundidad este modelo, puedes leer aquí un artículo que escribí específico de este modelo)**). **Awareness: Consciencia:** Crear consciencia en las personas de la necesidad del cambio, por qué es importante cambiar y qué puede suceder si no cambiamos. **Desire: Deseo:** Que las personas entiendan qué implica el cambio para ellas, para fomentar que apoyen y “se suban” a la ola del cambio, que deseen activamente el cambio. **Knowledge: Conocimiento:** Que las personas entiendan y reciban el conocimiento necesario para que puedan desempeñar su “nuevo papel” en el cambio, lo que se espera de ellas. **Ability: Habilidad o Capacidad:** Que una persona tenga conocimiento no significa necesariamente que tenga la habilidad. Hay que apoyar para que las personas desarrollen la habilidad en su día a día, para que incorporen este conocimiento y desarrollen la capacidad o habilidad. **Reinforcement: Reforzar:** ¿Qué necesitamos incentivar para que el cambio se refuerce, se mantenga a lo largo del tiempo? De la misma manera, pero en sentido opuesto: ¿Qué conductas o situaciones, que no están alineadas con el cambio, necesitamos desincentivar? Esto ayuda a hacer que el cambio con todo lo que implica: La nueva forma de trabajar, los nuevos métodos, los nuevos roles, etc., se mantenga en el tiempo y sea sostenible. # 3) Estimular la red con la Curva de Adopción Tecnológica La curva de Adopción Tecnológica, curva de Adopción de las Innovaciones, o curva de Rogers, es un modelo de referencia creado por Everett Rogers que ayuda a identificar el comportamiento de las personas ante una adopción tecnológica, pero que ayuda a modelar de igual manera cómo las personas que pueden apoyar y oponerse a un cambio. Esta curva indica que existen los siguientes “tipos” de personas: (image: leonel-zapien-lopez-ideas-agilidad-curva-adopcion-tecnologia-innovacion-guadalajara-mexico.webp) **Innovadores (2.5%)** Aquellas personas que son las más probables de adoptar un cambio de manera inicial, de subirse a una nueva ola, una nueva tendencia o tecnología. **Adoptadores tempranos (13.5%)** Una vez que los innovadores han adoptado el cambio, este grupo son los siguientes en apertura para probar e intentar nuevas cosas, se unen fácilmente una vez han visto que ya otros lo hacen. **Mayoría temprana (34%)** A la mayoría de las personas no le interesa el cambio, pero la mayoría temprana se puede subir si ven que suficientes personas (masa crítica) lo está haciendo, que el cambio es confiable y seguro. **Mayoría tardía (34%)** Son muy escépticos respecto al cambio, se requiere un esfuerzo mayor, que vean los beneficios tangibles de por qué aproximadamente la mitad de las personas se han subido al cambio, estar seguros. Solo entonces se unirán. **Rezagados (16%)** Este grupo de personas son totalmente renuentes al cambio, se suman cuando ya todos los demás lo han hecho y porque prácticamente no les queda de otra. # 4) Gestionar el ambiente con el modelo de las 4 "i" + 1 El último bloque de este súper modelo, es tener presente que no es posible intentar que una a una las personas quieran subirse al nuevo cambio, sin embargo, lo que buscamos es gestionar las variables adecuadas para que el cambio sea sistémico, ¿por qué este enfoque en el sistema?, porque está comprobado que, **si cambiamos las condiciones del sistema, las personas que estamos dentro del sistema cambiamos en consecuencia**. Estas variables son el modelo de las 4 “I” + una “I” adicional que agregó Jurgen Appelo: • Information: Información • Identity: Identidad • Incentives: Incentivos • Infrastructure: Infraestructura • Institutions: Instituciones (image: leonel-zapien-lopez-ideas-agilidad-gestion-del-cambio-guadalajara-mexico.webp) ¿Qué condiciones en cada una de estas “i” debemos de cambiar en el contexto de nuestro equipo u organización para que el cambio sea sostenible? (esto ayuda a “reforzar” el último bloque del modelo ADKAR: Reforzar). # Conclusiones La** resistencia al cambio** es natural y en el contexto organizacional no es la excepción. Más de las 70% de las iniciativas de cambio fallan, por esto es importante gestionar o acompañar adecuadamente el cambio organizacional al nivel más importante: Desde las personas. Un punto importante de este súper modelo del cambio es el enfoque que propone en la experimentación, recuerda que estamos tratando con personas, con complejidad. **Una organización es un “organismo vivo”, un Sistema Adaptativo Complejo** (CAS por sus siglas en inglés), por eso el enfoque experimental es la única manera de proceder, en este caso, con una iniciativa de cambio. ¿Conocías este modelo o alguno de sus aspectos?, ¿Cómo has llevado la gestión del cambio con tus equipos? Puedes descargar el modelo de** Change Management 3.0** de Jurgen Appelo haciendo clic (link: https://leonelzapien.com/recursos?item=gestion-del-cambio-de-management-3-0 text: **aquí mismo en mi sitio web)**. # Referencias • (link: https://www.amazon.com.mx/Management-3-0-Leading-Developers-Developing/dp/0321712471/ref=sr_1_1?__mk_es_MX=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2S322GDDF51KX&dib=eyJ2IjoiMSJ9.KsfNeZcE0dyeaMih21VU7LjnmhwIYhTHvJ5yQTYSJJTgMsVkJZPl4NIFi2lIxYcjb-SvftpMEwa-LCHL2fls8ilvOHl1647uoWYj-vP2TNmVi8OjOXSLxVZZG6OFGrRTtQWEpZBdQ_U_Y5M1YSwnBeN8M4yQ3fLftyVtEYBh7rPkto9YEh3lWVyelNgMsINnY3jMm7xsshtXUh5IqyUFm3D5itMop2lPqZ61hXyWaU_Be0nn7EPElJxdcJQyOJWc9IOlm8yhpCEJnE0VAj1nHFbbcreZsyYIFpcT4chTNpU.VGBXEWOSNN2wPHZfm1QEk1GS6bm5JMz7tEek7o7udZM&dib_tag=se&keywords=management+3.0&qid=1728225452&sprefix=management+3.0%2Caps%2C117&sr=8-1&ufe=app_do%3Aamzn1.fos.de93fa6a-174c-4df7-be7c-5bc8e9c5a71b text: Management 3.0: Leading Agile Developers, Developing Agile Leaders. Jurgen Appelo). • (link: https://www.amazon.com.mx/How-Change-World-Management-3-0/dp/9081905112/ref=sr_1_2?__mk_es_MX=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2S322GDDF51KX&dib=eyJ2IjoiMSJ9.KsfNeZcE0dyeaMih21VU7LjnmhwIYhTHvJ5yQTYSJJTgMsVkJZPl4NIFi2lIxYcjb-SvftpMEwa-LCHL2fls8ilvOHl1647uoWYj-vP2TNmVi8OjOXSLxVZZG6OFGrRTtQWEpZBdQ_U_Y5M1YSwnBeN8M4yQ3fLftyVtEYBh7rMi38XwFuMtPEm7QazskWmvn7J64fu9bVt9LXHYQGg_PPt0qNAv7YbELBZt2EnM-TFaLM4s6Uh3GYJU6K0M4EjO9IOlm8yhpCEJnE0VAj1nHFbbcreZsyYIFpcT4chTNpU.HeHvN6wLuy4oB4N-MO0NPWCIEtzWus_2VSK6cQGGq3w&dib_tag=se&keywords=management+3.0&qid=1728231439&sprefix=management+3.0%2Caps%2C117&sr=8-2&ufe=app_do%3Aamzn1.fos.de93fa6a-174c-4df7-be7c-5bc8e9c5a71b text: How to change de World: Change Management 3.0. Jurgen Appelo).
6 de octubre de 2024 -
Lean
Esto es Lean
Existen muchas definiciones de “Lean” como corriente o pensamiento, esta palabra que traducido literalmente significa “esbelto, delgado, magro”, una definición que me pareció muy sencilla es la que proponen los autores del libro “Esto es Lean / This is Lean”, quienes proponen: Lean es una estrategia de eficiencia de flujo, con dos principios clave: Justo a Tiempo (Just in Time o JIT), y Gestión visual (Visual Management). En el artículo de hoy conversaremos sobre este genial libro, “Esto es Lean / This is Lean”, escrito por Niklas Modig & Pär Ahlstrom. ¡Arrancamos! # No es una clase de historia, pero un poco de contexto: “Toyota es el padre del movimiento Lean” Todo inicia con el **Sistema de Producción de Toyota**, el cual le llevó a ser la empresa número uno en fabricación de coches a nivel mundial. Toyota, partiendo de una época de crisis y escases de recursos después de la Segunda guerra mundial, la necesidad los llevó a enfocar su organización en el usuario, en cubrir sus necesidades de manera rápida y a un precio competitivo. La clave de su éxito: Lograrlo a través de la eliminación de desperdicios en su flujo valor, produciendo vehículos solo cuando hubiera demanda del cliente, creando un sistema de producción bajo demanda. (image: this-is-lean-esto-es-lean-toyota-logo-toyota-prodcution-system.webp) ¿Qué tipo de desperdicios eliminaron de su proceso?, los tiempos de espera, el retrabajo por problemas de calidad, el exceso de inventario, los movimientos innecesarios, el sobre procesamiento, etcétera. Así nació lo que se conoce como Sistema de Producción Toyota (**TPS por sus siglas en inglés, Toyota Production System**), que ha sido “la referencia” para diversas industrias. En 1988 John Krafcik escribió el artículo “Triunfo de Lean Production System” ((link: https://edisciplinas.usp.br/pluginfile.php/6889199/mod_resource/content/4/krafcik_TEXTO_INTEGRAL.pdf text: puedes descargar el artículo original aquí)), donde trata sobre los sistemas de fabricación “robustos”, contra lo que hacía Toyota y su producción bajo demanda, definiendo el proceso de Toyota como “magro o esbelto”, es decir, “lean”. En este año se acuña el término “lean” y el Sistema de Producción de Toyota es traído a occidente. # Denominación de Origen En mi caso, soy de Guadalajara, Jalisco, en México. La tierra del Tequila. El Tequila es la bebida que se extrae de un tipo de agave específico sembrado en esta región de México, es su “denominación de origen”. Cualquier otra bebida extraída de agave, aunque sea el mismo tipo de agave, pero fuera de la región específica de México, no es Tequila, simplemente es Mezcal. Es el nombre genérico. Lo mismo sucede para diferenciar entre un Whisky y un Scoth (denominación de origen de Escocia), entre un Puro y un Habano (denominación de origen de Cuba). (image: this-is-lean-esto-es-lean-agave-tequila-jalisco-s.webp) fuente de imagen: entrecopasdeagave.com . Esta analogía me hace sentido cuando hablamos del** Toyota Production System o TPS (denominación de origen) y Lean (denominación genérica)**. Lean no es lo mismo que el TPS, digamos que se basa en él. Ambos buscan reducir los despilfarros o desperdicios, optimizar los procesos, maximizar la eficiencia de flujo (entre muchas otras cosas), pero como tal, son en realidad hablamos de dos movimientos ahora independientes. # El contexto El libro inicia con una historia de dos mujeres, nos lleva con todo detalle para explicarnos sin tecnicismos la diferencia entre la eficiencia de flujo contra la eficiencia de recursos. En la primera historia, una mujer vive “en carne propia” la eficiencia de utilización de recursos en un sistema de salud. En este enfoque, el objetivo es maximizar la utilización de los recursos como equipo especializado para realizar estudios clínicos, así como la máxima utilización de personas (personal que opera los equipos, enfermeras, médicos, etcétera), es decir, que “estén la mayor parte del tiempo ocupados”. **Primero, aquí abro paréntesis:** Si vamos a hablar de flujo de valor, primeramente, considero importante definir qué es esto: Un flujo de trabajo o (flujo de valor), son todos los pasos relevantes de un proceso que una organización necesita para producir un producto o servicio. **Cierro paréntesis, continuamos con el tema.** ## Perspectiva de Eficiencia de Recursos En este ejemplo, la paciente hace una cita al médico, la cita se la programan para dos días después, cuando llega el día acude al médico, quien considera que es necesario hacerle un estudio especializado, para lo cual solo hay disponibilidad de citas un par de semanas después. Cuando finalmente se ha realizado el estudio, debe de ir ahora a visitar al médico especialista, después otra cita más, y para cuando finalmente el médico le da el diagnóstico, han pasado en total 42 días. ¿Está bien esto o está mal?, nada de eso, todo lo contrario En este caso se mide la eficiencia de utilización de los recursos y personas, así, por ejemplo, se busca que el primer médico que visitó la paciente siempre esté “ocupado”, atendiendo un paciente tras otro sin que el médico pare (se considera muy costoso que tenga tiempo “ocioso”), mejor que sean los pacientes quienes esperan. Lo mismo con el equipo médico con el cual le realizan el estudio, igual consideración que con el médico especialista. Cuando nos centramos en la eficiencia de recursos, estos están siempre ocupados, con filas de materia prima o piezas en una línea de manufactura, en espera de ser procesadas (en este ejemplo, fila de personas esperando días para ser atendidas). **En la eficiencia de recursos medimos la tasa de utilización de los recursos**, buscando estar lo más cerca posible del 100% (claro que esto es muuuuuy ideal). (image: this-is-lean-esto-es-lean-eficiencia.webp) **Ejemplo Eficiencia de Recursos: ** Recurso: Escáner para estudios clínicos Tiempo de utilización: 6 horas Tiempo disponible (en un día): 24 horas. Eficiencia del recurso: Tiempo de utilización / Tiempo disponible = 6 horas / 24 horas = 25% Ok, pero en si la clínica no opera las 24 horas del día, digamos que solo 8 horas al día, tenemos: Tiempo disponible (en un turno): 8 horas. Eficiencia del recurso: Tiempo de utilización / Tiempo disponible = 6 horas / 8 horas = 75% ## Perspectiva de Eficiencia de Flujo Desde la perspectiva de la eficiencia de flujo, la unidad (materia prima, piezas en una línea de manufactura, o las personas en este ejemplo), sea procesada lo más eficientemente posible. Volviendo al ejemplo del sistema de salud y la atención médica, el objetivo aquí es que la paciente sea atendida lo más pronto posible, desde que inicia el proceso (cuando hace cita para la primera revisión médica) hasta que termina este flujo de valor (cuando recibe el diagnóstico), Mientras más pronto sea atendida la persona (o procesada la pieza en la línea de manufactura), mucho mejor. La clave en este cambio de enfoque es que, los tiempos de espera se consideran un despilfarro o desperdicio, ya que no aportan valor al paciente, es decir, son tiempo en los que no se está atendiendo directamente su necesidad o resolviendo su problema, solo está esperando a que los recursos y personas tengan capacidad disponible para atenderlo. Por lo tanto, buscamos eliminar (o minimizar lo más posible) estos tiempos de espera. Los autores nos comparten ahora una segunda historia de una mujer, que, bajo similares condiciones en su estado de salud, asiste a otra clínica. La diferencia es que en esta clínica se cuenta con todo lo necesario para brindar el diagnóstico en el momento: Médicos, Equipo especializado, personal para operar el equipo, enfermeras, asistentes, médicos especialistas. En esta segunda historia, la paciente recibe su diagnóstico en solo 120 minutos. Aquí una nota, el tiempo total que la paciente duró en la clínica fueron 120 minutos, claro que también hay tiempos de espera, por ejemplo, esperar a que el equipo clínico procese el estudio para dar un resultado, el tiempo de interpretación, etcétera. Solo que los tiempos son mucho menores. Teniendo lo anterior en cuenta, la paciente pasó 80 minutos en atención “activa”, los restantes 40 minutos fueron tiempos de espera como los mencionados anteriormente. En este caso, la eficiencia de flujo se mide desde la perspectiva de la paciente, el tiempo total que pasa en la clínica. Así que, para tratar de reducir este tiempo al máximo, se dispone de médicos “ociosos” (tienen capacidad disponible para atender a un paciente en cuanto llegue), lo cual permite una mejor experiencia para el usuario. **Ejemplo Eficiencia de Flujo Paciente #2: ** Tiempo activo de atención de la paciente: 80 minutos Tiempo total hasta que la paciente recibió el diagnóstico: 120 minutos. Eficiencia de flujo: Tiempo de atención / Tiempo total = 80 minutos / 120 minutos = 66.67% Pero aquí estamos comparando peras con manzanas, en el primer ejemplo se midió el porcentaje de utilización de un recurso, en este ejemplo estamos midiendo el tiempo de atención de la paciente. Para poder tener una comparativa adecuada, debemos medir lo mismo en ambos casos. Así que, desde la perspectiva de la paciente en el caso de la Eficiencia de Recursos, los 42 días que transcurrieron para que la paciente recibiera su diagnóstico (1,008 horas), tendríamos algo como esto: **Ejemplo Eficiencia de Flujo Paciente #1: ** Tiempo activo de atención de la paciente: 2 horas Tiempo total hasta que la paciente recibió el diagnóstico: 1,008 horas Eficiencia de flujo: Tiempo de atención / Tiempo total = 2 horas / 1,008 horas = 0.2% Aquí podemos ver el impacto de ambas aproximaciones: 0.2% contra 66.67% Claramente en el ejemplo #2 la eficiencia de flujo es mucho mayor, por lo cual la experiencia de la paciente es muchísimo mejor, pero consecuentemente es un servicio más costoso (se tienen personas y recursos con tiempo “ocioso” para garantizar tener capacidad disponible cuando se requiera). ¿Es esto también un despilfarro o desperdicio el no tener a las personas ocupadas al 100%? Como todo en la vida, depende. Imaginemos un escenario donde en una base de bomberos, los bomberos están al máximo de utilización de tal manera que, cuando surge un incendio, el tiempo de espera para que puedan atenderlo fuera de 60 minutos. ¿Sería viable? (image: this-is-lean-esto-es-lean-bomberos.webp) fuente de imagen: tv.buap.mx . Entonces, no es que la eficiencia de flujo sea buena ni que la eficiencia de recursos sea mala. Como vemos, depende del contexto. La** eficiencia de flujo no consiste en hacer más rápido nuestro producto o servicio,** no depende solo de incrementar la velocidad en la entregamos valor, se trata de medir la “densidad de valor”, esto es, **eliminar las actividades que no aportan valor**, como es el caso de los tiempos de espera. # Ok, mucho rollo, pero ¿Qué es Lean? Lo autores comienzan, antes de explicar Lean, explicando lo que no es Lean. El concepto de Lean es que ha sido definido de muchas maneras (o mejor dicho, a diferentes niveles de abstracción), de ahí que exista un poco de confusión. El primer problema es que Lean se define a diferentes niveles de abstracción. Por un lado, hay autores que definen Lean como una filosofía, una mentalidad o* mindset*, y hay quien lo lleva a niveles abstracción más bajos como prácticas puntuales. Esto nos lleva a confundir el “cómo” con el “por qué”. **Debemos de empezar y centrarnos en el propósito, sin acotarnos en el “cómo”**. Es por esto que, muchas organizaciones se centran en copiar prácticas de Toyota y esperan obtener los mismos resultados, pero lo Toyota generó esas prácticas partiendo del objetivo que tenían, las prácticas dependen, además de todo, de su contexto particular. # Esto es Lean Entonces, **¿Qué rayos es Lean?** Primeramente, Lean no define prácticas específicas, permite que las prácticas nazcan dentro del contexto de cada organización, en la búsqueda de la eficiencia de flujo y la mejora continua. Definir prácticas específicas es acotar el alcance de Lean. **Lean es una estrategia de eficiencia de flujo, con dos principios clave:** **1. Justo a Tiempo (Just in Time o JIT)**, alinear todo su el flujo de valor a partir de entregas justo a tiempo a todos los niveles, desde materia prima, partes ensambladas de su proceso, hasta el inventario final, evitando generar cantidades industriales de inventario, que es una manera de desperdicio. **2. Gestión visual (Visual Management)**, utilizar herramientas visuales como tableros, tarjetas indicadoras, código de colores, alarmas visuales, etcétera, que permitan mantener la visibilidad del proceso, y tomar decisiones. (image: this-is-lean-esto-es-lean-fabrica-visual-visual-management.webp) fuente de imagen: visualmitra.com . Por último, el concepto más importante sobre la eficiencia de flujo es el concepto de retroalimentación o feedback, que es una piedra angular de la **mejora continua**. # Conclusiones “Esto es Lean” es un libro imprescindible no solo para cualquier emprendedor o practicante Agile y Lean, sino para cualquier profesional donde exista un flujo de trabajo, y como no conozco ningún tipo de empresa o industria donde no exista flujo de valor, entonces es un libro recomendable para todos (siempre y cuando sea de su interés la mejora continua). Como hemos visto, lean no es solo un conjunto de prácticas, va más allá de eso, tiene un enfoque en la eficiencia de flujo y la mejora continua y para que sea sostenible, buscamos es enraizar o anclar esto en nuestra cultura organizacional (lo cual hizo muy bien Toyota, por ejemplo). Este libro me ha ayudado a entender a mucho mayor profundidad en es el movimiento Lean. Un concepto que está “de moda”, y se lo podemos ver por todos lados: • Lean Manufacturing • Lean Management • Lean Portfolio Management • Lean Change (Management) • Lean Coffee • Lean Construction • Lean IT • Lean Company • Lean Marketing • Lean Education • Lean Startup (por cierto, si te interesa este tema, (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí puedes leer un artículo que escribí precisamente sobre Lean Startup)). • Y una larga lista de etcéteras y etcéteras. Para terminar, este artículo (aunque extenso), ha sido solo un “chapuzón” en el mundo de Lean, si te ha interesado el tema y deseas bucear a profundidad en el tema para aplicarlo con tus equipos y en tu organización, este libro es una recomendación absoluta **nivel Master Jedi**. ## Referencia “Esto es Lean / This is Lean”. Niklas Modig & Pär Ahlstrom.
31 de agosto de 2024 -
Scrum
Antipatrones de Scrum: Scrum but
Scrum no funciona. He escuchado esta frase muchas más veces de las que me gustaría admitir, aunque la realidad es que, cuando profundizamos en cómo estos equipos llevan Scrum en su día a día, salen a flote diversas prácticas que desvirtúan Scrum, prácticas que se llevan a cabo de manera incorrecta (de manera intencional o no intencional), y por lo tanto un efecto aparente es que Scrum “no está funcionando”, cuando la causa raíz es, en realidad, una mala práctica, o lo que se conoce como un **antipatrón**. Scrum un marco de trabajo, pero más que eso, hoy siendo las 5:34 a.m. del 8 de julio de 2024, continúa siendo **el marco de trabajo más utilizado en el mundo**, no lo digo yo, lo muestran los diversos estudios anuales sobre Agilidad o Agilismo que se publican por diversas organizaciones. Scrum establece una forma de colaborar evaluando de manera continua cómo construir un producto (o servicio), obtener retroalimentación del cliente/usuario final, y adaptar creativamente en base a la información obtenida siempre centrados en entregar un incremento de producto que agregue valor al cliente/usuario final. En este artículo no abordaremos lo que Scrum es, no es un artículo introductorio (si quieres leer un poco sobre los principios de Scrum, (link: https://leonelzapien.com/blog/que-es-scrum text: te comparto aquí un artículo que escribí sobre este tema hace un par de años)), aquí abordaremos sobre eso que “no es Scrum”, esos antipatrones que desvirtúan el marco de trabajo y consecuentemente llevan a equipos a sufrir el proceso y concluir que “Scrum no funciona”. (image: scrum-logo.webp) # Anti… ¿qué? Aquí abro un breve paréntesis. Primero lo primero, no sé si conozcas el término **antipatrón**, pero vamos iniciando aquí. Un antipatrón es un enfoque que nos va a conducir a una mala solución a un problema, pueden ser en ocasiones enfoques “generalizados” o que se utilicen ampliamente, pero, aun así, no deja de ser una solución inadecuada y por lo mismo son ineficaces y/o improductivos para resolver determinada clase de problemas comunes. Una vez aclarado lo anterior, ya hemos calentado motores, entremos directo en tema sobre de antipatrones en Scrum, ¡Aquí vamos! Cierro paréntesis. # Scrum but Hoy vengo a platicarte sobre algo que se conoce como **Scrum but…**, que traducido sería algo como **Scrum pero…**, y se le conoce así precisamente porque, cuando a alguien le preguntan: - Y ustedes, ¿utilizan Scrum? - ¡Claro que sí! - ¿Y cómo les va con *[inserte-aquí-cualquier-tópico-relacionado-con-Scrum]* (por ejemplo, las retrospectivas / producto backlog / incrementos de producto / la definición de terminado, etc.)? - Ah, bueno. Es que sí utilizamos **Scrum, pero…** *[inserte-aquí-cualquier-“parche”-o-forma-de-hacer-algo-que-no-está-alineado-con-La-Guía-Scrum]* Y ahí es donde surge el “pero”, es ahí donde, como decimos acá en México, la puerca torció el rabo. Por esto, hoy hablaremos sobre **Scrum but,** ya que esta lista de “peros” puede ser virtualmente infinita, vamos a ver algunos de los principales ejemplos que he tenido oportunidad de ver de primera mano en diversos equipos, así como posibles soluciones. Un
8 de julio de 2024tiene la siguiente estructura: **Scrum + pero + Antipatrón + Forma alternativa de “solucionar” la situación** (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-estructura-antipatron-cursos-consultor-guadalajara-mexico.webp) ¿Estás listo? ¡Ponte cómoda o cómoda y relájate, no lo tomes personal si con algunos de estos antipatrones sientes que “le queda el saco a tu equipo”, cualquier parecido con la realidad es mera coincidencia! ## Antipatrón #01: El Daily eterno (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-01-guadalajara-mexico.webp) **Usamos Scrum + pero… + hay demasiados temas por conversar en nuestra Daily + así que, en vez de 15 minutos, este evento dura entre 45 minutos y 1 hora.** Este es por mucho el antipatrón que más comúnmente he visto, pero así mismo, es de los más sencillo de reenfocar. Primero lo primero, ¿Cuál es la esencia del Daily Scrum? De acuerdo con La Guía Scrum, el Daily Scrum es un evento de hasta 15 minutos para los Desarrolladores del Equipo Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint. ¿Cómo podemos ayudar al equipo a que se cumpla el bloque de tiempo (timebox) de 15 minutos?, aquí te comparto uno tip súper simple y no por eso menos poderoso: • Utilizar un** Estacionamiento de temas** o **Parking lot**, donde podemos “estacionar” los temas que surjan durante el Daily que necesiten conversarse, la idea es no resolver los problemas durante el Daily, sino identificarlos, y posteriormente conversarlos solo con las personas directamente implicadas, puede ser de manera inmediata al terminar el Daily (algunos le llaman a esto post-Daily), o en algún momento posterior. La esencia es no alargar el Daily, y que, cuando se vaya a conversar, solo se involucre a las personas necesarias y no a todo el equipo. ## Antipatrón #02: Saltarse la retrospectiva (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-02-guadalajara-mexico.webp) **Usamos Scrum + pero… + tenemos tanto trabajo al final del Sprint + que mejor aprovechamos el tiempo de la retrospectiva para trabajar en lo que tengamos pendiente.** Este antipatrón me recuerda el meme de un cavernícola que está empujando una montaña de piedras sobre una carreta con “ruedas cuadradas”, claro que va sudando a chorros y sufriendo tremendo, mientras un segundo cavernícola le muestra una “rueda redonda” diciéndole que su invento le va a hacer la vida más fácil, y el primer cavernícola solo puede responder con el poco aire que le queda: “No tengo tiempo, estoy muy ocupado jalando esta carreta”. Tristemente, es el segundo antipatrón más común que he visto, donde los equipos no se dan el tiempo de hacer una pausa para analizar el último periodo de trabajo o Sprint, y reflexionar sobre cómo pueden mejorar. La Guía Scrum menciona que “El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.” Sin estos espacios para identificar los principales problemas que afectaron el equipo, sin conversaciones que les puedan ayudar a mejorar su efectividad, no se puede llegar a la mejora continua. Cada evento en Scrum tiene un propósito específico, en este caso, la retrospectiva fomenta este espacio para detenernos a “Afilar la sierra”, por más ocupados que estemos es fundamental tener y fomentar estos espacios, así como escuchar todas las voces, priorizar los elementos que se identifiquen en base a su posible impacto, y darles seguimiento. ## Antipatrón #03: Un día sí, y al otro día quién sabe (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-03-guadalajara-mexico.webp) **Usamos Scrum + pero… + tener el Daily todos los días quita demasiado tiempo + así que tenemos el Daily Scrum un día a la semana.** El evento Daily Scrum debe de ser diariamente. Un antipatrón que tiene un impacto muy negativo en el potencial que marco Scrum puede ofrecer es el no tener los Daily ahora sí que dice la palabra, diariamente. He tenido oportunidad de coincidir con equipos que tienen los Daily en frecuencias distintas a lo definido en La Guía Scrum: 1 vez a la semana, o cada tercer día, por mencionar algunos ejemplos. Entre las principales razones para hacer esto (la verdad debo de confesar que se puede dedicar mucho esfuerzo y creatividad para justificarlo muy bien), he escuchado cosas como: • Es muy costoso detener a todo el equipo de trabajar, todos los días. • Nuestro proceso es muy estable, no necesitamos reunirnos a diario. • Es un desperdicio de tiempo. • Mejor nos reunimos cuando surja algo. • Entre otras cosas. ¿Te suena familiar? La Guía Scrum menciona que el Daily Scrum se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint, el Daily es una oportunidad para inspeccionar y adaptar el plan para lograr el objetivo del Sprint, y este es precisamente el sustento por el cual debe de realizarse diariamente, ya que trabajamos en entornos con alta volatilidad e incertidumbre, así mismo los productos o servicios que construimos, y las personas que colaboramos para construirlos, somos complejos. Hay infinitas variables que pueden afectar a un equipo, algo puede afectarnos durante un sprint, solo para asentarlo y nombrar algunas a manera de ejemplo: • Una persona se ha enfermado y no tenemos capacidad para realizar lo que él o ella hacía. • Para realizar algo en particular, acabamos de darnos cuenta de que se requiere un recurso específico (una licencia de un determinado software, un servidor, un servicio o proveedor, etc.), y se necesita conseguir a la brevedad posible, o bien, ver alguna opción alterna. • Ha surgido un defecto que es urgente solucionar. • Determinada situación ha provocado escasez o tiempos de entrega más largos de algún insumo. • Acaba de surgir una nueva pandemia, situación social que ha afectado al entorno del equipo, un apocalipsis zombi, etcétera y etcétera. La inspección frecuente permite la adaptación temprana, este es uno de los propósitos del Daily, identificar de manera oportuna problemas, riesgos, bloqueos que puedan presentarse, por eso la importancia de que sea diariamente, para proporcionar un ritmo o cadencia al equipo, y termina formando parte de los hábitos del equipo, por eso debe de celebrarse todos los días a la misma hora y en el mismo lugar (o en utilizando el mismo link de reunión recurrente, en caso de ser de manera remota), para de esta manera reducir la complejidad que implica el estarla reprogramando o moviendo de lugar (físico o remoto). ## Antipatrón #04: Sin retroalimentación real (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-04-guadalajara-mexico.webp) Usamos Scrum + pero… + nuestro cliente/usuario final está muy ocupado y no tiene tiempo para atender las Revisiones del Sprint + así que le enviamos un correo para informarle de las funcionalidades que se liberarán. La revisión del Sprint es un evento que, de acuerdo con La Guía Scrum, tiene como propósito inspeccionar el resultado del trabajo realizado durante el Sprint, y en base a esto, determinar futura adaptaciones. Aquí el punto clave es que el Equipo Scrum presente los resultados de su trabajo a los interesados clave y se discuta el progreso hacia el Objetivo del Producto. Pero, ¿Quiénes pueden ser interesados clave? La verdad es que depende del contexto, de entrada, es imprescindible que esté ahí el cliente / usuario final, esa persona quien finalmente va a utilizar nuestro producto. Lo que queremos es que este cliente / usuario final pruebe el producto, lo vea funcionar, lo tenga entre sus manos, le haga clic y vea qué hace… y en base a su experiencia con este incremento de producto real, nos proporcione retroalimentación valiosa que nos permita determinar si vamos bien, hacemos algunos ajustes, o definitivo no es por este camino y debemos girar el timón. Esta figura de cliente / usuario final es fundamental, pero aunado a esto y dependiendo del contexto, un interesado clave puede ser un determinado gerente, director, el patrocinador del proyecto o producto, inclusive dependiendo del caso, alguna figura externa como un proveedor, o algún representante de un organismo o grupo. Debido a todo esto, una Revisión de Sprint sin los interesados relevantes y sin esta figura principal que es el cliente / usuario final que viva en primera persona la experiencia del incremento de producto que el Equipo Scrum ha construido durante el Sprint, sin ellos, una revisión de Sprint carece totalmente de sentido. La Guía Scrum menciona también que, durante la Revisión del Sprint, el Equipo Scrum y los interesados revisan lo que se logró en el Sprint, conversan sobre lo que ha cambiado (prioridades, alguna cuestión del entorno, etc.), con base en esta información y con la experiencia de probar el incremento de producto, los asistentes a este evento colaboran para determinar qué hacer a continuación. Esto es fomenta un ambiente donde se transpiran los pilares de Scrum: Transparencia, inspección y adaptación. ## Antipatrón #05: No necesitamos un Scrum Master (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-05-guadalajara-mexico.webp) **Usamos Scrum + pero… + no necesitamos un Scrum Master, el equipo ya sabe Scrum + así que el resto del equipo cubre las actividades del Scrum Master.** La Guía Scrum define que el Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización. Un tema algunas veces controversial es, ¿Y qué hace el Scrum Master todo el tiempo?, es normal que esta pregunta surja sobre todo cuando el equipo Scrum ya tiene cierto grado de madurez y se puede decir que el equipo “ya sabe” Scrum. Pero el Scrum Master hace (o debería de hacer) muuucho más que eso, apoya al equipo Scrum (Desarrolladores y Product Owner), así como a la organización. La Guía Scrum menciona que el Scrum Master es responsable de lograr la efectividad del Equipo Scrum, por lo tanto, es el responsable final de que el equipo mejore continuamente, y siendo completamente honestos, esto implica **ver más allá de Scrum**, complementar con otras herramientas, métodos, prácticas, metodologías, etc., probar, experimentar, ayudar al equipo a descubrir nuevas formas de reducir los despilfarros o desperdicios, avanzar hacia mejores formas de colaborar. Esto puede incluir, por citar algunos ejemplos, complementar Scrum con **Kanban**, Pensamiento** Lean**, utilizar **Estructuras Liberadoras** para facilitar las sesiones ayudar a descubrir problemas, así como fomentar conversaciones, agregar prácticas de **Management 3.0** para centrarnos en las personas, prácticas de **Extreme Programming**, **Agile / Lean Inception**, **Lean Startup**, y una lista infinita de etcéteras y etcéteras. Por lo tanto, el Scrum Master es esencial, y si esta responsabilidad o rol (o cualquiera de los otros dos) no está, realmente no estamos trabajando con Scrum. ¿Cómo sabemos qué tal está haciendo su trabajo el Scrum Master?, su trabajo se ve indirectamente, se refleja en la forma en que el Equipo Scrum se está desempeñando, por eso es imprescindible esta figura para, como dice (link: https://agilemanifesto.org/ text: El Manifiesto Ágil): Continuar descubriendo mejores formas de trabajar. # Conclusiones Creo que una lista de antipatrones conocidos o potenciales en Scrum es virtualmente infinita, los cinco que he mencionado aquí creo que son algunos de los que he tenido oportunidad de ver de manera más recurrente. Lo triste del asunto es que este tipo de prácticas llevan a personas y equipos a sentir frustración porque **“Scrum no funciona”**, cuando la causa raíz es que se está llevando a cabo de una manera que no permite que los verdaderos super poderes de Scrum se muestren con todo su esplendor. Scrum define cómo un equipo autogestionado podría estructurar mejor su trabajo para ofrecer incrementos de producto y crear el mayor valor posible para todas las partes interesadas, funciona muy bien donde se trabaja con alta complejidad, donde existe alta incertidumbre, donde los requisitos del producto no están claros. De verdad que Scrum puede aportar enorme apalancamiento en todo esto. Solo, hay una consideración, y no es una que me haya inventado, sino que viene mencionada en la página 13 de La Guía Scrum 2020 (es la guía más reciente y, por lo tanto, la que está vigente). Dice lo siguiente: “El marco de trabajo Scrum, como se describe aquí [en La Guía Scrum], es inmutable. Si bien es posible implementar solo partes de Scrum, **el resultado no es Scrum**. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.” Así que podemos complementar Scrum con otros métodos, prácticas, herramientas, metodologías… pero no podemos “quitarle” cosas a como Scrum viene definido. Requiere de sus 3 roles, 5 eventos y 3 artefactos, tal y como se definen en La Guía Scrum. Cuando lo lleves a tu equipo, es esencial que lo acotes a tu contexto, experimentando lo que mejor funciona, pero dentro de lo que es válido para este marco de trabajo. Nunca dejemos de experimentar hacia la mejora continua, los resultados, más temprano que tarde, siempre, siempre, siempre llegan. **¿Qué opinas de estos antipatrones?, ¿Qué otros antipatrones agregarías?** -
MVP, Product Management, Innovación
Innovación & MVP - Diseñar y probar hipótesis de negocio
“No cometas el error de ejecutar ideas de negocio sin evidencia: Prueba tus ideas, sin importar qué tan bien luzcan en teoría” – David J. Bland & Alex Osterwalder. # Hipótesis de negocio ¿Tienes una idea de un nuevo producto o servicio?, ¿Una nueva funcionalidad que piensan agregar para tu usuario o cliente?, para pasar de una idea de negocio a un elemento validado, se debe de probar de manera rápida y lo más barato posible (en el artículo pasado hablamos sobre el **Producto Mínimo Viable o MVP**, Minimum Viable Product en inglés, puedes leer el artículo completo (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Pues bien, está chévere esta idea de que un MVP nos invita a validar ideas de negocio con experimentos antes de ir a mayor escala. Pero ¿Por dónde empezar si quiero hacer un experimento para probar una idea?, ¿Por dónde inicio? Lo primero que necesitamos asentar es que una **idea de negocio** es en realidad una **hipótesis** (ya sé que esto suena muy del ámbito científico, pero en realidad así es). Hasta que se valide obteniendo un resultado (se cumple y por lo tanto es correcta, o no se cumple), solo entonces dejará de ser una hipótesis. “El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje.” – Eric Ries (The Lean Startup) # Probar ideas de negocio: Un proceso iterativo El ciclo Diseño-Prueba es un proceso iterativo, creado por David Bland & Alex Osterwalder, tiene dos grandes áreas: Diseño & Prueba, veamos cada una a detalle: (image: design-test-innovacion-strategyzer-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) **Diseño:** Es la actividad de llevar ideas vagas o dispersas, a proposiciones de valor, que después puedan concretarse como modelos de negocio. **Prueba:** Necesitamos descomponer una idea de negocio en hipótesis pequeñas y fáciles de validar mediante experimentos que proporcionen evidencia que ayuden a decidir los siguientes pasos. # Diseño En este primer paso el objetivo es generar la mayor cantidad de opciones como sea posible (debemos evitar enamorarnos de nuestra primera idea, no es personal, solo son negocios), basándose en la intuición, observación o en lo que se conozca sobre los clientes. (image: design-test-innovacion-strategyzer-01-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) Las ideas locas, irreverentes, aquellas que retan el Status Quo, son más que bienvenidas (de hecho, eso es lo que buscamos). En este punto, no es el momento de empezar a desmenuzar el modelo de negocio y cuestionar la validez o potencial éxito en el mercado de una idea. No aún. **Queremos que el equipo diseñe como si tuviera razón**, ¿Tenemos sobre la mesa alguna idea de negocio innovadora? **Pregunta para llevar: ** ¿El equipo está “empujando” los límites?, o ¿Están jugando a lo seguro y manteniéndose cerca de lo que la empresa hace actualmente? # Prueba Una vez estemos satisfechos con lo realizado en la etapa de diseño, es hora de pasar a las pruebas. (image: design-test-innovacion-strategyzer-02-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) El primer paso en el ciclo de prueba es definir y priorizar las hipótesis de negocio. Si la hipótesis es muy grande, la dividimos pequeñas partes comprobables. Aquí lo esencial es la palabra “comprobable”, para esto debemos cocrear (de verdad, es increíble el poder de la crear de manera colaborativa), seleccionar y ejecutar experimentos adecuados que nos proporcionen información que respalde y nos ayuden a validar (o desechar) nuestras hipótesis. En pocas palabras, necesitamos **evidencia**. # Tarjeta de Prueba o Test Card Aquí te comparto una herramienta muy útil, desarrollada por Strategyzer, que nos ayuda a definir un experimento para probar una idea: (link: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card text: La Tarjeta de Prueba (Test Card)). Aquí veremos brevemente cómo llenar esta tarjeta: (image: test-card-strategyzer-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis:** Define la idea de negocio que se cree que es verdadera. **Ejemplo: **“Creemos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Prueba:** ¿Qué experimento (o experimentos) ejecutarás para determinar obtener información que permita validar si hipótesis es verdadera o falsa? **Ejemplo: **“Para verificar esto, nosotros agregaremos un breve video sobre el curso y un botón de
2 de junio de 2024en nuestro sitio web.” 3. **Métrica:** ¿Qué vamos a medir para validar la hipótesis?, la idea es que sea una medida específica, objetiva, no ambigua, binaria (cumple o no cumple) y reproducible. **Ejemplo:** “Y lo mediremos por el número de personas que ingresan a nuestro sitio web y hacen clic en el botón de .” 4. **Criterio: **Definir el resultado esperado respondiendo a la pregunta ¿Cómo es el escenario ideal que en nuestro contexto nos dice que la hipótesis ha sido exitosa? **Ejemplo: **“Y sabremos que tenemos éxito si se registran al menos 1,000 ‘compradores de pre-venta’ en la primera semana.” Este último punto es crítico ya que ayuda a responder la pregunta: ¿Qué necesita ser cierto para que esta idea de trabajo funcione? En este ejemplo, la definición de éxito que esta empresa de cursos en línea espera (de acuerdo con su contexto especifico, como costos fijos, retorno de inversión esperado, cobertura de mercado actual, etcétera), son 1,000 “compradores” registrados, pero ¿En cuánto tiempo?, para ellos ese bloque de tiempo es en la primera semana de correr el experimento. ¿Lo más importante?, el producto en este ejemplo, el curso en línea no ha sido creado aún, por lo que probar esta hipótesis es relativamente muy barato (y rápido). # Aprender El último paso es aprender de los experimentos que realizamos. ¿La evidencia recabada apoya o refuta nuestras suposiciones?, Eso que acabamos de obtener es aprendizaje, de hecho, es lo que Eric Ries (el creador del **Método Lean Startup**, puedes leer el artículo que hice sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)) llamó **Aprendizaje Validado**, pues se basa en evidencia. ¿Este aprendizaje validado nos indica que debemos de continuar por este mismo rumbo, o pivotar y explorar un nuevo camino? Para validar el aprendizaje, aquí comparto, al igual que en el punto anterior, una herramienta propuesta por Strategyzer: (link: https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card text: La tarjeta de Aprendizaje o Learning Card). Hemos realizado un experimento para tratar de validar una hipótesis de negocio, debemos de rescatar e identificar el aprendizaje obtenido y aplicarlo lo más pronto posible, pues el aprendizaje tiene una “fecha de caducidad”. ¿A qué nos referimos con aplicar el aprendizaje obtenido?, a aplicarlo en la toma de decisiones informada, identificar los siguientes pasos: ¿La hipótesis de negocio era correcta, y debemos continuar por este camino?, o ¿Debemos de cambiar el rumbo, partiendo de una nueva hipótesis? (esto último, se conoce como hacer un “**pivote**”). Retomando el ejemplo que revisamos en la Tarjeta de Prueba (Test Card), continuamos con el ejemplo para llenar ahora la Tarjeta de Aprendizaje: (image: learning-card-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis: **Define la idea de negocio que se creía verdadera. **Ejemplo: **“Creíamos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Observación: **¿Qué pudimos observar después de realizar el experimento? **Ejemplo: **“Observamos que solo un 1.2% de los clientes potenciales esperados hicieron clic en nuestro botón de en nuestro sitio web.” 3. **Aprendizajes e ideas clave:** El aprendizaje validado que se ha obtenido de la observación. **Ejemplo:** “Dado que esperábamos 1,000 clics de compra en pre-venta durante la 1ra semana y solo obtuvimos 12 clics (1.2%), este curso en línea no genera el interés esperado.” 4. **Decisiones y acciones:** Ahora que se ha visto si la hipótesis de negocio era válida o no, determinar los siguientes pasos que se realizarán a partir de este punto. **Ejemplo:** “No dedicaremos más recursos a esta hipótesis. Replantearemos nuestra idea de negocio y haremos un pivote a una nueva hipótesis que está por definirse.” En este caso de ejemplo, la hipótesis de negocio no era válida, ¿Lo más importante?, el producto en este ejemplo, el curso en línea sobre bordar manteles navideños con punto de cruz, nunca fue creado: No se dedicaron semanas o meses de trabajo a un producto que se creía que se vendería como pan caliente, pero que el experimento demostró que no había interés. Probar esta hipótesis fue relativamente muy barato y rápido. ¿Y cómo procedemos una vez se confirma el resultado de una hipótesis?, se pueden hacer varias 3 cosas: 1.** Perseverar: **Quiere decir que vamos por buen camino, y debemos de continuar por este rumbo. No es el caso en este supuesto, solo sucedería si la hipótesis resultara válida. 2. **Pivotar: **Hacer un cambio de rumbo, lo que Eric Ries en su libro “The Lean Startup” llama un “Pivote”, comenzar a explorar otros caminos y formular nuevas hipótesis. 3. **Descartar: **Tal vez, después de explorar varias hipótesis, negocio decide no continuar explorando este camino (y probablemente ningún otro similar o alineado con este camino). Continuando con este ejemplo, ¿Qué tal si a la gente no le interesa aprender a bordar manteles navideños, pero se acerca el Día de Star Wars, y bordar manteles temáticos de Star Wars es algo que las personas están buscando con singular alegría?, uno nunca sabe. ¿Cómo lo sabremos?, formulando una nueva hipótesis. (image: hipotesis-de-negocio-star-wars-copy.webp) # ¿Qué sigue después? En el centro del ciclo Diseño-Prueba se encuentra “Decidir”, se debe de decidir sobre este modelo de negocio que el equipo está probando. El objetivo final es comprobar **si el modelo de negocio es viable**, los equipos de innovación deben evaluar en este punto y reflexionar sobre su progreso hacia la búsqueda de un modelo de negocio rentable que funcione. Al evaluar la solidez de la evidencia que respalda cada componente básico del modelo de negocio, los equipos pueden identificar si aún hay incertidumbre y existen componentes que aún deben probarse, ¿Deben realizarse nuevos experimentos? Cuando se aprenden nuevas lecciones, se puede actualizar el modelo de negocio, identificar nuevas hipótesis y ejecutar el siguiente conjunto de experimentos. Esta es la razón por la que los equipos que pueden recorrer rápidamente el ciclo descubren más rápido si su idea de negocio es viable. Hasta aquí, ya tenemos información de la hipótesis de negocio mediante los experimentos realizados, ahora, muy recientemente en este último par de párrafos hemos comenzado a hablar de un “Modelo de negocio”. Para esto, el equipo de Strategyzer han creado también el (link: https://www.strategyzer.com/library/the-business-model-canvas text: Business Model Canvas, o Lienzo de Modelo de negocio), el cuál es el siguiente paso para ayudar al equipo de innovación a determinar la validez de su modelo. Aquí te presento el Lienzo de Modelo de Negocio, pero creo que este artículo ya es algo extenso, así que en un próximo artículo conversaremos específicamente sobre este Canvas. Por lo pronto, hemos visto cómo probar y validar ideas de negocio. (image: business-model-canvas-modelo-de-negocio-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) # Conclusiones La **apertura para experimentar** es esencial para desarrollar una **cultura de innovación** en cualquier organización. Las herramientas que hemos visto el día de hoy no son solo un par de tarjetas para prueba y aprendizaje, o un canvas con un modelo de negocio, son en realidad recordatorios de conversaciones enriquecedoras y poderosas que deben de suceder. Una tarjeta o un canvas como tal no resolverán ningún problema ni nos llevará al valle dorado de la innovación. Debemos fomentar los espacios para los individuos y sus interacciones, como dice el **Manifiesto Ágil** (puedes leer el artículo que escribí sobre el Manifiesto Ágil (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)). Así mismo, la experimentación y la innovación son unos músculos que deben de ejercitarse, es posible que a tu equipo le tome algunos ciclos el comenzar a entrar en calor, a agarrar ritmo, y a perder el miedo a experimentar (y para esto último se requiere un adecuado **liderazgo** y sólidos cimientos de **Seguridad Psicológica** en tu organización y equipo). Lo importante de la experimentación es obtener aprendizaje validado, con esto, el ciclo Diseño-Prueba se ha completado, de manera rápida y lo más barata posible. En este ejemplo, no fue viable continuar con el producto, así que el ciclo vuelve a iniciar, esta vez, con una nueva hipótesis de negocio. ¡Nunca dejemos de experimentar y aprender! **¿Cómo validas tus ideas de negocio?** ## Nota final #01 Las herramientas sobre las cuales hemos conversado hoy, Tarjeta de Prueba, Tarjeta de Aprendizaje y el Canvas de Modelo de Negocio, los puedes descargar en su versión original del sitio de (link: https://www.strategyzer.com/ text: Strategyzer), o en su defecto, los puedes descargar en una versión traducida a español, aquí en mi sitio web en la sección de (link: https://leonelzapien.com/recursos text: Recursos para descargar). ## Nota final #02 Existen varios canvas o lienzos que apoyan para crear modelos de negocio, hace unos meses hablé sobre el **Tablero de la Visión del Producto o Product Vision Board,** creado por Roman Pichler, escritor y todo un master Jedi en Agile & Product Management. Este canvas es muy útil para cocrear una visión compartida del producto (lo que se conoce como “envisioning”), y puede de igual manera apoyar como siguiente paso, ya que es similar al Business Canvas Model en algunos aspectos. Si quieres leer sobre el Tablero de la Visión del Producto, puedes leer el artículo que escribí sobre el tema (link: https://leonelzapien.com/blog/como-iniciamos-el-tablero-de-vision-del-producto text: aquí). ## Nota final #03 De verdad que existe el “**Día de Star Wars**”, millones de fans a lo largo y ancho de toda la galaxia lo celebramos el día 4 de mayo. ¿Por qué el 4 de mayo?, por el juego de palabras de la frase: “Que La Fuerza te acompañe”. En inglés se dice “May the Force be with you”, lo cual es un juego de palabas y cuando se dice en voz alta casi-casi como “May the Fourth be with you”… o sea “Que el 4 de mayo te acompañe”, y de ahí derivó que cada 4 de mayo se celebre el Día de Star Wars (Sí, debo de reconocer que nos buscamos cualquier pretexto para ese tener un día para usar sables láser y ponernos el casco de Darth Vader). **Referencias:** • Testing Business Ideas. David J. Bland & Alex Osterwalder. • Business Model Generation. Alex Osterwalder & Yves Pigneur. • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries.
