El bloc de notas de un Agilista Jedi
-
Agile, PMI
PMI - Manifiesto para la Agilidad Empresarial
Recién salido del horno este mes, la (link: https://agilealliance.org/ text: Agile Alliance) del (link: https://www.pmi.org/ text: Project Management Institute o PMI) , acaba de publicar el Manifiesto para la Agilidad Empresarial (Manifiesto for Enterprise Agility), ¿Pero no es lo mismo que el (link: https://leonelzapien.com/blog/25-aniversario-del-manifiesto-agile text: Manifiesto Ágil de hace 25 años)?, la respuesta sería algo como: "Sí pero no": Este Manifiesto habla de Agilidad a nivel Empresarial, es decir, más allá de a nivel equipo, y es justo en este punto donde complementa al clásico (link: https://agilemanifesto.org/ text: Manifiesto Agile), busca ir más allá de equipos Scrum o equipos Kanban (esto lo menciono solo como ejemplo, y también es cierto que existen marcos y métodos de escalado que buscan abordar esta situación, como Scrum@Scale, LeSS o Large Scale Scrum, Nexus, Enterprise Kanban, Spotify Model, Scaled Agile o SAFE, y varios más que bien solo este punto es bastante amplio y puede ser tema para un próximo artículo, si te interesa compárteme un mensaje o correo, y con gusto lo podemos abordar), pues bien, con la perspectiva del PMI de Agilidad Empresarial se busca hablar de una alineación a lo largo y ancho de toda la organización, desde los valores y principios, sin acotarlo a un marco de trabajo o método en particular. (image: pmi-agile-alliance-leonel-zapien-lopez-guadalajara-mexico.webp) ## Agilidad Empresarial En base a este enfoque más allá de equipos, el PMI define **Agilidad Empresarial **como la capacidad de adaptarse a escala sin perder coherencia: decidir con rapidez, redirigir recursos deliberadamente y mantener la estrategia viable bajo la presión del mundo real, y algo clave es que la identifica como una **habilidad** esencial para la supervivencia en un entorno marcado por la incertidumbre, la IA y los cambios constantes del mercado. Este Manifiesto tiene un enfoque amplio al enfatizar la alineación entre la estrategia, objetivos a largo plazo, ventajas competitivas y sostenibilidad alineados a lo largo y ancho de toda la organización, con una organización capaz de a ver ajustes o pivotes más rápidos que el mercado, mientras se mantiene un crecimiento sostenible. (image: pmi-agile-alliance-manifiesto-agilidad-empresarial-leonel-zapien-lopez-guadalajara-mexico-pmp-pmi-acp.webp) ## Empieza con el “Porqué” (así pegado y con acento) Como menciona (link: https://simonsinek.com/ text: Simon Sinek) en su increíble libro **Empieza con el Porqué** (siempre menciono que la palabra “porqué”, así pegado y con acento, significa causa, motivo o razón), debemos de partir siempre desde el propósito, esa poderosa razón por la cual hacemos lo que hacemos. (image: simon-sinek-empieza-con-el-porque-circulo-dorado-golden-circle-leonel-zapien-lopez-guadalajara-mexico.webp) **Imagen:** Simon Sinek, creador del “Cículo Dorado” y autor del libro “Empieza con el Porqué”. En este mismo orden de ideas, personalmente algo que me ha encantado y me parece súper poderoso es que el Manifiesto menciona la importancia de partir primeramente desde el Propósito, al mencionar: “Propósito claro realizado a través de planes adaptativos”, y pone, así mismo, un especial foco en las personas: “Centrarse en el ser humano en medio del cambio”. Agile Alliance menciona que cuando la Agilidad Empresarial funciona, la estrategia se convierte en acción sin fricciones, los equipos actúan con autonomía y alineación, y la organización evoluciona más rápido que el mercado, manteniendo al mismo tiempo su crecimiento. ## Principios y valores Este Manifiesto cuenta con 9 principios, y prioriza algunos valores: 1. Guiar con propósito y ajustar en el camino en lugar de mantener una ilusión de control. 2. Priorizar objetivos a largo plazo y la colaboración a lo largo de toda la organización sobre objetivos a corto plazo (Objetivos Clave de Desempeño o KPIs a nivel local o departamental). 3. Desafiar activamente los modelos operativos establecidos e innovación sobre la inercia estructural y preservación del Status Quo. 4. Aprendizaje continuo, desarrollar resiliencia, habilitar la autonomía, y liderar con empatía la confianza, sobre liderar el cambio solo basado en procesos. P.D. La lista completa de valores no la transcrito aquí para no extender demasiado el artículo, pero si es de tu interés conocerla, la puedes consultar en la sección de "Anexos", al final del artículo. ## El Liderazgo es clave El Manifiesto de Agilidad Empresarial menciona y reconoce como elemento clave de apalancamiento el **nuevo rol del liderazgo**, menciona que los líderes deben de ser los primeros en adaptar sus enfoques, así mismo, deben de fomentar un entorno donde el aprendizaje a partir del error sea posible a través de entornos de seguridad psicológica, es acerca de reemplazar el miedo a fallar con un apetito por experimentar y progresar. ## Conclusiones Este Manifiesto cambia radicalmente le enfoque de la Agilidad, reconoce la Agilidad como una habilidad, y busca permear un impacto a lo largo y ancho de toda la organización, el foco no es tener equipos súper ágiles que trabajen de manera aislada, sino desarrollar la capacidad de adaptación a lo largo de múltiples equipos, a lo largo de la organización (por cierto, si te interesa profundizar un poco más en este tema de pasar más allá de equipos aislados, te invito a ver el** video** de una charla referente a este tema que tuve el enorme gusto de impartir titulada: “**Alineándonos alrededor de Flujos de Valor o Value Streams**”, puedes ver el video haciendo (link: https://www.youtube.com/watch?v=eVbt1R2HZ6o text: clic aquí)). Y en esencia, hablamos de valores y principios, nada de marcos de trabajo o frameworks, ni métodos o herramientas. Con este enfoque el PMI integra la Agilidad de manera natural, ahora con una perspectiva amplia, con vistas a los objetivos a largo plazo. ¿Qué opinas de este Manifiesto y su enfoque? **P.D.** Te comparto que **soy miembro activo del PMI desde 2013** (PMP, PMI-ACP), y a lo largo de los años algo que he visto es la evolución, tanto del enfoque del PMI como del movimiento Agile, así que este Manifiesto me parece un gran acierto en este sentido. Sabemos que la constante es el cambio, por lo tanto, debemos de mantenernos en constante evolución. ## Anexos Puedes descargar el Manifiesto para la Agilidad Organizacional directo de la página del PMI, haciendo (link: https://www.pmi.org/learning/agile/manifesto-for-enterprise-agility text: clic aquí.)
31 de marzo de 2026 -
Agile
A 25 años del Manifiesto Agile
Este mes de febrero de 2026 cumplió **25 años el Manifiesto Ágil**, la piedra angular con la cual surge oficialmente el movimiento Agile, traducido al español como Agilidad o Agilismo. Un mítico fin de semana del 11 al 13 de febrero de 2001, en Snowbird, Utah, se reunieron 17 personas, pioneros de nuevas e innovadoras “prácticas ligeras” para el desarrollo de software, prácticas como Scrum , Extreme Programming (XP), Crystal, entre otras, y cocrearon el “Manifiesto por el Desarrollo Ágil de Software”, el cual propone 4 valores y 12 principios que destilan una manera de pensar o mindset, para abordar un enfoque ligero y adaptativo de desarrollo, un enfoque que nos ayude a responder al cambio. (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-04.webp) (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-06.webp) ## Surge en el mundo del Software y se permea a todo tipo de Industrias Si bien este movimiento inició en el área de Desarrollo de Software, hoy en día es ampliamente utilizado en diversas industrias por millones de personas y equipos en todo el mundo, y está conformado por 4 valores y 12 principios (Puedes leer el Manifiesto Ágil en su sitio original aquí). Los 4 valores que promulga este manifiesto son: 1. **Individuos e interacciones** sobre **procesos y herramientas.** 2. **Software funcionando** sobre **documentación extensiva.** 3. **Colaboración con el cliente** sobre **negociación contractual.** 4. **Respuesta ante el cambio** sobre **seguir un plan.** (image: agile-manifesto-4-valores-visual-agile-coach.webp) Los 17 autores del manifiesto aclaran que, "aunque reconocen la importancia de los elementos de la derecha, valoran más los de la izquierda". Esto es fundamental, ya que la Agilidad o Agilismo no dice, por ejemplo, que no se documente nada en absoluto (es por llevarse al extremo que Agile se considera algo “hippie” o “muy informal”), más bien se valoran más los elementos de la derecha. En este sentido, me gusta preguntar a los equipos: “Si nos centramos en el valor y la colaboración, ¿Qué es lo mínimo que necesitamos documentar?”. En 25 años han cambiado muchas cosas… cambios exponenciales, nuevos productos/servicios, Inteligencia Artificial, y una lista de infinitos etcéteras. Sin embargo, aún buscamos lo mismo en esencia, buscamos desarrollar la capacidad de responder y adaptarnos al cambio a nivel organizacional ## ¡Cuidado! Y justamente hablando de Agilidad Organizacional, aquí viene el primer **¡Mucho ojo!** de este artículo (así decimos acá en México para referirnos a que debemos de tener mucho cuidado), y tiene que ver con: **El objetivo es desarrollar la Agilidad Organizacional, no solo equipos aislados haciendo prácticas ágiles.** Claro que puede hacer una enorme diferencia el tener equipos ágiles (y ha funcionado a lo largo de los años, en mayor o menor medida), pero estamos lejos de obtener el máximo valor que pueden lograr un montón de equipos (link: https://scrumguides.org/ text: Scrum), equipos (link: https://kanban.university/kanban-guide/ text: Kanban), Squads, o cualquier-otro-nombre-rimbombante-que-esté-de-moda trabajando de manera aislada. El objetivo es “agilizar equipos”, pero también sus interacciones de forma que se permee a lo largo y ancho de toda la organización (Si te interesa aprender un poco más sobre este punto, aquí te comparto el link a un artículo que escribí: (link: https://leonelzapien.com/blog/reconsiderando-la-agilidad-organizacional text: Reconsiderando la Agilidad Organizacional)), buscamos desarrollar la Agilidad como una capacidad en lugar de solo prácticas, una mentalidad libre de marcos de trabajo o métodos. ## El Manifiesto debería de actualizarse Muy personalmente considero que el Manifiesto debería actualizarse, por ejemplo, el tercer valor menciona “Software funcionado”, pero si hablamos de que Agile se ha difundido a múltiples industrias, sería adecuado cambiar eso de “Software funcionando” por “Producto o entregable funcional” para quitar el foco de que solo se puede utilizar para desarrollar software, y ¿Qué tal un paso más allá?, qué tal si de una vez cambiamos a: “Producto o entregable funcional que aporte **valor**”, ya que, el entregar un producto funcionando es una prioridad para obtener retroalimentación rápida del cliente y/o usuario final… pero el objetivo final no es solo que este producto funcione, sino que éste aporte valor al cliente o usuario final en cuestión, que resuelva su necesidad, que le haga la vida más fácil. Y todavía un paso más allá es que estos productos o servicios generan un resultado que produzca un **impacto** en la vida de las personas. Este debería ser el enfoque que conduzca el crear un producto o servicio, orientado totalmente en el cliente o usuario. …Y si vamos todavía nos ponemos más aspiracionales y good-vibes, debemos ir otro paso más adelante para que en vez de productos que hagan la vida más fácil, busquemos **¡crear productos que enamoren!** (Lo sé, soy un romántico incorregible, de esos chapados a la antigua 😊) (Si quieres aprender un poco más sobre valor e impacto, aquí te comparto un artículo que escribí sobre el tema: (link: https://leonelzapien.com/blog/outputs-outcomes-impact text: Outputs, Outcomes & Impact - Salidas, Resultados e Impacto)). En realidad, siempre debimos de haber hablado de herramientas Pero bueno, la verdad es que el Manifiesto es un documento histórico que cumple 25 años. El mundo de la Agilidad, como su esencia lo define, también ha ido evolucionando. Los diversos marcos de trabajo, métodos y/o herramientas que lo conforman no son los mismos que hace 2 o 3 décadas, todo evoluciona, y ya no se trata de enfoques **Predictivos vs Adaptativos** ((link: https://leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: Waterfall o Cascada) vs (link: https://leonelzapien.com/blog/que-es-agile text: Agile)), ese nunca fue el objetivo sino un distractor. El enfoque debe de ser el reconocer que cada enfoque es en realidad una herramienta, y como tal, debemos de utilizar la herramienta al contexto adecuado, eso incluye tanto enfoques Predictivos (Waterfall o en cascada), adaptativos (Agile), como **enfoques Híbridos**, esto es la intersección entre los dos enfoques que puede aportar mucho valor (lo “mejor” de cada mundo dependiendo del contexto). ## Agile is dead (La Agilidad ha muerto) Últimamente está muy fresco el tema sobre si la Agilidad ha muerto. Personalmente creo que simplemente **debe de evolucionar y nosotros junto con ella. ** Algo que es innegable es que el movimiento Agile comenzó a mostrar resultados, y rápidamente una industria de certificaciones emergió de súbito con certificaciones que salieron hasta debajo de las piedras, pero la realidad es que no podemos saltarnos etapas, no podemos pasar de cero a cien con un curso de 16 horas y una certificación, se necesita un verdadero proceso para interiorizar el aprendizaje y crear experiencia con horas de vuelo. Sin entrar en temas controversiales, considero que el vender soluciones instantáneas y empaquetadas, soluciones tipo “Sea ágil en 2 días y transforme su negocio”, deformó un poquitico el rumbo y creó expectativas ilusorias. (image: agile-instantaneo-caja-cereal-desayuno-leonel-zapien-lopez.webp) Debemos ser capaces de demostrar su verdadero valor más allá de casarnos con un marco de trabajo o por tener una certificación. Debemos continuar adaptándonos, quizá los nombres puedan cambiar en el futuro, pero la esencia de Agile probablemente permanezca y nos acompañe, quizá con otro nombre, quizá con un reboot, quizá todo lo contrario. Todo, finalmente, es evolución. Como dice Bob Dylan: “los tiempos están cambiando”, y mientras tanto, mientras surge una nueva ola, honor a quien honor merece, así que: Feliz 1er cuarto de siglo al Manifiesto Ágil 😁 (image: manifiesto-agile-25-anos-scrum-kanban-leonel-zapien-lopez-consultor-cursos-certificaciones-guadalajara-jalisco-mexico.webp) ## Nota final Como nota final, los 17 firmanes del Manifiesto Ágil fueron: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas. Puedes leer el Manifiesto Ágil en su sitio original (link: https://agilemanifesto.org/ text: aquí). **Créditos de imágenes:** • Imágenes de los Valores y Principios del Manifiesto Ágil, son del genial arte de (link: https://www.linkedin.com/in/thevisualacademy/ text: Olina Glindevi), desde Estocolmo (The Visual Agile Coach). • Las fotografías de los días en Snowbird, publicadas por Alistair Cockburn (firmante del Manifiesto Ágil).
28 de febrero de 2026 -
Lean
Los 7 Desperdicios del Pensamiento Lean en el lugar de trabajo
Eliminar las actividades innecesarias, también conocidas como desperdicio o despilfarro, es una de las piezas clave para construir una empresa apta para la supervivencia, y es una piedra angular del Pensamiento Lean. En Lean, un desperdicio es cualquier actividad que consume recursos, pero no agrega valor al cliente final, es decir, el cliente no estaría dispuesto a pagar por esa actividad. Estos desperdicios son independientes del giro de nuestra empresa o en la industria en la que estemos, aplican tanto para áreas de productos como de servicios. El problema de estos desperdicios, es que reducen la rentabilidad de la organización, aumentan los costos para cliente, disminuyen la calidad de los productos o servicios que entregamos, e incluso disminuyen la satisfacción y compromiso de los empleados. La idea original de eliminar desperdicios se origina en el (link: https://global.toyota/en/company/vision-and-philosophy/production-system/ text: Sistema de Producción Toyota o TPS) (por sus siglas en inglés, Toyota Production System), creado por(link: https://es.wikipedia.org/wiki/Taiichi_Ohno text: Taiichi Ono), y de ahí se llevó al Pensamiento Lean (si quieres profundizar un poco más en Lean, (link: https://leonelzapien.com/blog/esto-es-lean text: en este artículo) hablo un poco más sobre este tema). (image: this-is-lean-esto-es-lean-toyota-logo-toyota-prodcution-system.webp) # Las 3M De acuerdo con el Pensamiento Lean, se identifican tres obstáculos para las empresas, los cuales son conocidos como las 3M (y ojo, no tiene nada que ver con la famosa empresa creadora de los Post-its, le llaman así porque cada una de estas 3 palabras japonesas inician con la letra “M”). Estas 3M son: 1. Muda (Desperdicios) 2. Mura (Variabilidad) 3. Muri (Sobrecarga) (image: leonel-zaien-lopez-muda-mura-muri-desperdicio-despilfarro-sobrecarga-variablidad-flujo-de-trabajo-flow-lean-thinking.webp) Aunque en este artículo nos enfocamos en la primera M, Muda o Desperdicio, veamos un poco de cada una para tener el contexto completo. ### Muda (Desperdicios) Son todas aquellas actividades que no agregan valor, son aquello elementos que consumen recursos sin aportar valor añadido. Veremos este concepto a detalle un poco más adelante en este artículo. ### Mura (Variablidad) Se refiere a la irregularidad o desigualdad en los procesos. Es “normal” que en un proceso existan ciertas variaciones, esto se refiere a que hay ocasiones en que las personas o las máquinas tienen más elementos de trabajo de los que pueden procesar, y en algunas otras ocasiones no hay tanto trabajo por hacer. La variabilidad resulta de programas de producción irregulares, fluctuaciones en la demanda, variaciones en el volumen de trabajo debido a problemas internos como defectos, tiempos de espera, etc. Mura puede causar Muda, es decir, la Variabilidad en un proceso puede provocar Desperdicios, por ejemplo, retrabajos, tiempos de espera, exceso de inventario, entre otros, dependiendo del contexto. Mura también puede causar Muri, esto es, la variabilidad en un proceso puede provocar que algunas veces las personas y las máquinas estén sobrepasados, y esta sobrecarga es precisamente Muri. ### Muri (Sobrecarga) Muri es sobrellevar a una persona o máquina más allá de sus límites naturales, lo cual puede resultar en problemas de seguridad y problemas de calidad. Muri puede provocar Muda, es decir, la sobrecarga puede provocar desperdicios, por mencionar algunos ejemplos, puede provocar que las personas cometan errores, o que las piezas elaboradas se dañen por exceso de inventario, así como incrementar los tiempos y movimientos para mover todo el inventario. Pero esto no es todo, Muri puede resultar aún en cuestiones peores como problemas de seguridad o salud de las personas. # Los 7 tipos de desperdicios Es momento de hablar sobre los 7 Desperdicios o Mudas, veamos cada uno de ellos: (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-sobreproduccion.webp) ### 1. Sobreproducción: Producir más de lo necesario (más de la demanda) o antes de que se requiera. **Ejemplos:** • Fabricar productos sin pedidos concretos, o más de lo requerido “por si acaso”. • Realizar documentación o reportes que nadie usa. • Agregar características o funcionalidades a un software o servicio que el usuario no necesita. (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-tiempo-de-espera.webp) ### 2. Tiempos de espera: Tiempo perdido esperando materiales o información (requerimientos, confirmación, aprobación, etcétera). Pueden reflejar cuellos de botella. **Ejemplos:** • Operarios esperando materia prima, piezas, instrucciones, o que una máquina tenga capacidad. • Empleados esperando aprobación o visto bueno de otra área, o confirmación de algún requerimiento por parte de un stakeholder o parte interesada (un manager, líder, el cliente, comité, otro equipo / área / departamento, etc.) (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-inventario.webp) ### 3. Inventario: Acumulación innecesaria de materiales, productos o información. **Ejemplo:** • Tener stock o inventario excesivo sin demanda inmediata. • Información acumulada sin uso estratégico. • Correos sin leer (estar en cadenas de correos en las que no tenemos relación directa “para estar enterados”), documentos, reportes, formularios duplicados o que traslapan información. (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-transporte.webp) ### 4. Transporte: Movimiento innecesario de materiales o productos (ese movimiento no agrega valor al producto). Movimiento innecesario de materiales o productos (ese movimiento no agrega valor al producto), pueden ser movimientos de empleados (o maquinaria) que son complicados e innecesarios o usar métodos innecesariamente rebuscados. **Ejemplos:** • Trasladar piezas o materiales entre estaciones, edificios, áreas distantes. • Trasladar documentos físicamente entre oficinas, edificios, áreas. • Cambiar de tarea con mucha frecuencia, innumerables interrupciones o por cambios de prioridades. (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-movimientos.webp) ### 5. Movimientos innecesarios: Aunque pudiera parecer muy similar al punto anterior, esta Muda ser refiere movimientos de empleados (o maquinaria) que son complicados e innecesarios o usar métodos innecesariamente rebuscados. Ejemplos: • Movimiento innecesario de empleados o maquinaria. • Reuniones innecesarias o esfuerzo adicional para encontrar información. • Espacios de trabajo mal organizados o estructurados. (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-calidad.webp) ### 6. No calidad (Defectos): Errores o defectos que requieren corrección o rehacer el trabajo (retrabajo). **Ejemplos:** • Producto mal ensamblado o fuera de especificación, piezas rotas o defectuosas. • Datos mal ingresados en un sistema. • Bugs (Defectos en Software). • Documentos con errores tipográficos o de ortografía, no alineados a la imagen corporativa o con contenido erróneo. (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-proceso.webp) ### 7. Sobreprocesamiento: Hacer más trabajo del necesario, trabajo que no aporta valor adicional y aumenta el precio final del producto o servicio (algo por lo que el cliente no está dispuesto a pagar). **Ejemplos:** • Pulir una pieza más allá de lo requerido. • Esfuerzos duplicados por falta de claridad en roles. • Múltiples niveles de aprobación para tareas pequeñas o no críticas. • Complejos algoritmos para problemas simples (image: leonel-zapien-lopez-guadalajara-mexico-7-desperdicios-lean-toyota-production-system-muda-mura-muri-tps-talento.webp) ### 8. Talento desperdiciado. Y como decimos acá en México cuando crees que ya es todo y recibes o te dan una pieza más o un poco más, pero no lo esperabas: "El pilón", es decir, el 8vo Desperdicio. Aclaro que no forma parte de los 7 desperdicios originales, se agrega después en la primera edición del libro que menciono en las referencias, así como en algunas fuentes, y se considera que este desperdicio puede provocar alguno (o varios) de los primeros 7 desperdicios originales. Corresponde a no aprovechar el talento, conocimiento y la creatividad de las personas que laboran en la organización. Para la mejora continua y la generación de valor, la pieza clave somos las personas (por eso es uno de los pilares del Sistema de Producción Toyota). # Pequeño caso para cerrar (image: documentoscaso-de-estudio.webp) Para comprender a lo que se refiere la definición de que Desperdicio cuando menciona que “el cliente no estaría dispuesto a pagar por ello”, veamos el siguiente breve ejemplo hipotético: • Imagina que te sientes mal y necesitas ir al médico. Tú como cliente buscas atención para resolver tu necesidad, en este caso buscas sentirte mejor. • Realizas primeramente una llamada telefónica para programar una cita. Con suerte te atiendan ese mismo día, sino debes de esperar unos días. Para este ejemplo imaginemos que esperas dos días para tu consulta (suponiendo no es nada urgente). • El día de tu cita, al llegar al lugar de atención médica, un hospital, debes de buscar estacionamiento en el edificio, tal vez a varios pisos de donde tienes tu consulta. Llegas al lobby donde tienes que esperar unos minutos a que te atienda la asistente, después registrarte y esperar por instrucciones o una credencial para permitirte el acceso. • Al llegar al consultorio, debes de registrarte de nuevo. Y con esto, pueden ocurrir distintas cosas: Te solicitan tu información si eres paciente nuevo o buscan tu expediente si ya eres un paciente, tienes que esperar atención, aunque tal vez programaste una cita telefónica (siempre hay algo de variabilidad en la duración de las citas, quizá ingresó a alguien de último momento en la lista de pacientes por ser alguna situación de emergencia, y eso ha retrasado aún más tu cita). • Esperas atención durante 1 hora exacta. • Entras a la consulta, el médico revisa tu expediente, conversa contigo, te revisa, y te indica los medicamentos correspondientes en una receta. • Sales del consultorio, y te diriges con la asistente para realizar el pago. • Tal vez le proporcionas tu información de facturación para que realicen la correspondiente factura. • Tienes que regresar hasta el piso donde dejaste estacionado tu coche. Pagas el boleto de estacionamiento, ingresas a tu vehículo, y procedes a manejar de regreso a tu casa. En el camino haces una escala en una farmacia para comprar el medicamento. Lo que como cliente esperas es sentirte mejor. Hasta este punto, apenas tienes medicamento que vas a comenzar a tomarte. Han pasado dos días, tiempos de espera en el consultorio, papeleo antes y después de la consulta, traslados desde y hasta el lugar de estacionamiento… todo esto para una consulta que duró, supongamos, 30 minutos. Para indicar una cifra fácil de calcular para los fines didácticos de este ejemplo, supongamos que pagaste $100 dólares por la consulta. En este servicio hubo un asistente telefónico, una agenda, una asistente que hace la facturación, registrarte múltiples veces, búsqueda o captura de un expediente, y tiempo de espera… 2 días para la atención y 1 hora dentro del consultorio, más los tiempos de espera con las asistentes. Todas estas esperas, personas, papeleo, es algo que va dentro del costo de los $100 dólares, es decir, te cobraron también todo eso, aunque lo que tú querías era solo la consulta, y, en última instancia, sentirte bien. Para este ejemplo supongamos que todo este papeleo, asistentes, etc., costaron $50 dólares de los $100 dólares que pagaste. ¿Te parece “adecuado” que hayas pagado por todo esto?, y ¿Qué tal que se optimizara el proceso de atención, se redujera a la mitad todo el tiempo de espera (con lo cual tu experiencia como cliente es mejor) y como la cereza del pastel, además, solo tuvieras que pagar $50 dólares en total? Pues bien, tal vez pudieras decir que es “normal” todo lo que menciono. Y así es, en cierta medida. Pero en este ejemplo podemos ver gran cantidad de Desperdicios. La verdad es que hay desperdicios que se pueden eliminar de los procesos y algunos que no (del todo). Lo importante es identificarlos y no darlos por sentado como “normales”, porque solo así es como podemos tomar acciones para reducirlos y con esto, mejorar el valor hacia el cliente. Por esto mismo menciono que los Desperdicios incrementan los costos de proporcionar el servicio y, por lo tanto, el precio que paga el cliente. Así mismo, estos Desperdicios tienen un impacto directo en la experiencia del cliente y en su satisfacción (y como vimos en el ejemplo, no hablemos del precio). # Conclusiones Ahora que hemos dado un vistazo cada uno de estos 7 desperdicios (o mejor dicho, 8 desperdicios), podemos ver que aplican tanto a áreas de servicios como de productos, y que forman parte de nuestros procesos, de nuestra forma de trabajar. Lo importante es identificarlos y no darlos por sentado como “normales”, no dar por hecho que “el proceso siempre ha sido así, debe de tener 75 aprobaciones y es imposible modificarse”, porque solo así, analizando y cuestionando la manera en cómo hacemos las cosas, es como podemos tomar acciones para reducirlos y con esto, mejorar el valor hacia el cliente. **¿Conocías estos desperdicios?** **¿Te sentiste identificada o identificado con alguno (o algunos) de estos desperdicios en tu lugar de trabajo?** # Referencia: (link: https://www.amazon.com/-/es/Toyota-Way-Second-Management-Manufacturer/dp/1260468518/ref=sr_1_1?__mk_es_US=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=NVP1M2H0FGTD&dib=eyJ2IjoiMSJ9.yXzsz7lCfAoA-ABFchwtHEaLcG0Rqr9FGfz88CMtosIEBeGoN60M71B2LJ-sxDN4HioyacKtNGAKnB6N3KqO5OYEMbHntyLcxJ628_Q93eSkx_cBP1LXgkYTofvkvfqUCNattz8g_00vtuz2a-PHsDzSpZ0iRM0eGvcX4XybGztdKtYr0zAdCqWeqwKQNJgWDwquYl4nKQUO2LonFOMWNznfElc1bzVINJwxxm24OaY.rdsCnIDGGpNt_IFG78jLlzX-9gZOFjUvfjqWqq4979w&dib_tag=se&keywords=the+toyota+way&qid=1759084769&sprefix=the+toyota+way%2Caps%2C214&sr=8-1 text: The Toyota Way: ) 14 Management principles form the world’s greatest manufacturer. 2nd Edition. Jeffrey K. Liker (2021). McGraw Hill.
28 de septiembre de 2025 -
Trabajo en Equipo, Varios
Mentalidad Fija vs Mentalidad de Crecimiento: Cambiar el chip para avanzar
¿Alguna vez has escuchado a alguien decir “yo no soy bueno para las matemáticas” o “nunca voy a aprender inglés”? Estas frases, aunque parecen inofensivas, reflejan una forma de pensar que puede limitar nuestro desarrollo. La psicóloga Carol Dweck, profesora en la Universidad de Stanford, estudió durante años cómo nuestras creencias sobre la inteligencia y el talento influyen en lo que logramos. De acuerdo con el trabajo de Carol Dweck, existen dos formas distintas de ver el mundo, es lo que llama: **Mentalidad Fija y Mentalidad de Crecimiento (Fixed mindset & Growth mindset)**. (image: carol-dweck-mindset-book-mentalidad-del-exito-libro-leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad.webp) (Imagen: Carol S. Dweck, Ph.D.) Veamos un poco de estos conceptos y cómo aplican en nuestra vida diaria, personal y profesional, para aprender, superar obstáculos, y crecer. # Mentalidad fija (image: leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad-mentalidad-de-crecimiento-vs-mentalidad-fija-growth-fixed-mindset-carol-dw.webp) La mentalidad fija es la creencia de que nuestra inteligencia, habilidades o capacidades son algo que no cambia. Si alguien “nació” bueno para los deportes, entonces así es, y no puede desarrollar otras habilidades como el pensamiento analítico o ser bueno para las artes, por ejemplo. Pero esto va un poco más allá, ya que una persona con mentalidad fija no está abierta para aprender en todo el sentido de la palabra, no solo me refiero a buscar aprender nuevas cosas (como tomar cursos o formar parte de institutos), esto implica también que suele evitar retos o teme equivocarse y se va por realizar actividades “a la segura” (en las que no puede equivocarse), lo cual le evitar el aprender y desarrollar nuevas habilidades. Esto tiene también que ver con que, por ejemplo, pueden tomar una **retroalimentación o feedback** como una invalidación personal, con frustración, actuando a la defensiva y poniendo la responsabilidad en los demás en lugar de en sí misma o en sí mismo, ya que no está abierta para aprender y esto incluye el negarse a identificar áreas de mejora en su persona. Un ejemplo podría ser alguien que, al recibir una retroalimentación limpia y objetiva, comienza a justificarse con mil argumentos posibles: “No hice las pruebas unitarias porque era un elemento de trabajo de urgencia alta” o “No entregué el reporte porque no entendí que era para hoy, pensé que se podía entregar otro día”… y no se malinterprete que solo las personas con personalidad fija cometen errores, la diferencia es la apertura para reconocerlo, porque en ambos ejemplos que he mencionado, el resultado sería totalmente distinto si la persona hubiera preguntado o confirmado, si la persona levanta la mano para solicitar apoyo. # Mentalidad de crecimiento (image: leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad-mentalidad-de-crecimiento-vs-mentalidad-fija-growth-fixed-mindset-02.webp) La mentalidad de crecimiento, en cambio, es la creencia de que podemos aprender y desarrollar nuevas habilidades, que mediante práctica y dedicación podemos crecer. Si una persona con mentalidad de crecimiento no sabe algo, puede preguntar ya que no teme a mostrarse abierta o abierto y reconocer que no lo sabe todo. Así mismo, puede experimentar ya que no teme a que algo no funcione como se esperaba, por el contrario, identifica el aprendizaje de las situaciones. Una mentalidad de crecimiento es una perspectiva de la vida en la que una persona cree que sus talentos, inteligencia y habilidades pueden desarrollarse todavía más. Quienes poseen esta mentalidad buscan oportunidades para aprender, adquirir nuevas habilidades y mejorar las existentes. Cuando se presenta un reto o desafío, una persona con mentalidad de crecimiento no lo ve como una oportunidad para crecer. Creen que el trabajo constante, y no la suerte o el azar, determina lo que consiguen en la vida. Es totalmente proactiva o proactivo, siempre dispuesta o dispuesto. Es importante una aclaración, como dicen mis amigos chilenos: ¡Ojo al piojo!, veamos: # Mentalidad de crecimiento no es mantener siempre un positivismo aparente Si a una persona le fue mal en un examen, si no fue aceptado en la universidad a la que aplicó, si le tocó un despido debido a un recorte de personal en su organización (layoff o downsizing), o si ha tenido un problema personal / familiar o en su relación de pareja, no quiere decir que no se permita sentirse mal o decepcionada o decepcionado, ¿Quién no lo estaría?, ¡Somos humanos! (image: leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad-mentalidad-de-crecimiento-vs-fija-growth-fixed-mindset-optimismo-tristeza.webp) (Imagen de: Depositphotos) La enorme diferencia es que no “tiran la toalla”, tal vez pasen por un periodo de duelo (en mayor o menor medida, todos lo hacemos, dependiendo del contexto), pero acepta la situación y se pone a trabajar para afrontar el reto. No toma la situación como una “justificación”, como lo haría una persona con mentalidad fija. También es importante mencionar que una Mentalidad de Crecimiento no trata de negar nuestras limitaciones ni que existen atributos o características que pueden ayudar a que una determinada actividad nos resulte más fácil o más difícil, pero, un hecho, es que una característica clave de la mentalidad de crecimiento implica reconocer de manera objetiva tanto nuestras fortalezas como nuestras debilidades, ambas, e identificar las áreas en las que necesitamos trabajar. (image: leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad-mentalidad-de-crecimiento-vs-fija-growth-fixed-mindset-04.webp) (Imagen de creación propia con mi amigo Copilot) # Aplicación en la vida profesional En el trabajo, tener una mentalidad de crecimiento puede marcar la diferencia en cómo avanzamos, cómo nos adaptamos a los cambios, qué tan dispuestos estamos para aprender nuevas herramientas. Esto es aún más crítico (por el impacto que puede tener) en un líder, ya que la Mentalidad de Crecimiento del líder puede ayudar a desarrollar a sus colaboradores, fomentar el aprendizaje en su equipo, celebrar los intentos y no castigar los errores. De nueva cuenta, ¡Ojo al piojo!, hay de errores a errores, claro, y no quiere decir que no se deban de conversar, pero hay siempre maneras adecuadas, y es fundamental enfatizar que un líder con Mentalidad de Crecimiento fomenta un entorno de alta seguridad Psicológica (si te interesa conocer un poco más sobre **Seguridad Psicológica**, puedes leer el artículo de mi blog sobre este tema (link: https://leonelzapien.com/blog/la-importancia-de-un-entorno-de-alta-seguridad-psicologica-psychological-safety text: aquí)). # Un ejemplo de la vida real En un equipo en el cual estuve hace vaaarios años, yo era **Scrum Master**, comenzamos a trabajar con Scrum desde cero con un equipo nuevo. Después de los tropiezos y aprendizajes iniciales de todo equipo (no solo el equipo era nuevo en Scrum, sino que era un equipo de nueva formación), después de un proceso de inmersión en Scrum, ya cuando el equipo estuvo trabajando aproximadamente 5 Sprints comenzaba a acoplarse, tanto como un equipo que pasa por diversas etapas (aunque existen otros modelos que lo explican muy bien, personalmente me parece muy adecuado el Modelo de Tuckman que explica que un equipo pasa por cuatro etapas: formación, conflicto, normalización y desempeño), como en lo concerniente a aprender Scrum y Agile (si te interesa conocer un poco más estos temas, puedes leer aquí mismo en mi Blog un artículo sobre Scrum (link: https://leonelzapien.com/blog/que-es-scrum text: aquí), un artículo sobre Agile (link: https://leonelzapien.com/blog/que-es-agile text: aquí), un artículo sobre el Scrum Master (link: https://leonelzapien.com/blog/quiero-iniciarme-en-scrum-por-donde-comienzo text: aquí), o un artículo sobre el Agile Coach (link: https://leonelzapien.com/blog/scrum-master-o-agile-coach text: aquí)). Después de estos 5 Sprints, el equipo comenzaba a entregar software de mejorar calidad, los eventos de Scrum ya casi siempre cumplían su duración (timebox) y propósito, las estimaciones de sus historias de usuario estaban mejorando bastante (en aquel tiempo solo hacíamos estimaciones, después aprendí sobre herramientas de pronóstico, pero ese es tema para un futuro artículo), y otros muchos etcéteras. Sin embargo, no todo era “miel sobre hojuelas”. Un día que me quedé realmente hasta tarde en la oficina por unas cuestiones que estaba revisando con un manager, me di cuenta que un chico del equipo aún estaba trabajando, y ya pasaban de las 9 de noche. Hablé con él y me comentó que estaba revisando unas cosas, pero todo estaba bien. A la semana siguiente, fui en la noche a la oficina junto con otras personas por un despliegue a producción que iba a realizar otro equipo, eran las diez y media de la noche, y nuevamente ahí estaba este chico, aún trabajando. Esto ya era claramente un foco rojo. En conjunto con su manager revisamos sus horarios de entrada y salida, y nos dimos cuenta de que todos los días salía entre 8 y 11 de la noche. Diariamente. Nadie en el equipo nos habíamos percatado de esto ya que entregaba en tiempo sus tareas, a veces tenía uno que otro retraso, pero nada de impacto. En los Daily Scrum, nunca tenía bloqueos, impedimentos, ni nada “atípico”. Me di cuenta de que cumplía con su trabajo, pero le tomaba muchas más horas que al resto de los integrantes del equipo en hacerlo. Me di cuenta de que nunca levantaba la mano para solicitar ayuda, de que claramente tenía dudas técnicas, problemas con su código, pero no lo externaba. Claramente sabía que era un chico algo “serio”, pero no tenía idea del nivel de frustración con el cual estaba cargando. (image: leonel-zapien-lopez-guadalajara-mexico-ideas-agilidad-mentalidad-de-crecimiento-vs-fija-growth-fixed-mindset-presona-frustrada.jpg) (Imagen de: eepsicologia.lat) Así que fue tiempo de intervenir directamente. Durante la conversación uno-a-uno, para mi sorpresa, explotó. Creo que por un lado el estrés y cansancio acumulado no ayudaron a la situación, y, por otro lado, su frustración hizo el caldo perfecto en la olla de presión. Fue un tema que se abordó, no existe ninguna varita mágica, así que se requirieron varios meses de acompañamiento y seguimiento para ayudarlo a él, y consecuentemente a todo el equipo. Años después, cuando leí sobre las mentalidades de crecimiento y fija, todo hizo sentido. Sería muy simplista tratar de reducir todo el escenario a unas cuantas variables, por un lado, su enfoque en “continuar trabajando e intentándolo” pudieran sugerir una mentalidad de crecimiento, sin embargo, el estar en la oficina a tan altas horas de la noche todos los días, era una respuesta desde miedo, lo cual creaba un efecto que no era sostenible. Por eso nunca solicitó ayuda, fue meramente circunstancial que nos dimos cuenta. En palabras de Carol Dweck: “Las personas con mentalidad fija suelen expresarse sobre sí mismas como 'Soy un fracasado o fracasada', 'Todos son mejores que yo', o 'Mi vida es lastimosa', ven las situaciones que les suceden como una medida directa de su competencia o de su valía ante los demás”. ¿Te ha sucedido alguna historita similar, de una u otra manera? # Recomendaciones para pasar de Mentalidad Fija a Mentalidad de Crecimiento De acuerdo con Carol Dweck, podemos pasar de una mentalidad fija a una de crecimiento, el proceso requiere básicamente de dos puntos. Primero que todo, de la toma de consciencia de parte de la nosotros, personalmente considero que puede ser lo más “difícil” el reconocer la situación. El segundo punto, la intención de cambiar. Nada de esto es sencillo, pero un paso a la vez. Aquí te comparto algunas sugerencias para este paso de una mentalidad a otra: **1. Reconoce tu mentalidad actual** Carol Dweck sugiere que el primer paso es identificar cuándo estás operando desde una mentalidad fija. Observa tus pensamientos automáticos ante el error, la crítica o el reto. ¿Te dices cosas como “no soy buena o bueno en esto” o “mejor no lo intento”? **2. Reformula el lenguaje interno** Cambia frases como “no puedo” por “todavía no puedo”. El uso del “todavía” (“not yet”) es una herramienta poderosa que Carol Dweck destaca para abrir la puerta al aprendizaje. **3. Enfócate en el proceso, no solo en el resultado** Celebra el esfuerzo, la estrategia y la persistencia, no solo el éxito final. Carol Dweck enfatiza que valorar el proceso fortalece la motivación y la resiliencia. **4. Redefine el error como parte del aprendizaje** En lugar de ver el fracaso como una prueba de incompetencia, míralo como una fuente de información. Pregúntate: “¿Qué puedo aprender de esto?” en lugar de “¿Qué hice mal?” **5. Busca retroalimentación y úsala como guía** Carol Dweck señala que las personas con mentalidad de crecimiento ven la retroalimentación o feedback como una oportunidad. Cuando recibas retroalimentación, detén el impulso de defenderte. Escucha activamente y analiza la información recibida con calma, lleva la idea a tu casa y piénsala un par de días, esto ayudará a ver las cosas con otra óptima. Después pregúntate cómo puedes aplicar lo que te dicen. **6. Rodéate de entornos que fomenten el aprendizaje** Las personas de las cuales nos rodeamos y la cultura que predomine en ese entorno influye. Si estás en un equipo o entorno que castiga el error, será más difícil cambiar de mentalidad. Busca espacios donde se valore la curiosidad, la experimentación y la mejora continua. **7. Practica el “aprender a aprender”** Carol Dweck propone que la inteligencia no es fija, sino maleable. Cultivar el hábito de aprender es clave. Lee, pregunta, experimenta. No para demostrar que sabes, sino para seguir creciendo. **8. Modela el cambio en otros** Si eres líder, docente o mentor, tu mentalidad impacta directamente en los demás. Muestra vulnerabilidad, habla de tus propios aprendizajes y errores, y celebra los intentos de tu equipo. # Conclusiones La mentalidad que adoptamos frente a los retos no solo afecta lo que logramos, sino también cómo nos sentimos en el proceso. La buena noticia es que la mentalidad de crecimiento se puede cultivar. No es ninguna bala de plata, ni magia, solo es práctica. Se trata de comprender que los errores como parte del camino y de entender que aprender es un proceso, no un destino. En lo personal, esto nos ayuda a enfrentar miedos, mejorar relaciones y crecer como individuos. En lo profesional, nos vuelve más adaptables, creativos y resilientes. Y aquí hago un pequeño paréntesis ya que hace rato di un ejemplo de un equipo del cual fui **Scrum Master**, y es que cuando hablamos de formas de trabajo/filosofías como **Agile, Scrum, Lean, Kanban, OKRs,** etcétera, damos por sentado que las personas están ávidas de aprender nuevas herramientas, de experimentar, de mostrar con completa transparencia su trabajo, de inspeccionar y adaptar. Pero esto no siempre es cierto. Como todo en la vida, depende. En mi caso, no soy psicólogo ni mucho menos, pero considero que lo importante es sumar herramientas que nos ayude a identificar diversas situaciones para ayudar a nuestros equipos, tal vez hasta pudiera llegar a ser necesario en algunos casos la intervención de ayuda profesional, pero nosotros, al estar ahí todos los días con las personas, tenemos la responsabilidad de ser los primeros en levantar la mano. Como personas y profesionales, no se trata de que tengamos todas las respuestas. Se trata de reconocer nuestras debilidades y fortalezas para actuar en consecuencia. Se trata de mantener una constante apertura de **aprender a aprender**. (image: growth-mindest-fixed-mindset-management-30.webp) Imagen: Tabla comparativa de Mentalidad Fija vs Mentalidad de crecimiento, cortesía de (link: https://management30.com/ text: Management 3.0) # Referencias (link: https://www.amazon.com/-/es/Mindset-Psychology-Carol-S-Dweck/dp/0345472322/ref=sr_1_1?__mk_es_US=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=HV9YWE2ZTMPS&dib=eyJ2IjoiMSJ9.RpTt2SA4YSDFfxiM1s2fDQ.URrjjsoktcD1eeJ_m6LMfoYb2njShUmtyJA9PtnRmis&dib_tag=se&keywords=Mindset%2C+the+new+psychology+of+success%3A+How+we+can+learn+to+fulfill+our+potential&qid=1756088228&sprefix=mindset%2C+the+new+psychology+of+success+how+we+can+learn+to+fulfill+our+potential%2Caps%2C161&sr=8-1 text: Mindset, the new psychology of success: How we can learn to fulfill our potential). Carol S. Dweck. Ballantine Books (2016).
25 de agosto de 2025 -
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, PMI
¿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, PMI
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.” # ¿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. # 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
