"Estoy convencido de que la Agilidad o Agilismo es un camino y no un fin. Me encanta ayudar a los equipos a cocrear las mejores condiciones para abrazar la Agilidad Organizacional."
Próximos
Cursos

Cursos
In-company
Cualquiera de los cursos ofertados en el calendario, o bien, cursos específicos a la medida de tus necesidades. Podemos cocrear juntos una experiencia sublime de capacitación en un grupo privado, formado por personas de tu empresa.
Hey!, Más información sobre estoConsultoría
La Agilidad o Agilismo es un camino y no un fin. Te acompaño en este viaje para cocrear las mejores condiciones en tu organización para abrazar la Agilidad Organizacional
Testimonios
Algunos testimonios de personas con quienes he tenido el gran gusto de colaborar profesionalmente a lo largo de este mágico camino de la Agilidad:
Visita mi
Blog

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 2025Yo soy
Leonel :)

¡Hey!, ¿Qué tal?
Soy un espíritu libre y creativo: Amo viajar y las actividades al aire libre como trekking y acampar.
Soy fan de los comics, de Star Wars y me encanta la salsa cubana.
Mi pasión en la vida (además de la Agilidad) es la fotografía y la literatura.... todo esto es parte de mi ikigai.
Aquí te platico sobre mí y mi experiencia profesional