El bloc de notas de un Agilista Jedi

Todos

Change Management

Management 3.0

Lean

Scrum

MVP

Product Management

Innovación

OKRs

Agile

Agilidad

Agilismo

Agilidad vida cotidiana

Kanban

Project Management

Change Management, Management 3.0

El "Método Mojito" en Gestión del Cambio: Change Management 3.0

Ya lo había mencionado anteriormente en otro artículo, pero es súper crítico, así que abrimos con esta estadística de nueva cuenta:** De acuerdo con diversos estudios, más del 70% de las iniciativas de cambio fracasan**. Las razones principales de este fracaso van desde la resistencia de los empleados hasta la falta de un modelo de liderazgo. En resumen… las iniciativas de cambio fracasan debido que no consideraron y obviaron cuestiones de lo más complejo e importante de las organizaciones: Las personas. El día de hoy vengo a poner este tema sobre la mesa: El modelo de Gestión del Cambio que propone Jurgen Appelo: **Change Management 3.0.** # Pero primero lo primero: ¿Qué es un cambio organizacional? Cambio organizacional es el proceso en el cual una empresa modifica un elemento importante de su organización, por ejemplo: Un modelo nuevo de negocio, un cambio tecnológico que modifica la forma de operar, o sus procesos internos. Estos cambios organizacionales tienen un impacto en la organización ya que pueden implicar cambios en los objetivos de la empresa, en los productos o servicios que ofrecen, o en sus operaciones… pero lo realmente complejo de estos cambios es que implican un cambio en las personas, en la manera en que venían trabajando. Así, cuando en tu organización ha habido alguna reestructuración que modifica o crea un departamento o división nueva, modifican su modelo de negocio, implementan una nueva forma de trabajar (por ejemplo, la adopción la Agilidad o Agilismo a través de Scrum, Kanban, Management 3.0, entre otros, o la implementación de programas de Mejora Continua, 5s, Manufactura Esbelta, etcétera), cuando ha habido implementaciones de nuevas herramientas tecnológicas como sistemas ERP, herramientas de colaboración en la nube, automatizaciones, o cualquier otro cambio tecnológico… todos estos son ejemplos de cambios organizacionales. ¿Te suena familiar esta situación? # Importancia de la Gestión (o acompañamiento) del Cambio La gestión del cambio es la aplicación de un proceso estructurado y un conjunto de herramientas para abordar el lado humano de los cambios, se centra en las personas, en cómo ayudarlas a no temer, reducir la resistencia, a participar, y adoptar un cambio en su trabajo diario. # Ahora sí, vamos al punto: Change Management 3.0 El modelo de Gestión de Cambio de Management 3.0, que es parte del kit de herramientas de Management 3.0, propone 4 aspectos: 1) Bailar con el sistema con el modelo Planear-Hacer-Verificar-Actuar (PDCA). 2) Centrarnos en las personas con el modelo ADKAR. 3) Estimular la red con la Curva de Adopción Tecnológica. 4) Gestionar el ambiente con el modelo de las 4 "i" + 1. (image: leonel-zapien-lopez-change-management-3.0-gestion-del-cambio-consultor-curso-guadalajara-mexico.webp) Este “super modelo”, como lo describe Jurgen Appelo, lo llama así porque se forma a su vez de otros modelos. Es lo que Jurgen llama el **“Método Mojito”**: Tomar partes que ya de por sí son buenas (como la hierbabuena, el agua mineral, el limón), para crear algo que combinado es aún mejor. Veamos cada uno de estos cuatro elementos: # 1) Bailar con el sistema con el modelo Planear-Hacer-Verificar-Actuar (PDCA) El modelo Planear-Hacer-Verificar-Actuar (PHVA en español, o en inglés PDCA por sus siglas) es un modelo iterativo de 4 pasos creado por Walter Shewhart y popularizado por Edwards Deming, utilizada ampliamente en el mundo de la Calidad para la mejora continua (y de ahí llevada a diversas industrias y sectores), pero que por que puede ayudar a una iniciativa de gestión del cambio. El ciclo PHVA es un ciclo que nunca termina: (image: leonel-zapien-lopez-ideas-agilidad-ciclo-pdca-mejora-continua-lean-kaizen-guadalajara-mexico.webp) **Planear:** ¿Cuál es el propósito del cambio?, las personas necesitan tener claro por qué es necesario cambiar, cuál es la meta, y transmitirla. **Hacer:** Partiendo de la visión inicial del cambio, avanzar paso a paso hacia la dirección deseada, que todas las personas vean y entiendan cómo se está avanzando (siempre manteniendo un enfoque experimental, por eso viene el siguiente paso del modelo). **Verificar:** Recabar retroalimentación o feedback de manera rápida, en ciclos cortos, medir cómo va respondiendo el sistema (en este caso el sistema puede ser mi equipo, departamento u organización) a los pasos que hemos avanzado hasta el momento. **Actuar:** Ya que hemos medido resultados, determinar qué ajustes son necesarios hacer en la iniciativa de cambio: ¿Qué ha funcionado bien que debemos de mantener y reforzar?, ¿Qué experimentos no funcionaron como se esperaba y debemos ajustar? Recuerda que debemos de experimentar, pues estamos tratando con complejidad. Una organización es un “organismo vivo”, un **Sistema Adaptativo Complejo **(CAS por sus siglas en inglés). # 2) Centrarnos en las personas con el modelo ADKAR El Modelo ADKAR® (creado por Prosci®), es un modelo orientado a resultados, con enfoque en las personas, para acompañar un proceso de cambio. ADKAR es un acrónimo en inglés, significa que para un cambio debemos de fomentar en las personas: • Awareness: Consciencia • Desire: Deseo • Knowledge: Conocimiento • Ability: Habilidad o Capacidad • Reinforcement: Reforzar (image: leonel-zapien-lopez-ideas-agilidad-adkar-change-management-gestion-del-cambio-curso-guadalajara-mexico.webp) Revisemos cada uno de los elementos del modelo ADKAR **((link: https://leonelzapien.com/blog/gestion-del-cambio-organizacional-modelo-adkar text: si quieres conocer a mayor profundidad este modelo, puedes leer aquí un artículo que escribí específico de este modelo)**). **Awareness: Consciencia:** Crear consciencia en las personas de la necesidad del cambio, por qué es importante cambiar y qué puede suceder si no cambiamos. **Desire: Deseo:** Que las personas entiendan qué implica el cambio para ellas, para fomentar que apoyen y “se suban” a la ola del cambio, que deseen activamente el cambio. **Knowledge: Conocimiento:** Que las personas entiendan y reciban el conocimiento necesario para que puedan desempeñar su “nuevo papel” en el cambio, lo que se espera de ellas. **Ability: Habilidad o Capacidad:** Que una persona tenga conocimiento no significa necesariamente que tenga la habilidad. Hay que apoyar para que las personas desarrollen la habilidad en su día a día, para que incorporen este conocimiento y desarrollen la capacidad o habilidad. **Reinforcement: Reforzar:** ¿Qué necesitamos incentivar para que el cambio se refuerce, se mantenga a lo largo del tiempo? De la misma manera, pero en sentido opuesto: ¿Qué conductas o situaciones, que no están alineadas con el cambio, necesitamos desincentivar? Esto ayuda a hacer que el cambio con todo lo que implica: La nueva forma de trabajar, los nuevos métodos, los nuevos roles, etc., se mantenga en el tiempo y sea sostenible. # 3) Estimular la red con la Curva de Adopción Tecnológica La curva de Adopción Tecnológica, curva de Adopción de las Innovaciones, o curva de Rogers, es un modelo de referencia creado por Everett Rogers que ayuda a identificar el comportamiento de las personas ante una adopción tecnológica, pero que ayuda a modelar de igual manera cómo las personas que pueden apoyar y oponerse a un cambio. Esta curva indica que existen los siguientes “tipos” de personas: (image: leonel-zapien-lopez-ideas-agilidad-curva-adopcion-tecnologia-innovacion-guadalajara-mexico.webp) **Innovadores (2.5%)** Aquellas personas que son las más probables de adoptar un cambio de manera inicial, de subirse a una nueva ola, una nueva tendencia o tecnología. **Adoptadores tempranos (13.5%)** Una vez que los innovadores han adoptado el cambio, este grupo son los siguientes en apertura para probar e intentar nuevas cosas, se unen fácilmente una vez han visto que ya otros lo hacen. **Mayoría temprana (34%)** A la mayoría de las personas no le interesa el cambio, pero la mayoría temprana se puede subir si ven que suficientes personas (masa crítica) lo está haciendo, que el cambio es confiable y seguro. **Mayoría tardía (34%)** Son muy escépticos respecto al cambio, se requiere un esfuerzo mayor, que vean los beneficios tangibles de por qué aproximadamente la mitad de las personas se han subido al cambio, estar seguros. Solo entonces se unirán. **Rezagados (16%)** Este grupo de personas son totalmente renuentes al cambio, se suman cuando ya todos los demás lo han hecho y porque prácticamente no les queda de otra. # 4) Gestionar el ambiente con el modelo de las 4 "i" + 1 El último bloque de este súper modelo, es tener presente que no es posible intentar que una a una las personas quieran subirse al nuevo cambio, sin embargo, lo que buscamos es gestionar las variables adecuadas para que el cambio sea sistémico, ¿por qué este enfoque en el sistema?, porque está comprobado que, **si cambiamos las condiciones del sistema, las personas que estamos dentro del sistema cambiamos en consecuencia**. Estas variables son el modelo de las 4 “I” + una “I” adicional que agregó Jurgen Appelo: • Information: Información • Identity: Identidad • Incentives: Incentivos • Infrastructure: Infraestructura • Institutions: Instituciones (image: leonel-zapien-lopez-ideas-agilidad-gestion-del-cambio-guadalajara-mexico.webp) ¿Qué condiciones en cada una de estas “i” debemos de cambiar en el contexto de nuestro equipo u organización para que el cambio sea sostenible? (esto ayuda a “reforzar” el último bloque del modelo ADKAR: Reforzar). # Conclusiones La** resistencia al cambio** es natural y en el contexto organizacional no es la excepción. Más de las 70% de las iniciativas de cambio fallan, por esto es importante gestionar o acompañar adecuadamente el cambio organizacional al nivel más importante: Desde las personas. Un punto importante de este súper modelo del cambio es el enfoque que propone en la experimentación, recuerda que estamos tratando con personas, con complejidad. **Una organización es un “organismo vivo”, un Sistema Adaptativo Complejo** (CAS por sus siglas en inglés), por eso el enfoque experimental es la única manera de proceder, en este caso, con una iniciativa de cambio. ¿Conocías este modelo o alguno de sus aspectos?, ¿Cómo has llevado la gestión del cambio con tus equipos? Puedes descargar el modelo de** Change Management 3.0** de Jurgen Appelo haciendo clic (link: https://leonelzapien.com/recursos?item=gestion-del-cambio-de-management-3-0 text: **aquí mismo en mi sitio web)**. # Referencias • (link: https://www.amazon.com.mx/Management-3-0-Leading-Developers-Developing/dp/0321712471/ref=sr_1_1?__mk_es_MX=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2S322GDDF51KX&dib=eyJ2IjoiMSJ9.KsfNeZcE0dyeaMih21VU7LjnmhwIYhTHvJ5yQTYSJJTgMsVkJZPl4NIFi2lIxYcjb-SvftpMEwa-LCHL2fls8ilvOHl1647uoWYj-vP2TNmVi8OjOXSLxVZZG6OFGrRTtQWEpZBdQ_U_Y5M1YSwnBeN8M4yQ3fLftyVtEYBh7rPkto9YEh3lWVyelNgMsINnY3jMm7xsshtXUh5IqyUFm3D5itMop2lPqZ61hXyWaU_Be0nn7EPElJxdcJQyOJWc9IOlm8yhpCEJnE0VAj1nHFbbcreZsyYIFpcT4chTNpU.VGBXEWOSNN2wPHZfm1QEk1GS6bm5JMz7tEek7o7udZM&dib_tag=se&keywords=management+3.0&qid=1728225452&sprefix=management+3.0%2Caps%2C117&sr=8-1&ufe=app_do%3Aamzn1.fos.de93fa6a-174c-4df7-be7c-5bc8e9c5a71b text: Management 3.0: Leading Agile Developers, Developing Agile Leaders. Jurgen Appelo). • (link: https://www.amazon.com.mx/How-Change-World-Management-3-0/dp/9081905112/ref=sr_1_2?__mk_es_MX=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2S322GDDF51KX&dib=eyJ2IjoiMSJ9.KsfNeZcE0dyeaMih21VU7LjnmhwIYhTHvJ5yQTYSJJTgMsVkJZPl4NIFi2lIxYcjb-SvftpMEwa-LCHL2fls8ilvOHl1647uoWYj-vP2TNmVi8OjOXSLxVZZG6OFGrRTtQWEpZBdQ_U_Y5M1YSwnBeN8M4yQ3fLftyVtEYBh7rMi38XwFuMtPEm7QazskWmvn7J64fu9bVt9LXHYQGg_PPt0qNAv7YbELBZt2EnM-TFaLM4s6Uh3GYJU6K0M4EjO9IOlm8yhpCEJnE0VAj1nHFbbcreZsyYIFpcT4chTNpU.HeHvN6wLuy4oB4N-MO0NPWCIEtzWus_2VSK6cQGGq3w&dib_tag=se&keywords=management+3.0&qid=1728231439&sprefix=management+3.0%2Caps%2C117&sr=8-2&ufe=app_do%3Aamzn1.fos.de93fa6a-174c-4df7-be7c-5bc8e9c5a71b text: How to change de World: Change Management 3.0. Jurgen Appelo).
6 de octubre de 2024

¡No te pierdas los artículos más recientes!

Te invito a suscribirte a mi Blog para que recibas artículos poderosos y súper chéveres cada quince días!
Sé parte de esta comunidad en crecimiento, actualmente somos 348 suscriptores :)
Lean

Esto es Lean

Existen muchas definiciones de “Lean” como corriente o pensamiento, esta palabra que traducido literalmente significa “esbelto, delgado, magro”, una definición que me pareció muy sencilla es la que proponen los autores del libro “Esto es Lean / This is Lean”, quienes proponen: Lean es una estrategia de eficiencia de flujo, con dos principios clave: Justo a Tiempo (Just in Time o JIT), y Gestión visual (Visual Management). En el artículo de hoy conversaremos sobre este genial libro, “Esto es Lean / This is Lean”, escrito por Niklas Modig & Pär Ahlstrom. ¡Arrancamos! # No es una clase de historia, pero un poco de contexto: “Toyota es el padre del movimiento Lean” Todo inicia con el **Sistema de Producción de Toyota**, el cual le llevó a ser la empresa número uno en fabricación de coches a nivel mundial. Toyota, partiendo de una época de crisis y escases de recursos después de la Segunda guerra mundial, la necesidad los llevó a enfocar su organización en el usuario, en cubrir sus necesidades de manera rápida y a un precio competitivo. La clave de su éxito: Lograrlo a través de la eliminación de desperdicios en su flujo valor, produciendo vehículos solo cuando hubiera demanda del cliente, creando un sistema de producción bajo demanda. (image: this-is-lean-esto-es-lean-toyota-logo-toyota-prodcution-system.webp) ¿Qué tipo de desperdicios eliminaron de su proceso?, los tiempos de espera, el retrabajo por problemas de calidad, el exceso de inventario, los movimientos innecesarios, el sobre procesamiento, etcétera. Así nació lo que se conoce como Sistema de Producción Toyota (**TPS por sus siglas en inglés, Toyota Production System**), que ha sido “la referencia” para diversas industrias. En 1988 John Krafcik escribió el artículo “Triunfo de Lean Production System” ((link: https://edisciplinas.usp.br/pluginfile.php/6889199/mod_resource/content/4/krafcik_TEXTO_INTEGRAL.pdf text: puedes descargar el artículo original aquí)), donde trata sobre los sistemas de fabricación “robustos”, contra lo que hacía Toyota y su producción bajo demanda, definiendo el proceso de Toyota como “magro o esbelto”, es decir, “lean”. En este año se acuña el término “lean” y el Sistema de Producción de Toyota es traído a occidente. # Denominación de Origen En mi caso, soy de Guadalajara, Jalisco, en México. La tierra del Tequila. El Tequila es la bebida que se extrae de un tipo de agave específico sembrado en esta región de México, es su “denominación de origen”. Cualquier otra bebida extraída de agave, aunque sea el mismo tipo de agave, pero fuera de la región específica de México, no es Tequila, simplemente es Mezcal. Es el nombre genérico. Lo mismo sucede para diferenciar entre un Whisky y un Scoth (denominación de origen de Escocia), entre un Puro y un Habano (denominación de origen de Cuba). (image: this-is-lean-esto-es-lean-agave-tequila-jalisco-s.webp) fuente de imagen: entrecopasdeagave.com . Esta analogía me hace sentido cuando hablamos del** Toyota Production System o TPS (denominación de origen) y Lean (denominación genérica)**. Lean no es lo mismo que el TPS, digamos que se basa en él. Ambos buscan reducir los despilfarros o desperdicios, optimizar los procesos, maximizar la eficiencia de flujo (entre muchas otras cosas), pero como tal, son en realidad hablamos de dos movimientos ahora independientes. # El contexto El libro inicia con una historia de dos mujeres, nos lleva con todo detalle para explicarnos sin tecnicismos la diferencia entre la eficiencia de flujo contra la eficiencia de recursos. En la primera historia, una mujer vive “en carne propia” la eficiencia de utilización de recursos en un sistema de salud. En este enfoque, el objetivo es maximizar la utilización de los recursos como equipo especializado para realizar estudios clínicos, así como la máxima utilización de personas (personal que opera los equipos, enfermeras, médicos, etcétera), es decir, que “estén la mayor parte del tiempo ocupados”. **Primero, aquí abro paréntesis:** Si vamos a hablar de flujo de valor, primeramente, considero importante definir qué es esto: Un flujo de trabajo o (flujo de valor), son todos los pasos relevantes de un proceso que una organización necesita para producir un producto o servicio. **Cierro paréntesis, continuamos con el tema.** ## Perspectiva de Eficiencia de Recursos En este ejemplo, la paciente hace una cita al médico, la cita se la programan para dos días después, cuando llega el día acude al médico, quien considera que es necesario hacerle un estudio especializado, para lo cual solo hay disponibilidad de citas un par de semanas después. Cuando finalmente se ha realizado el estudio, debe de ir ahora a visitar al médico especialista, después otra cita más, y para cuando finalmente el médico le da el diagnóstico, han pasado en total 42 días. ¿Está bien esto o está mal?, nada de eso, todo lo contrario En este caso se mide la eficiencia de utilización de los recursos y personas, así, por ejemplo, se busca que el primer médico que visitó la paciente siempre esté “ocupado”, atendiendo un paciente tras otro sin que el médico pare (se considera muy costoso que tenga tiempo “ocioso”), mejor que sean los pacientes quienes esperan. Lo mismo con el equipo médico con el cual le realizan el estudio, igual consideración que con el médico especialista. Cuando nos centramos en la eficiencia de recursos, estos están siempre ocupados, con filas de materia prima o piezas en una línea de manufactura, en espera de ser procesadas (en este ejemplo, fila de personas esperando días para ser atendidas). **En la eficiencia de recursos medimos la tasa de utilización de los recursos**, buscando estar lo más cerca posible del 100% (claro que esto es muuuuuy ideal). (image: this-is-lean-esto-es-lean-eficiencia.webp) **Ejemplo Eficiencia de Recursos: ** Recurso: Escáner para estudios clínicos Tiempo de utilización: 6 horas Tiempo disponible (en un día): 24 horas. Eficiencia del recurso: Tiempo de utilización / Tiempo disponible = 6 horas / 24 horas = 25% Ok, pero en si la clínica no opera las 24 horas del día, digamos que solo 8 horas al día, tenemos: Tiempo disponible (en un turno): 8 horas. Eficiencia del recurso: Tiempo de utilización / Tiempo disponible = 6 horas / 8 horas = 75% ## Perspectiva de Eficiencia de Flujo Desde la perspectiva de la eficiencia de flujo, la unidad (materia prima, piezas en una línea de manufactura, o las personas en este ejemplo), sea procesada lo más eficientemente posible. Volviendo al ejemplo del sistema de salud y la atención médica, el objetivo aquí es que la paciente sea atendida lo más pronto posible, desde que inicia el proceso (cuando hace cita para la primera revisión médica) hasta que termina este flujo de valor (cuando recibe el diagnóstico), Mientras más pronto sea atendida la persona (o procesada la pieza en la línea de manufactura), mucho mejor. La clave en este cambio de enfoque es que, los tiempos de espera se consideran un despilfarro o desperdicio, ya que no aportan valor al paciente, es decir, son tiempo en los que no se está atendiendo directamente su necesidad o resolviendo su problema, solo está esperando a que los recursos y personas tengan capacidad disponible para atenderlo. Por lo tanto, buscamos eliminar (o minimizar lo más posible) estos tiempos de espera. Los autores nos comparten ahora una segunda historia de una mujer, que, bajo similares condiciones en su estado de salud, asiste a otra clínica. La diferencia es que en esta clínica se cuenta con todo lo necesario para brindar el diagnóstico en el momento: Médicos, Equipo especializado, personal para operar el equipo, enfermeras, asistentes, médicos especialistas. En esta segunda historia, la paciente recibe su diagnóstico en solo 120 minutos. Aquí una nota, el tiempo total que la paciente duró en la clínica fueron 120 minutos, claro que también hay tiempos de espera, por ejemplo, esperar a que el equipo clínico procese el estudio para dar un resultado, el tiempo de interpretación, etcétera. Solo que los tiempos son mucho menores. Teniendo lo anterior en cuenta, la paciente pasó 80 minutos en atención “activa”, los restantes 40 minutos fueron tiempos de espera como los mencionados anteriormente. En este caso, la eficiencia de flujo se mide desde la perspectiva de la paciente, el tiempo total que pasa en la clínica. Así que, para tratar de reducir este tiempo al máximo, se dispone de médicos “ociosos” (tienen capacidad disponible para atender a un paciente en cuanto llegue), lo cual permite una mejor experiencia para el usuario. **Ejemplo Eficiencia de Flujo Paciente #2: ** Tiempo activo de atención de la paciente: 80 minutos Tiempo total hasta que la paciente recibió el diagnóstico: 120 minutos. Eficiencia de flujo: Tiempo de atención / Tiempo total = 80 minutos / 120 minutos = 66.67% Pero aquí estamos comparando peras con manzanas, en el primer ejemplo se midió el porcentaje de utilización de un recurso, en este ejemplo estamos midiendo el tiempo de atención de la paciente. Para poder tener una comparativa adecuada, debemos medir lo mismo en ambos casos. Así que, desde la perspectiva de la paciente en el caso de la Eficiencia de Recursos, los 42 días que transcurrieron para que la paciente recibiera su diagnóstico (1,008 horas), tendríamos algo como esto: **Ejemplo Eficiencia de Flujo Paciente #1: ** Tiempo activo de atención de la paciente: 2 horas Tiempo total hasta que la paciente recibió el diagnóstico: 1,008 horas Eficiencia de flujo: Tiempo de atención / Tiempo total = 2 horas / 1,008 horas = 0.2% Aquí podemos ver el impacto de ambas aproximaciones: 0.2% contra 66.67% Claramente en el ejemplo #2 la eficiencia de flujo es mucho mayor, por lo cual la experiencia de la paciente es muchísimo mejor, pero consecuentemente es un servicio más costoso (se tienen personas y recursos con tiempo “ocioso” para garantizar tener capacidad disponible cuando se requiera). ¿Es esto también un despilfarro o desperdicio el no tener a las personas ocupadas al 100%? Como todo en la vida, depende. Imaginemos un escenario donde en una base de bomberos, los bomberos están al máximo de utilización de tal manera que, cuando surge un incendio, el tiempo de espera para que puedan atenderlo fuera de 60 minutos. ¿Sería viable? (image: this-is-lean-esto-es-lean-bomberos.webp) fuente de imagen: tv.buap.mx . Entonces, no es que la eficiencia de flujo sea buena ni que la eficiencia de recursos sea mala. Como vemos, depende del contexto. La** eficiencia de flujo no consiste en hacer más rápido nuestro producto o servicio,** no depende solo de incrementar la velocidad en la entregamos valor, se trata de medir la “densidad de valor”, esto es, **eliminar las actividades que no aportan valor**, como es el caso de los tiempos de espera. # Ok, mucho rollo, pero ¿Qué es Lean? Lo autores comienzan, antes de explicar Lean, explicando lo que no es Lean. El concepto de Lean es que ha sido definido de muchas maneras (o mejor dicho, a diferentes niveles de abstracción), de ahí que exista un poco de confusión. El primer problema es que Lean se define a diferentes niveles de abstracción. Por un lado, hay autores que definen Lean como una filosofía, una mentalidad o* mindset*, y hay quien lo lleva a niveles abstracción más bajos como prácticas puntuales. Esto nos lleva a confundir el “cómo” con el “por qué”. **Debemos de empezar y centrarnos en el propósito, sin acotarnos en el “cómo”**. Es por esto que, muchas organizaciones se centran en copiar prácticas de Toyota y esperan obtener los mismos resultados, pero lo Toyota generó esas prácticas partiendo del objetivo que tenían, las prácticas dependen, además de todo, de su contexto particular. # Esto es Lean Entonces, **¿Qué rayos es Lean?** Primeramente, Lean no define prácticas específicas, permite que las prácticas nazcan dentro del contexto de cada organización, en la búsqueda de la eficiencia de flujo y la mejora continua. Definir prácticas específicas es acotar el alcance de Lean. **Lean es una estrategia de eficiencia de flujo, con dos principios clave:** **1. Justo a Tiempo (Just in Time o JIT)**, alinear todo su el flujo de valor a partir de entregas justo a tiempo a todos los niveles, desde materia prima, partes ensambladas de su proceso, hasta el inventario final, evitando generar cantidades industriales de inventario, que es una manera de desperdicio. **2. Gestión visual (Visual Management)**, utilizar herramientas visuales como tableros, tarjetas indicadoras, código de colores, alarmas visuales, etcétera, que permitan mantener la visibilidad del proceso, y tomar decisiones. (image: this-is-lean-esto-es-lean-fabrica-visual-visual-management.webp) fuente de imagen: visualmitra.com . Por último, el concepto más importante sobre la eficiencia de flujo es el concepto de retroalimentación o feedback, que es una piedra angular de la **mejora continua**. # Conclusiones “Esto es Lean” es un libro imprescindible no solo para cualquier emprendedor o practicante Agile y Lean, sino para cualquier profesional donde exista un flujo de trabajo, y como no conozco ningún tipo de empresa o industria donde no exista flujo de valor, entonces es un libro recomendable para todos (siempre y cuando sea de su interés la mejora continua). Como hemos visto, lean no es solo un conjunto de prácticas, va más allá de eso, tiene un enfoque en la eficiencia de flujo y la mejora continua y para que sea sostenible, buscamos es enraizar o anclar esto en nuestra cultura organizacional (lo cual hizo muy bien Toyota, por ejemplo). Este libro me ha ayudado a entender a mucho mayor profundidad en es el movimiento Lean. Un concepto que está “de moda”, y se lo podemos ver por todos lados: • Lean Manufacturing • Lean Management • Lean Portfolio Management • Lean Change (Management) • Lean Coffee • Lean Construction • Lean IT • Lean Company • Lean Marketing • Lean Education • Lean Startup (por cierto, si te interesa este tema, (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí puedes leer un artículo que escribí precisamente sobre Lean Startup)). • Y una larga lista de etcéteras y etcéteras. Para terminar, este artículo (aunque extenso), ha sido solo un “chapuzón” en el mundo de Lean, si te ha interesado el tema y deseas bucear a profundidad en el tema para aplicarlo con tus equipos y en tu organización, este libro es una recomendación absoluta **nivel Master Jedi**. ## Referencia “Esto es Lean / This is Lean”. Niklas Modig & Pär Ahlstrom.
31 de agosto de 2024
Scrum

Antipatrones de Scrum: Scrum but

Scrum no funciona. He escuchado esta frase muchas más veces de las que me gustaría admitir, aunque la realidad es que, cuando profundizamos en cómo estos equipos llevan Scrum en su día a día, salen a flote diversas prácticas que desvirtúan Scrum, prácticas que se llevan a cabo de manera incorrecta (de manera intencional o no intencional), y por lo tanto un efecto aparente es que Scrum “no está funcionando”, cuando la causa raíz es, en realidad, una mala práctica, o lo que se conoce como un **antipatrón**. Scrum un marco de trabajo, pero más que eso, hoy siendo las 5:34 a.m. del 8 de julio de 2024, continúa siendo **el marco de trabajo más utilizado en el mundo**, no lo digo yo, lo muestran los diversos estudios anuales sobre Agilidad o Agilismo que se publican por diversas organizaciones. Scrum establece una forma de colaborar evaluando de manera continua cómo construir un producto (o servicio), obtener retroalimentación del cliente/usuario final, y adaptar creativamente en base a la información obtenida siempre centrados en entregar un incremento de producto que agregue valor al cliente/usuario final. En este artículo no abordaremos lo que Scrum es, no es un artículo introductorio (si quieres leer un poco sobre los principios de Scrum, (link: https://leonelzapien.com/blog/que-es-scrum text: te comparto aquí un artículo que escribí sobre este tema hace un par de años)), aquí abordaremos sobre eso que “no es Scrum”, esos antipatrones que desvirtúan el marco de trabajo y consecuentemente llevan a equipos a sufrir el proceso y concluir que “Scrum no funciona”. (image: scrum-logo.webp) # Anti… ¿qué? Aquí abro un breve paréntesis. Primero lo primero, no sé si conozcas el término **antipatrón**, pero vamos iniciando aquí. Un antipatrón es un enfoque que nos va a conducir a una mala solución a un problema, pueden ser en ocasiones enfoques “generalizados” o que se utilicen ampliamente, pero, aun así, no deja de ser una solución inadecuada y por lo mismo son ineficaces y/o improductivos para resolver determinada clase de problemas comunes. Una vez aclarado lo anterior, ya hemos calentado motores, entremos directo en tema sobre de antipatrones en Scrum, ¡Aquí vamos! Cierro paréntesis. # Scrum but Hoy vengo a platicarte sobre algo que se conoce como **Scrum but…**, que traducido sería algo como **Scrum pero…**, y se le conoce así precisamente porque, cuando a alguien le preguntan: - Y ustedes, ¿utilizan Scrum? - ¡Claro que sí! - ¿Y cómo les va con *[inserte-aquí-cualquier-tópico-relacionado-con-Scrum]* (por ejemplo, las retrospectivas / producto backlog / incrementos de producto / la definición de terminado, etc.)? - Ah, bueno. Es que sí utilizamos **Scrum, pero…** *[inserte-aquí-cualquier-“parche”-o-forma-de-hacer-algo-que-no-está-alineado-con-La-Guía-Scrum]* Y ahí es donde surge el “pero”, es ahí donde, como decimos acá en México, la puerca torció el rabo. Por esto, hoy hablaremos sobre **Scrum but,** ya que esta lista de “peros” puede ser virtualmente infinita, vamos a ver algunos de los principales ejemplos que he tenido oportunidad de ver de primera mano en diversos equipos, así como posibles soluciones. Un tiene la siguiente estructura: **Scrum + pero + Antipatrón + Forma alternativa de “solucionar” la situación** (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-estructura-antipatron-cursos-consultor-guadalajara-mexico.webp) ¿Estás listo? ¡Ponte cómoda o cómoda y relájate, no lo tomes personal si con algunos de estos antipatrones sientes que “le queda el saco a tu equipo”, cualquier parecido con la realidad es mera coincidencia! ## Antipatrón #01: El Daily eterno (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-01-guadalajara-mexico.webp) **Usamos Scrum + pero… + hay demasiados temas por conversar en nuestra Daily + así que, en vez de 15 minutos, este evento dura entre 45 minutos y 1 hora.** Este es por mucho el antipatrón que más comúnmente he visto, pero así mismo, es de los más sencillo de reenfocar. Primero lo primero, ¿Cuál es la esencia del Daily Scrum? De acuerdo con La Guía Scrum, el Daily Scrum es un evento de hasta 15 minutos para los Desarrolladores del Equipo Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint. ¿Cómo podemos ayudar al equipo a que se cumpla el bloque de tiempo (timebox) de 15 minutos?, aquí te comparto uno tip súper simple y no por eso menos poderoso: • Utilizar un** Estacionamiento de temas** o **Parking lot**, donde podemos “estacionar” los temas que surjan durante el Daily que necesiten conversarse, la idea es no resolver los problemas durante el Daily, sino identificarlos, y posteriormente conversarlos solo con las personas directamente implicadas, puede ser de manera inmediata al terminar el Daily (algunos le llaman a esto post-Daily), o en algún momento posterior. La esencia es no alargar el Daily, y que, cuando se vaya a conversar, solo se involucre a las personas necesarias y no a todo el equipo. ## Antipatrón #02: Saltarse la retrospectiva (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-02-guadalajara-mexico.webp) **Usamos Scrum + pero… + tenemos tanto trabajo al final del Sprint + que mejor aprovechamos el tiempo de la retrospectiva para trabajar en lo que tengamos pendiente.** Este antipatrón me recuerda el meme de un cavernícola que está empujando una montaña de piedras sobre una carreta con “ruedas cuadradas”, claro que va sudando a chorros y sufriendo tremendo, mientras un segundo cavernícola le muestra una “rueda redonda” diciéndole que su invento le va a hacer la vida más fácil, y el primer cavernícola solo puede responder con el poco aire que le queda: “No tengo tiempo, estoy muy ocupado jalando esta carreta”. Tristemente, es el segundo antipatrón más común que he visto, donde los equipos no se dan el tiempo de hacer una pausa para analizar el último periodo de trabajo o Sprint, y reflexionar sobre cómo pueden mejorar. La Guía Scrum menciona que “El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.” Sin estos espacios para identificar los principales problemas que afectaron el equipo, sin conversaciones que les puedan ayudar a mejorar su efectividad, no se puede llegar a la mejora continua. Cada evento en Scrum tiene un propósito específico, en este caso, la retrospectiva fomenta este espacio para detenernos a “Afilar la sierra”, por más ocupados que estemos es fundamental tener y fomentar estos espacios, así como escuchar todas las voces, priorizar los elementos que se identifiquen en base a su posible impacto, y darles seguimiento. ## Antipatrón #03: Un día sí, y al otro día quién sabe (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-03-guadalajara-mexico.webp) **Usamos Scrum + pero… + tener el Daily todos los días quita demasiado tiempo + así que tenemos el Daily Scrum un día a la semana.** El evento Daily Scrum debe de ser diariamente. Un antipatrón que tiene un impacto muy negativo en el potencial que marco Scrum puede ofrecer es el no tener los Daily ahora sí que dice la palabra, diariamente. He tenido oportunidad de coincidir con equipos que tienen los Daily en frecuencias distintas a lo definido en La Guía Scrum: 1 vez a la semana, o cada tercer día, por mencionar algunos ejemplos. Entre las principales razones para hacer esto (la verdad debo de confesar que se puede dedicar mucho esfuerzo y creatividad para justificarlo muy bien), he escuchado cosas como: • Es muy costoso detener a todo el equipo de trabajar, todos los días. • Nuestro proceso es muy estable, no necesitamos reunirnos a diario. • Es un desperdicio de tiempo. • Mejor nos reunimos cuando surja algo. • Entre otras cosas. ¿Te suena familiar? La Guía Scrum menciona que el Daily Scrum se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint, el Daily es una oportunidad para inspeccionar y adaptar el plan para lograr el objetivo del Sprint, y este es precisamente el sustento por el cual debe de realizarse diariamente, ya que trabajamos en entornos con alta volatilidad e incertidumbre, así mismo los productos o servicios que construimos, y las personas que colaboramos para construirlos, somos complejos. Hay infinitas variables que pueden afectar a un equipo, algo puede afectarnos durante un sprint, solo para asentarlo y nombrar algunas a manera de ejemplo: • Una persona se ha enfermado y no tenemos capacidad para realizar lo que él o ella hacía. • Para realizar algo en particular, acabamos de darnos cuenta de que se requiere un recurso específico (una licencia de un determinado software, un servidor, un servicio o proveedor, etc.), y se necesita conseguir a la brevedad posible, o bien, ver alguna opción alterna. • Ha surgido un defecto que es urgente solucionar. • Determinada situación ha provocado escasez o tiempos de entrega más largos de algún insumo. • Acaba de surgir una nueva pandemia, situación social que ha afectado al entorno del equipo, un apocalipsis zombi, etcétera y etcétera. La inspección frecuente permite la adaptación temprana, este es uno de los propósitos del Daily, identificar de manera oportuna problemas, riesgos, bloqueos que puedan presentarse, por eso la importancia de que sea diariamente, para proporcionar un ritmo o cadencia al equipo, y termina formando parte de los hábitos del equipo, por eso debe de celebrarse todos los días a la misma hora y en el mismo lugar (o en utilizando el mismo link de reunión recurrente, en caso de ser de manera remota), para de esta manera reducir la complejidad que implica el estarla reprogramando o moviendo de lugar (físico o remoto). ## Antipatrón #04: Sin retroalimentación real (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-04-guadalajara-mexico.webp) Usamos Scrum + pero… + nuestro cliente/usuario final está muy ocupado y no tiene tiempo para atender las Revisiones del Sprint + así que le enviamos un correo para informarle de las funcionalidades que se liberarán. La revisión del Sprint es un evento que, de acuerdo con La Guía Scrum, tiene como propósito inspeccionar el resultado del trabajo realizado durante el Sprint, y en base a esto, determinar futura adaptaciones. Aquí el punto clave es que el Equipo Scrum presente los resultados de su trabajo a los interesados clave y se discuta el progreso hacia el Objetivo del Producto. Pero, ¿Quiénes pueden ser interesados clave? La verdad es que depende del contexto, de entrada, es imprescindible que esté ahí el cliente / usuario final, esa persona quien finalmente va a utilizar nuestro producto. Lo que queremos es que este cliente / usuario final pruebe el producto, lo vea funcionar, lo tenga entre sus manos, le haga clic y vea qué hace… y en base a su experiencia con este incremento de producto real, nos proporcione retroalimentación valiosa que nos permita determinar si vamos bien, hacemos algunos ajustes, o definitivo no es por este camino y debemos girar el timón. Esta figura de cliente / usuario final es fundamental, pero aunado a esto y dependiendo del contexto, un interesado clave puede ser un determinado gerente, director, el patrocinador del proyecto o producto, inclusive dependiendo del caso, alguna figura externa como un proveedor, o algún representante de un organismo o grupo. Debido a todo esto, una Revisión de Sprint sin los interesados relevantes y sin esta figura principal que es el cliente / usuario final que viva en primera persona la experiencia del incremento de producto que el Equipo Scrum ha construido durante el Sprint, sin ellos, una revisión de Sprint carece totalmente de sentido. La Guía Scrum menciona también que, durante la Revisión del Sprint, el Equipo Scrum y los interesados revisan lo que se logró en el Sprint, conversan sobre lo que ha cambiado (prioridades, alguna cuestión del entorno, etc.), con base en esta información y con la experiencia de probar el incremento de producto, los asistentes a este evento colaboran para determinar qué hacer a continuación. Esto es fomenta un ambiente donde se transpiran los pilares de Scrum: Transparencia, inspección y adaptación. ## Antipatrón #05: No necesitamos un Scrum Master (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-05-guadalajara-mexico.webp) **Usamos Scrum + pero… + no necesitamos un Scrum Master, el equipo ya sabe Scrum + así que el resto del equipo cubre las actividades del Scrum Master.** La Guía Scrum define que el Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización. Un tema algunas veces controversial es, ¿Y qué hace el Scrum Master todo el tiempo?, es normal que esta pregunta surja sobre todo cuando el equipo Scrum ya tiene cierto grado de madurez y se puede decir que el equipo “ya sabe” Scrum. Pero el Scrum Master hace (o debería de hacer) muuucho más que eso, apoya al equipo Scrum (Desarrolladores y Product Owner), así como a la organización. La Guía Scrum menciona que el Scrum Master es responsable de lograr la efectividad del Equipo Scrum, por lo tanto, es el responsable final de que el equipo mejore continuamente, y siendo completamente honestos, esto implica **ver más allá de Scrum**, complementar con otras herramientas, métodos, prácticas, metodologías, etc., probar, experimentar, ayudar al equipo a descubrir nuevas formas de reducir los despilfarros o desperdicios, avanzar hacia mejores formas de colaborar. Esto puede incluir, por citar algunos ejemplos, complementar Scrum con **Kanban**, Pensamiento** Lean**, utilizar **Estructuras Liberadoras** para facilitar las sesiones ayudar a descubrir problemas, así como fomentar conversaciones, agregar prácticas de **Management 3.0** para centrarnos en las personas, prácticas de **Extreme Programming**, **Agile / Lean Inception**, **Lean Startup**, y una lista infinita de etcéteras y etcéteras. Por lo tanto, el Scrum Master es esencial, y si esta responsabilidad o rol (o cualquiera de los otros dos) no está, realmente no estamos trabajando con Scrum. ¿Cómo sabemos qué tal está haciendo su trabajo el Scrum Master?, su trabajo se ve indirectamente, se refleja en la forma en que el Equipo Scrum se está desempeñando, por eso es imprescindible esta figura para, como dice (link: https://agilemanifesto.org/ text: El Manifiesto Ágil): Continuar descubriendo mejores formas de trabajar. # Conclusiones Creo que una lista de antipatrones conocidos o potenciales en Scrum es virtualmente infinita, los cinco que he mencionado aquí creo que son algunos de los que he tenido oportunidad de ver de manera más recurrente. Lo triste del asunto es que este tipo de prácticas llevan a personas y equipos a sentir frustración porque **“Scrum no funciona”**, cuando la causa raíz es que se está llevando a cabo de una manera que no permite que los verdaderos super poderes de Scrum se muestren con todo su esplendor. Scrum define cómo un equipo autogestionado podría estructurar mejor su trabajo para ofrecer incrementos de producto y crear el mayor valor posible para todas las partes interesadas, funciona muy bien donde se trabaja con alta complejidad, donde existe alta incertidumbre, donde los requisitos del producto no están claros. De verdad que Scrum puede aportar enorme apalancamiento en todo esto. Solo, hay una consideración, y no es una que me haya inventado, sino que viene mencionada en la página 13 de La Guía Scrum 2020 (es la guía más reciente y, por lo tanto, la que está vigente). Dice lo siguiente: “El marco de trabajo Scrum, como se describe aquí [en La Guía Scrum], es inmutable. Si bien es posible implementar solo partes de Scrum, **el resultado no es Scrum**. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.” Así que podemos complementar Scrum con otros métodos, prácticas, herramientas, metodologías… pero no podemos “quitarle” cosas a como Scrum viene definido. Requiere de sus 3 roles, 5 eventos y 3 artefactos, tal y como se definen en La Guía Scrum. Cuando lo lleves a tu equipo, es esencial que lo acotes a tu contexto, experimentando lo que mejor funciona, pero dentro de lo que es válido para este marco de trabajo. Nunca dejemos de experimentar hacia la mejora continua, los resultados, más temprano que tarde, siempre, siempre, siempre llegan. **¿Qué opinas de estos antipatrones?, ¿Qué otros antipatrones agregarías?**
8 de julio de 2024
MVP, Product Management, Innovación

Innovación & MVP - Diseñar y probar hipótesis de negocio

“No cometas el error de ejecutar ideas de negocio sin evidencia: Prueba tus ideas, sin importar qué tan bien luzcan en teoría” – David J. Bland & Alex Osterwalder. # Hipótesis de negocio ¿Tienes una idea de un nuevo producto o servicio?, ¿Una nueva funcionalidad que piensan agregar para tu usuario o cliente?, para pasar de una idea de negocio a un elemento validado, se debe de probar de manera rápida y lo más barato posible (en el artículo pasado hablamos sobre el **Producto Mínimo Viable o MVP**, Minimum Viable Product en inglés, puedes leer el artículo completo (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)). Pues bien, está chévere esta idea de que un MVP nos invita a validar ideas de negocio con experimentos antes de ir a mayor escala. Pero ¿Por dónde empezar si quiero hacer un experimento para probar una idea?, ¿Por dónde inicio? Lo primero que necesitamos asentar es que una **idea de negocio** es en realidad una **hipótesis** (ya sé que esto suena muy del ámbito científico, pero en realidad así es). Hasta que se valide obteniendo un resultado (se cumple y por lo tanto es correcta, o no se cumple), solo entonces dejará de ser una hipótesis. “El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje.” – Eric Ries (The Lean Startup) # Probar ideas de negocio: Un proceso iterativo El ciclo Diseño-Prueba es un proceso iterativo, creado por David Bland & Alex Osterwalder, tiene dos grandes áreas: Diseño & Prueba, veamos cada una a detalle: (image: design-test-innovacion-strategyzer-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) **Diseño:** Es la actividad de llevar ideas vagas o dispersas, a proposiciones de valor, que después puedan concretarse como modelos de negocio. **Prueba:** Necesitamos descomponer una idea de negocio en hipótesis pequeñas y fáciles de validar mediante experimentos que proporcionen evidencia que ayuden a decidir los siguientes pasos. # Diseño En este primer paso el objetivo es generar la mayor cantidad de opciones como sea posible (debemos evitar enamorarnos de nuestra primera idea, no es personal, solo son negocios), basándose en la intuición, observación o en lo que se conozca sobre los clientes. (image: design-test-innovacion-strategyzer-01-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) Las ideas locas, irreverentes, aquellas que retan el Status Quo, son más que bienvenidas (de hecho, eso es lo que buscamos). En este punto, no es el momento de empezar a desmenuzar el modelo de negocio y cuestionar la validez o potencial éxito en el mercado de una idea. No aún. **Queremos que el equipo diseñe como si tuviera razón**, ¿Tenemos sobre la mesa alguna idea de negocio innovadora? **Pregunta para llevar: ** ¿El equipo está “empujando” los límites?, o ¿Están jugando a lo seguro y manteniéndose cerca de lo que la empresa hace actualmente? # Prueba Una vez estemos satisfechos con lo realizado en la etapa de diseño, es hora de pasar a las pruebas. (image: design-test-innovacion-strategyzer-02-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) El primer paso en el ciclo de prueba es definir y priorizar las hipótesis de negocio. Si la hipótesis es muy grande, la dividimos pequeñas partes comprobables. Aquí lo esencial es la palabra “comprobable”, para esto debemos cocrear (de verdad, es increíble el poder de la crear de manera colaborativa), seleccionar y ejecutar experimentos adecuados que nos proporcionen información que respalde y nos ayuden a validar (o desechar) nuestras hipótesis. En pocas palabras, necesitamos **evidencia**. # Tarjeta de Prueba o Test Card Aquí te comparto una herramienta muy útil, desarrollada por Strategyzer, que nos ayuda a definir un experimento para probar una idea: (link: https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card text: La Tarjeta de Prueba (Test Card)). Aquí veremos brevemente cómo llenar esta tarjeta: (image: test-card-strategyzer-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis:** Define la idea de negocio que se cree que es verdadera. **Ejemplo: **“Creemos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Prueba:** ¿Qué experimento (o experimentos) ejecutarás para determinar obtener información que permita validar si hipótesis es verdadera o falsa? **Ejemplo: **“Para verificar esto, nosotros agregaremos un breve video sobre el curso y un botón de en nuestro sitio web.” 3. **Métrica:** ¿Qué vamos a medir para validar la hipótesis?, la idea es que sea una medida específica, objetiva, no ambigua, binaria (cumple o no cumple) y reproducible. **Ejemplo:** “Y lo mediremos por el número de personas que ingresan a nuestro sitio web y hacen clic en el botón de .” 4. **Criterio: **Definir el resultado esperado respondiendo a la pregunta ¿Cómo es el escenario ideal que en nuestro contexto nos dice que la hipótesis ha sido exitosa? **Ejemplo: **“Y sabremos que tenemos éxito si se registran al menos 1,000 ‘compradores de pre-venta’ en la primera semana.” Este último punto es crítico ya que ayuda a responder la pregunta: ¿Qué necesita ser cierto para que esta idea de trabajo funcione? En este ejemplo, la definición de éxito que esta empresa de cursos en línea espera (de acuerdo con su contexto especifico, como costos fijos, retorno de inversión esperado, cobertura de mercado actual, etcétera), son 1,000 “compradores” registrados, pero ¿En cuánto tiempo?, para ellos ese bloque de tiempo es en la primera semana de correr el experimento. ¿Lo más importante?, el producto en este ejemplo, el curso en línea no ha sido creado aún, por lo que probar esta hipótesis es relativamente muy barato (y rápido). # Aprender El último paso es aprender de los experimentos que realizamos. ¿La evidencia recabada apoya o refuta nuestras suposiciones?, Eso que acabamos de obtener es aprendizaje, de hecho, es lo que Eric Ries (el creador del **Método Lean Startup**, puedes leer el artículo que hice sobre este tema (link: https://leonelzapien.com/blog/el-metodo-lean-startup-producto-minimo-viable-mvp text: aquí)) llamó **Aprendizaje Validado**, pues se basa en evidencia. ¿Este aprendizaje validado nos indica que debemos de continuar por este mismo rumbo, o pivotar y explorar un nuevo camino? Para validar el aprendizaje, aquí comparto, al igual que en el punto anterior, una herramienta propuesta por Strategyzer: (link: https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card text: La tarjeta de Aprendizaje o Learning Card). Hemos realizado un experimento para tratar de validar una hipótesis de negocio, debemos de rescatar e identificar el aprendizaje obtenido y aplicarlo lo más pronto posible, pues el aprendizaje tiene una “fecha de caducidad”. ¿A qué nos referimos con aplicar el aprendizaje obtenido?, a aplicarlo en la toma de decisiones informada, identificar los siguientes pasos: ¿La hipótesis de negocio era correcta, y debemos continuar por este camino?, o ¿Debemos de cambiar el rumbo, partiendo de una nueva hipótesis? (esto último, se conoce como hacer un “**pivote**”). Retomando el ejemplo que revisamos en la Tarjeta de Prueba (Test Card), continuamos con el ejemplo para llenar ahora la Tarjeta de Aprendizaje: (image: learning-card-leonel-zapien-lopez-ideas-agilidad-business-hypholesis-s.webp) 1. **Hipótesis: **Define la idea de negocio que se creía verdadera. **Ejemplo: **“Creíamos que las personas están interesadas en un curso en línea sobre bordar manteles navideños con punto de cruz.” 2. **Observación: **¿Qué pudimos observar después de realizar el experimento? **Ejemplo: **“Observamos que solo un 1.2% de los clientes potenciales esperados hicieron clic en nuestro botón de en nuestro sitio web.” 3. **Aprendizajes e ideas clave:** El aprendizaje validado que se ha obtenido de la observación. **Ejemplo:** “Dado que esperábamos 1,000 clics de compra en pre-venta durante la 1ra semana y solo obtuvimos 12 clics (1.2%), este curso en línea no genera el interés esperado.” 4. **Decisiones y acciones:** Ahora que se ha visto si la hipótesis de negocio era válida o no, determinar los siguientes pasos que se realizarán a partir de este punto. **Ejemplo:** “No dedicaremos más recursos a esta hipótesis. Replantearemos nuestra idea de negocio y haremos un pivote a una nueva hipótesis que está por definirse.” En este caso de ejemplo, la hipótesis de negocio no era válida, ¿Lo más importante?, el producto en este ejemplo, el curso en línea sobre bordar manteles navideños con punto de cruz, nunca fue creado: No se dedicaron semanas o meses de trabajo a un producto que se creía que se vendería como pan caliente, pero que el experimento demostró que no había interés. Probar esta hipótesis fue relativamente muy barato y rápido. ¿Y cómo procedemos una vez se confirma el resultado de una hipótesis?, se pueden hacer varias 3 cosas: 1.** Perseverar: **Quiere decir que vamos por buen camino, y debemos de continuar por este rumbo. No es el caso en este supuesto, solo sucedería si la hipótesis resultara válida. 2. **Pivotar: **Hacer un cambio de rumbo, lo que Eric Ries en su libro “The Lean Startup” llama un “Pivote”, comenzar a explorar otros caminos y formular nuevas hipótesis. 3. **Descartar: **Tal vez, después de explorar varias hipótesis, negocio decide no continuar explorando este camino (y probablemente ningún otro similar o alineado con este camino). Continuando con este ejemplo, ¿Qué tal si a la gente no le interesa aprender a bordar manteles navideños, pero se acerca el Día de Star Wars, y bordar manteles temáticos de Star Wars es algo que las personas están buscando con singular alegría?, uno nunca sabe. ¿Cómo lo sabremos?, formulando una nueva hipótesis. (image: hipotesis-de-negocio-star-wars-copy.webp) # ¿Qué sigue después? En el centro del ciclo Diseño-Prueba se encuentra “Decidir”, se debe de decidir sobre este modelo de negocio que el equipo está probando. El objetivo final es comprobar **si el modelo de negocio es viable**, los equipos de innovación deben evaluar en este punto y reflexionar sobre su progreso hacia la búsqueda de un modelo de negocio rentable que funcione. Al evaluar la solidez de la evidencia que respalda cada componente básico del modelo de negocio, los equipos pueden identificar si aún hay incertidumbre y existen componentes que aún deben probarse, ¿Deben realizarse nuevos experimentos? Cuando se aprenden nuevas lecciones, se puede actualizar el modelo de negocio, identificar nuevas hipótesis y ejecutar el siguiente conjunto de experimentos. Esta es la razón por la que los equipos que pueden recorrer rápidamente el ciclo descubren más rápido si su idea de negocio es viable. Hasta aquí, ya tenemos información de la hipótesis de negocio mediante los experimentos realizados, ahora, muy recientemente en este último par de párrafos hemos comenzado a hablar de un “Modelo de negocio”. Para esto, el equipo de Strategyzer han creado también el (link: https://www.strategyzer.com/library/the-business-model-canvas text: Business Model Canvas, o Lienzo de Modelo de negocio), el cuál es el siguiente paso para ayudar al equipo de innovación a determinar la validez de su modelo. Aquí te presento el Lienzo de Modelo de Negocio, pero creo que este artículo ya es algo extenso, así que en un próximo artículo conversaremos específicamente sobre este Canvas. Por lo pronto, hemos visto cómo probar y validar ideas de negocio. (image: business-model-canvas-modelo-de-negocio-leonel-zapien-lopez-ideas-agilidad-guadalajara-mexico.webp) # Conclusiones La **apertura para experimentar** es esencial para desarrollar una **cultura de innovación** en cualquier organización. Las herramientas que hemos visto el día de hoy no son solo un par de tarjetas para prueba y aprendizaje, o un canvas con un modelo de negocio, son en realidad recordatorios de conversaciones enriquecedoras y poderosas que deben de suceder. Una tarjeta o un canvas como tal no resolverán ningún problema ni nos llevará al valle dorado de la innovación. Debemos fomentar los espacios para los individuos y sus interacciones, como dice el **Manifiesto Ágil** (puedes leer el artículo que escribí sobre el Manifiesto Ágil (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)). Así mismo, la experimentación y la innovación son unos músculos que deben de ejercitarse, es posible que a tu equipo le tome algunos ciclos el comenzar a entrar en calor, a agarrar ritmo, y a perder el miedo a experimentar (y para esto último se requiere un adecuado **liderazgo** y sólidos cimientos de **Seguridad Psicológica** en tu organización y equipo). Lo importante de la experimentación es obtener aprendizaje validado, con esto, el ciclo Diseño-Prueba se ha completado, de manera rápida y lo más barata posible. En este ejemplo, no fue viable continuar con el producto, así que el ciclo vuelve a iniciar, esta vez, con una nueva hipótesis de negocio. ¡Nunca dejemos de experimentar y aprender! **¿Cómo validas tus ideas de negocio?** ## Nota final #01 Las herramientas sobre las cuales hemos conversado hoy, Tarjeta de Prueba, Tarjeta de Aprendizaje y el Canvas de Modelo de Negocio, los puedes descargar en su versión original del sitio de (link: https://www.strategyzer.com/ text: Strategyzer), o en su defecto, los puedes descargar en una versión traducida a español, aquí en mi sitio web en la sección de (link: https://leonelzapien.com/recursos text: Recursos para descargar). ## Nota final #02 Existen varios canvas o lienzos que apoyan para crear modelos de negocio, hace unos meses hablé sobre el **Tablero de la Visión del Producto o Product Vision Board,** creado por Roman Pichler, escritor y todo un master Jedi en Agile & Product Management. Este canvas es muy útil para cocrear una visión compartida del producto (lo que se conoce como “envisioning”), y puede de igual manera apoyar como siguiente paso, ya que es similar al Business Canvas Model en algunos aspectos. Si quieres leer sobre el Tablero de la Visión del Producto, puedes leer el artículo que escribí sobre el tema (link: https://leonelzapien.com/blog/como-iniciamos-el-tablero-de-vision-del-producto text: aquí). ## Nota final #03 De verdad que existe el “**Día de Star Wars**”, millones de fans a lo largo y ancho de toda la galaxia lo celebramos el día 4 de mayo. ¿Por qué el 4 de mayo?, por el juego de palabras de la frase: “Que La Fuerza te acompañe”. En inglés se dice “May the Force be with you”, lo cual es un juego de palabas y cuando se dice en voz alta casi-casi como “May the Fourth be with you”… o sea “Que el 4 de mayo te acompañe”, y de ahí derivó que cada 4 de mayo se celebre el Día de Star Wars (Sí, debo de reconocer que nos buscamos cualquier pretexto para ese tener un día para usar sables láser y ponernos el casco de Darth Vader). **Referencias:** • Testing Business Ideas. David J. Bland & Alex Osterwalder. • Business Model Generation. Alex Osterwalder & Yves Pigneur. • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries.
2 de junio de 2024
Product Management, MVP, Innovación

El Método Lean Startup & Producto Mínimo Viable (MVP)

“Si estamos creando algo que nadie quiere, no importa si lo hacemos en tiempo y dentro del presupuesto” – Eric Ries El creador del método Lean Startup, Eric Ries, menciona que “demasiados planes de negocio parecen diseñados para planificar cómo lanzar un cohete: Prescriben los pasos que hay que dar y los resultados esperables con un gran nivel de detalle en cada paso, lo establecen todo como si cada minúsculo error en las asunciones o suposiciones pudiera llevar a un resultado catastrófico.” Eric Ries lo deja muy en claro: No podemos prever todos los posibles pasos (por más análisis de Fortalezas y Debilidades, de riesgos, estimaciones, simulaciones, y una larga lista de etcéteras), no podemos preparar cada detalle, nunca podremos concebir todos los posibles escenarios. Es por esto que Eric Ries, propone: **El Método Lean Startup**, que se basa en una premisa simple pero fundamental: En lugar de hacer planes complejos basados en muchas suposiciones, se pueden hacer ajustes constantes mediante un ciclo de retroalimentación llamado **Crear-Medir-Aprender**. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-01.webp) En el artículo de hoy, hablaremos sobre Lean Startup, el ciclo Crear-Medir-Aprender, y sobre el poderoso enfoque del **Producto Mínimo Viable** (**MVP**, por sus siglas en inglés, Minimum Viable Product). # El caso de IMVU: Un error garrafal que llevó a la gran epifanía de Eric Ries IMVU, una gran empresa dedicada al desarrollo de software, decidió entrar en el mercado de mensajería instantánea. Era el año 2004, y este mercado en aquel tiempo tenía centenares de millones de usuarios a nivel mundial. Empresas como AOL (America On Line), Microsoft y Yahoo! dominaban el mercado. (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-02.webp) IMVU llega con una nueva idea: Mundos y juegos virtuales a través de avatares 3D personalizables, que pueden agregarse a las aplicaciones de mensajería instantánea ya existentes. Si el mercado de mensajería instantánea tenía cientos de millones de usuarios, entrar con esta propuesta que complementaba a las aplicaciones de mensajería, sonaba como un gran éxito. El equipo de IMVU, liderados en aquel tiempo por Eric Ries, estuvo más de 6 meses trabajando intensamente para desarrollar este producto, haciendo pruebas, discutiendo qué elementos o funcionalidades agregar y cuáles remover, poniendo muchísimo esfuerzo en la calidad, trabajando durante meses, jornadas hasta altas horas de la noche y fines de semana. Finalmente llegó el gran día del lanzamiento. Eric Ries menciona al respecto lo siguiente: **“Y entonces, ¡no pasó nada! Resultó que nadie probó nuestro producto”** **“Nuestra propuesta de valor estaba tan desencaminada de lo que los clientes querían, que ni siquiera lo probaban**, y, por lo tanto, no llegaban a descubrir lo malas que habían sido nuestras elecciones sobre el diseño. Los consumidores no descargaban nuestro producto.” El equipo de IMVU optó por hacer mejoras al producto, introducir nuevos cambios, uno que otro cliente llegaba a descargar su producto (Eric Ries reconoce que al inicio eran principalmente amigos y familiares de ellos mismos), y a pesar de tantas mejoras y retrabajo, pronto se quedaron sin amigos que quisieran probar su producto, y con unos ingresos mensuales de poco más de $300 dólares al mes. **“Estábamos mejorando el producto día a día, pero el comportamiento de los consumidores no cambiaba: todavía no querían probarlo.”** # Momento de hacer las cosas de manera diferente Para que el equipo de IMVU intentara hacer las cosas de manera distinta a partir de este punto, influyeron fuertemente dos factores: Un poco tuvo que ver la frustración de estar trabajando en un producto que nadie compraba, y un poco más tuvo que ver que se estuvieran quedando sin dinero para continuar operaciones. Hay un dicho: “La desesperación es la madre de la inventiva”, así que en este punto Eric Ries y todos en IMVU estaba bastante desesperados. ¿Qué hicieron ahora? **Comenzaron a hablar con los clientes** (verdaderas conversaciones, de esas que son cara a cara). Llevaban a clientes a sus oficinas, los entrevistaban, les mostraban pruebas de su producto, hacían ajustes en base a sus comentarios, y después volvían a mostrarles más pruebas. El equipo de IMVU tenía una idea en mente de su producto: Un avatar 3D que se puede personalizar, que se agrega como complemento a la aplicación de mensajería instantánea de preferencia del usuario, se enamora del producto, después invita a todos sus amigos a usarlo, y se vuelve viral. No suena nada mal. La cuestión es que después de docenas de entrevistas y pruebas con clientes reales, directo en sus oficinas, se dieron cuenta que su concepto de “mensajería instantánea complementaria” estaba destinado al fracaso desde un inicio, a nadie le interesaba eso. # Ok, y entonces ¿ahora qué? Era momento de reconocer que el trabajo de más de 8 meses no le interesaba a nadie. Trabajo tirado a la basura. ¿Cuál fue la razón de que el equipo de IMVU durara tanto para construir su producto?, habían estado trabajando en hacer un producto de alta calidad, que fuera compatible para todas las redes sociales o aplicaciones de mensajería de aquella época… y cuando hicieron todo esto, se dieron cuenta que a nadie le interesaba. # Es hora de hacer redirigir el rumbo: Pivotar (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-03.webp) Eric Ries menciona que Pivotar es detenerse, hacer una pausa y evaluar si merece la pena seguir por este camino. En este caso de IMVU, al reconocer finalmente que la respuesta de los clientes no era positiva, la decisión fue abandonar la estrategia inicial, **tomar un nuevo camino** lanzando un nuevo producto (hacer un pivote), y validar lo más pronto posible su nueva propuesta, directamente con los clientes. El objetivo de estas conversaciones directas y (ahora más frecuentes) que querían tener con los clientes era ayudarles a **identificar conforme iban construyendo su producto**, qué funcionalidades les gustaban a los clientes (aportan valor), y cuáles no (lo cual se considera como un desperdicio o despilfarro). La idea es obtener esta retroalimentación lo más pronto posible y no ya que el producto está totalmente terminado, 8 meses después, y descubrir que fueron 8 meses de trabajo tirado a la basura. No se trataba de adivinar lo que los clientes querían, ni de decirles lo que deberían de querer, sino de entenderlos, ver cómo utilizaban la propuesta de producto, y en base a la retroalimentación obtenida directamente de su experiencia con el producto, lo que Eric Ries llamó **Aprendizaje Validado**, ahora sí, mejorar el producto. “Cuando pivotamos a partir de la estrategia inicial (después de escuchar a los clientes), todo empezó a cambiar […] no porque estuviéramos trabajando más duro, sino porque lo hacíamos de una forma más inteligente, **a partir de escuchar las necesidades reales de nuestros clientes.**” # Ciclo Crear-Medir-Aprender Lo que el equipo de IMVU comenzó a hacer a partir de su experiencia anterior, fue plantearse una **hipótesis de negocio:** (sí, ya sé que esto de "hipótesis" suena muy del ámbito científico, pero en realidad así es, ya que es algo que creemos pero hasta que no lo validemos, no sabremos si es cierto o no). La hipótesis en este ejemplo era: Creemos que los jóvenes están interesados en un avatar 3D para sus aplicaciones de mensajería instantánea. Basados en esta hipótesis, en vez de construir durante 8 meses un producto que fuera compatible para todas las aplicaciones de mensajería, y que tuviera todas las funcionalidades, determinaron **construir un experimento que les permitiera validar su hipótesis lo más pronto posible.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-04.webp) **Crear **un producto que no fuera malo en cuestiones de calidad, pero no algo muy robusto ni sofisticado, solo las funcionalidades básicas y que pudiera utilizarse, por ejemplo, en vez de que fuera compatible con todas las aplicaciones de mensajería, elegir una sola, la de mayor uso (de esta manera, se requeriría relativamente muy poco tiempo en construirlo). Esta primera versión del producto es lo que se conoce como **Producto Mínimo Viable** (**MVP** por sus siglas en inglés, Minimum Viable Product), un producto con las mínimas funcionalidades que requerimos, solo las necesarias para probar si a la gente le aporta valor o no. Obtener información es el siguiente paso, a fin de poder **medir**… ¿Cómo medimos?, cara a cara con el cliente: Observándolo con nuestro producto o servicio, ¿Qué funcionalidades o características utiliza y cuáles no?, ¿Es fácil e intuitivo que lo utilice o tenemos que explicarle cómo hacerlo?, ¿Cuáles son sus comentarios después de utilizar nuestro producto?, ¿Le gusta?, ¿Realmente resuelve su necesidad o le hace la vida más fácil?, ¿Descargan nuestra versión del producto?, ¿La recomiendan? La idea es obtener información relevante, **métricas accionables** que nos ayuden a determinar cómo vamos. **Aprender **es el último paso de este ciclo. En base a la información recabada, ¿Cómo vamos?, ¿Cuál es el aprendizaje validado después de correr este pequeño experimento?, aquí la cuestión fundamental es: La hipótesis de negocio que habíamos considerado de manera inicial, ¿se cumple?, si la respuesta es positiva, podemos continuar por este rumbo con un producto o servicio que sabemos que tiene aceptación de parte de los clientes, tal vez agregando o removiendo algunas funcionalidades o características, haciendo algunos ajustes. Por otro lado, tal vez la respuesta es negativa y a nadie le interesa este producto o servicio, si es el caso, se debe de evaluar si es necesario hacer un **pivote** y ajustar el rumbo: **Plantear una nueva hipótesis de negocio y volver a correr el ciclo Crear-Medir-Aprender.** # El Método Lean Startup Así nace el método Lean Startup, creado por Eric Ries. Pero a todo esto, **¿Qué es el Método Lean Startup? La aplicación del pensamiento Lean (reducir el desperdicio o despilfarro) al proceso de Innovación.** (image: leonel-zapien-lopez-ideas-agilidad-eric-ries-metodo-lean-startup-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) En el método Lean Startup, un experimento es más que una simple investigación teórica; también es un primer producto. Un **Producto Mínimo Viable o MVP**, que ayude a empezar con el proceso de aprendizaje lo más pronto posible. El MVP no es necesariamente el producto más pequeño que se pueda imaginar; es la forma más rápida de entrar en el ciclo de retroalimentación **Crear-Medir-Aprender** con el mínimo esfuerzo (y lo más barato posible). El objetivo de un MVP es probar las hipótesis fundamentales del negocio, es sólo un primer paso en un proceso de aprendizaje. A lo largo de este proceso, tras muchas iteraciones, se puede descubrir que algún elemento del producto o estrategia es erróneo y decidir que ha llegado el momento de cambiar, un pivote, a un método diferente para alcanzar la visión. # ¿Y es factible construir ese MVP? Ok, esa idea de MVP suena bien... pero ¿Ya existe la tecnología de Star Trek para teletransportar a una persona, o hacer maleable el adamantium?, aquí la palabra clave es si este MVP es **factible **de construirse. De acuerdo con **Paulo Caroli**, famoso escritor y desarrollador de **Lean Inception **(sí, lo sé. Parece que todos se han puesto de acuerdo para agregar la palabra “Lean” como prefijo a todo lo nuevo), el error más común en la creación de un MVP es el pensamiento unilateral: Pensar solo en el desafío tecnológico, o solo en lo que le encantaría al usuario, o simplemente en lo que valida el negocio. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-06.webp) Un MVP adecuado, de acuerdo con Paulo Caroli, se encuentra justo en la intersección de: 1. Lo que es valioso para el usuario. 2. Es utilizable. 3. Es técnica y económicamente factible construirlo. (image: leonel-zapien-lopez-ideas-agilidad-paulo-caroli-lean-inception-mvp-producto-minimo-viable-guadalajara-mexico-05.webp) # Conclusiones Es imposible predecir cómo responderá un cliente a un producto o servicio que se lance al mercado. La mejor manera de entonces de actuar es escucharlo directamente, cómo responde y cuáles son sus necesidades reales. Para esto, la mejor aproximación es partir de experimentos, un producto mínimamente viable que nos ayude a validar una hipótesis de negocio de manera rápida y barata, antes de proceder a construir un producto o servicio a mayor escala y detalle. Para esto nos podemos apoyar en el ciclo Crear-Medir-Aprender, y cada vez que completemos una vuelta a este ciclo, determinar la forma en que habremos de actuar en base al **aprendizaje validado** que hemos obtenido. Eric Ries menciona que “la cantidad de tiempo que una empresa puede mantenerse como líder del mercado para explotar sus primeras innovaciones se está reduciendo y esto crea un imperativo. Incluso para las empresas más afianzadas: invertir en innovación”, y ¿Cómo podemos hacer esto?, creando algo “barato”, midiendo con los clientes o usuarios finales, aprendiendo, determinar si es necesario ajustar, y volver a iniciar. Añadiría un elemento más a lo anterior: Aprender divirtiéndonos durante el proceso, disfrutar el viaje por el ciclo Crear-Medir-Aprender, si hacemos lo que hacemos con pasión, la experiencia (además de enriquecedora), será totalmente memorable. **¿Habías escuchado hablar antes del Método Lean Startup?, ¿Cómo te ha ido experimentando con MVPs y obteniendo aprendizaje validado de tus productos o servicios?** ## Referencia: • El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua. Eric Ries. • Lean inception: Creando conversaciones hacia un producto exitoso. Paulo Caroli.
6 de mayo de 2024
OKRs

Objetivos y Resultados Clave (OKRs) para crear enfoque y alineación

OKR es un acrónimo en inglés que significa Objetivos y Resultados Clave (Objectives and Key Results), y se trata de un marco de trabajo de pensamiento crítico para el establecimiento de objetivos a través de resultados específicos y medibles. Hay una definición de OKRs que personalmente me gusta mucho, de los autores Paul R. Niven & Ben Lamorte: “Los OKR son un marco de pensamiento crítico y una disciplina continua que busca asegurar que los empleados trabajen juntos, centrando sus esfuerzos en hacer contribuciones mensurables que impulsen a la empresa hacia adelante.” # Introducción y (solo realmente) un poco de Historia Los OKR son ampliamente utilizados en el mundo ya que ayudan a las organizaciones a alinear objetivos y garantizar que todos estén trabajando colaborativamente en aquellos objetivos que realmente importan. De ahí parte todo: “Medir lo que importa”, es decir, métricas accionables, alineadas con los objetivos estratégicos de la compañía, y que nos indiquen paso a paso cómo vamos. Sin que esto sea una clase de historia, pero sí de forma general y a manera de contexto, te platico que los OKR fueron creados por Andy Grove cuando era CEO de Intel a finales de la década de 1980 y durante la de 1990. Esta forma de trabajar y alinear a Intel fue tan revolucionaria, que se extendió rápidamente por todo Silicon Valley, a empresas como Google y Netflix, y continúa creciendo al resto del mundo. Uno de los principales discípulos de Andy Grove, John Doerr, presentó los OKR en 1999 a los creadores de Google y ayudó a introducirlos en su compañía, publicó en 2017 el libro “**Mide lo que importa**” (Measure what matters), y a partir de ahí, la adopción de este marco ha crecido exponencialmente. (image: leonel-zapien-lopez-ideas-agilidad-andy-grove-john-doerr-okrs-mesure-what-matters.webp) ¡Ya!, es toda la historia que voy a contar, lo prometo. Pasemos mejor directo a tema sobre qué son los OKRs y por qué son tan poderosos. # Objetivos y Resultados Clave, vamos parte por parte ### Objetivo (O): Un objetivo es una declaración concisa que describe una meta cualitativa, diseñada para impulsar a la organización hacia la dirección deseada. Responde a la pregunta: "¿Qué queremos hacer?" Un objetivo bien redactado tiene un plazo determinado (factible en un trimestre) y debe inspirar y capturar la imaginación compartida de tu equipo. ### Resultados Clave (KR): Un resultado clave es un elemento cuantitativo que mide el alcance de un objetivo determinado. Si el objetivo responde a la pregunta “¿Qué queremos hacer?”, un resultado clave responde a la pregunta: “¿Cómo sabremos si hemos alcanzado nuestros objetivos?”. “El reto (y el valor real) de un resultado clave es el ayudarnos a definir maneras cuantificables para asentar, o para remover la ambigüedad e intangible de un objetivo. Por medio de los resultados clave, no es subjetivo o ambiguo si hemos alcanzado un objetivo o no, se vuelve algo medible y, por lo tanto, binario: Se cumplió o no se cumplió. (image: leonel-zapien-lopez-ideas-agilidad-okrs-consultor-cursos-agilismo-guadalajara-mexico.webp) # Vamos con un ejemplo: A manera de definir un primer ejemplo para asentar las características de los Objetivos y los Resultados Clave, imaginemos que queremos lanzar un nuevo y flamante sitio web para nuestra compañía. Bajo este contexto, uno de nuestros **objetivos** para este trimestre puede ser: “Diseñar un sitio web atractivo que llame a la gente a visitarnos como clientes potenciales”. El objetivo es conciso (sólo quince palabras), y su alcance es totalmente cualitativo (un sitio web atractivo, que llama a la gente). El objetivo no contiene números, eso corresponde a los resultados clave. Al definir un límite de tiempo (durante este trimestre) estamos confiamos en que podemos crear un diseño inspirador y que involucre nuestra creatividad en la producción de un sitio que la gente encuentre útil y estéticamente atractivo). Pero ahora, ¿Cómo sabremos si avanzamos en la dirección correcta para el logro de este objetivo que tiene adjetivos como “atractivo”, u oraciones como “que llame a la gente a visitarnos” ?, aquí es donde entran los resultados clave, y donde podemos encontrarnos con algunos problemas, ya que no hay una manera de traducir “un sitio web atractivo” a números, por lo cual se debe de “traducir” o definir en base al contexto específico de la organización. Basado en lo anterior, algunos posibles **resultados clave** para este ejemplo podrían ser: 1. Incrementar en 40% el número de visitas a nuestro sitio web de la compañía. 2. 20% de visitantes a nuestro sitio web que regresen a visitarnos nuevamente, dentro de una semana. 3. 10% de visitantes que dejen un mensaje o pregunta sobre nuestros productos. **Aquí algunos puntos importantes:** • El cumplimiento (o no) de los resultados clave, determinará el grado de cumplimiento del objetivo. • Y el otro punto importante: **Caja de tiempo o Timebox**. Estos resultados clave y objetivo son para un periodo de tiempo corto, en este ejemplo, para un trimestre. De esta manera tenemos el resultado cuantificable esperado durante un periodo de tiempo esperado. Esto es totalmente específico, medible e innegable. # Y… ¿Eso es todo?, parece realmente algo muy simple La verdad es que sí, los OKRs son una aproximación simple en esencia, pero no por eso menospreciemos los resultados que apoyan a lograr (digo, por algo Google y Netflix los utilizan hoy en día). Algunos de los elementos principales que lo hacen un marco tan poderoso son: ### Despliegue a todos los niveles de la organización La idea de los OKRs es que los objetivos y resultados clave que más aporten a la organización a nivel estratégico estén claramente definidos, y cada división, departamento, equipo (e inclusive puede implementarse a nivel persona) tengan claro cómo sus OKRs individuales aportan, día a día, paso a paso, a los OKRs de toda la compañía. Ya que los OKRs a nivel organización, los OKRs a nivel división, los OKRs a nivel departamento y los OKRs a nivel equipo, son transparentes y visibles para todos, la alineación que se puede lograr es extraordinaria (esto se conoce como **alineación vertical**). De la misma manera, ya que en nuestro día a día dependemos (en muchas circunstancias) de otros equipos o departamentos. Un punto de dolor común es diversas compañías, es que cada equipo o cada división tiene sus propias métricas para evaluar cómo están realizando su trabajo. Hasta aquí todo parece ir bien, ¿correcto?, pero ¿Qué sucede cuando las métricas o indicadores “individuales” de un equipo o departamento se contraponen con los indicadores de otro equipo o departamento? (image: leonel-zapien-ideas-agilidad-okrs-alineacion.webp) **Te voy a contar una historia (Me gusta mucho contar historias)** 😉 Claro que no puedo compartir nombres, pero una compañía con la que colaboré realizaba un producto X, y la verdad es que era todo un éxito. En el proceso de elaboración de este producto, había dos áreas importantísimas, una era desarrollo y la otra era calidad. Desarrollo elaboraba el producto y lo enviaba al área de calidad para que hiciera las validaciones correspondientes. Hasta ahorita todo parece aún ir bien, ¿aún correcto? El detalle, es que a desarrollo lo medían por la cantidad de trabajo que enviaban a calidad (más, en este sentido, es mejor. Al menos para desarrollo). A calidad lo medían por la cantidad de defectos que detectaban (aquí también, más defectos detectados es mejor, desde el punto de vista de los indicadores de calidad). Pues bien, desarrollo se enfocaba en enviar y enviar la mayor cantidad de trabajo que pudiera a calidad, a destajo, podían llegar a ser cantidades descomunales de trabajo. Calidad es un muestreo (claro que hay temas como automatizaciones que nos pueden ayudar para no hacerlo manual), pero ningún proceso puede asegurar un porcentaje de errores de 0.0000000%... en ese sentido, a calidad se le podían ir algunos defectos (en especial cuando tenían un alto volumen de trabajo por revisar), y cuando se “escapan” estos defectos y llegaban al cliente. ¿De quién era la culpa? El argumento de Desarrollo era: “Calidad no lo revisó bien”, se podía caer en el objetivo de enviar trabajo por enviar, desarrollo cumplía su indicador (cantidad de trabajo “terminado”), y si calidad no detectaba algún error o defecto y llegaba hasta el cliente, cuando volvía era un indicador de calidad. Lo sé, mal, mal, mal, en este escenario pintaba todo mal (y en realidad al final todos perdían). Pues bien, los OKRs se utilizan también para crear **alineación horizontal**, entre divisiones, departamentos, equipos. Deben de cocrearse objetivos y resultados clave que corresponsabilicen a ambas partes, que promueva la colaboración y que asienten la base para un verdadero ganar-ganar, tanto entre los equipos implicados, como a nivel organización. # Si me enfoco en todo, no me estoy enfocando en nada (poco es mejor) Los OKRs por definición deben de ser pocos, de tal manera que se tenga un enfoque real. Dependiendo la fuente que revises, puedes encontrar un poco de variación en cuando a las cantidades (pero es algo realmente menor, no es como que un autor diga 4 y otro diga 44). Respecto al número de Objetivos y Resultados Clave, las fuentes bibliográficas que he leído, por ejemplo, los autores Paul R. Nivel y Ben Lamorte, así como lo que he comprobado que funciona bien en la práctica, son los siguientes: **Número de Objetivos (O):** De 2 a 5 (como máximo, pero de verdad menos es mejor). **Número de Resultados Clave (KR):** De 2 a 4 para cada objetivo. # Cadencia Otro de los elementos poderosísimos de los OKRs es que es un modelo cíclico, que funciona en base a iteraciones o cadencias. (image: cadencia.webp) Retomemos el mismo ejemplo que conversábamos más arriba en este artículo: “Diseñar un sitio web atractivo que llame a la gente a visitarnos como clientes potenciales”. Los resultados clave asociados a este objetivo, lo que nos hará saber de una manera medible cómo vamos con respecto a este objetivo, son los siguientes: 1. Incrementar en 40% el número de visitas a nuestro sitio web de la compañía. 2. 20% de visitantes a nuestro sitio web que regresen a visitarnos nuevamente, dentro de una semana. 3. 10% de visitantes que dejen un mensaje o pregunta sobre nuestros productos Mencionábamos que este equipo hipotético tenía este objetivo para un trimestre. Pues bien, si llegamos al final del trimestre para evaluar y darnos cuenta en ese mismísimo momento que no se logró el objetivo, tal vez (solo tal vez), ya sea un poco tarde para intentar hacer algunos ajustes durante el camino. Por esto, hay todo un ciclo de OKRs que ayuda a dar cadencia a este marco, y tenemos transparencia constante para inspeccionar y adaptar. Pues bien, este ciclo de OKRs establece que se pueden definir Objetivos y Resultados Clave de la manera siguiente: **1. De manera anual (para la estrategia d etoda la organización).** Es definir los OKRs a nivel estratégico para toda la organización. En este sentido, hay muchos autores que “anti-rrecomiendan”, y yo soy solo autor de este blog, pero coincido en que es un periodo de tiempo muy largo para la vorágine del mundo VUCA-BANI en el cual vivimos (por cierto, si quieres saber un poco más sobre los acrónimos VUCA y BANI, (link: https://www.youtube.com/watch?v=2uPBLpm5Qno text: te comparto aquí este link a un video de un webinar que di al respecto)). **2. Cuatro veces al año, o lo que es cada tres meses (Quarterly).** Definir los OKRs para el periodo de tres meses que está por comenzar (o alinearlos con los OKRs anuales que pudieran haberse definido a nivel organización). **3. Revisiones a mitad del cuarto (Mid-quarter).** El objetivo de estas revisiones es, habiendo llegado a la mitad del periodo, ver el avance que se tiene hasta el momento, conocer la probabilidad de alcanzar los resultados clave, y ajustar. La verdad es que aún en este punto, a mitad del trimestre, es incierto determinar si los OKRs se lograrán, pero maximiza por mucho el enfoque de los equipos y todos comparten la misma base de información. Es un trabajo colaborativo. **4. Revisiones semanales.** El objetivo de estas revisiones que se recomiendan cada semana es compartir información, evaluar el progreso, identificar riesgos potenciales antes de que se conviertan en verdaderos problemas, y, uno de los puntos de mayor valor: Mantener el enfoque, asegurar consistencia y **ayudar a que la forma de trabajar con OKRs se establezca y eche raíces en la cultura de la organización**. # Beneficios de los OKRs Después de su despliegue e implementación de los OKRs en muchísimas compañías a lo largo y ancho del mundo, entre los principales los beneficios que reportan haber obtenido las compañías que los han implementado, podemos encontrar: **1. Enfoque:** Con OKRs se asegura que todos tienen claro qué es lo que más importa, y enfocarse en ello. **2. Transparencia:** El tener metas medibles y visibles a todos los niveles, promueve la toma de decisiones informadas y el puntual paso a la acción. **3. Alineación:** La transparencia promueve la alineación multifuncional, entre personas, equipos, departamentos, divisiones. **4. Comunicación:** Al ser un sistema de fácil comprensión, se incrementa su uso y aceptación, fomentando la comunicación alineada entre las personas, equipos, departamentos, divisiones. **5. Agilidad:** Al trabajar en ciclos cortos y frecuentes de retroalimentación, se fomenta la agilidad y se está mejor preparado para los cambios. **6. Compromiso:** La mayoría de los OKRs se originan de “abajo hacia arriba” en la estructura organizacional (bottom-up), de tal manera que las personas y equipos son dueños y responsables de sus metas. **7. Pensamiento visionario:** Los OKRs ayudan a “estirar” nuestro pensamiento acerca de lo que es posible, para alcanzar metas más retadoras. # Conclusiones Hasta aquí, de manera general he compartido la esencia de este marco de trabajo conocido como OKRs. La verdad es que es muy sencillo de comprender, considero que el verdadero reto reside por un lado en la elaboración y definición de Objetivos y Resultados Clave efectivos y retadores, que no indiquen métricas de vanidad o que no aporten a la estrategia organizacional, así como que no sean realmente retadores y solo lleven a los equipos a continuar trabajando igual, a hacer lo que se conoce como** BAU (Business as Usual)**, es decir, trabajar de la misma manera que se ha venido trabajando siempre. Por otro lado, el segundo punto de importancia en la adopción de OKRs, y uno muy importante para que de verdad se den resultados sorprendentes, es algo que había mencionado un poco más arriba en el artículo: Los OKRs deben de enraizarse en la cultura de la organización. Es decir, debe de haber una seguridad para que los equipos puedan experimentar y proponer, para intentar lograr sus objetivos, alineación vertical y horizontal que fomente la colaboración y enfoque, patrocinio de los niveles directivos en el programa de OKRs, compartir y conversar en espacios que realmente detonen maneras creativas de alcanzar y superar los OKRs. Hay una cita respecto al cambio, que siempre me ha encantado: **“Un cambio es cultural, o no lo es”**. Así de simple y así de poderoso. Fomentemos los OKRs con un enfoque experimental, de aprendizaje. Siempre con la mentalidad o mindset de la Agilidad o Agilismo en el foco, siempre recordando que todo parte de los Individuos y sus interacciones, sobre los procesos y las herramientas. **¿Habías escuchado hablar antes de los OKRs?, ¿Cómo te ha ido experimentando con ellos en tus equipos?** ### Referencia: **Objectives and Key Results: Driving focus, alignment, and engagement with OKRs.** Paul R. Nive and Ben Lamorte.
4 de marzo de 2024
Agile, Agilidad, Agilismo

A 23 años del nacimiento del Manifiesto Ágil

Hoy, aprovechando la fecha, vamos a platicar un poco sobre lo que se conoce como el “Manifiesto Ágil”, que es la piedra angular con la cual surge oficialmente el movimiento **agile** (traducido al español como **agilidad** o **agilismo**), que nació un 12 de febrero de 2001 (al momento de escribir este artículo, hace 23 años). Su nombre completo es “Manifiesto por el Desarrollo Ágil de Software”, el cual propone 4 valores y 12 principios que destilan en una manera de pensar o mindset, para abordar un enfoque ligero y adaptativo, un enfoque que nos ayude a responder al cambio, el cual es la esencia de la agilidad o agilismo. No te preocupes, no va a ser una charla de historia aburrida (espero), sobre el Manifiesto, pero sí conversaremos algunos puntos relevantes. ¡Comencemos por el principio! (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-06.webp) # Contexto Histórico A finales de la década de 1980, estaba en una etapa de crecimiento la industria del software, pero había puntos de dolor en común que personas alrededor de todo el punto sufrían: Problemas con los tiempos de entrega, con la respuesta y expectativa del cliente o usuario final cuando finalmente (después de varios meses o años inclusive), por fin veía su producto anhelado… y la brecha entre lo que él o ella esperaban contra lo que se había construido. Todo esto tenía una causa raíz: Tratar de planear y diseñar de manera anticipada absolutamente todo al detalle, pero todo-todo, lo que el cliente o usuario necesitaría, para después construirlo y que, hasta el final, este cliente o usuario, viera su producto funcionando. Esta es la forma en que se trabaja en la industria por aquel entonces… (lo bueno es que esa manera de trabajar ya ha quedado atrás, ¿verdad?). Bajo esta premisa, diversos especialistas del área de software se reunieron como respuesta a los métodos tradicionales y formales con los que se trabajaba entonces en la industria. Fue un ¡basta ya! a las prácticas tradicionales, un llamado a la acción. # Cada uno estaba experimentando con sus equipos Había un grupo de profesionales en el Desarrollo de Software, cada uno había estado experimentando durante algunos años con maneras alternativas y bastante radicales de trabajar (radicales para la época), de crear productos, y habían estado obteniendo resultados súper reveladores en distintos contextos. Por un lado, había figuras que habían creado marcos de trabajo como **Scrum**, **Extreme Programming (XP)**, **Crystal**, entre otros. Pero eran esfuerzos en mayor medida aislados, cada quien trabajaba en su isla, y la idea era que entre todos estos Rockstars del Desarrollo de Software, cocrearan algo superior y que unificara estas formas nuevas de trabajar. # Todos acuden al llamado Kent Beck, creador del mencionado Extreme Programming (XP), fue quien convocó a una reunión, y dado que en aquella época no había Zoom ni Teams, se programó una reunión presencial. El lugar: **Snowbird, Utah**. El propósito: Tratar sobre técnicas y procesos para desarrollar software. Así lucía Snowbird en aquella ocasión: (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-01.webp) Atendieron el llamado un total de **17 expertos nivel Master Jedi**, hicieron un retiro en Snowbird durante un par de días, y el lunes 12 de febrero de 2001, se acuñó el término **Agile** para definir a los métodos y marcos que estaban surgiendo como alternativa a las metodologías tradicionales de desarrollo, a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y altísimo grado de dependencia de planificaciones detalladas previas al desarrollo. Lo que se buscaba con estas nuevas maneras de trabajar agrupadas bajo el término Agile era proporcionar en poco tiempo piezas pequeñas de sistemas de software en funcionamiento, para mostrarlas directamente al cliente en periodos cortos de tiempo, obtener retroalimentación rápida, y con esto ayudar a mejorar la satisfacción del cliente. Estos marcos utilizan enfoques flexibles pues aceptan los cambios que puedan surgir en las diferentes etapas del ciclo de vida, en lugar de resistirse a ellos. (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-05.webp) (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-02.webp) ### Nota #01: El término **Agile** lo podrás encontrar en español traducido como **Agilidad o Agilismo** (Agilismo es un término con el cual concuerdo más, pero es relativamente muy reciente. ¿Por qué Agilismo y no Agilidad?, ya estoy preparando un artículo para conversar sobre esto, próximamente conversaremos). ### Nota #02: Por cierto, de manera inicial, a estas nuevas maneras de trabajar les llamaban “**Marcos ligeros**”, y el nombre Agile no fue la primera opción sobre la mesa, pero las otras opciones estaban ya en uso y había temas de derecho de autor. De esta reunión, los 17 asistentes resumieron los principios sobre los que se basan los métodos alternativos en los que estaban trabajando, y la esencia de esto quedó definida en 4 valores y 12 principios: Lo que ha quedado denominado como Manifiesto Ágil. # 4 Valores y 12 Principios 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. Los 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?”. Estos cuatro valores se asientan en 12 principios: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de 'software' con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos 'software' funcional frecuentemente, entre dos semanas y dos meses, preferentemente en el periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo, y entre los miembros del equipo, es la conversación cara a cara. 7. El 'software' funcionando es la medida principal de progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. (image: agile-manifesto-12-principios-visual-agile-coach.webp) # ¿Y la evolución del Manifiesto Ágil? El Manifiesto se firmó hace 23 años y en su momento fue “la onda” (como decimos acá en México). Sin embargo, los métodos y marcos de trabajo que alineaba han evolucionado con el tiempo, lo cual está bien y es natural: Por ejemplo, siempre digo que el Scrum de 1995 (cuando fue presentado públicamente al mundo), no es el mismo que el Scrum de hoy, y la prueba está en que la Guía Scrum, el documento que sienta las bases de este marco de trabajo, se ha actualizado varias veces. Lo interesante es que **el Manifiesto Ágil nunca se ha actualizado en todo este tiempo**. (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-04.webp) Muy personalmente considero que el Manifiesto debería actualizarse, por ejemplo, cambiar el “**Software funcionado**” por algo más genérico como “**Producto o entregable funcional**” (para quitar el foco de que solo se puede utilizar para desarrollar software). Pero no solo eso, sino ir un paso más allá, cambiándolo a: “**Producto o entregable funcional y valioso**”, 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 aporte **valor** a este 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. Esto 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 un paso más adelante, en vez de productos que hagan la vida más fácil para las personas, **busquemos crear productos que enamoren! ** (Lo sé, soy un romántico incorregible, de esos chapados a la antigua 😊) # Conclusiones Si bien el concepto de Agile o Agilidad o Agilismo no es del todo nuevo, pues sus principios han sido ampliamente utilizados desde hace varias décadas, no es sino hasta febrero de 2001 cuando oficialmente nace la agilidad con el Manifiesto por el Desarrollo Ágil de Software. El Manifiesto es un documento histórico que cumple 23 años. Y el mundo de la Agilidad o Agilismo, 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 20 años, todo evoluciona. **Últimamente está muy fresco el tema sobre si la Agilidad ha muerto**. Personalmente no creo que sea así, simplemente debe de evolucionar y nosotros junto con ella. Debemos ser capaces de demostrar su verdadero valor, y quizá los nombres puedan cambiar en el futuro, pero la esencia de la Agilidad o Agilismo probablemente permanezca y nos acompañe, quizá con otro nombre, quizá con un reboot. Todo, finalmente, es evolución. ### Feliz cumpleaños #23 al Manifiesto Ágil 😁 (image: leonel-zapien-lopez-ideas-agilidad-manifiesto-agil-agile-agilidad-agilismo-23-aniversario.webp) # Anexo: Como nota final, el Manifiesto Ágil fue firmado por: 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/thevisualagilecoach/ text: Olina Glindevi), desde Estocolmo ((link: https://www.linkedin.com/in/thevisualagilecoach/ text: The Visual Agile Coach)). * Las fotografías de los días en Snowbird, publicadas por Alistair Cockburn (firmante del Manifiesto Ágil).
16 de febrero de 2024
Agilidad vida cotidiana

Poniendo foco en lo que importa en nuestro día a día (y en nuestra vida): El Método Bullet Journal

Estar ocupado no es lo mismo que ser productivo, y para ser productivos no es necesario que estemos saturados. El método Bullet Journal comienza con misión irresistible: Dar seguimiento al pasado, ordenar el presente y diseñar el futuro. ¿Cómo? Nos ayuda a tomar consciencia acerca de cómo gastamos los dos recursos más valiosos en nuestra vida, nuestro tiempo y energía. En la segunda semana del año pasado, **Ric Granados**, un amigo de Venezuela me platicó de Bullet Journal. No lo había escuchado mencionar antes, y con lo que me explicó enseguida llamó mi atención como para investigar más. En ese momento estaba pasando por un gran pico de trabajo y tantas cosas por atender, siempre pasando de una reunión a la siguiente, pendientes encolados, compromisos ya programados que se me pasaban (a pesar de utilizar notas y eventos en el calendario de mi teléfono), así que me pareció una genial idea probarlo. Si no intentamos hacer cosas distintas, ¿cómo esperamos obtener resultados distintos? Leí algunos artículos, vi un par de videos, y aunque con esto ya tenía un gran punto de partida, decidí comprar el libro de **The Bullet Journal Method** (conocido simplemente como **Método BuJo**), de su creador Ryder Carroll. Desde el primer mes del 2023 comencé a utilizarlo, y después de un par de semanas de implementarlo fui capaz de identificar dónde era necesario poner mi enfoque, y a dónde iba mes con mes, para alinear mis esfuerzos diarios con mi propósito. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0001.webp) Es por esto que me decidí a escribir este artículo, como **un convencido evangelizador a 1 año de adoptar el Bullet Journal en mi vida cotidiana**, y cómo mi productividad y enfoque se multiplicaron 😊 # Poner foco en lo que importa Aquí voy a ser muy sincero al mencionar que BuJo no reinventa la rueda, el método puede parecer en esencia muy sencillo (taaan sencillo que se puede subestimar el potencial que puede aportar). **Estar ocupado no es lo mismo que ser productivo, y para ser productivos no es necesario que estemos saturados.** Bullet Journal nos ayuda a hacer un **inventario mental** de todas esas cosas que están orbitando en nuestra cabeza, y asentarlas para poner enfoque en lo que es realmente importante. # ¿Qué es el un Bullet Journal o BuJo? Si lo tradujéramos al español, sería un **Diario de viñetas**, así que sencillamente es esto: Una libreta en blanco para organizar nuestros objetivos, tareas y cualquier idea. Como método, es un sistema de planeación y una manera de organizar nuestro día a día en esta libreta, utilizando un sistema de viñetas o bullets para crear listas, que nos ayuda a enfocarnos en nuestros objetivos a corto, medio y largo plazo. Es tan simple y poderoso, que es utilizado por millones de personas en el mundo. El creador del **BuJo** es Ryder Carroll, un diseñador de Nueva York, quien creó la idea del Bullet Journal como una alternativa eficiente para contrarrestar las dificultades con las que se enfrentaba en su día a día debido a su trastorno de déficit de atención, y necesitaba un método para ordenar su vida. Nada revolucionario, nada esotérico, pero sí algo muy poderoso que requiere mucha constancia para que proporcione verdaderos resultados (como el hábito de leer, aprender a utilizar un** sable láser**, o cualquier otra cosa que valga la pena en la vida). # Elementos de un Bullet Journal Una libreta de Bullet Journal sirve para muchas cosas, el objetivo principal es poder organizar tu día, mes y tu año, a la vez que nos ayuda a por escritos nuestros pensamientos. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0002.webp) Algunos elementos del Bullet Journal son: • Registro de elementos diarios: Tareas, eventos, notas, etc. • Gestión de objetivos mensuales y anuales. • Seguimiento de hábitos. • Lista de libros por leer. • Lista de películas por ver. • Lista de frases inspiracionales o que nos gusten. • Espacio para descargar ideas en crudo. • Registro de gastos. • Y cualquier otro elemento que consideres necesario agregar. Una lista para anotar elementos diarios no es tan simple como una lista de tareas, nos podemos traer el mundo de la **Agilidad o Agilismo** el concepto de **Backlog**, y es que, esta lista es un documento vivo, que tiene distintos tipos de elementos (tareas, eventos, notas, etc.), y ordenarlos por relevancia, para **enfocarnos en hacer lo de mayor valor**. # Comenzando a armar nuestro Bullet Journal ### Índice Reservar las primeras páginas de nuestra libreta para indicar un índice, es de mucha ayuda. ### Símbolos Si tuviera que definir la esencia de un BuJo, sería esta parte, definir los símbolos que usaremos en nuestra libreta Bullet Journal para cada tipo de elemento. Todo parte de definir cuáles serán los símbolos para nuestras viñetas o bullets, que ayudan a crear coherencia y un flujo. Aquí te comparto algunas definiciones de símbolos que propone el creador del método, aunque los puedes personalizar. (image: leonel-zapien-lopez-ideas-agilidad-simbolos-bullet-journal.webp) Los símbolos para tus viñetas los puedes personalizar, por ejemplo, yo prefiero escribir un “guion” en vez de una “X” para una tarea que he completado. Espera, **¿Qué rayos es una “Tarea migrada” ?**, sí, a mi también me surgió esa duda cuando estaba leyendo el libro, pero no te preocupes, lo menciono un poco más adelante, en la sección “Migración”. ### Registro mensual Esta sección del BuJo nos ayuda a planificar nuestros objetivos durante cada mes del año. En el registro mensual anotamos las tareas o eventos que tenemos planeados realizar en el presente mes, y también funciona como un “inventario mental” del mes (anotar ideas, actualizar tareas o eventos conforme el mes avanza). El poder visualizarlos (crear **Transparencia**, como decimos en el mundo de la **Agilidad o Agilismo**), ayuda a crear enfoque y organizar nuestras actividades en consecuencia. Lo importante de lo que planeamos en nuestro mes, es que esté alineado con nuestro propósito del año (y con nuestro propósito de vida). (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0003.webp) (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0004.webp) ### Registro diario Realizar un registro diario de lo que necesitamos hacer, de manera sencilla. Debemos anotar cuáles son nuestras actividades en un día regular: citas o eventos, tareas, notas, etcétera. Hazlo utilizando los símbolos que hayas definido para tus viñetas. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0005.webp) Seguramente surgirán actividades o eventos en el día a día, pero lo importante es que avancemos sin perder de vista los objetivos del mes, esto para asegurar que no nos desviemos del rumbo y para **crear alineación**. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-proposito-y-objetivos.webp) (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0006.webp) ### Migración Al final del día, una actividad o tarea que no hayamos realizado por cualquier circunstancia, la migramos al día siguiente, para no perderla de vista, hasta completarla (o se vuelva no relevante y ya no sea necesario realizarla). Es decir, si algo es importante y no completamos en un día, lo migramos al día siguiente para asegurarnos de terminarlo. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0007.webp) (En la imagen, la tarea de ejemplo “Tarea 03” no la completé el día 01 de enero, y la migré al día siguiente, el 02 de enero) De la misma manera como migramos tareas de un día a otro, al finalizar el mes, debemos de hacer una revisión del log mensual, y migrar al mes siguiente aquellas actividades que no hayamos realizado o completado en el mes que acaba de terminar. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0008.webp) (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0009.webp) Esto de la migración es uno de los elementos que me parecieron más poderosos de BuJo, porque así no perdemos el foco de los pendientes que sean importantes, y los vamos migrando de día o de mes, hasta realizarlos. De igual manera, es importante visualizar las actividades que migramos al año siguiente o que, desde este año conocemos con anticipación que deben de realizarse en una fecha determinada el próximo año, para programarlas (sí, me queda claro que en una agenda común y corriente también se puede hacer esto), por ejemplo: Un aniversario o cumpleaños, la fecha de un viaje, la renovación de la licencia de conducir o la licencia de un software, o quizá** el Día de Star Wars** (sí, en verdad existe este día, millones de fans alrededor de la galaxia lo celebramos el 4 de mayo). (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0010.webp) ### Otras secciones o elementos de BuJo Las secciones anteriores son para llevar el registro de nuestras actividades, pero como mencionaba, nos ayuda también a reducir el “ruido mental” de todas esas ideas que orbitan en nuestra cabeza, o eliminar la necesidad de otros diversos post-its o notas en el teléfono, dejando todo por escrito en un solo lugar. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0011.webp) Para esto, cuenta con diversos elementos o secciones, la idea es que tomes o agregues las que más te aporten. Las mencioné anteriormente, pero aquí van de nuevo, para que no tengas que hacer scroll y regresar: • Registro de elementos diarios: Tareas, eventos, notas, etc. • Gestión de objetivos mensuales y anuales. • Seguimiento de hábitos. • Lista de libros por leer. • Lista de películas por ver. • Lista de frases inspiracionales o que nos gusten. • Espacio para descargar ideas en crudo. • Registro de gastos. • Y cualquier otro elemento que consideres necesario agregar. Particularmente, yo no llevo mi registro de gastos en el BuJo (para eso utilizo una hoja de cálculo compartida, discúlpenme la herramienta los Jedi en Finanzas, sé que es muy básico, pero me funciona y a final de cuentas creo que lo importante es llevar un registro de gastos sin importar la herramienta), pero en cambio, sí utilizo otras secciones, como: **Lista de libros por leer, lista de películas por ver, lista de lugares que quiero visitar, lista de frases que me gustan, y un espacio para descargar ideas**. La idea es que personalices esto de acuerdo a tu necesidad, no sé, tal vez si** James Bond** utilizara Bullet Journal tendría una sección llamada “Lugares donde he tomado un en compañía de una super modelo”, o tal vez **Batman** utilizaría una sección “Lista de bati-inventos para construir”. ### Un tip final… ¿Por qué escribir a mano, cuando de seguro hay muchas Apps que pueden ayudarnos? **Reconozco que este fue el primer “pero” que le encontré… ¿Por qué escribir a mano en una libreta de papel, tal como lo hacían nuestros antepasados?** Hasta ese momento, el 98.74% de todo lo que escribía era a través de teclados (físicos o táctiles). De acuerdo con (link: https://www.bbc.com/mundo/noticias/2016/01/160125_escribir_a_mano_cerebro_finde_dv text: un estudio de la BBC), se estima que el 30% de la población mundial no ha escrito a mano durante los últimos seis meses de su vida. Primero, desde un punto de vista neurocientífico, escribir a mano estimula el cerebro y es fundamental en el aprendizaje de la lectoescritura. El método BuJo se puede utilizar sin ningún tema en dispositivos digitales, solo enfatizo el hecho de lo poderoso que fue desentumir los músculos de mi mano que sostienen un bolígrafo (“pluma”, como lo llamamos más comúnmente acá en México), así como ejercitar el cerebro, y comenzar a escribir. ### Un “Hack” adicional (basado en la Agilidad o Agilismo) Antes de conocer el método BuJo, como buen Agilista, utilizaba un tablero de visualización, esto tiene que ver con vivir la Agilidad, con pasarla por el cuerpo como dice mi amiga **Ro Sosa**, de Chile. (image: leonel-zapien-lopez-ideas-agilidad-bullet-journal-0013.webp) En este sentido, el BuJo vino a complementar mi enfoque, y al día de hoy continúo utilizando un tablero, lo tengo a un lado de mi escritorio, en casa, y lo que he aprendido es a complementar ambos enfoques, que desde mi punto de vista no se contraponen en lo absoluto. # Conclusiones El Método Bullet Journal o BuJo, es realmente muy sencillo en esencia, pero sumamente poderoso para poner orden en nuestra vida y foco en lo que verdaderamente importa, día a día, mes a mes. Porque así es como se llevan a cabo los proyectos más retadores y las misiones más críticas, así es como se construyen los grandes imperios: Un día a la vez, sin perder el objetivo de vista. BuJo claro que funciona, eso sí, no es ninguna solución que metes al horno de microondas y está lista en 4 minutos **(como decimos en el mundo de la Agilidad o Agilismo: “No es una bala de plata”)**. Como todo lo que vale la pena en la vida, requiere constancia para aplicarlo, para incorporarlo a nuestros hábitos. Solo de esa manera proporcionará verdaderos resultados, así que, pruébalo con un enfoque ágil: Experimentando, inspeccionado y adaptando, pero sobre todo: No aflojes el ritmo. **¿Cómo nos comemos a un elefante? Una mordida a la vez.** Así que, lleva el registro de tus mordidas diarias y mensuales en tu Bullet Journal, ¡Nos compartes qué tal te funciona! ### Referencias: • The Bullet Journal Method. Ryder Carroll. • ¿Por qué es mejor que sigamos escribiendo a mano? BBE News Mundo (Recuperado de: https://www.bbc.com/mundo/noticias/2016/01/160125_escribir_a_mano_cerebro_finde_dv) * Todas las imágenes son fotografías propias.
15 de enero de 2024
Agilidad

Reconsiderando la Agilidad Organizacional

“La Agilidad Organizacional no es creada poniendo juntos a varios equipos Agile, la Agilidad es creada cuando las interacciones entre los equipos son ágiles.” Klaus Leopold. Estuve leyendo en los últimos días el libro “Reconsiderando Agile”, de Klaus Leopold. Es un libro lleno de aprendizaje, geniales ilustraciones y muy divertido. Aquí comparto un resumen de algunas de las ideas principales de este tremendo libro. Klaus nos lleva de la mano a una organización cualquiera, que quiere comenzar a “implementar agilidad” para estar preparada para el futuro. Este punto es, ya de entrada, un tema muy común cuando se ve la Agilidad Organizacional como una moda, y su implementación como seguir una receta de cocina. En esta organización, después de todo un proceso de transformación, que llevó meses de capacitación, reestructuración y definición de nuevos roles y equipos, los números indicaban que la compañía estaba lejos de ese objetivo inicial:** Llegar más rápido al mercado (esta métrica se conoce como TTM o Time To Market).** ¿Por qué llegar más rápido al mercado es una prioridad? Porque el ciclo que va desde idear una iniciativa o producto nuevo hasta que llega a las manos del cliente, debe de ser lo más corto posible, porque lo que se busca es llegar al cliente para que nos proporcione retroalimentación real de nuestro producto o servicio. Solo así una organización será capaz de inspeccionar y adaptar en base a lo que está entregando a mercado, ser flexibles en base a lo que el mercado demanda. Esto es esencial para sobrevivir. Es en este punto cuando llaman a Klaus (en el libro no menciona a detalle cómo lo llaman, pero de seguro fue por una especie de “batiseñal”). (image: batisenal.webp) Al analizar la situación de esta organización, identifica varios hallazgos críticos para alcanzar esa Agilidad Organizacional que con tanta añoranza buscan. Y para ello, ofrece algunos puntos muy interesantes que les pueden ayudar: # 1. Hacer visibles las dependencias y gestionarlas Todos los equipos y todas las organizaciones tienen dependencias, dependen de otros equipos para poder concluir su trabajo. Esto es normal e inevitable. El problema es que muchas veces estas dependencias externas se traducen en tiempos de espera, es decir, mi equipo depende de otro equipo para que complete determinada tarea que yo necesito y solo ellos realizan, proporcione una validación o aprobación, entre otras cuestiones. Esto genera tiempos de espera, debo de esperar a que el otro equipo tenga capacidad para atender mi solicitud. El primer punto para gestionar las dependencias es hacerlas visibles, el objetivo es eliminar las que más sea posible y reducir el tiempo de espera en aquellas que no puedan eliminarse. Para esto, el primer paso fue generar esta visibilidad mostrando el trabajo de todos los equipos y sus interacciones, esos momentos en que el trabajo “sale” de un equipo para ingresar al flujo de algún otro equipo, y después, cuando este trabajo es completado, cómo “regresa” al equipo original para que esta pueda continuar su trabajo. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-team-dependencies.webp) Una propuesta para organizar las dependencias fue organizar el trabajo en torno a productos, y visualizar estas dependencias ayuda a hacer más ágil las interacciones entre equipos, que la comunicación fluya lo más rápido y de manera adecuada entre equipos. # 2. Integrar el flujo completo Es muy importante visualizar el flujo de valor completo, es decir, todos los pasos relevantes del proceso que una organización necesita para producir un producto o servicio. Esto fomenta a que no veamos el trabajo que los equipos generan como algo aislado, sino de “punta a punta”. Si lo que queremos es mejorar el tiempo para llegar al mercado (desde idear una iniciativa o producto nuevo hasta que llega a las manos del cliente), entonces tenemos que ver la fotografía completa de este flujo de valor. Lo que sucede antes de que el trabajo llegue a mi equipo, se conoce como **“Aguas arriba” (Upstream)**. Después el trabajo llega a mi puerta (está en mi “cancha”, como decimos acá en México), y por lo tanto comienzo yo a trabajar en esto. Cuando “termino mi parte”, lo paso a la siguiente cancha, a que continúe con su flujo **“Aguas abajo” (Downstream)**, y ahora otro equipo o área puede comenzar su trabajo. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01upstream-and-downstream.webp) Si queremos ser ágiles a nivel organización, de poco o nada sirve que a nivel individual cada equipo sea súper-archi-requete-rápido o mega-efectivo o de alto desempeño o “ágil”, si al final del día, lo que sucede aguas arriba o aguas abajo sigue siendo no-ágil. Por eso es necesario visualizar el flujo completo e integrar Upstream y Downstream en un solo flujo de valor. En este sentido, Klaus Leopold nos dice que **“La cuestión no es respecto a cuántos pasos de Upstream son parte de mi flujo de valor, sino cuán rápido esos pasos son”.** Visualizar las dependencias y el flujo completo no es la solución a todos los problemas, lo realmente importante es que detona las conversaciones necesarias para que se den las situaciones que resuelvan estos problemas. Un mejor tiempo para llegar al mercado tiene que ver con tomar decisiones frecuentes que ayuden a mejorar el flujo de trabajo a través de la colaboración entre equipos. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01complete-value-stream.webp) # 3. Gestión estratégica del Portafolio La Agilidad Organizacional integra todo el flujo de valor, Upstream y Downstream, ¿Qué tan “aguas arriba” debo comenzar?, desde el nivel superior, donde nace la estrategia. Los niveles directivos deben de integrarse también, por lo tanto, también se debe de visualizar y gestionar todo lo que sucede a nivel portafolio, las iniciativas de negocio que se van a iniciar y su importancia de acuerdo con la estrategia. Esto se llama Gestión estratégica del Portafolio. El objetivo es alinear todo en un flujo continuo, es decir, no iniciar más iniciativas de las que los equipos tienen capacidad de ejecutar. Se busca crear un flujo de trabajo alineado, no generar demasiado WIP o trabajo en progreso, sin importar si hablamos de nivel operativo o estratégico. Recordemos que el objetivo es llegar lo más rápido posible a mercado, para obtener retroalimentación real del cliente o usuario final, para medir ese impacto real, ese valor que nuestro producto o servicio realmente le está entregando, y con esto ajustar lo que sea necesario (pero no solo a nivel equipos o a nivel operativo, sino desde el nivel estratégico). Con esto, se puede crear un continuo alineamiento estratégico. # Fligh Levels (Niveles de vuelo) Finalmente, Klaus Leopold introduce algo que llama el Modelo de Fligh Levels, lo cual describe como "una herramienta que ayuda a visualizar y organizar los distintos tipos de trabajo en una empresa”, desde la estrategia hasta las operaciones. Los tres niveles de vuelo son: ## Nivel 3: Gestión estratégica del Portafolio Una vista a nivel macro de todo lo que sucede en la organización, la estrategia e iniciativas que indican la dirección de la empresa. A este nivel no se tiene tanta definición como para poder ver (y microgestionar) algo tan granular como las actividades operativas. ## Nivel 2: Coordinación El enfoque en este nivel es la coordinación de inicio a fin de las actividades para convertir una idea en valor. Tiene menor visión general que el Nivel 3, pero ve una parte mayor de la fotografía que el Nivel 1. Como habíamos visto, la optimización a nivel equipos no es suficiente, debe de optimizarse también sus interacciones. Aquí es donde se busca optimizar estas interacciones entre equipos. ## Nivel 1: Nivel Operativo Es el nivel de vuelo más a nivel de suelo, a nivel donde los equipos realizan el trabajo diario. El trabajo a nivel equipo debe de ser optimizado (ya si le ponemos nombre, puede ser que los equipos trabajen con Scrum, Kanban, Extreme Programming, o cualquier opción entre los marcos y métodos ágiles existentes… digamos simplemente equipos Lean-Agile. Como habíamos visto, la optimización a nivel equipo es necesaria y se lleva a cabo en este nivel. Es fundamental realizar esto, para poder pasar al Nivel 2 para, digámoslo así: **“Optimizar las interacciones entre equipos optimizados”.** (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01-fligh-levels.webp) Este modelo de Flight Levels está muy interesante y es súper poderoso, definitivo es un tema que trataré de manera específica en un siguiente artículo. Pinky promise 😉 . # Conclusiones La Agilidad Organizacional no puede florecer si la organización está integrada de islas ágiles, es decir, de equipos optimizados que trabajan de manera “ágil-pero-aislada. Las interacciones entre equipos deben de optimizarse también, me gusta decirlo de esta manera: **“Optimizar las interacciones entre equipos optimizados”.** Por esto, menciona Klaus Leopold, la Agilidad Organizacional no tiene que ver con Equipos Ágiles o Equipos Agile… a nivel local un equipo Scrum o Kanban o Extreme Programming… o simplemente un equipo Lean-Agile, puede trabajar muy pero muy bien, pero ¿Cómo estamos como Organización?, Medimos puntos de historia de usuario entregados o elementos de trabajo completados… pero ¿Cómo andamos en métrica como organización? ¡Cuál es nuestro valor entregado y nuestro Tiempo para llegar al mercado? Comencemos por visualizar y gestionar el flujo de valor completo, desde que una idea se genera hasta que es entregado el producto o servicio al cliente o usuario final. **Si el usuario final no es feliz, poco importa que nuestro equipo sea el mejor equipo Scrum o el mejor equipo Kanban de toda la galaxia.** **¿Qué te parece esta aproximación de Agilidad Organizacional?, Me gustaría escuchar qué opinas.** . ## Referencias: • Rethinking Agile: Why Agile teams have nothing to do with Business Agility. Klaus Leopold (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-book-portada.webp) * Todas las imágenes (a partir del punto 1. Hacer visibles las dependencias y gestionarlas), son propiedad de Klaus Leopold y LEANability.
12 de diciembre de 2023
Management 3.0

Formando una cultura de aprendizaje continuo

De acuerdo con un estudio realizado por Forbes a finales de 2022, más del 70% de los profesionales encuestados consideran que carecen de las habilidades necesarias para avanzar con confianza en sus carreras, ¿Sabes qué competencias necesitan desarrollarse en tu equipo? *Imagen de: workbeat.com* . Los equipos no pueden lograr sus objetivos si los integrantes no están capacitados adecuadamente y no cuentan con las habilidades necesarias para realizar su trabajo. La labor de los líderes es contribuir al desarrollo de las competencias de sus equipos. La propuesta de **Management 3.0** es que los equipos deben identificar en qué necesitan ser competentes y cuál es su estado actual, a fin de entender qué necesitan aprender, mejorar y decidir por sí mismos cómo hacerlo (con la ayuda del líder, claro está. No es dejarlos solos al “ahí se va, resuelvan la situación cómo puedan”). Personas que no cuentan con todas las habilidades necesarias para desarrollar su trabajo, o cuando sí cuentan con las habilidades, hay una dependencia altísima de esta persona para realizar determinadas tareas, ¿Te suena familiar?, tristemente esto es un problema muy común, y parece una frase del libro de Gabriel García Márquez que se titula: “Crónica de una muerte anunciada”. En el estudio antes mencionado de Forbes, el 74% de los trabajadores encuestados afirman estar dispuestos a continuar aprendiendo y adquirir nuevas habilidades para seguir siendo empleables, pero indican que sienten una falta de oportunidades en sus lugares de trabajo para desarrollarlo. . # Bueno, que no todo sea catarsis: ¿Qué podemos hacer? Uno de los 6 ejes o vistas de** Management 3.0** aborda este tema: **Desarrollar Competencias**, donde el enfoque es que los líderes deben de fomentar las condiciones para crear un entorno de aprendizaje continuo y contribuir al desarrollo de las competencias de sus equipos. (image: leonel-zapien-lopez-ideas-agilidad-eje-4-management-3.0-agile-team-competency-matrix.webp) . # Matriz de Competencias de Equipo (Team Competency Matrix) Una de las herramientas específicas que propone Management 3.0 en el contexto de Aprendizaje y Competencias, es la “Matriz de Competencias de Equipo” (Team Competency Matrix). El propósito de esta matriz es fomentar la Transparencia: **1. **Primeramente tomar una “fotografía” del estado actual de las diversas competencias que necesita el equipo para realizar su trabajo, y en qué nivel se identifica cada persona (principiante, intermedio o avanzado, por ejemplo). **2. **Tomando el punto anterior como línea base, el siguiente paso es hacer visible las posibles brechas o gaps entre lo requerido y el estado actual. El objetivo es detonar conversaciones para identificar y co-crear accionables sobre cómo se puedan desarrollar aquellas habilidades que sean más críticas o que tengan una mayor brecha. (image: leonel-zapien-lopez-ideas-agilidad-management-3.0-agile-matriz-competencias-equipos-team-competency-matrix.webp) En las columnas superiores de la matriz se colocan los nombres de los miembros del equipo, en las filas (lado Izquierdo), se listan todas las competencias que se requieren. Es importante facilitar una sesión donde los integrantes del equipo conversen. Lo importante es hacer una autoevaluación sincera y realista de cada integrante (no se trata de señalar o exponer a las personas, sino de saber cómo estamos para apoyarnos a salir adelante, como equipo). Esta herramienta es muy poderosa, fomenta y refuerza la transparencia… pero, como decimos acá en México: “¡Mucho ojo!” (lo cual quiere decir que estemos atentos a riesgos o peligros), porque la Matriz de Competencias de Equipo por sí sola no va a solucionar ningún problema, es un recordatorio visible para todos, acerca de las conversaciones que se deben de tener para co-crear una solución. Recordemos que la labor de los líderes es contribuir al desarrollo de las competencias de sus equipos, así que, sin el involucramiento de los líderes, sencillamente esto no tiene razón de ser. . # Los líderes deben de fomentar un entorno de aprendizaje continuo Y hablando de la responsabilidad de los líderes en cuanto a desarrollo de Aprendizaje y Competencias, los líderes deben de fomentar un entorno de aprendizaje continuo, que implica, entre otras cuestiones, brindar a las personas: **1. Tiempo** Una ventana de tiempo, un espacio programado al día o a la semana para que las personas puedan aprender por sí mismas, así como en equipo. Tiempo para investigar, probar, experimentar. Si las personas están “quemadas” en tiempo, es decir, de junta en junta, trabajando hasta noche o fines de semana, o atendiendo emergencias todo el tiempo (acá en México le decimos atendiendo “bomberazos”, mis amigos de Argentina me platican que allá le dicen “ventanazos”)… con todo lo anterior, nunca habrá tiempo para aprender. **2. Recursos** Esto se refiere a brindar a las personas lo necesario para que puedan aprender y desarrollar sus habilidades: Libros, acceso a recursos digitales, formaciones, así como cualquier herramienta que pudieran necesitar. **3. Espacio** Este punto puede obviarse o subestimarse, pero se requiere un espacio (físico o digital) al cual las personas puedan recurrir para estudiar sin interrupciones o compartir y conversar en equipo, que cuente con pizarras, áreas para colaborar, dibujar, conectarse, etcétera. Esto ayuda a fomentar esa especie de rituales que terminan por permearse en la cultura organizacional y moldearla hacia el aprendizaje. . # Organizaciones de Aprendizaje Ahora, ya que toqué el tema de la cultura, cuando el autoaprendizaje y aprendizaje en equipo se asienta en la cultura de la empresa, pueden comenzar a dar los primeros pasos al siguiente nivel Master Jedi: **Organizaciones de aprendizaje**, un término acuñado por **Peter Senge en su libro La Quinta Disciplina** (The Fifth Discipline): “Las organizaciones de aprendizaje son organizaciones donde las personas expanden continuamente su capacidad para crear los resultados deseados, donde se nutren nuevos patrones de pensamiento, donde la aspiración colectiva se libera y las personas continuamente aprenden juntas a ver el todo.” **Peter Senge, La Quinta Disciplina** El tema de organizaciones de aprendizaje es por sí mismo un tema muy amplio profundo, como para abordarse en un artículo dedicado, pero, de entrada y para dar un poco más de contexto, me gustaría mencionar algunas características de este tipo de organizaciones para ver cómo idénticas a tu organización actual: **1. **Proporcionan oportunidades de aprendizaje continuo. **2. **Se apalancan en el aprendizaje para alcanzar sus metas. **3. **Fomentan la investigación y el diálogo, haciendo que sea seguro para las personas compartir abiertamente y asumir riesgos. **4. **Conocen e interactúan continuamente con su entorno, para continuar aprendiendo. . # Conclusiones Los equipos no pueden lograr sus objetivos si los integrantes no están capacitados ni cuentan con las habilidades necesarias para realizar su trabajo. La labor de los líderes es contribuir al desarrollo de las competencias de sus equipos ¿Cómo?, los líderes fomentan las condiciones necesarias, son los responsables de colocar la semilla de una cultura de aprendizaje. **Seamos ese tipo de líderes que nutran una cultura de aprendizaje, ese tipo de líderes nuestros equipos necesitan, para avanzar todos juntos, hacia una Organización de Aprendizaje. Todos ganamos** 😊 ¿Conocías la Matriz de Competencias de Equipo de Management 3.0? ¿Crees que te aportaría en tu equipo? ¿Consideras que la cultura de tu organización les ayuda a avanzar hacia (o quizá ya está en ese nivel de) Organizaciones de Aprendizaje? **Me gustaría escuchar qué opinas.** . ### Referencias: • Management 3.0: Leading agile developers, developing agile leaders (Jurgen Appelo). • La quinta disciplina: Cómo impulsar el aprendizaje en la organización inteligente (Peter Senge). • (link: https://www.forbesuruguay.com/liderazgo/sueldos-2024-proyectan-empresas-n43719 text: Cómo los CEO pueden empoderar a su equipo mediante la creación de una cultura de aprendizaje continuo) (Valentina Drofa, Forbes).
15 de noviembre de 2023
Scrum

Quiero iniciarme en el mundo de Scrum y existen 12’457,925 certificaciones… ¿Por dónde comienzo?

En un océano rojo de certificaciones, últimamente una pregunta que he escuchado mucho es: Quiero iniciar en el mundo de Scrum, quiero certificarme, pero ¿Por dónde comienzo? Pffff, pues la respuesta en estos casos siempre es: “**Depende**”. Y precisamente por ese “Depende”, aquí te comparto una **comparativa sobre algunas de las diversas casas certificadoras**, poniendo como suelo común para todas las mismas variables de comparación. **Primeramente: **Tooodas las entidades certificadoras ofrecen más o menos lo mismo: **Un curso de entre 12 y 20 horas + 2 intentos de examen**. Así que, de entrada, esto no es diferenciador sobre una decisión de dónde certificarse. Hay muchas opciones de entidades certificadoras: **Scrum Alliance, Scrum.org, Scrum Inc., AIBES, CertiProf, SCRUMstudy, inclusive también el PMI **tiene relativamente poco que ofrece su certificación de Scrum Master! Hay muchas opciones de entidades certificadoras: Unas más caras, unas más baratas, unas con mayor “prestigio” debido a que son respaldadas por algunos rockstars del mundo de la Agilidad. Pero de entrada **siempre he dicho que llegar a la conclusión que alguien es un Scrum Master "mejor preparado" porque se certificó con una entidad o con otra, es como decir que alguien egresado de una universidad privada "es mejor profesional" que alguien de una universidad pública**, no demerito en absoluto los planes de estudio ni los controles ni los recursos, pero en última instancia **depende de la persona** qué tanto lo aprovecha, depende de qué tantas ganas le ponga el alumno, no de la institución. El segundo punto antes de comenzar (y no menos importante), es que **una certificación no es garantía de experiencia,** es una evidencia de una acreditación, he conocido excelentes profesionales que no contaban con ninguna certificación, así como profesionales que contaban con una o varias certificaciones, y su nivel de desempeño era independiente de todo lo que había gastado. **De nueva cuenta: depende de la persona.** Con los dos puntos anteriores en mente, ahora sí, aquí te comparto esta comparativa objetiva entre diversas casas certificadoras, poniendo como suelo común las siguientes variables: • Si es mandatorio tomar un curso con ellos para poder presentar su examen de certificación. • Ofrece la opción de presentar exámenes sin tomar curso con ellos (esta opción es realmente complementaria a la anterior, pero lo separo para efecto de asentar y quede más claro). • Vigencia de sus certificaciones, ya que algunas no expiran y algunas necesitas estar renovándolas (con su correspondiente fee o cuota, además de algunos requisitos, de renovación). • Si cuenta o no con un path avanzado en el camino del Scrum Master. • Agrego una opción que pudiera parece ser obvia, pero en realidad es un gran diferenciador: Si se basa en **La Guía Scrum** o no. Como contexto te menciono que **La Guía Scrum** es escrita por sus co-creadores Jeff Sutherland y Ken Schwaber, por lo tanto, es **la fuente original de Scrum**, de aquí la importancia de que sepas si una certificación está basada en esta guía o no. • Idioma de sus exámenes. • Y sin entrar en detalles del rango de cuántos billetes verdes cuesta cada una, mejor de manera sencilla menciono una escala de precios: Alta, media o baja, para simplicidad en la comparación. ¿Qué te parece la idea, estás listo? Comencemos entonces: . # Scrum Alliance (image: scrumalliance.webp) • **Curso para presentar exámenes: **Obligatorio • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** No • **Vigencia de sus certificaciones:** 3 años • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes: **Inglés, español, etc. • **Escala de precios: **Alta La puse primero porque es la organización que más tiempo lleva activa. Fue creada por Ken Schwaber (uno de los co-creadores de Scrum), aunque hace ya varios años que se salió para crear su propia casa certificadora. Así mismo, varios de los rockstars de la Agilidad y firmantes del Manifiesto Ágil han colaborado aquí. Cuenta con 3 niveles de especialización: 1. **Certified ScrumMaster (CSM): **Nivel I 2. **Advance Certified ScrumMaster (A-CSM): **Nivel II 3. **Certified Scrum Professional - ScrumMaster (CSP-SM):** Nivel III Cuando hice el examen con ellos (hace varios años ya), era un examen de 35 preguntas a responder, tengo entendido que ahora lo incrementaron a 50 preguntas en 1 hora. La única manera de obtener una certificación de Scrum Alliance es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. Sus certificaciones se renuevan cada 3 años, y para hacerlo debes de realizar una de dos cosas: 1. Pagar un fee o cuota de renovación + haber sumado una serie de puntos que Scrum Alliance llama SEUs (Scrum Education Units), que puedes obtener de diversas maneras: Estudiando o actualizándote en el tema, como tomando cursos o webinars, haciendo voluntariado, etc. Cada hora de un curso que tomes o cada hora de voluntariado que realices equivale a 1 SEU, y dependiendo de la certificación, puedes requerir acreditar entre 20 y 30 SEUs (ojo: Si acumulas más certificaciones con ellos, vas a necesitar más SEUs, pues a más certificaciones solicitan más SEUs para renovar). 2. La segunda opción es, si ya tienes una certificación y tomas otro curso con ellos y te certificas, automáticamente se renueva el periodo de tu primera certificación (en este caso la extensión se vigencia se hace solo por 2 años más). Como dato cultural, la certificación Certified ScrumMaster (CSM) fue la primera certificación de Scrum en el mundo en salir al mercado. Aunque de eso, como decimos acá en México, ya llovió. . # Scrum.org (image: scrumorg.webp) • **Curso para presentar exámenes: **Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones:** Sin expiración • **Cuenta con path avanzado:** Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes:** Solo en inglés • **Escala de precios:** Alta Surgió algunos años después que Scrum Alliance, Ken Schwaber (co-fundador de Scrum) después de dejar Scrum Alliance respalda ahora esta casa certificadora, así que el material y contenido tiene ese aval de alineación a La Guía Scrum. Cuenta con 3 niveles de especialización: 1. **Professional Scrum Master I (PSM I):** Nivel I 2. **Professional Scrum Master II (PSM II): **Nivel II 3. **Professional Scrum Master III (PSM III):** Nivel III Aquí una observación: Scrum.org ofrece este path de especialización como Scrum Master, pero cuenta con otras opciones para avanzar en el camino de Scrum, como por ejemplo profundizar en Nexus, un marco para escalar Scrum. Cuando hice el examen con ellos, era un examen de 80 preguntas a responder en 1 hora. Otro punto: Sus exámenes los ofrece solo en idioma inglés (claro puedes utilizar un traductor, pero de entrada para que lo consideres). Sus certificaciones no expiran, eso es algo importante a poner en la balanza al momento de evaluar tus opciones, considerando que esta casa certificadora con precios altos. Una manera de obtener una certificación de Scrum.org es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente mucho más bajo que si tomas el curso, aquí ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. . # Scrum Inc. (image: scruminc.webp) • **Curso para presentar exámenes:** Obligatorio • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** No • **Vigencia de sus certificaciones: **Anual • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum:** Sí • **Idiomas de sus exámenes:** Inglés, español, etc. •** Escala de precios: **Media-Alta Esta casa certificadora es de las más recientes en creación, pero no en experiencia ya que fue fundada por Jeff Sutherland (el otro co-creador de Scrum), así que el material y contenido tiene ese aval de alineación a La Guía Scrum. La única manera de obtener una certificación de Scrum Inc. es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. Su certificación es: • **Registered Scrum Master (RSM).** Aquí una observación: Scrum Inc. No ofrece un path de especialización como Scrum Alliance o Scrum.org directamente para el Scrum Master, pero cuenta con otras opciones para avanzar en el camino de Scrum, como por ejemplo profundizar en Scrum@Scale, un marco para escalar Scrum. En cuanto al tema de las renovaciones, sus certificaciones se deben de renovar cada año, y para hacerlo ofrecen 2 opciones: • Pagar un fee o cuota de renovación anual, y renovar tu certificación cada año. • Pagar un fee o cuota un tanto mayor que la opción anual, pero es un pago de una sola ocasión y con esto extiendes tu certificación a que ya no expire. . # AIBES (image: aibes.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones: **Sin expiración • **Cuenta con path avanzado: **No • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes: **Solo en español •** Escala de precios: **Media Esta casa certificadora es la Asociación Iberoamericana de Scrum (AIBES), también es de relativa reciente en creación. Como su nombre lo indica, de entrada, su sitio web y recurso son en idioma español, algo que no sucede con otras entidades certificadoras. Su certificación es: • **Official Scrum Master Certification (OSMC).** Una manera de obtener una certificación de AIBES es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente mucho más bajo que si tomas el curso, aquí al igual que con otras casas certificadoras que ofrecen este esquema de vouchers para examen, ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. Como nota adicional, AIBES ofrece también una certificación de fundamentos en Scrum, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Va que va? . # CertiProf (image: certiprof.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones:** Sin expiración • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes:** Inglés, español, etc. •** Escala de precios:** Baja Esta casa certificadora también es de relativa reciente en creación, ofrece diversas certificaciones, entre las cuales están las de Scrum. Cuenta con 2 niveles de especialización: 1. **Scrum Master Professional Certificate (SMPC):** Nivel I 2. **Scrum Advanced Professional Certificate (SAPC): **Nivel II Aquí una observación: CertiProf ofrece este path de especialización, solo que no es un nivel exclusivo de Scrum Master, ya que puedes llegar a Scrum Advanced Professional Certificate (SAPC) por el camino de Scrum Master o de Product Owner, contar con una certificación de Scrum Master o Product Owner de cualquier otra entidad certificadora es el prerrequisito para aplicar para SAPC + presentar un examen y aprobar un examen. Una manera de obtener una certificación de CertiProf es tomando un curso con uno de sus facilitadores, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente más bajo que si tomas el curso, aquí al igual que con otras casas certificadoras que ofrecen este esquema de vouchers para examen, ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. El examen de Scrum Master de CertiProf consta de 40 preguntas a realizarse en 60 minutos. Como nota adicional, CertiProf ofrece también una certificación de fundamentos en Scrum que es gratuita, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Okidoki? . # SCRUMstudy (image: scrumstudy.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** Sí • **Vigencia de sus certificaciones:** 3 años • **Cuenta con path avanzado:** Sí • **Basada en La Guía Scrum: **No • **Escala de precios: **Media Esta entidad certificadora es de relativa reciente creación, aunque tiene ya algunos años. Ofrece no solo certificaciones en Scrum, sino también en otras áreas. Cuenta con 3 niveles de especialización: 1. **Scrum Master Certificate (SMC):** Nivel I 2. **Scaled Scrum Master Certificate (SSMC):** Nivel II 3. **Expert Scrum Master Certificate (ESMC):** Nivel III Aquí una observación: SCRUMstudy ofrece este path de especialización, pero el nivel siguiente que mencionan en su sitio web, Scaled Scrum Master Certified, es para escalar Scrum, y para hablar de lo mismo, poniendo en contexto manzanas con manzanas, si hablamos de escalar Scrum, deberíamos compararlo con Nexus de Scrum.org o Scrum@Scale de Scrum Inc., pero este es el path que ofrecen. Así mismo, el nivel de Expert Scrum Master Certificate (ESMC) no es un nivel exclusivo de Scrum Master, ya que puedes llegar por el camino de Scrum Master o de Product Owner, dentro de sus certificaciones. El examen para Scrum Master Certificate consta de 100 preguntas a responder en 2 horas. Una manera de obtener una certificación de SCRUMstudy es tomando un curso con uno de sus facilitadores, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. Aquí ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. Un punto para tu consideración: SCRUMstudy ha creado algo que se llaman SBOK (Scrum Body of Knowledge), la cual es su guía para la implementación de Scrum, en este sentido, es la única entidad certificadora que se basa en el SBOK y no en La Guía Scrum para su contenido y exámenes. No menciono que esté bien o mal (ni todo lo contrario 😉), solo menciono objetivamente que SCRUMStudy es la única que se basa en el SBOK y todos los demás en La Guía Scrum (además de que el SBOK tiene grandes diferencias de fondo contra La Guía Scrum), entonces revisa muy bien el contenido antes de tomar una decisión. Sus certificaciones se renuevan cada 3 años, y para hacerlo debes de: • Realizar un examen de recertificación (Consta de la mitad de preguntas que el examen de certificación inicial). Tomar de nueva cuenta un curso con ellos es opcional, acreditar el examen de recertificación es el objetivo, por lo cual puedes pagar directamente tu voucher para presentarlo, cualquiera de las dos opciones. Como nota adicional, SCRUMstudy ofrece también una certificación de fundamentos en Scrum que es gratuita, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Va que va? . # Scrum Master del PMI y SAFe Aquí abro un paréntesis y menciono tanto al PMI (Project Management Institute), como SAFe (Scaled Agile Framework) porque también ofrecen certificaciones de Scrum Master, solo que los menciono como un adendum porque su certificación es particular para su contexto, ¿A qué me refiero con esto? Comencemos con SAFe, que sacó al mercado su certificación de Scrum Master primero que el PMI. . # SAFe (Scaled Agile Framework) (image: safe.webp) La certificación de SAFe se llama: • **SAFe Scrum Master** Es el rol de Scrum Master dentro del contexto de SAFe, es decir, profundizan en cuestiones que solo son aplicables a este modelo de escalado. Habla por lo tanto de incrementos de programa (PI), roles de SAFe, entre otras cuestiones. El examen para obtener la certificación SAFe Scrum Master consta de 45 preguntas a realizar en 90 minutos, y esta certificación tiene un año de vigencia, para renovarla es necesario un fee o cuota de renovación. . # PMI (Project Management Institute) (image: pmi.webp) La certificación del PMI se llama: • **Disciplined Agile Scrum Master (DASM)** Es el rol de Scrum Master dentro del contexto de Disciplined Agile del PMI. Discipline Agile incluye conceptos de Scrum, pero adicionalmente de Kanban, y hasta de SAFe, entre otros. Por lo tanto, el rol es más amplio, y toma los principios de Agile y Scrum, en conjunto con otras herramientas. Tiene un path de especialización: • **Disciplined Agile Scrum Master (DASM)** • **Disciplined Agile Senior Scrum Master (DASSM)** Después de las certificaciones anteriores, el path de especialización continúa, pero ya va enfocado en temas de Agile Coaching o Flujos de valor (Vale Stream). La certificación DASM tiene un año de vigencia, y para renovarla es un proceso similar a cualquier otra certificación del PMI: Reunir una cantidad determinada de PDUs (Professional Development Unit) que reúnes a través de horas de formación, cursos o webinars, voluntariado, etc. + un fee o cuota de renovación. Como nota adicional, el PMI cuenta además con la certificación PMI-ACP (Project Management Institute – Agile Certified Practitioner), lo menciono para que lo tengas presente, pero queda fuera del alcance de este artículo porque no es específica de Scrum. . ## Pfffff… toooodo eso!!! Este es (y por mucho) el artículo más largo que he escrito hasta el momento, pero creo que el tema lo valía y finalmente** la idea es que cuentes con la información necesaria para que puedas tomar una decisión informada. Al menos, esa es mi intención de todo corazón :)** Me gustaría cerrar reiterando lo que mencioné al inicio de este (sumamente largo) artículo, de que una certificación no es garantía de experiencia, sino algo que puede ser un complemento a la misma, y que un Scrum Master "mejor preparado" es indistinto de la entidad certificadora donde se haya certificado, es como decir que alguien egresado de una universidad privada "es mejor profesional" que alguien de una universidad pública, no demerito en absoluto los planes de estudio ni los controles ni los recursos, pero **en última instancia todo depende de la persona** qué tanto lo aprovecha, depende de qué tantas ganas le ponga el alumno, **no de la institución.** **Cuéntame, ¿Qué te pareció esta guía de certificaciones de Scrum Master?, ¿Te ayudó aclarar tus dudas o te han surgido algunas nuevas?** ** Cualquier duda o comentario, quedo a un clic de distancia.**
31 de octubre de 2023
Change Management

Gestión del Cambio Organizacional: Modelo ADKAR

De acuerdo con diversos estudios, **más del 70% de las iniciativas de cambio fracasan** estruendosamente. Las razones principales de este fracaso van desde la resistencia de los empleados hasta la falta de un modelo de liderazgo. En resumen… las iniciativas de cambio fracasan debido que no consideraron y obviaron cuestiones de lo más complejo e importante de las organizaciones:** Las personas**. . # Primero lo primero: ¿Qué es un cambio organizacional? Cambio organizacional es el proceso en el cual una empresa modifica un elemento importante de su organización, por ejemplo: Un modelo nuevo de negocio, un cambio tecnológico que modifica la forma de operar, o sus procesos internos. Estos cambios organizacionales tienen un impacto en la organización ya que pueden implicar cambios en los objetivos de la empresa, en los productos o servicios que ofrecen, o en sus operaciones… pero lo realmente complejo de estos cambios es que implican un cambio en las personas, en la manera en que venían trabajando. Así, cuando en tu organización ha habido alguna reestructuración que modifica o crea un departamento o división nueva, modifican su modelo de negocio, implementan una nueva forma de trabajar (por ejemplo, la adopción la Agilidad o Agilismo a través de Scrum, Kanban, Management 3.0, entre otros, o la implementación de programas de Mejora Continua, 5s, Manufactura Esbelta, etcétera), cuando ha habido implementaciones de nuevas herramientas tecnológicas como sistemas ERP, herramientas de colaboración en la nube, automatizaciones, o cualquier otro cambio tecnológico… todos estos son ejemplos de cambios organizacionales. ¿Te suena familiar esta situación? . # Importancia de la Gestión del Cambio La gestión del cambio es la aplicación de un proceso estructurado y un conjunto de herramientas para abordar el lado humano de los cambios, se centra en las personas, en cómo ayudarlas a no temer, reducir la resistencia, a participar, y adoptar un cambio en su trabajo diario. . # El cambio ocurre una persona a la vez Un cambio organizacional, de cualquier tipo que este sea, sucede una persona a la vez. Esto es debido a que u**n cambio en toda la organización solo ocurre cuando las diversas personas, una a una, cambian la manera de realizar su trabajo, de acuerdo con cada iniciativa de cambio**. Existen varios modelos para el cambio, aquí conversamos sobre el modelo El **Modelo ADKAR**®, desarrollado por Prosci®, el cual facilita el cambio a nivel de personas, para permearse a toda la organización. ADKAR es un acrónimo, cada letra corresponde a uno de los 5 elementos o bloques que conforman este modelo. Cada uno de estos bloques debe de haberse llevado a cabo para que un cambio pueda ser realizado. Estos cinco elementos o bloques son: 1.** Awareness (Conciencia)** 2. **Desire (Deseo)** 3. **Knowledge (Conocimiento)** 4. **Ability (Capacidad o Habilidad)** 5. **Reinforcement (Reforzamiento)** Aquí vemos a detalle cada uno de estos elementos, con algunos ejemplos de cuando ha sido llevar esto con diversos equipos. . # Awareness (Conciencia) Es el primer paso para habilitar un cambio: La toma de conciencia de una persona sobre el entendimiento sobre la necesidad de cambiar y por qué es importante. Con esto se responde a la pregunta natural de cualquier persona: “¿Por qué?” Para fomentar la toma de conciencia en las personas sobre la necesidad del cambio, las conversaciones deben de considerar responder cuestiones como: • ¿Cuál es la naturaleza del cambio y cómo este cambio se alinea con la visión de la organización? • ¿Por qué este cambio se está implementando y cuáles son los riesgos de no cambiar? • ¿Cómo el cambio impactará en mi rol, equipo, departamento, división, y en toda la organización? • ¿Qué beneficio hay en este cambio para mí? **Ejemplo:** Si a un equipo le imponen una nueva forma de trabajar, por ejemplo, implementando Scrum y simplemente les notifican que comenzarán con capacitación para arrancar con esta iniciativa… Surge mucha incertidumbre y las personas no se sentirán incluidas en el cambio por no haber sido partícipes de la iniciativa desde el inicio. Crear conciencia tiene que ver con responder ¿Por qué es necesario cambiar? ¿Qué riesgos pueden suceder si continuamos trabajando de la misma manera? (image: awareness.webp) . # Desire (Deseo) Es la voluntad para soportar y comprometerse con el cambio. Crear conciencia no quiere decir que una persona quiera cambiar. Respecto a generar el deseo de cambiar, es mucho más fácil decirlo que hacerlo, porque no es algo que esté en nuestro control (recordemos que, como personas, somos complejas, por lo tanto, no existe una receta de cocina la cual podamos seguir al pie de la letra para lograrlo, pero la buena noticia es que existen muchas opciones para maximizar la probabilidad de que esto suceda de manera satisfactoria). Para maximizar la probabilidad de fomentar el deseo, se deben de tomar en cuenta algunos factores, como: • La naturaleza del cambio y cómo impacta a la persona (¿Qué beneficio hay en este cambio para mí?), si no hay un beneficio, una persona no se querrá subir al barco. • Contexto organizacional. Esto es, la historia particular de la empresa en iniciativas de cambio anteriores: ¿Han sido exitosas?, ¿Por qué han fallado?, así como la cultura organizacional respecto a este tipo de cambios. • La situación personal de cada individuo. • Motivadores de las personas. Lo que buscamos es identificar incentivar esos motivadores intrínsecos individuales. **Ejemplo:** Continuando con el equipo que va a comenzar a trabajar con Scrum, es necesario conversar con el equipo, escucharlos y aclarar sus dudas. ¿Por qué este cambio es diferente de otros? (especialmente si otras iniciativas anteriores han fallado). ¿Qué se va a hacer diferente para que este cambio funcione? Escuchar a los miembros ayuda a identificar elementos motivadores que pueden detonar la aceptación del cambio. (image: desire.webp) . # Knowledge (Conocimiento) Considera todo lo necesario para que las personas obtengan el conocimiento requerido para ejecutar el cambio: Información, entrenamientos o educación que sea necesaria para que las personas conozcan a detalle todo lo requerido para el cambio: Procesos, Conductas, herramientas, sistemas, habilidades, técnicas, entre otras cuestiones. Diversos factores influyen en difundir conocimiento de manera satisfactoria, algunos importantes son: • La base de conocimiento actual de cada persona. ¿Qué tan grande es la brecha o gap actual entre el nivel conocimiento de una persona contra el requerido para el cambio? • La disposición individual para el nuevo conocimiento. Tiene que ver con la capacidad de cada persona para aprender. • La disponibilidad de recursos para capacitar al personal. Tiene que ver los fondos para contratar entrenamiento, así como la disponibilidad de expertos en el tema, disponibilidad de material adecuado (no solo en contenido, también el idioma, por ejemplo). **Ejemplo:** En este escenario de ejemplo, lo siguiente es llevar a cabo los programas de entrenamiento que el equipo necesite para los diferentes roles: Scrum Master, Desarrollador, Product Owner, así como para los interesados o stakeholders. (image: knowledge.webp) . # Ability (Capacidad o Habilidad) El conocer el tema (obtenido durante el bloque anterior) no lleva necesariamente a tener la capacidad o habilidad. Este cuarto bloque es la realización o ejecución del cambio, es decir, el conocimiento desarrollado en el bloque anterior se lleva a la acción, las personas aprenden a desarrollar la habilidad necesaria a través la práctica. Diversos factores influyen en que las personas alcancen la habilidad de manera satisfactoria, algunos importantes son: • Barreras psicológicas, habilidades físicas y capacidad intelectual. Dependiendo del tipo de cambio, algunas personas pueden tener ciertas dificultades o requerir mayor acompañamiento, para poder desarrollar estas habilidades. • Tiempo disponible para desarrollar la habilidad necesaria (¿Se cuenta con unos pocos días o estamos hablando de meses?) • Disponibilidad de recursos para soportar el desarrollo de la nueva habilidad (Por ejemplo: herramientas, expertos que proporcionen acompañamiento). **Ejemplo:** Todo el equipo ya tiene el entrenamiento necesario, ahora deben de comenzar a asentar el conocimiento practicando. Es importantísimo un ambiente seguro y de respaldo para la experimentación, sin consecuencias negativas por probar. Se debe de contar con acompañamiento para el equipo, y considerarse la curva de aprendizaje. (image: ability.webp) . # Reinforcement (Reforzamiento) Es el reforzamiento a través de factores internos y externos para hacer que el cambio sea sostenible y se mantenga a lo largo del tiempo, evitando regresar a la anterior forma de trabajar. Varios factores influyen en que las personas alcancen la habilidad de manera satisfactoria, algunos importantes son: • El grado en que el reforzamiento sea significativo para las personas impactadas por el cambio. Tiene que ver con reconocimientos o recompensas para las personas. • La asociación del reforzamiento con el progreso del cambio y los beneficios actuales demostrados (¿El cambio trajo los beneficios reales que se dijo que se iban a obtener?). • Ausencia de consecuencias negativas por mostrar la conducta esperada para el cambio. **Ejemplo:** El equipo ya está usando Scrum, entregando incrementos de producto cada Sprint. Lo que se busca es que no se regrese a los modelos anteriores, que el cambio sea de fondo y la manera de trabajar no implique usar “Scrum-por-encimita” o trabajando de la manera anterior pero ahora los roles se llaman de acuerdo con La Guía Scrum. (image: reinforce.webp) . # Conclusiones La resistencia al cambio es natural y en el contexto organizacional no es la excepción. Más de las 70% de las iniciativas de cambio fallan, por esto es importante gestionar adecuadamente el cambio organizacional al nivel más importante: Desde las personas. **El lado humano de cualquier cambio no es el lado suave, sino es el lado más duro de un cambio**. Por esto se debe de gestionar el lado humano de los esfuerzos organizacionales para maximizar los cambios exitosos. El modelo ADKAR proporciona un marco que facilita el cambio a nivel de personas, para permearse a toda la organización. Y otra cosa muuuy importante:** El Modelo ADKAR puede aplicarse no solo para cambios en el ámbito organizacional, sino en cualquier tipo de contexto: Hasta en el personal,** ¿Te suena la idea? Si te ha interesado el tema, **(link: https://leonelzapien.com/blog/change-management-3-0 text: aquí puedes leer otro artículo que escribí sobre Gestión del Cambio desde la perspectiva del Modelo de Change Management 3.0)**, de Jurgen Appelo, que incorpora también el modelo ADKAR. **¿Cuál ha sido tu experiencia con los cambios? ** . **Referencia:** ADKAR: A model for change in business, government and our community. Jeffrey M. Hiatt
11 de octubre de 2023
Kanban

No todo el trabajo es siempre una urgencia

Debemos optimizar la capacidad: Kanban propone un enfoque para evaluar las prioridades de los elementos de trabajo. Esto se llama Clases de Servicio (CoS en inglés, Class of Service). Imagen de: interhelpambulancia.com . # Tenemos capacidad finita, se necesitan Clases de Servicio **Clases de Servicio (CoS)**, es una manera de **clasificar el trabajo** para proporcionar **niveles de atención aceptables** (y consecuentemente de satisfacción al cliente) a un costo económico óptimo, es decir, como no podemos atender todo porque la capacidad es finita, se define **qué trabajo se va a atender primero en base a su impacto y prioridad o urgencia**. Se basa en que podemos estar trabajando en una tarea y, si surge una que tiene mayor impacto o urgencia, necesitamos dejar de lado la tarea no urgente, para atender la de urgencia máxima, pero esto de manera ordenada:** con transparencia y basados en políticas **claras para todos. Un punto importante es que estas clases de servicio deben de definirse en base a su impacto de negocio, y cada clase representa un determinado compromiso con el cliente. David J. Anderson, creador del Método Kanban, propone 4 clases de servicio, pero aclara que son solo una guía y puedes definir las que consideres de acuerdo con el contexto de tu equipo. **Aquí te comparto las 4 clases de servicio que propone el Método Kanban:** . # Estándar (Standard) Este es (o debería de ser) la mayoría del trabajo que un equipo realiza, tareas regulares. Deben atenderse en orden de llegada, primero en entrar primero en salir (FIFO, por sus siglas en inglés Fist Input First Ourput), o algún mecanismo acordado para ello. Este trabajo es importante y no es urgente. (image: cos-standard-cool.webp) . # Expedito (Expedite) Tiene la máxima prioridad y debe de atenderse inmediatamente. Es una urgencia, y de manera normal solo debería de existir un elemento de esta clase a la vez (en progreso). Por ser una emergencia, este tipo de clase debe moverse rápidamente a través del flujo de trabajo, y por lo tanto puede ser ingresado a un sistema Kanban (debe de ser atendido) incluso si se ha alcanzado el límite de WIP (es el único momento en que un límite de WIP puede violarse). (image: cos-expedite-cool.webp) **Ejemplos **de elementos de trabajo expeditos: • Defectos o bugs que surgen en producción (dependiendo de su impacto, claro está). • Problemas que causen que una línea de producción se detenga. • Elementos que impactan a un cliente o usuario final, y puede generar una experiencia negativa. • Situaciones que detienen algún proceso de negocio. • Cumplimientos regulatorios o normativos (aquí una nota, ya que depende de la fecha de este cumplimiento, como se menciona en el siguiente elemento de trabajo: Fecha Fija). • Incidentes particulares, vulnerabilidades de seguridad, etc. Es importante ver el contexto de cada equipo, por ejemplo: ¿Cuántas “urgencias” surgen que el equipo debe de atender? Si surge urgencia tras urgencia, si el equipo vive apagando incendio tras incendio, es importante levantar la pregunta de lo que es **“verdaderamente-de-veras-de-veras-urgente”**. Hay una cita que me hace mucho sentido para estos casos: “**Cuando todo es urgente, entonces nada es urgente”**, es decir, la naturaleza de una urgencia es que es algo atípica y especial, no todo el trabajo regular es una urgencia. **Me gusta esta analogía:** Si pasa una ambulancia por la avenida en la que vamos manejando, entendemos que es una urgencia, y le cedemos el paso. Pero ¿Qué pasaría si todos los coches que van por la avenida trajeran una sirena de ambulancia?, ¿Podemos darles el paso a todos? O una de dos: o ninguno es una urgencia real, o ha ocurrido algo verdaderamente atípico y catastrófico (por ejemplo, ha iniciado un apocalipsis zombi y por eso todos quieren huir). Debemos de tomar en cuenta que el atender un elemento expedito realmente tiene un impacto, genera retraso en entregas de otras tareas (por ejemplo, puede llegar a suceder que un trabajo que se estaba realizando y se dejó de lado de hacer para atender una urgencia, se termine convirtiendo a su vez en una urgencia). Por lo tanto, **no deben de tomarse a la ligera**. . # Fecha fija (Fixed Delivery Date) Este debe ser entregado antes de una determinada fecha. Puede que no sea urgente al momento de realizarse, pero tiene un costo o impacto alto en caso de que no sea completado antes de la fecha determinada (por eso en la gráfica se ve que el impacto se incrementa, se vuelve una línea vertical, esto es cuando la fecha de compromiso ha llegado y no se ha realizado o completado esta tarea). (image: cos-fixed-date-cool.webp) **Algunos ejemplos** de este tipo de elementos podrían ser: • Cumplimientos regulatorios o normativos: Pago de impuestos, renovación de licencias, pago de nóminas y/o proveedores, entre otros. • Fechas especiales de lanzamiento de productos: Un producto o cierta promoción que debe de salir al mercado en una fecha específica, como navidad, día de acción de gracias, día de Star Wars (sí existe, millones de fans alrededor de la galaxia lo celebramos el 4 de mayo. True story!), día del amor y de la amistad, entre otros. • Hitos o milestones importantes de un proyecto. • Etcétera. **Si el trabajo no se completa en la fecha y forma indicada, este elemento puede convertirse en uno de la mayor urgencia (expedito)**. . # Intangible Es trabajo que es importante realizarse pues aporta un beneficio o mejora para el equipo u organización, pero por lo general no tiene un costo de retraso o impacto visible o “tangible”. La realidad es que, aunque es importante, por lo general se pospone su realización porque en el día a día surgen elementos con mayor “urgencia”. (image: cos-intangible-cool.webp) **Ejemplos **de esta clase de servicio pueden ser: • Realizar automatizaciones para hacer más rápido y eficiente algún proceso manual. • Refactorización / resolver Deuda técnica. • Rediseño de algún proceso o forma de trabajo. • Ciertos tipos de mantenimientos preventivos. • Implementar mejoras de cualquier tipo (investigar, hacer experimentos, pruebas de concepto, etc.) ¿Te ha sucedido que existe alguna tarea que periódicamente requiere mucho de tu tiempo, sabes que es necesario darte un espacio para analizar y automatizar o mejorar la forma en que se realiza, precisamente para que te tome menos tiempo y sea realizado de manera más eficiente… pero sencillamente no tienes tiempo para hacerlo? (Si es así, no estás solo o sola, a millones nos pasa de repente en la vorágine del mundo actual ☹). Este es precisamente un elemento de trabajo Intangible. . # Transparencia: No nos olvidemos de las Políticas Ahora, como mencionaba anteriormente, estas clases de servicio son solo una guía que propone **Kanban**, el primer paso es siempre identificar las clases de servicio de acuerdo al equipo/organización y su contexto. Lo siguiente es definir políticas para cada clase de servicio (esto continúa fomentando esta transparencia que hemos venido mencionando, así como la autogestión para que los equipos puedan decidir cómo atender cada elemento de trabajo). Y parar no hacer este artículo tan largo, aquí algunas ideas de políticas para clases de servicio, que puedes ajustar al contexto de tu equipo: 1. Clase Expedito: Utilizará tarjetas rojas. 2. Clase Intangible: Utilizará tarjetas verdes. 3. Solo puede haber un elemento Expedito a la vez. 4. Los elementos Estándar se atenderán conforme vayan llegando, primero en entrar – primero en salir (FIFO). 5. Acuerdos de niveles de servicio para cada tipo de elemento de trabajo. 6. Entre otras. . # Conclusiones Las clases de servicio ofrecen una manera transparente para **optimizar la capacidad** y, consecuentemente, la **satisfacción del cliente**. El impacto desde la perspectiva de negocio debe de ser siempre tomado en cuenta al momento de definir las clases de servicio en el contexto de tu equipo. Finalmente, recordemos que nada está escrito en piedra (o en adamantium), las clases de servicio y las políticas pueden evolucionar a lo largo del tiempo. En este sentido, el enfoque experimental es súper poderoso: Siempre inspeccionemos cómo nos está funcionando en el contexto de nuestros equipos, y adaptemos en consecuencia. ¿Qué opinas de las clases de servicio? ¿identificaste alguna o algunas que con las que ya trabajan en tu equipo, pero que les llaman de otra manera? . **Referencia:** Kanban: Successful evolutionary change for your technology business. David J. Anderson .
12 de septiembre de 2023

El bloc de notas de un Agilista Jedi

Change Management, Management 3.0

El "Método Mojito" en Gestión del Cambio: Change Management 3.0

¡No te pierdas los artículos más recientes!

Lean

Esto es Lean

Scrum

Antipatrones de Scrum: Scrum but

MVP, Product Management, Innovación

Innovación & MVP - Diseñar y probar hipótesis de negocio

Product Management, MVP, Innovación

El Método Lean Startup & Producto Mínimo Viable (MVP)

OKRs

Objetivos y Resultados Clave (OKRs) para crear enfoque y alineación

Agile, Agilidad, Agilismo

A 23 años del nacimiento del Manifiesto Ágil

Agilidad vida cotidiana

Poniendo foco en lo que importa en nuestro día a día (y en nuestra vida): El Método Bullet Journal

Agilidad

Reconsiderando la Agilidad Organizacional

Management 3.0

Formando una cultura de aprendizaje continuo

Scrum

Quiero iniciarme en el mundo de Scrum y existen 12’457,925 certificaciones… ¿Por dónde comienzo?

Change Management

Gestión del Cambio Organizacional: Modelo ADKAR

Kanban

No todo el trabajo es siempre una urgencia