Agile, Lean,
Gestión del Cambio
Consultor, Facilitador
& Speaker

0
Alumnos capacitados
0
Asistentes a mis conferencias & webinars
0
Países alcanzados
0
Certificaciones profesionales con las que cuento

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

Próximos
Cursos

Ver más cursos
incompany

Cursos
In-company

Cualquiera de los cursos ofertados en el calendario, o bien, cursos específicos a la medida de tus necesidades. Podemos cocrear juntos una experiencia sublime de capacitación en un grupo privado, formado por personas de tu empresa.

Hey!, Más información sobre esto

Consultoría

La Agilidad o Agilismo es un camino y no un fin. Te acompaño en este viaje para cocrear las mejores condiciones en tu organización para abrazar la Agilidad Organizacional

  • Facilitación
    Facilitación

    Facilitar es “hacerlo fácil”.
    Facilito sesiones para guiar a personas y equipos hacia un resultado predeterminado ¿Cómo?, a través prácticas, dinámicas y herramientas diversas de gamificación que fomenten las conversaciones poderosas y liberen el potencial de las personas.
  • Mentoría & Coaching
    Mentoría & Coaching

    Enfocada en cuestiones directas sobre temas específicos. Es una opción adecuada si tienen alguna consulta puntual y se encuentran en la exploración de alternativas.
    Una manera de ayudar a desarrollar nuevos conocimientos y habilidades específicos ¿Cómo?, a través de compartir experiencia y guía, a la vez que se pone en práctica lo aprendido.
  • Consultoría
    Consultoría

    Les acompaño en el viaje de evolución ágil de tu organización: Partir de un estado inicial, co-crear las mejores condiciones de manera iterativa que potencialicen su capacidad de adaptarse al cambio y abrazar la Agilidad.
Hey!, Más información sobre esto

Testimonios

Algunos testimonios de personas con quienes he tenido el gran gusto de colaborar profesionalmente a lo largo de este mágico camino de la Agilidad:

  • “

    Leonel consiguió resultados de cambio sorprendentes en la empresa con la mentoría de Scrum. Es un profesional muy enfocado para trabajar en el aprendizaje de cada colaborador de nuestra organización. Tiene excelentes conocimientos en el marco de Scrum, y gracias a él hemos podido llevar a cabo la implementación de varios proyectos de forma exitosa.

    **Miguel Ángel Pedraza González** Dirección de Transformación Digital e Innovación en (Fintech-Retail) **(México)**

    Miguel Ángel Pedraza González
    Dirección de Transformación Digital e Innovación en (Fintech-Retail)
    (México)

  • “

    Destaco la facilitación de nuestro trainer Leonel Zapien López, impecable.
    Me llevo la forma de explicar los conceptos y las dinámicas utilizadas que ayudan a entender los conceptos puestos en práctica.

    **Cristian Rodríguez** Enterprise Agile Coach | SAFe Agilist | CSM | Transformación digital **(España)**

    Cristian Rodríguez
    Enterprise Agile Coach | SAFe Agilist | CSM | Transformación digital
    (España)

  • “

    Gran dominio del tema, excelentes visualizaciones, los ejercicios prácticos fueron de mucho aprendizaje, en conclusión Leonel Zapien Lopez felicidades por tu enorme capacidad de transmitir conocimientos.

    **Katheryn Hodgson** Gestión Administrativa-Financiera en Organizaciones sin Fines de Lucro **(Nicaragua)**

    Katheryn Hodgson
    Gestión Administrativa-Financiera en Organizaciones sin Fines de Lucro
    (Nicaragua)

  • “

    Superó mis expectativas!! Me encantó y 100 de calificación a Leo.

    **Guillermina Marín Covarrubias** Program Manager **(México)**

    Guillermina Marín Covarrubias
    Program Manager
    (México)

  • “

    Leonel comparte muchísimo más Valor del que esperé desde el momento que supe de su curso. Me parece que tiene un estilo bastante amigable, amable y atento para impartir el conocimiento.
    Busca siempre resolver cualquier duda posible y da tiempo suficiente y adicional para responder cada pregunta. Estaría dispuesto a tomar más cursos con él, sin duda, y lo recomiendo 100%

    **Leopoldo García** Program Manager **(México)**

    Leopoldo García
    Program Manager
    (México)

  • “

    Como siempre Leonel Zapien Lopez dándonos una cátedra. Sencillamente magistral, muchísimas gracias por compartir con nosotros tus conocimientos y experiencias. Un abrazo gigante desde Venezuela hasta México.

    **Ileana Ramos Pereira** PMP, PMI-ACP, Scrum Master, Product Owner. Consultoría de Negocios **(Venezuela)**

    Ileana Ramos Pereira
    PMP, PMI-ACP, Scrum Master, Product Owner. Consultoría de Negocios
    (Venezuela)

  • “

    Taller 100% recomendable, Leonel Zapien Lopez con clases muy entretenidas, imposible no mantenerse atento!

    **Leonardo Soto Cartes** Director de Ciberseguridad **(Chile)**

    Leonardo Soto Cartes
    Director de Ciberseguridad
    (Chile)

  • “

    Me encantó el curso, mucha información entregada de una manera muy amena, dinámica y entretenida. Felicidades por estos skills educativos.

    **Fabiola Fajardo** Clinical Neuro- Scientist | Life Science Consultant & Project Manager **(México)**

    Fabiola Fajardo
    Clinical Neuro- Scientist | Life Science Consultant & Project Manager
    (México)

  • “

    Una gran experiencia con el facilitador, con un alto grado de innovación y cocreacion, siempre nos mantuvo demasiado enfocados en los temas que se nos pasaban las sesiones rapidísimo por su gran manera de abordar los temas. Sabe liderar de manera excelente el curso, muy flexible al momento de dar respuesta a dudas, siempre con una gran amabilidad y establece de una manera muy entendible el contexto de los temas a fin de que todos podamos entenderlos.

    **Miguel Ángel López** Gerente de Operaciones **(México)**

    Miguel Ángel López
    Gerente de Operaciones
    (México)

  • “

    Quiero expresar mi agradecimiento a Leonel Zapien Lopez, talentoso facilitador, por su experiencia y dedicación en la enseñanza de este poderoso enfoque ágil.

    **Noemí Zalazar** Desarrollo Full Stack con enfoque en Frontend | Metodologías Ágiles | PM **(Argentina)**

    Noemí Zalazar
    Desarrollo Full Stack con enfoque en Frontend | Metodologías Ágiles | PM
    (Argentina)

  • “

    Algo que cabe destacar entre todo lo positivo, es su método y el expertise con el cual se maneja en conjunto con la pasión y dinamismo que emplea al explicar los temas, por ende, puedo confirmar y reafirmar que ha sido una de las mejores experiencias de aprendizaje profesional que he tenido.

    **Sascha Alexander Pedersbeck Franco** Scrum Master | PM **(México)**

    Sascha Alexander Pedersbeck Franco
    Scrum Master | PM
    (México)

  • “

    ¡Sos un crack Leonel!
    Como dice la frase “Ser un Facilitador es como ser un artista, tienes los flujos de procesos de diferentes colores combinados en una obra de arte” ~ Greg Cimmarrusti

    **Sheila Santos** Scrum Master| Coach Ontológico| Project Manager **(Argentina)**

    Sheila Santos
    Scrum Master| Coach Ontológico| Project Manager
    (Argentina)

  • “

    Es un referente a nivel Latam y en muchas comunidades llevando a todos la agilidad desde Management 3.0. Todo muy bien, temas bien explicados y la pasión que transmite sin igual.

    **Víctor Uriel López Vázquez** PSM I™ / PSPO I™/ PSPBM™ / PSK I™ / A-CSM® / DASM® / Kenshuin Level 4 TPS-NPS **(México)**

    Víctor Uriel López Vázquez
    PSM I™ / PSPO I™/ PSPBM™ / PSK I™ / A-CSM® / DASM® / Kenshuin Level 4 TPS-NPS
    (México)

Visita mi
Blog

Scrum NO es una metodología… 30 años después
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
Técnicas de Priorización: Si todo es urgente, nada es urgente
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
¿Scrum Master o Agile Coach? Evolución y competencias del Agile Coach
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
Ver más artículos súper chéveres

Yo soy
Leonel :)

leonel-zapien-lopez-consultor-cursos-speaker-agile-lean-pmi-pmp-scrum-kanban-management-3.0-okrs-guadalajara-mexico-04

¡Hey!, ¿Qué tal?

Soy un espíritu libre y creativo: Amo viajar y las actividades al aire libre como trekking y acampar.
Soy fan de los comics, de Star Wars y me encanta la salsa cubana.

Mi pasión en la vida (además de la Agilidad) es la fotografía y la literatura.... todo esto es parte de mi ikigai.

Aquí te platico sobre mí y mi experiencia profesional