El bloc de notas de un Agilista Jedi

Todos

Management 3.0

Scrum

Change Management

Kanban

Product Management

Agile

Project Management

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

¡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 268 suscriptores :)
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 (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 recetade 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 (Habilidad) El conocer el tema (obtenido durante el bloque anterior) no lleva necesariamente a tener la 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? **¿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
Product Management

¿Cómo iniciamos? El Tablero de Visión del Producto

. La visión del producto es un sólido cimiento para la toma de decisiones relacionadas con el producto, para buscar maximizar el valor entregado a clientes y usuarios, así como a la organización. **Roman Pichler**, escritor y todo un master Jedi en Agile & Product Management, es el creador del **Tablero de la Visión del Producto**, un canvas muy útil para ayudar a cocrear una visión compartida del producto (lo que se conoce como “envisioning”). . # Las 6 cualidades de una Visión de Producto Roman Pichler, en su libro **Agile Product Management with Scrum** (Gestión de Productos Ágil con Scrum), menciona que una visión de producto efectiva contiene 6 cualidades: 1. Inspiracional 2. Es compartida 3. Ética y ofrece un producto que realmente proporciona un beneficio 4. Concisa y memorable 5. Grande y ambiciosa 6. No está amarrada a una solución específica . # El Tablero de la Visión de Producto (Product Vision Board) El Tablero de Visión de Producto de Pichler es muy poderoso, pero no es la única herramienta, es solo una de las tantas que existen para el proceso de crear una visión compartida o “envisioning”. Algo que es súper relevante mencionar, es que su fuerza no radica en el propio tablero, sino en las conversaciones que genera (como con cualquier canvas o radiador de información), por lo cual, es necesario que todas las personas relevantes para el producto formen parte de este envisioning: **Debe de ser un proceso colaborativo**. Hay un punto clave que menciona Roman Pichler y que siempre me ha parecido relevante: Evitar tratar de crear un producto que guste a todo-el-mundo o que satisfaga todas las necesidades. Hay una cita de **Steven Blank** a este respecto que dice: **“Crea un producto para unos pocos”**, es decir, enfocado a un nicho, a un cliente objetivo. La visión del producto es el punto de partida, guía a la organización, a los equipos y a las personas hacia donde se quiere ir. Sin embargo, es crítico no confundir esta visión con un plan para seguir ciegamente un camino predefinido. Gran cantidad empresas caen en la trampa de construir hacia una visión como “acto de fe” en lugar de adaptar en caso de ser necesario. ¿Es que entonces, la visión de un producto puede cambiar? Claro, pero en lo personal me gusta más el sentido de la palabra “evolucionar” que solo “cambiar”, porque evolución implica que hay aprendizaje y adaptación conforme a diversas variables del entorno. **La visión de un producto puede (y en muchos casos debe) evolucionar. ** Ahora bien, como herramienta para crear esta visión, Roman Pichler propone dos versiones de su tablero de Visión de Producto, una estándar y una extendida, que son en realidad el mismo tablero solo que el extendido incluye más elementos a considerar. En su sitio web puedes descargar ambas versiones en formato PDF ((link: https://www.romanpichler.com/tools/product-vision-board/ text: te comparto el link aquí)). Esta es mi versión del tablero de Roman Pichler. Platiquemos uno a uno los elementos que lo conforman y las preguntas a las que debe de responder: (image: product-vision-board-web-version-para-el-blog-02.webp) (Los primero 5 elementos son la versión estándar del tablero, los elementos 6 al 9 forman parte de la versión extendida). **1. Visión**: ¿Qué cambio positivo debería proporcionar? ¿Cuál es el propósito de crear el producto? Personalmente, me parece súper poderoso comenzar respondiendo esta pregunta, se alinea totalmente a lo que menciona Simon Sinek en su libro: “**Empieza con el porqué* (Start with Why)*”, que no indica que debemos de comenzar con el propósito o el fin en la mente. **2. Grupo Objetivo:** ¿A qué mercado o segmento de mercado está dirigido el producto? ¿Quiénes son los clientes y usuarios objetivo? **3. Necesidades:** ¿Qué problemas resuelve el producto? ¿Qué beneficio proporciona? **4. Producto:** ¿Qué producto es este? ¿Qué lo hace destacar? ¿Es factible desarrollar el producto? **5. Objetivos de negocio:** ¿Cómo va a beneficiar el producto a la organización? ¿Cuáles son los objetivos de negocio a los que aporta este producto? (Versión extendida) **6. Competidores:** ¿Quiénes son los competidores principales? ¿Cuáles son las fuerzas y debilidades? **7. Flujo de ingresos:** ¿Cómo se puede monetizar el producto y generar ingresos? **8. Factores de costo:** ¿Cuáles son los principales costos de desarrollar, llevar al mercado, vender y proporcionar servicio de este producto? **9. Canales:** ¿Cómo se llevará al mercado y venderá el producto? ¿Los canales existen actualmente? ¿Cómo llenar este tablero? Cuando he colaborado con equipos donde ha sido necesario crear esa visión, en los casos que hemos utilizado este tablero, reconozco que ha habido ocasiones en que al inicio es fácil identificar ese escepticismo y cierta renuencia a colaborar, es hasta cierto grado normal. Pero después de ir recorriendo el tablero, de ir avanzando a través de dinámicas, las personas terminan enganchándose y se detona un proceso creativo y colaborativo muy poderoso. . # Algunos tips poderosos para facilitar la cocreación de una visión Aquí te comparto unos tips que me han funcionado: **1. **Es necesario invitar a los interesados relevantes o stakeholders clave. **2. **Que los asistentes sea un grupo que incluya personal de todas las áreas implicadas y, de diversos niveles jerárquicos (ventas, marketing, desarrollo, etcétera). Es supremamente relevante escuchar los diversos puntos de vista, y por lo general siempre surgen ideas que a nadie se le habían ocurrido inicialmente. **3. **Si es una **facilitación en un espacio físico**, promueve que se sienten revueltos entre áreas o departamentos (no todos los de sistemas juntos, y los de ventas al otro lado de la sala de juntas), busca **fomentar conversaciones más diversas**. **4. **Si es una **facilitación remota**, puedes apoyarte de grupos pequeños en algunos momentos, combinando a personas de distintas áreas (la idea es la misma que el punto anterior: No envíes a un grupo pequeño a todos los de sistemas y a otro grupo pequeño solo a los de ventas).** Buscamos la diversidad**. **5.** Todas las ideas son bienvenidas, todas las ideas se escriben y son consideradas de manera inicial. Después habrá que conducir las conversaciones necesarias para converger, para reducir de manera natural las opciones (eso viene después), pero de entrada: **Todas las ideas son bienvenidas!** **6. **Si no se tiene una respuesta, pueden crearse** hipótesis** que necesiten ser validadas mediante **experimentos**. Súper interesante! ¿Quién se sumará a estos experimentos? Busca a esos innovadores y/o adaptadores tempranos que de manera natural les interese experimentar en esta etapa, así la resistencia al cambio será un factor mínimo de impacto negativo. **7. **Facilita las dinámicas necesarias para cada situación que pueda surgir: para ayudar al grupo a divergir, priorizar, descartar, converger, concluir, identificar accionables, cocrear, y etcétera y etcétera… pero, antes que directores o gerentes o desarrolladores, recuerda que estás tratando primeramente con personas, por lo tanto, facilita dinámicas para **que el grupo se divierta durante el proceso** (no por ser algo importante debe de ser algo serio y aburrido, mientras más memorable, mejor). . # Conclusiones Termino este post mencionando que, a pesar de tener una visión que haya sido cocreada, compartida, ética, concisa, memorable, ambiciosa, inspiracional, factible, pegajosa, rimbombante, trendy, chévere, bacán, bacana, y etcétera y etcétera... un producto puede fallar, ese tipo de historias están a la vuelta de la esquina. Entonces, ¿De qué sirve hacer una visión?, bueno, el contar con una visión adecuada no garantiza el éxito, si embargo minimiza mucho la probabilidad de un daño catastrófico. En este sentido, una visión abordada desde el enfoque de la Agilidad puede hacer la diferencia (un ejemplo es el ciclo crear-medir-aprender de** Eric Ries**, que este autor menciona en su libro **The Lean Startup**), tan es así que Roman Pichler concluye en su libro:** “Haz una entrega o liberación rápida de la primera versión de tu producto, muéstrala a clientes y usuarios. Escucha sus respuestas para saber si estás vas por el camino correcto. Entonces Inspecciona y Adapta.”** . # Un tip final, postdata, un plus, extra, o como decimos acá en México: “Un pilón”: No subestimes el poder de una **visión cocreada y compartida**, como menciona **Peter Senge** en su libro La quinta disciplina: **“Cuando las personas comparten verdaderamente una visión, estas personas conectan y crean un lazo que los guía juntos hacia una aspiración común”**, y esto, una aspiración común de un grupo de personas, crea un efecto muy poderoso y positivo. ¡Imagina si llevas esto a tu organización! (y no hablo solo para el envisioning de un producto, sino el poder de la cocreación en todos los aspectos). ¿Qué opinas sobre la importancia de una visión y el poder de una visión cocreada y compartida? ¿Qué te parecieron estos tableros de Visión del Producto de Roman Pichler? .
30 de agosto de 2023
Management 3.0

6 consideraciones para recompensar a tu equipo (desde la perspectiva de Management 3.0)

"Un gran número de estudios y evidencia demuestra que, en la mayoría de las circunstancias, un incentivo económico por resultados (o bono), puede hacer que el desempeño de las personas empeore. Mientras más alto el pago, peor el desempeño.” **Nic Fleming – El mito del bono**. # Partamos de las motivaciones Las motivaciones de las personas pueden ser de tipo extrínsecas e intrínsecas: **Extrínsecas: **Estímulos externos a como un incentivo económico o bono que promueve las conductas deseadas o castiga las conductas no deseadas **Intrínsecas: **Internas o inherentes a las personas, como por ejemplo alcanza la maestría, curiosidad para investigar y aprender cosas nuevas, tener un propósito, entre otras *((link: https://www.leonelzapien.com/blog/cuales-son-los-motivadores-intrinsecos-de-tu-equipo text: puedes leer aquí un artículo que escribí sobre los motivadores intrínsecos y su práctica en Management 3.0)*). Hablando de recompensas, lo que buscamos mayor e idealmente es **detonar los motivadores intrínsecos de las personas**, ya que décadas de estudios demuestran que esto es más sostenible que los motivadores extrínsecos (si le aumentas el sueldo a una persona, esta estará satisfecha por algunos meses, después de un tiempo requerirá otro aumento para sentirse satisfecha, y después otro… lo cual no es sostenible). Además, recompensar a personas en tu equipo u organización (e inclusive en tu familia), a través de incentivos económicos asociados a un resultado determinado, puede resultar contraproducente si se realiza de manera inadecuada (más adelante en este mismo artículo describo algunos ejemplos). Por esto, te comparto aquí 6 consideraciones desde la perspectiva de **Management 3.0** (propuestas por** Jurgen Appelo**, en su libro “Gestionando la Felicidad” o “**Managing for Happiness**”). Estas 6 consideraciones maximizan por mucho la probabilidad de que las personas se sientan motivadas, se refuercen sus motivadores intrínsecos, y consecuentemente mejore el desempeño y los niveles de bienestar en el área de trabajo. Aquí las 6 consideraciones para dar reconocimientos o recompensas, desde la perspectiva de **Management 3.0**: # 1. No prometas la recompensa por adelantado. Si vas a dar un reconocimiento o recompensa, que este sea **inesperado** por la persona. Lo que buscamos es que la persona no cambie sus intenciones o enfoque solo para obtener la recompensa. Hay diversos estudios que muestran que cuando una recompensa es inesperada, la probabilidad de que se afecte a la motivación intrínseca de la persona es mínima. Pero cuidado, o como decimos acá en México: “*¡Mucho ojo!*”, porque si lo haces demasiado frecuente, el factor **“inesperado” **se puede convertir en factor **“ya-sé-que-no-lo-dices-con-anticipación-pero-siempre-me-das-una-recompensa-cuando-hago-el-trabajo-y-finjo-como-que-no-me-lo-esperaba”**, y cuando esto es el caso, se pierde totalmente el sentido, pues se convierte en una recompensa esperada. ¿Y qué pasa cuando la recompensa es esperada? La persona modifica su comportamiento a fin de obtenerla. (image: 01-expectativa_cool.webp) # 2. Si prometiste una recompensa por adelantado, que sea algo pequeño. Algunas veces no podemos evitar anunciar una recompensa potencial. En estos casos, de acuerdo con diversos estudios, las recompensas grandes logran un efecto de mermar el desempeño, ya que la gente está enfocada en lo que puede obtener. En cambio, con **recompensas pequeñas**, la probabilidad de dañar o afectar a este desempeño es mínima. No hay nada escrito sobre qué puede ser “algo pequeño”, qué pudiera ser adecuado depende totalmente del contexto del equipo, pero quizá un reconocimiento público (como se menciona en el punto #4), una fotografía de equipo, unos chocolates, una salida a cenar para el equipo, unos frappes de su cafetería favorita, **o una caja de galletas (keto, sin azúcar, sin colorantes y con chispas de cacao orgánico)** pueden funcionar. (image: 02-regalo-pequeno-cool.webp) # 3. Recompensa continuamente, no solo una vez. No esperen un momento para celebrar solo una vez al mes o cada año. Los pequeños reconocimientos y celebraciones tienen un efecto muy positivo. Hay que celebrar las pequeñas victorias, el aprendizaje validado, celebraciones casuales y sencillas, no esperar al cierre del proyecto dentro de 3 años para hacer una fiesta con “bombo y platillo”. (image: 03-calendario-kudos-cool.webp) # 4. Recompensa públicamente, no en privado. La esencia de este punto es: **Transparencia**. Para todas las personas debe de ser claro qué se está recompensado y por qué. El objetivo de dar recompensas es **reconocer las buenas conductas y reforzarlas**, pero más allá de eso, se quiere fomentar un entorno donde las personas disfruten trabajar. Por lo tanto, los recordatorios públicos funcionan muy bien en reforzar lo positivo. (image: 04-publicamente-cool.webp) # 5. Recompensa los comportamientos y actitudes, no solo el resultado. Un determinado **resultado u outcome** (*(link: https://www.leonelzapien.com/blog/outputs-outcomes-impact text: puedes leer aquí más sobre resultados/outcomes e impacto en este otro artículo que escribí tres semanas antes de este que justo estás leyendo)*) puede ser alcanzado mediante atajos (inclusive a través de prácticas no éticas, o más allá de eso: ilegales). **Como ejemplo: **El controversial caso de la multinacional **Volkswagen**, que en la búsqueda por ser más competitivo y conseguir aprobaciones medioambientales, instalaba un software en sus vehículos para conseguir mediciones contaminantes en banco de pruebas muy por debajo de las auténticas, entre 10 y 40 veces menos de lo real. Este software se instaló en más de 11 millones de vehículos de la marca de 2009 a 2015. La Agencia de Protección Medioambiental estadounidense (EPA) acusó a Volkswagen de utilizar un "dispositivo de engaño" para evadir la regulación sobre emisiones. **Cuando lo que se busca es “alcanzar” el objetivo a cualquier costo, las formas de llevarlo a cabo pueden no ser las idóneas** (la verdad es que no es tan simple, intervienen muchas variables en esto, pero predominantemente viene de los valores y la **cultura organizacional “real”**, es decir, esa que se vive en el día a día, no la que se muestra en posters o cuadros en los pasillos y salas de juntas de la compañía). Cuando el enfoque (y la recompensa) es solo en un resultado deseado, las personas pueden aprender a obtener ese resultado a cualquier costo. Podemos preguntarle a Volkswagen. La conducta, en cambio, es un indicador del compromiso y trabajo realizado. Si se recompensan las buenas conductas, esto tiende a reforzarlas. Buscamos la siembra de valores para cosechar estas buenas conductas. (image: 05-conducta-no-resultado-outcome-cool.webp) # 6. Fomenta el reconocimiento entre pares, no solo de jefes a subordinados. Los reconocimientos, al igual que la retroalimentación, no deben de ser solo de un superior jerárquico a un subordinado (de arriba hacia abajo), debemos de fomentar un entorno en el cual los reconocimientos puedan darse entre pares o colegas en igual nivel jerárquico, e inclusive de “abajo hacia arriba” en la jerarquía. El reconocimiento entre pares es muy positivo, ya que en el día a día y en muchas ocasiones, estos pares conocen a mucho mayor detalle el trabajo que realiza una persona que inclusive su jefe directo. (image: 06-peer-recognition-cool.webp) # Conclusiones Para concluir, es importante enfatizar que no estamos demeritando el dinero, ya que es fundamental que las personas estén bien remuneradas en primera instancia. Si esto no se cumple, no se puede compensar esto con un diploma de felicitación o una caja de chocolates. Estamos partiendo del supuesto de que esta necesidad está cubierta, ya que** hay una tremenda diferencia entre tener una remuneración base adecuada y utilizar el dinero como un sustituto para alcanzar un desempeño profesional deseado**. La verdad es que este tema de la motivación me encanta, es súper poderoso. Personalmente creo que no podemos dar aquello que no tenemos, por lo tanto, es necesario identificar primeramente y fomentar nuestra motivación, aplicarlo primeramente en nosotros mismos, antes de llevarlo a nuestros equipos y familias. Este tema de la motivación da para mucho, mucho de verdad. Continuaré hablando de esto en siguientes artículos. Pero cuéntame, ¿Conocías algunas de estas 6 consideraciones para las recompensas? ¿Al menos de manera empírica? ¿Cuáles has aplicado y cómo te han funcionado?
1 de agosto de 2023
Product Management

Outputs, Outcomes & Impact - (Salidas, Resultados e Impacto)

# Una vieja historia conocida, nuevos actores Un equipo Scrum con el cual colaboré hace un par de años, estaba pasando por una situación: Habían terminado un nuevo producto (en este caso era un software para uno de sus clientes), habían construido todas las funcionalidades y características solicitadas “al pie de la letra, con puntos y comas” por este cliente, les daba retroalimentación, y en base a eso terminaron un producto… cuando llegó el usuario final, resulta que para la forma “real” en que él trabajaba y sus necesidades, este software no le ayudaba. No aportaba un beneficio mayor, un valor real, finalmente no utilizaba el nuevo, flamante (y costoso) programa. ¿Te suena conocida esta historia? Se entregaron las nuevas características tal como las solicitó el cliente, así como en el tiempo y costo definido en el contrato. En este caso un punto importante es que el cliente y el usuario no eran la misma persona, quien pagó por el producto (el cliente) no era quien realzaba las operaciones del día a día, quien daba la cara al cliente, no era quien iba a usar el producto (usuario). El equipo puso todo el enfoque y empeño en entregar, esto es lo que se conoce como **enfoque en “salidas” (outputs)**, es decir, cumplo al entregar en las condiciones estipuladas: tiempo, costo, las funcionalidades tal cual se solicitaron. Una vieja historia conocida de terror contemporáneo, es La-Pesadilla de las pesadillas, es algo que tristemente aún continúa cobrando a los equipos horas y horas de trabajo / miles líneas de código / documentos infinitamente extensos… trabajo que, desde el punto de vista Lean, termina siendo un desperdicio. **El epitafio de este producto diría algo: “Aquí yace un producto construido impecablemente, que nadie compra”** ☹ # ¿Hay algo más en qué debo de poner el enfoque? ¡Claro!, lo que buscamos es un impacto positivo, resolver el problema del usuario, hacerle la vida más fácil. Para poder llegar a generar un impacto, primeramente, debemos de enfocarnos en algo que se puede traducir como “resultados” (outcomes). Hay una definición de outcomes que en lo personal me gusta mucho, propuesta por su **Joshua Seiden** en su libro **“Outcomes over Outputs: Why customer behavior is the key metric for business success” (Resultados sobre Salidas: Por qué el comportamiento de los usuarios es la métrica clave para el éxito del negocio)**, nos dice que: **“Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.”** Esta definición me parece muy poderosa, porque nos transmite que un outcome no tiene que ver con solo “construir o entregar algo”, sino en un cambio en una conducta o comportamiento del usuario/cliente que conduce a un valor positivo para el negocio. En el caso de este equipo Scrum que mencionaba al inicio de este artículo, ellos hicieron entrega de un producto, funcionaba perfectamente (no tenía errores), inclusivo era visualmente muy mono (se veía re-bonito, hasta tenía unas animaciones muy chéveres), y “lo más importante” es que lo entregaron en el tiempo y presupuesto acordado… suena como un producto perfecto, ¿no?... pero aún así, no producía ningún cambio en la forma en que el usuario final realizaba sus actividades porque sencillamente no le ayudaba en la realidad de su día a día, no facilitaba sus tareas, sus operaciones, no le hacía la vida más fácil. Para asentar un poco el enfoque en outcomes (y finalmente en el impacto en la vida del usuario final), al leer el libro de Seiden me encontré con este modelo que me encantó y estaba muy emocionado por escribir sobre él, o como decimos acá en México: **Se me quemaban las habas** por compartirlo. Este modelo y ejemplo que Seiden plantea en su libro, este se llama: **Program Logic Model o Modelo lógico de programa** (creado por W.K. Kellogg Foundation). Este modelo es muy simple: (image: modelo-01.webp) El enfoque en los outcomes en vez de outputs no es nada nuevo, de hecho, es muy conocido. Sin embargo, el agregarle ese enfoque final en el** impacto** me pareció poderoso y creo que aporta muchísimo valor. Claro que en la realidad, en el día a día, en nuestros equipos y organizaciones buscamos ese impacto final con la entrega de un nuevo producto o servicio, pero al menos personalmente nunca lo había definido con una palabra concreta, impacto, por lo cual este modelo me pareció muy alineado con lo buscamos con puntos como **“La meta del Producto” o Product Goal** que define La Guía Scrum, o con el famosísimo **“Porqué”** (sí, así pegado y con acento) que menciona Simon Sinek en su libro** “Comienza con el Porqué”**, esa razón de ser que nos guía. Así que, ya sin tanto rollo, el ejemplo para explicar este modelo es el siguiente: Una fundación tiene como propósito ayudar a mejorar la calidad de vida de una pequeña comunidad que vive en una zona alejada y sin servicios básicos. La gente de esta comunidad dedica buena parte de su día en caminar hasta un río para acarrear agua. En base a la observación, una hipótesis de la fundación es que, si la comunidad contara con un pozo de agua en el centro de su villa, no dedicarían tanto tiempo en acarrear agua desde el río, y este tiempo que se “ahorren” podrán dedicarlo a realizar otras actividades que les permitan mejorar su calidad de vida (tal vez aprender nuevos oficios, mejorar sus viviendas, cultivar más, o cosas como de ese estilo). En este caso, construir un pozo para la comunidad es el entregable que la fundación pretende entregar, la salida **(output)**. El resultado **(outcome)** que esta salida genera es que las personas toman agua de aquí y ya no van hasta el río todos los días. Esto cumple con la definición que nos comparte Seiden, porque** hay un cambio positivo en el comportamiento de las personas** que usan el pozo. El impacto que se busca, que las personas dediquen más tiempo a realizar otras actividades que mejoren en la calidad de vida de la comunidad, debe de observarse para determinar si se logra. # ¿Cómo garantizar que se obtenga el impacto deseado? Este es un tema que da para mucho, de esas charlas largas y apasionantes acompañadas de un buen café o mate (en lo personal prefiero un té verde). Siempre le he batallado con esto: ¿Cómo garantizas que se obtenga el impacto deseado?, ya que en la universidad no cursé la materia o asignatura llamada **“Ver el futuro en una bola de cristal”** :D Ya hablando en serio, hablar del impacto es hablar de **complejidad**, de cuestiones que no se pueden predecir (en la realidad existen infinitas variables que pueden influir en el impacto, y no siempre es posible identificar una correlación lineal o directa entre estas variables). ¿Cómo garantizar entonces el impacto? La verdad es que no es posible, ¿Entonces? Aquí lo importante es abordarlo con un enfoque de experimentación y plantear este impacto como una **hipótesis**. Para ver si esta hipótesis es correcta, se pueden correr experimentos pequeños, controlados, baratos, que nos den retroalimentación sobre la factibilidad de los outputs y outcomes para el impacto buscado. En este caso de ejemplo, supongamos que es factible llevar camiones o pipas de agua que abastezcan a la comunidad durante un periodo de tiempo que se considerará como un muestreo, y durante este tiempo se puede observar los cambios en las conductas o comportamiento de las personas y una “muestra” del impacto, a fin de validar si la hipótesis es correcta, antes de avanzar más… pero este solo punto, como mencionaba, es tema charlas mucho más profundas, o al menos de otro artículo particular (de hecho lo voy a abordar en un video que está en proceso de edición, próximamente lo compartiré por aquí: Pinky promise). El modelo de este ejemplo quedaría algo como: (image: modelo-02.webp) ¿Cómo te parece el modelo de este ejemplo? # Conclusión Para cerrar, me gustaría mencionar nuevamente la definición de outcomes que nos propone Seiden: “Un outcome (resultado) es un cambio en un comportamiento humano que conduce a un resultado de negocio.” El definir primeramente impacto que se espera en función a outcomes, es decir, en función del comportamiento de los clientes/usuarios, sirve como guía para ayudar a fomentar una cultura centrada en ellos, los clientes y usuarios, lo cual puede ayudar a que la organización obtenga también el impacto esperado: Valor de negocio. **P.D.** No olvidemos también a nuestro equipo, a las personas: Que construyan el producto o servicio en un ambiente de bienestar es, como se dice: un MUST, o sea que es imprescindible. ¿En qué se enfocan en tu equipo u organización actualmente? ¿Aún en outputs? ¿En outcomes, pero solo en esto? ¿O ya están centrados en los Impactos?
12 de julio de 2023
Scrum

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

En Scrum, hablar de calidad del producto es hablar de la **Definición de Terminado**, la cuál es popularmente conocida como **DoD**, así a secas, DoD, un acrónimo debido a su nombre en inglés: **Definition of Done**. Esta Definición de Terminado es una descripción formal de lo que debe de cumplirse para que el producto que se está entregando cuente con las medidas de calidad requeridas. Es decir, lo que debe de cumplirse y validarse para asegurar que el producto que se está construyendo pueda ser puesto en producción, que lo pueda utilizar directamente usuario final, y que sea un producto de calidad (que no tenga fallas o bugs, que cumpla con los lineamientos de la organización, que el programa no “se rompa”, etcétera). No pretendo que este sea un artículo teórico, pero es necesario ver algo de teoría. Así que, partiendo de una “definición de libro”, veamos qué es la Definición de Terminado. De acuerdo con el Glosario de Scrum.org, la Definición de Terminado es: **“Un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.”** Aquí hay un par de ideas clave que es relevante enfatizar: • **“Entendimiento compartido”:** Esto significa que es co-creada por todo el equipo Scrum, que todos la comprenden y están de acuerdo con ella. Es decir, que no es algo que definen solo los desarrolladores como área técnica, sino que negocio, a través del Product Owner, debe de compartir este entendimiento. **• “Las expectativas que el incremento debe cumplir”:** En Scrum buscamos entregar un incremento de producto en cada sprint, esto es un incremento funcional que puede utilizar el usuario final a partir de ese momento en caso de ser requerido. Por eso, al definir en la DoD lo que el producto debe de cumplir, se crea una línea base en términos de calidad, ya que cualquier incremento de producto cumple siempre con la DoD, lo que quiere decir que hay un nivel de calidad “mínimo” establecido para todos los incrementos. **• “Para ser liberado a producción”:** Como mencionaba en el punto anterior, cada incremento de producto que se entrega debe de ser un incremento completamente funcional, que puede utilizar el usuario final, a partir de ese momento en caso de ser requerido. Al ser un entendimiento compartido, es claro y transparente para todo el equipo lo que “terminado” significa. No existe algo como “**casi-casi-terminado**”, está terminado o no lo está, por lo tanto, se puede entregar o no. Aquí me gustaría compartir 5.1 puntos muy chéveres para que puedas co-crear con tu equipo una poderosa Definición de Terminado. Estas son algunas ideas que han funcionado después de colaborar con diversos equipos. Veamos una por una: # 1. Co-creación: Ya que se trata de un entendimiento compartido por el equipo, es mucho más enriquecedor que sea co-creado por todo el equipo. Parecerá obvio este punto, pero una vez colaboré con un equipo en el cual el líder técnico definía la DoD porque era quien “tiene más experiencia”, y el resto del equipo, por ser juniors, solo se apegaba a lo definido. Nos tomó un tiempo el que pudiéramos avanzar todos juntos hacia la co-creación, pero ya llegando a ese nivel, el crecimiento del equipo y de la calidad del producto fue innegable. **La co-creación fomenta la diversidad de ideas y perspectivas, además de que ayuda s que las personas sientan que formaron parte en el proceso de crear algo nuevo, por lo que el sentido de pertenencia y compromiso aumenta.** # 2. Evolutiva: **La DoD debe de inspeccionarse y adaptarse regularmente**, no está escrita en piedra, y conforme el equipo va madurando, también la DoD debe de hacerlo. En un escenario real, ya que hablamos de responder al cambio, es necesario que la DoD se ajuste conforme el contexto técnico cambia, por ejemplo, ¿Se ha detectado un nuevo defecto o bug que no había ocurrido antes?, o ¿Qué tal cuando una actualización tecnológica hace necesaria una nueva validación? Si es el caso, agregar eso a la DoD. # 3. Visión del futuro: Ya que la DoD debe de ir madurando y evolucionado, es poderosísimo que el equipo tenga una visión compartida del estado futuro que pretende alcanzar, el nivel de calidad al cual el equipo aspira a llegar, quizá no este sprint ni el siguiente, pero sí como un estado hacia el cual el equipo va avanzando, paso a paso. Tal vez técnicamente el equipo aún no tiene los conocimientos y/o experiencia necesaria, pero está capacitándose, aprendiendo y eventualmente llegarán a ahí. # 4. No es una receta de cocina: La DoD no debe de ser prescriptiva. Indicar con puntos y comas lo que se debe de hacer como un procedimiento o receta, puede limitar la autogestión del equipo. Aquí no hay “mejores prácticas”, solo recordemos que no buscamos la documentación extensiva. Lo adecuado, como todo en la vida, es el balance. Documentar en la DoD lo justo y necesario para el equipo, no más, no menos. # 5. Transparencia real: La transparencia significa que la información debe de estar visible y disponible para las personas interesadas. En este caso, con transparencia “real” me refiero a que no solo visible y disponible es suficiente, sino que debe de ser entendible y comprensible para todos. Por ejemplo, ¿El Producto Owner sabe a qué se refiere que todo el código esté integrado?, la verdad es que no es necesario que sepa cómo hacerlo técnicamente, pero sí es importante que comprenda la esencia de lo que esto implica, y que comprenda su importancia, así como el impacto de no hacerlo. # 5.1 Y aquí un Bonus: ¡Diversión! Esto es fundamental. El cumplir con objetivos de calidad y código limpio no implica que debe de ser algo aburrido. Desde las dinámicas de facilitación para co-crear una DoD, inspeccionarla y adaptarla, hasta el aseguramiento de su cumplimiento, son oportunidades para que el equipo se divierta, se abra a lo lúdico, a nuevas ideas, fomentar las condiciones para que el equipo entre en estado de “Flow” y detone la creatividad. ¿Lo has experimentado con tu equipo? Que el equipo cuente con una DoD es esencial, si no cuenta con una,** el mejor momento para empezar a co-crearla fue el sprint pasado. El segundo mejor momento es hoy**. El hacer código limpio siempre evita problemas y dolores de cabeza, ayuda a no dejar trabajo pendiente para el final o “**escondido debajo de la alfombra**” que regresará al equipo después como problemas debido a mala calidad. El retrabajo es un tipo de desperdicio e impacta en la productividad. (image: icono-iceberg-05-large-to-web-site.webp) Para cerrar, me gustaría reforzar que el objetivo de Scrum es entregar cada sprint un incremento de producto que sea funcional, que cumpla con el objetivo del sprint y que, en última instancia, sea un paso adelante hacia el objetivo del producto… y la Definición de Terminado, es piedra angular en esto. Recordemos que** en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento de producto.** Cuéntanos, ¿Qué te parecieron estos 5.1 puntos para una poderosa DoD? ¿Qué otro punto agregarías? Me encatará leerte y que conversemos :)
2 de junio de 2023
Management 3.0

Tarjetas de colaboración: Fomentando conversaciones & armonía

En el trabajo, no somos solo empleados. También tenemos una vida, tenemos personalidad, preferencias personales, entre otras infinitas cosas. Al ser primeramente personas, nuestro estado de ánimo y desempeño en la oficina puede verse impactado por estas preferencias y rasgos personales. Conocernos unos a otros, en nuestros equipos y fuera de estos, ayuda a que las personas seamos identificados como eso, personas con una vida, y nos proporciona la sensación de que somos escuchados y que el mundo es empático con nosotros. Esto ayuda a fomentar un ambiente de trabajo que funciona mejor para todos. Por otro lado, al ignorar estos rasgos y necesidades personales, cuando sentimos que otros los ignoran constantemente, es un detonante potencial de conflictos e infelicidad en el lugar de trabajo. Y esto se ve reflejado en nuestro desempeño. **Management 3.0** llega con una propuesta: (link: https://management30.com/practice/personal-collab-cards/ text: Tarjetas Personales de Colaboración (Personal Collab Cards)), el cual puede verse como “un manual personal” con un resumen de aspectos relevantes para el trabajo, aspectos que debemos de conocer de cada persona con la que colaboramos. Las tarjetas de colaboración personal “estándar” que propone Management 3.0 contienen, entre otra información: • Zona horaria y disponibilidad para reuniones. • Canales de comunicación preferidos y formas de usarlos. • Funciones y temas de los que una persona es responsable o en los que desea ser incluida. • Intereses personales y cosas que pueden desmotivarlos • Partes interesadas con las que una persona trabaja regularmente, especialmente fuera del equipo. Poniendo un ejemplo concreto, **mi Tarjeta de Colaboración Personal **menciona cosas como: • Me llamo Leonel y gusta que me digan Leo. • Radico en Guadalajara, México, y mi zona horaria es Hora Central Estándar (CST), es decir UTC-6. • Si necesitan contactarme, mi forma predilecta es por mensaje de Whats App, así podemos ponernos de acuerdo fácilmente para una llamada o reunión (a menos que sea algo urgente). Para algo urgente no hay nada mejor que una llamada. • Si me envían un correo electrónico, entiendo que es algo que debo de atender, que es importante, pero asumo que no es algo urgente. • Mis horarios regulares para atender reuniones son de 09:00 a 18:00 horas, pero al colaborar con personas de distintos husos horarios, puedo tomar sin problema alguna reunión antes de mis 07:00 o después de mis 18:00 para alguna situación especial, solo necesitamos ponernos de acuerdo previamente. • Entre otros puntos… pero mejor, aquí comparto **mi Tarjeta Personal de Colaboración**: (image: management-3.0-personal-collab-card-leo-v01-a.webp) La **T-R-A-N-S-P-A-R-E-N-C-I-A** es la clave para a que, algo tan sencillo como las Tarjetas Personales de Colaboración, funcionen. Las tarjetas deben de estar disponibles y visibles para todas las personas con quienes colaboramos. Pegadas en un área común, si hablamos de un entorno presencial al 100%, o por ejemplo, en un tablero en Miro/Mural, en Trello o Confluence para contextos digitales o equipos distribuidos. **Como en toda herramienta visual, el punto no es el tablero o, en este caso, la Tarjeta de Colaboración, sino las conversaciones que se generan.** Y eso es lo poderoso de este tipo de herramientas. ## No hay que perder de vista el enfoque Ágil Recordemos el primer valor del (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto Ágil): **“Individuos e interacciones sobre procesos y herramientas”**, esta herramienta, la Tarjeta de Colaboración, es solo eso… una herramienta. Lo enriquecedor y realmente poderoso es la conversación entre personas que esta tarjeta fomenta. **Procuremos pues, esas conversaciones agradables, con un café, un mate o como en mi caso, un té verde, donde seamos personas charlando antes que profesionales llegando a un acuerdo.** ## Tips para pasar al nivel Jedi en Colaboración Ya para comenzar a cerrar, aquí un par de puntos importante para que los tomes en cuenta cuando apliques esto en tu equipo: 1. Las Tarjetas de Colaboración Personal no sustituyen a otras prácticas o herramientas para que los integrantes de un equipo se conozcan mejor, por ejemplo, los (link: https://www.leonelzapien.com/blog/mapas-personales-conociendo-mejor-a-un-equipo text: Mapas Personales de Management 3.0). En este sentido, se complementan. Los Mapas Personales hablan más a detalle de las personas, las Tarjetas de Colaboración se pueden ver como un “resumen” o como un “manual” de lo esencial que necesitamos conocer sobre una persona con quien colaboramos. 2. Los campos que conforman las Tarjetas de Colaboración se pueden adaptar, no es obligatorio que sean de la manera en que se muestra en la plantilla de Management 3.0, depende del contexto de tu equipo y organización. Solo recuerda conservar la esencia:** ¡Mantenerlo simple!** 3. Las Tarjetas de Colaboración no están escritas en piedra, al igual que cualquier elemento o artefacto, son dinámicas. ¿Por qué? Porque nosotros como personas somos dinámicas, evolucionamos con el tiempo, cambian nuestro contexto, nuestras ideas… por lo tanto, recuerda revisar esto con tu equipo regularmente. 4. Estas tarjetas son poderosas para hacer más suave la llegada de nuevos integrantes al equipo (súper poderoso revisarlas durante el **onboarding**). ## Conclusión Para finalizar, no es mandatorio un tiempo o espacio específico para que un equipo cree sus tarjetas, pero si lo haces: **Si das al equipo un tiempo y espacio específico para que juntos revisen, actualicen y conversen sus Tarjetas de Colaboración, por ejemplo, durante un workshop o durante una sesión de integración de equipo o team building, la atmósfera hará el ejercicio aún más enriquecedor**. Se puede enlazar esta dinámica en equipo junto con los Mapas Personales, que anteriormente ya había mencionado, y estos pueden servir como base para desarrollar dinámicas más profundas para los equipos, como el (link: https://management30.com/practice/team-agreement-canvas/ text: Lienzo de Acuerdos de Equipo (Team Agreement Canvas))… pero esto es tema de otro artículo en este blog. Te invito a que experimentes aplicando las Tarjetas Personales de Colaboración con tu equipo, siempre inspeccionando y adaptando los resultados. Si te animas, nos compartes qué resultados obtuvieron. Cuéntanos… ¿Habías escuchado hablar antes de las Tarjetas Personales de Colaboración?, ¿Qué opinas sobre sobre esta herramienta? ¿Qué información sugieres agregar para utilizarla en tu equipo?
7 de mayo de 2023
Scrum

El primer libro de Scrum del mundo

**“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”**. Así es como introducen Ken Schwaber y Mike Beedle por primera vez el evento Daily Scrum en el libro **“Agile Software Development with Scrum”**, el cual fue el primer libro escrito en la historia de la humanidad sobre el marco de trabajo Scrum, por allá del año 2001. Hace unos días estuve releyendo el libro “Agile Software Development with Scrum” (Desarrollo de Software con Scrum), el cual es conocido en el mundo de la Agilidad como **“El libro negro de Scrum” **por su característica portada. Es una joya histórica por ser el primero de miles y miles y miles de libros que se han escrito sobre Scrum a lo largo y ancho del mundo. ¿Te ha pasado alguna vez que una película o canción que “te gustaba mil” cuando eras adolescente, cuando la ves o escuchas 10-15 años después… como que ya no “conecta” contigo? De igual manera, cada que leemos de nueva cuenta un libro lo vemos con una perspectiva distinta, puesto que somos una persona “diferente” de cuando lo leímos por primera vez (nuevas experiencias de vida nos han llevado a nuevos modelos mentales, nuevos paradigmas, nueva ideología, nuevas prioridades, etcétera). En este caso, después de releer “El libro negro de Scrum” no puede ser más cierto que lo veo desde una perspectiva distinta, no solo porque yo he evolucionado como persona… sino que **Scrum, como marco de trabajo, también ha evolucionado** (a verdaderos pasos agigantados) desde que lo presentaron al mundo oficialmente en 1995 sus co-creadores Jeff Sutherland y Ken Schwaber (quien es, por cierto, uno de los co-autores de este libro). Aquí te comparto varias ideas sobre Scrum tal como fueron concebidas originalmente, así como una comparativa con el enfoque actual. Lo interesante es que, si lo vemos con las gafas o lentes de hoy,** a 21 años de la publicación de este libro, muchas de sus ideas pueden considerarse como disfuncionales o incluso antipatrones**… Entonces, ¿está mal el libro? ¡Nada de eso!, solo recordemos que estamos en la “tierra del empirismo”, debemos de crear para enseguida inspeccionar y adaptar. Así que el hecho de que Scrum haya evolucionado de la manera que lo ha hecho (y lo seguirá haciendo), es una muestra clara del empirismo aplicado a su máximo potencial. ¡Poderosísimo! Sin más rollos, aquí van algunas de estas comparativa de ideas acerca del “Scrum del primer libro” y el enfoque actual: ## 1. El Daily Scrum es una junta de estatus… que solo debe de llevar ¡el Scrum Master! **1.1 **“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum” **1.2 **“El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum. El Scrum Master mantiene el Daily Scrum breve, hace cumplir las reglas asegurándose de que las personas hablen brevemente.” Si un Scrum Master llegara este 2023 al evento internacional Scrum Day y dijera que el evento Daily Scrum es una junta de estatus, una muchedumbre con antorchas y trinchetes lo acusaría de anti-Agilista. (image: muchedumbre-con-fuego-y-trinchetes.webp) Imagen de WikiSimpsons (https://simpsons.fandom.com/es/wiki/Turba_furiosa) Me sorprendió ver que al Daily Scrum se le concibió inicialmente como una junta de estatus. Todo esto ha evolucionado, actualmente el Daily (así se le conoce en el medio, Daily “a secas”) no es para entregar estatus, tiene como propósito generar transparencia, que en equipo se inspeccione el progreso hacia el Objetivo del Sprint y adaptar según sea necesario. Respecto a la segunda idea del libro,** “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum”**, la evolución nos ha llevado a buscar el enfoque en la autogestión del equipo, es decir, que sean capaces de gestionarse sin necesidad de que un Scrum Master lo haga por ellos, por esto actualmente el Daily es un evento de los Desarrolladores para los Desarrolladores, ellos mismos inspeccionan su progreso hacia el ya mencionado Objetivo del Sprint, el Scrum Master no dirige la sesión, y, de hecho, puede no asistir y el evento no se detiene. ## 2. No es un Marco de Trabajo o Framework… es un ¿Método? En la introducción del libro, Mike Beedle (co-autor) menciona: “Tuve la buena fortuna de leer un mensaje de Jeff Sutherland y reconocer que era de hecho información muy importante. Él anunció que junto con Ken Schwaber estuvieron trabajando en **un método llamado Scrum**” Este punto me llamó mucho la atención, pues es añejo el debate sobre Scrum sobre si es un Framework y por qué no es una Metodología, pero antes de este libro nunca había visto que lo llamaran método. Para aquellos que ya conocen Scrum, disculpen que lo vuelva a mencionar, pero siempre partimos de aclarar que Scrum es un Marco de Trabajo o Framework, pues proporciona una serie de eventos y artefactos con los que se debe de trabajar, indicando 3 roles (Scrum Master, Product Owner y Desarrolladores), con esto se identifican los resultados que se desean obtener, pero no entra en ningún tipo de detalle sobre la manera en que esto debe de hacerse, es decir, deja “espacio abierto” a los propios equipos para sean ellos quienes decidan la mejor manera de hacer esto, el “cómo” hacerlo, en su contexto particular. Eso es un Framework, en tanto que un Método es un modo ordenado y sistemático de actuar o proceder para llegar a un resultado o fin determinado. Siendo muy simplistas podemos decir que es un procedimiento que se sigue para conseguir un objetivo. Un Framework deja más espacio a que las personas definan la manera de hacer las cosas, fomenta la experimentación y el empirismo, pues solo es una base para resolver un tipo de situaciones. ## 3. Enfoque en Proyectos y más Proyectos **3.1 **“Cada proyecto es diferente […] Diversas tácticas ayudan, pero sin Scrum esos proyectos fueron eventualmente abrumados por la complejidad inherente en proyectos de desarrollo de sistemas” **3.2 **“La gerencia debe de negociar de las cuatro variables [costo, fecha, funcionalidad y calidad] con los clientes “ Es oficial: **Scrum inició como un enfoque para gestionar proyectos de manera ágil**. Esto ha evolucionado en el último par de décadas y el enfoque actual no es hacer proyectos, sino productos. Esto quizá pueda sonar contradictorio, pues un producto puede ser el entregable que se genera al finalizar un proyecto, un resultado único. Esto es cierto, vivimos en un mundo de proyectos, pero la enorme diferencia es el enfoque… un proyecto se centra en entregar “algo” dentro del tiempo, costo y alcance definido, en tanto que, desde la perspectiva de producto, nos centramos en el impacto que este “algo” que entregamos produce para el usuario final. Buscamos construir productos que resuelvan algún problema del usuario/cliente, que hagan su vida más fácil. Un producto define su éxito en base al **V-A-L-O-R **que proporciona. ** P.D. #1** Personalmente siempre he creído que debemos de ir un paso más allá… un producto que resuelva un problema lo puede hacer cualquiera, **debemos enfocarnos en ¡crear productos que enamoren!** Estas son solo algunas de las ideas del “Scrum del primer libro” que plantean Schwaber y Beedle, la verdad es que hay mucha tela de la cual cortar. Es de esos temas profundos que dan para largas conversaciones acompañadas de un buen café, té, mate o la bebida de tu predilección (en mi caso, me inclino por el té verde). Por esto, y para no hacer un artículo tan extenso, en una próxima entrada de Blog continuaré con la segunda parte de “El primer libro de Scrum del mundo”. ¡Nos vemos en el capítulo 2! **P.D. #2** Mike Beedle (1962-2018), co-autor de este libro y firmante original del Manifiesto Ágil, fue mi primer maestro de Scrum. Con él tuve el enorme gusto de tomar mi primer curso de Scrum por allá del año 2014, una experiencia súper chévere! **Pero, por favor cuéntanos: ¿Conocías la esencia original de Scrum? ¿Qué opinas sobre la forma en que Scrum ha evolucionado? ¿Qué te pareció?**
26 de abril de 2023
Management 3.0

Niko-Niko calendar: Un registro de la felicidad del equipo

¿Te ha sucedido alguna vez que algún miembro de tu equipo de trabajo se muestra serio y hasta molesto en la oficina, y resulta que tenía algún problema o preocupación en su vida personal? ¿No sabes si algún compañero de trabajo ha tenido un mal día? Y si lo sabes, ¿Sabes si hay algo que puedas hacer para ayudarle? Recuerda que la forma en nos sentimos, felices o no felices, tiene un efecto en todas las áreas de nuestra vida, desde lo familiar hasta lo profesional. Es por esto que los trabajadores felices hacen más y logran más. Precisamente en este punto quiero detenerme un momento para enfocarme en la felicidad y hablar sobre si es posible medirla. ¿Existe algún tipo de encuesta de la felicidad que sea confiable? En el artículo de 2012 "La ciencia detrás de una sonrisa" ((link: https://hbr.org/2012/01/the-science-behind-the-smile text: The science behind the smile)) de Harvard Business Review, entrevistan a Daniel Gilbert, autor del libro "Tropezando con la felicidad" (Stumbling on Happiness), quien** habla de sus investigaciones sobre la felicidad y responde a la pregunta de cómo es posible medir algo tan subjetivo como la felicidad, menciona que la mejor manera para medirla es mediante los informes en tiempo real de las personas ya que son muy buenas aproximaciones de sus experiencias y nos permiten ver el mundo a través de sus ojos**. Daniel Gilbert continúa con que **es posible que las personas no puedan decirnos lo felices que estaban ayer o lo felices que estarán mañana, pero pueden decirnos cómo se sienten en el momento en que les preguntamos "¿Cómo estás?"**. El autor concluye con que hay muchas formas de medir la felicidad e indica que podemos preguntarle a la gente "¿Qué tan feliz estás ahora?" y pedirles que lo califiquen en una escala. Finalmente, un(link: https://wrap.warwick.ac.uk/63228/7/WRAP_Oswald_681096.pdf text: estudio de la universidad de Warwick) indica que las personas más felices son más productivas hasta en un 12% que las personas promedio. **Niko-Niko calendar es una herramienta de Management 3.0 la cual sirve para rastrear y llevar el registro de la felicidad de un equipo a lo largo del tiempo**, lo cual puede ser divertido y ayudar a que las personas se comprometan, ya que cuando los compañeros de equipo comparten cosas personales que suceden a diario, la comunicación genera confianza y empatía. Los detalles de esta práctica pueden encontrarse en la página oficial de Mangement 3.0 (link: https://management30.com/practice/niko-niko-calendar/ text: aquí). Estoy en un equipo de trabajo integrado por 5 personas en el área de desarrollo de software y yo soy el Scrum Master. El equipo se llama Avengers, trabajamos juntos desde hace poco más de 2 años. Dadas las circunstancias actuales de la pandemia, estamos trabajando desde casa desde inicios de 2020. El nivel de compromiso del equipo es muy bueno, pero sentimos que el nivel de motivación de las personas no lo es tanto. Cuando comenzó la pandemia todos en el equipo se fueron a trabajar desde sus casas y esto creemos que esto ha afectado al equipo, pero no se dispone de ninguna herramienta para saber cómo están las personas, especialmente durante el tiempo de confinamiento. Es por esto por lo que cuando escuché sobre esta práctica de Management 3.0 me ayudó a identificar la manera de conocer y registrar el estado de felicidad del equipo de manera oportuna, lo cual fue la principal razón para realizar esta práctica, ¿Cuán felices están las personas? para tratar de conocer y motivar más al equipo de trabajo. Para facilitar la práctica, se creó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida. Se definió una escala utilizando 3 emojis, aunque en tu equipo pueden ajustar esto de acuerdo a como les resulte mejor, por ejemplo, utilizando 4 emojis en lugar de 3, es totalmente válido: (image: 07-niko-niko-caritas_large.webp) En este caso, fueron 3 emojis y cada uno de estos representa: 1) Verde: “gran día” 2) Amarillo: “día regular” 3) Rojo: “mal día” El objetivo de la práctica es que las personas registren diariamente cómo se sienten, saber cómo ha sido su día, para de esta manera poder medir la felicidad de las personas y del equipo. Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción al Niko-Niko calendar y explicación de la práctica. 2. Cada integrante coloque en la casilla del día correspondiente el emoji de acuerdo con cómo ha sido su día. 3. Se platica en equipo cómo se sienten. 4. Cierre. Las acciones que fueron llevadas a cabo como facilitador incluyen la disponibilidad de un tablero Niko-Niko calendar, impulsar a los miembros del equipo a reconocer y registrar cómo se sienten. Un punto importante es mencionar que como equipo se estuvo probando cómo les parecía mejor, si actualizar el calendario por las mañanas al iniciar la jornada, o por la tarde al finalizar el día. Ambas maneras se probaron, y en base a esta experiencia el equipo coincidió en que les parecía mejor llevarlo al final del día, para que su sentir fuera más representativo. (image: 07-niko-niko-practica-01.webp) (image: 07-niko-niko-practica-02.webp) (image: 07-niko-niko-practica-final.webp) El registro que se comenzó a llevar desde el 12 de octubre. El calendario está hecho para registrar solamente los días hábiles y no contar los fines de semana. Se completó el mes de octubre y se creó un nuevo calendario para el mes de noviembre. Durante este periodo de muestra se puede observar lo siguiente: 1. Hubo un periodo en que un miembro del equipo registró un par de días regulares antes de “mal día” durante 3 días seguidos. El compañero mencionó que se estaba comenzando a sentir enfermo, y los días malos corresponden a una gripa. Los días y el fin de semana ayudaron a que el primer lunes de noviembre ya estuviera recuperado y con buena actitud. 2. Se registró un periodo de varios “día regular” de forma consecutiva para otro miembro del equipo, esto nos permitió darnos cuenta de que, al estar estudiando una maestría, en esos días estuvo entregando trabajos y en exámenes, por lo cual se sentía estresado. Los resultados son bastante reveladores, ya que el cómo se sienten las personas, por ejemplo, cosas que les preocupen en su vida personal, afectan en la vida profesional, es por esto por lo que es fundamental darnos un minuto al día para platicar cómo nos sentimos y ver si podemos ayudar en algo como equipo, al menos apoyo emocional. Como facilitador aprendí cuán importante es la felicidad y cómo se sienten las personas y el impacto que esto tiene en la vida laboral. Así mismo, aprendí la importancia de preguntar a los integrantes del equipo cómo se siente o cómo ha estado su día. El equipo aprendió que algo tan sencillo como reunirnos un par de minutos al día para platicar cómo nos sentimos puede ayudar bastante, por ejemplo, en el caso del compañero que estuvo enfermo de gripa todos se mostraron preocupados, inclusive le ayudaron un poco con algunas actividades para que su día fuera menos pesado. Lo mismo sucedió con el miembro del equipo que estaba estresado por las actividades escolares, el apoyo de tus colegas ayuda a que las cosas sean más llevaderas. Mi próximo experimento con esta práctica será utilizar una escala numérica para cada uno de los emojis, de esta manera se pueden “sumar” los emojis y obtener un indicador numérico que funcione como índice de la felicidad del equipo, y poder llevar registros semanales o mensuales sobre cómo se siente el equipo, así como cada una de las personas. La escala numérica puede ser, por ejemplo: 1) Verde: “gran día” = 2 2) Amarillo: “día regular” = 1 3) Rojo: “mal día” = 0 Como consejos, les puedo recomendar los siguientes tips: 1. Prueba con tu equipo registrar su estado de felicidad al iniciar la jornada y al finalizar, antes de decidir con cuál opción se sienten más cómodos y elegirla. 2. Pueden optar por registrar su estado de felicidad de manera individual, pero si se toman 5 minutos para hacerlo todos juntos como equipo, es un buen momento para platicar de cómo se sienten, lo cual es muy positivo para integrar al equipo. 3. Hay que fomentar un ambiente de actitud positiva y apertura, no debes de forzar a las personas a que registren su estado de la felicidad, no es una obligación, sino una invitación abierta. Mi recomendación es que** pruebes en tu equipo qué momento del día se sienten mejor de llenar el calendario, si al inicio o al final de la jornada**. Así mismo, si tienen agendas complicadas pueden no esperar a estar reunidos todos a la misma hora, sino que cada integrante puede llenar individualmente su casilla en el calendario cuando le sea más sencillo, aunque en nuestro caso el hacerlos todos al mismo tiempo permitió dedicar un par de minutos a platicar cómo nos sentimos, lo cual fue enriquecedor. Espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que apliquen Niko-Niko calendar en su equipo, los resultados que obtendrán serán bastante felices.
16 de diciembre de 2020
Management 3.0

¿Cuáles son los motivadores intrínsecos de tu equipo?

Un **motivador intrínseco **es aquel que nos lleva a hacer algo sin una recompensa externa, por ejemplo, haces algo porque te parece disfrutable o interesante, está relacionado con los deseos innatos de las personas de hacer las cosas bien y tener un afán de autocontrol y autodirección para lograr los objetivos. La motivación intrínseca exitosa es el resultado del cumplimiento de los deseos básicos. Por otro lado, los motivadores extrínsecos están basados en recompensas externas como pagos, bonos o promociones. Como líderes, nuestra primordial tarea es mantener motivados a los miembros del equipo, la idea es que fomentemos un ambiente o entorno donde se permita desarrollar los motivadores intrínsecos sobre los extrínsecos, y los identifiquemos correctamente, porque lo que es disfrutable para alguien puede no serlo para otra persona, es por esto que es importante conocer qué motiva a cada individuo. Christine Comaford, en su artículo (link: https://www.forbes.com/sites/christinecomaford/2018/01/20/why-leaders-need-to-embrace-employee-motivation/?sh=3ec0c4e91272 text: "Por qué los líderes necesitan adoptar la motivación de los empleados" (Why Leaders Need To Embrace Employee Motivation)) de 2018 escrito para Forbes, habla sobre un estudio llevado a cabo por la empresa Gallup donde se encontró que solo **2 de cada 10 empleados coindicen firmemente en que su desempeño es gestionado por su gerente en una manera que los mantiene motivados para hacer un trabajo extraordinario**, lo que se ve reflejado en lo que Gallup estima como el **costo de una pobre gestión de empleados** que no están comprometidos, tan solo en Estados Unidos, **produce una pérdida de productividad de entre $960 billones y $1.2 trillones de dólares por año**. El equipo en el que estoy se llama Avengers, trabajamos juntos desde hace poco más de 2 años, está integrado por 5 personas en el área de desarrollo de software, y yo soy el Scrum Master del equipo. Dadas las circunstancias actuales de la pandemia, estamos trabajando desde casa desde inicios de 2020. El nivel de compromiso del equipo es muy bueno, pero no se cuenta con ninguna manera de conocer qué motiva a las personas. Durante algún tiempo hemos estado en búsqueda de herramientas para motivar al equipo, es por eso que decidí aplicar esta práctica creada por Jurgen Appelo, la cual ayuda a identificar los motivadores intrínsecos de las personas en el ambiente laboral. Los detalles de esta práctica pueden encontrarse en el sitio oficial de Management 3.0 (link: https://management30.com/practice/moving-motivators/ text: aquí). Los diez motivadores intrínsecos que menciona Jurgen Appelo, se derivan del acrónimo CHAMPFROGS, este acrónimo es en inglés, los motivadores en español son los siguientes: ● **Curiosidad**: Tengo muchas cosas para investigar y pensar. ● **Honor**: Me siento orgulloso de que mis valores personales se reflejen en mi forma de trabajar. ● **Aceptación**: Las personas que me rodean aprueban lo que hago y lo que soy. ● **Maestría**: Mi trabajo desafía mi competencia, pero aún está dentro de mis habilidades. ● **Poder**: Hay suficiente espacio para que pueda influir en lo que sucede a mi alrededor. ● **Libertad**: Soy independiente de los demás con mi trabajo y mis responsabilidades. ● **Relaciones**: Tengo buenos contactos sociales con las personas de mi trabajo. ● **Orden**: Hay suficientes reglas y políticas para un entorno estable. ● **Meta**: Mi propósito en la vida se refleja en el trabajo que hago. ● **Estatus**: Mi posición es buena y reconocida por las personas que trabajan conmigo. El objetivo de la práctica es identificar y reflexionar sobre la motivación de los integrantes del equipo y cómo afecta al cambio organizacional. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida: (image: 03-moving-motivators-practica-01.webp) (image: 03-moving-motivators-practica-02.webp) Para llevar a cabo la práctica se siguieron los siguientes pasos: 1. Introducción, explicación de cada uno de los 10 motivadores (CHAMPFROGS), así como de la práctica de **Moving Motivators**. 2. Cada participante ordena las imágenes de las cartas de motivadores en orden de importancia para él o ella. (image: 03-moving-motivators-board-01.webp) 3. Lo siguiente es evaluar cómo se siente cada miembro respecto a los motivadores, se mueve cada imagen hacia arriba de la línea central para un cambio positivo, es decir, algo que en mi trabajo haya mejorado mi sentir sobre este motivador en las últimas semanas. De igual manera, la imagen se mueve hacia debajo de la línea para un cambio negativo, es decir, algo que en mi trabajo haya empeorado mi sentir sobre este motivador en las últimas semanas. (image: 03-moving-motivators-board-02.webp) 4. Cada integrante explica sus motivadores y cómo se ha sentido (cambio positivo o negativo) y agrega una nota o comentario para explicar cómo se siente. (image: 03-moving-motivators-board-02_02.webp) 5. Entre todos los integrantes se eligen los motivadores del equipo de trabajo, es decir, identificar en consenso cuáles considera el equipo que son sus principales motivadores, y se ordenan en orden de importancia. (image: 03-moving-motivators-board-03.webp) 6. Se revisan los motivadores del equipo. 7. Cierre. En la siguiente imagen se muestra el tablero final ya terminado: (image: 03-moving-motivators-board-final.webp) Como facilitador aprendí una gran herramienta para ayudar a conocer los motivadores intrínsecos de las personas, ya que nunca con anterioridad se había aplicado alguna herramienta para identificar y conocer qué motiva a cada individuo. Cada persona es única, por lo que es fundamental saber qué la motiva a salir adelante día con día. Los resultados fueron diversos, y se puede observar lo siguiente: ● (C) Curiosidad: Fue el primer lugar con dos miembros, y el segundo y cuarto lugar con otros dos integrantes. ● (G) Meta: Fue el primer lugar con un miembro, el segundo lugar con dos miembros y tercer lugar con otro integrante. ● (M) Maestría: Fue el primer lugar con un miembro y segundo lugar con otro integrante. ● (F) Libertad: Fue el primer lugar con un miembro, y ocupó el segundo y tercer lugar con otros dos integrantes. ● (A) Aceptación: Fue el tercer lugar con dos integrantes. Todos en el equipo aprendimos y nos dimos cuenta de que cada individuo posee sus propios motivadores, y lo que motiva a un integrante puede no motivar en primera instancia a otro integrante. Además, fue muy revelador porque tenemos un par de años de estar trabajando juntos y había cosas que no sabíamos sobre los demás. Finalmente, en el consenso como equipo los motivadores: Curiosidad, Meta y Maestría fueron los tres elementos elegidos en las primeras posiciones, lo cual demuestra el grado en el que a las personas les motiva que su trabajo les proporcione cosas sobre las cuales investigar y les hagan pensar, que su propósito personal de vida se refleje en su trabajo, y que se desafíen a sus competencias. Mi próximo experimento con esta práctica será evaluar de forma periódica cómo se siente cada integrante con respecto al orden de sus motivadores, al menos cada seis meses, así como si ha habido cambio positivo o negativo. Esto servirá de línea base para dar seguimiento a la evolución de cada persona, así como a su sentir respecto a sus motivadores y cómo su trabajo impacta en ellos. La idea es llevar este experimento un paso adelante y revisar con mi gerente los avances para que se tome en cuenta lo que motiva a cada persona y de esta manera tratar de orientarnos en ese sentido: Permitir investigar más, brindar mayor capacitación, permitir trabajar desde casa, etcétera, dependiendo de los motivadores de cada persona, y hablar sobre los resultados en las evaluaciones de desempeño del personal. Esta es una de mis prácticas favoritas de Management 3.0, espero que esta experiencia les resulte de interés y los invito ampliamente a que apliquen **Moving Motivators** con su equipo de trabajo, los resultados que obtendrán serán increíbles.
16 de diciembre de 2020
Management 3.0

Los 12 pasos de la Felicidad :D

La felicidad es una condición subjetiva y relativa, por lo que varía mucho de una persona a otra, es una emoción que se busca alcanzar. Un estudio realizado por la universidad de Harvard demuestra que el 40% de la felicidad de las personas viene de las decisiones que tomamos. Matthew Solan, en su artículo de 2017 (link: https://www.health.harvard.edu/blog/the-secret-to-happiness-heres-some-advice-from-the-longest-running-study-on-happiness-2017100512543 text: "¿El secreto de la felicidad? Aquí algunos consejos del estudio más largo sobre la felicidad") (The secret to happiness? Here’s some advice from the longest-running study on happiness) escrito para Harvard Health Publishing habla sobre el estudio de la **Universidad de Harvard ** para el desarrollo adulto, uno de los estudios de mayor duración sobre la felicidad, el cual siguió a 724 hombre desde que eran adolescentes en 1938.** El estudio encuentra que, conforme la gente envejece, tiene a enfocarse en aquello que los hace felices, cuestiones como relaciones cercanas o hobbies, más que dinero o fama, es aquello que mantiene a la gente feliz a lo largo de su vida. ** El equipo en el que estoy se llama Avengers, trabajamos juntos desde hace poco más de 2 años, está integrado por 5 personas en el área de desarrollo de software, y yo soy el Scrum Master del equipo. Dadas las circunstancias actuales de la pandemia, estamos trabajando desde casa desde inicios de 2020. La búsqueda de la felicidad en la vida de las personas es una parte fundamental, y la forma en nos percibimos, felices o no felices, tiene un efecto en todas las áreas de nuestra vida, desde lo familiar hasta lo profesional. De la misma manera, de acuerdo con una extensiva investigación realizada por Jurgen Appelo, **la felicidad no es algo que se alcance, sino que es un camino, algo que se vive**, por lo que es primordial que contemos con formas de implementarla en nuestra vida diaria. Es en este punto donde Jurgen Appelo sugiere la práctica de **12 Pasos para la Felicidad**, enfatizando la necesidad de implementar estas prácticas en nuestra vida y transportarlas hasta la cultura de la empresa. Los detalles de esta práctica pueden encontrarse (link: https://management30.com/practice/happiness-steps/ text: aquí). Los doce pasos de la felicidad son los siguientes: ● **Agradece** a alguien y se agradecido hacia tus colegas todos los días. ● **Dar algo** a otras personas o hacer posible que otros ofrezcan regalos. ● **Ayuda** a alguien que necesite ayuda, o permitir que los colegas se ayuden mutuamente. ● **Come bien** y hacer que los alimentos buenos y saludables estén fácilmente disponibles para todos. ● **Ejercita **y trabaja con regularidad y facilita que las personas cuiden sus cuerpos. ● **Descansa bien**, duerme lo suficiente y permite que tus colegas refresquen sus mentes. ● **Experimenta cosas nuevas**, pruebas cosas y deja que la gente ejecute todo tipo de experimentos. ● **Camina al aire libre**, disfruta de la naturaleza y permite que la gente escape de la oficina y de la ciudad. ● **Medita** y consigue que las personas aprendan y adopten prácticas de meditación. ● **Socializa**, relacionarse con otras personas, hacer que sea fácil para los colegas desarrollar conexiones. ● **Apunta a una meta** y consigue que la gente entienda y se dé cuenta de su propio propósito. ● **Sonríe** siempre que puedas, aprecia el humor y consigue que tus colegas participen en actividades divertidas. (image: 12-pasos-de-la-felicidad-template-espanol-v02.webp) Puedes descargar esta plantilla de los 12 Pasos de la Felicidad del sitio oficial de Management 3.0 (link: https://management30.com/download/22948/ text: aquí). El objetivo de la práctica es reflexionar sobre la felicidad, revisar cómo se siente cada integrante del equipo en cada uno de los 12 pasos. Además, identificar qué puede hacer cada integrante en cada uno de los 12 pasos para mejorar el nivel en el que se siente. Se propone realizar la práctica con una puntuación numérica que funcione como indicador de la felicidad tanto de manera individual como para el equipo. Para facilitar la dinámica, se utilizó un tablero colaborativo en miro, dado que el equipo trabaja de manera distribuida: (image: 04-12-steps-to-happiness-practica-02.webp) Los pasos que se llevaron a cabo fueron los siguientes: 1. Introducción, explicación de cada uno de los 12 pasos de la felicidad, así como de la práctica. 2. Cada integrante tiene dos columnas: (image: 04-12-steps-to-happiness-board-02.webp) a. “¿Cómo me he sentido?”: Debe de colocar un valor numérico del 1 al 5 de acuerdo con cómo se ha sentido en cada uno de los 12 pasos, donde 1 es el número menor y 5 es el número de mayor puntuación. Por ejemplo: Para el paso “Dar”, un integrante colocó un “4”. b. “¿Qué haré esta semana?: Debe de escribir lo que hará para incrementar el valor numérico asignado a ese paso, algo que pueda realizar durante esa semana. Por ejemplo: Para tratar de incrementar el paso “Dar” de “4” a “5”, el integrante escribió: “Donar las cosas que ya no necesito”. (image: 04-12-steps-to-happiness-board-01.webp) 3. Los integrantes del equipo llenan los 12 pasos. 4. Enseguida se suman las columnas, es decir los 12 números, lo que resulta en un valor numérico o índice individual (el máximo valor individual puede ser 60). (image: 04-12-steps-to-happiness-board-03.webp) 5. A continuación se suman las filas de cada paso, lo que resulta en un valor numérico o índice del equipo (el máximo valor que se puede obtener por el equipo es 25, ya que el equipo está conformado por cinco integrantes). (image: 04-12-steps-to-happiness-board-04.webp) 6. El resultado de la sumatoria de todas las filas es un valor numérico que indica la forma en que se siente el equipo en ese preciso momento con respecto a los 12 pasos de la felicidad. Por ejemplo: En este caso el valor obtenido por el equipo fue “215” (el valor máximo que se puede obtener es 300). (image: 04-12-steps-to-happiness-board-05.webp) 7. Cada integrante explica al equipo cómo se siente en cada uno de los 12 pasos y qué acciones llevará a cabo para incrementar su número. Por ejemplo: Como equipo obtuvimos un “11” en el paso “Caminar al aire libre”. 8. Como equipo se definen las acciones para incrementar el número de cada uno de los 12 pasos de todo el equipo. Por ejemplo: Para el paso “Caminar al aire libre”, el consenso al que llegó el equipo es: “Todos coincidimos en salir a caminar más con nuestras mascotas y familia". 9. Se revisan los resultados finales de todo el equipo. 10. Cierre. El tablero terminado es el siguiente: (image: 04-12-steps-to-happiness-final-board.webp) El equipo se mostró muy motivado con la práctica. El hecho de analizar y hablar de diversas áreas de su vida, como caminar al aire libre, meditar, socializar o hacer ejercicio, fue muy agradable y sirvió para que todos saliéramos de la rutina del trabajo. Como facilitador aprendí la gran importancia de encontrar maneras de vivir e implementar todos esos elementos que integran nuestra felicidad, pero aplicado al equipo al que pertenezco.** El hecho de utilizar valores numéricos para cada uno de los pasos fue muy interesante ya que arrojó valores que pueden ser analizados, como, por ejemplo: ¿Cuáles fueron los pasos con menor calificación?, ¿Cuáles fueron los pasos con mayor calificación? Esto puede ayudar a llevar a cabo acciones particulares para incrementar la calificación de los distintos pasos, lo cual puede ayudar a incrementar la felicidad de los individuos.** Estos resultados numéricos fueron bastante reveladores, y se pueden observar varias cosas, como lo siguiente: ● Los resultados de los 12 pasos de la felicidad de cada miembro del equipo estuvieron entre los valores de “33” y “46”, siendo 60 el valor máximo que se podía alcanzar. Los miembros con los valores más bajos se mostraron abiertos a reconocer que hay áreas de su vida que están descuidadas, como meditar, caminar al aire libre o experimentar cosas nuevas. ● **El paso con mayor calificación como equipo fue “Ayudar”** con un total de “25”. Los miembros del equipo reconocieron que les gusta ayudar y buscan continuamente hacerlo, lo cual les brinda satisfacción. ● **El paso con menor calificación como equipo fue “Meditar”** con un total de “9”. Los miembros del equipo reconocieron que es la actividad a la que asignan menor prioridad y por lo tanto es a la que menos tiempo dedican durante su semana. Los miembros afirman que deben de programar su día y reservar tiempo para meditar, ya que saben que es algo importante. ● El resultado total de los 12 pasos de la felicidad como equipo fue el valor “215”, siendo 300 el valor máximo que se podía alcanzar. Si bien mientras el número sea más alto puede ser considerado como mejor, este resultado no es “bueno” ni “malo”, solo es un indicador del sentir del equipo en un momento particular. Todos en el equipo aprendimos bastante ya que fue muy enriquecedor escuchar a los diversos integrantes hablar sobre cada uno de los 12 pasos en su propia vida. Esta dinámica ayudó a conocernos más ya que se descubrieron cosas que no sabíamos de otros integrantes, como por ejemplo que hay algunos que meditan, o que hay algunos que les gusta darle mantenimiento a su bicicleta a fin de poder usarla durante la semana como ejercicio regular. Mi próximo experimento con esta práctica será establecer un “índice de los 12 pasos de la felicidad”, tomar el valor de 215 como línea base, que fue el resultado actual del equipo, y revisar mensualmente cómo nos sentimos como individuos y como equipo y ver en qué acciones se han estado llevando a cabo, así como si hay algo que se pueda hacer para incrementar ese índice. Espero que esta experiencia que he compartido les resulte de interés y los invito ampliamente a que apliquen “12 pasos de la felicidad” con su equipo de trabajo, los resultados que obtendrán serán totalmente sorprendentes.
16 de diciembre de 2020

El bloc de notas de un Agilista Jedi

Management 3.0

Formando una cultura de aprendizaje continuo

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

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

Product Management

¿Cómo iniciamos? El Tablero de Visión del Producto

Management 3.0

6 consideraciones para recompensar a tu equipo (desde la perspectiva de Management 3.0)

Product Management

Outputs, Outcomes & Impact - (Salidas, Resultados e Impacto)

Scrum

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

Management 3.0

Tarjetas de colaboración: Fomentando conversaciones & armonía

Scrum

El primer libro de Scrum del mundo

Management 3.0

Niko-Niko calendar: Un registro de la felicidad del equipo

Management 3.0

¿Cuáles son los motivadores intrínsecos de tu equipo?

Management 3.0

Los 12 pasos de la Felicidad :D