3. Scrum Master: Líder al servicio del equipo Scrum

En este capítulo, nos adentraremos en la función vital que desempeña el Scrum Master en la implementación de Scrum. El Scrum Master no solo asegura una adopción precisa de Scrum según lo delineado en la Guía de Scrum, sino que también facilita la comprensión y el respeto de su teoría y prácticas a todos los niveles organizacionales. A lo largo de este segmento, desplegaremos un análisis detallado de las diversas actividades, habilidades y responsabilidades que caracterizan esta función, ampliando lo ya explorado en el modelo core de Scrum. Puntos Clave de este Capítulo - Profundizar en la responsabilidad crítica del Scrum Master en la adopción y mejora de Scrum. - Analizar las actividades clave que el Scrum Master facilita dentro del equipo Scrum. - Estudiar las habilidades esenciales que un Scrum Master debe cultivar para liderar con eficacia. - Examinar las responsabilidades a nivel organizacional que incumben al Scrum Master.

3.1 - Habilidades del Scrum Master

Un Scrum Master debería tener un conocimiento profundo del marco Scrum por varias razones:

Como scrum master (SM) es necesario brindar soporte y soluciones al Equipo Scrum y a la organización en general; para esto debe contar con aptitudes y actitudes que contribuyan al liderazgo, a continuación se muestran algunas habilidades que tiene un SM:

Habilidades de liderazgo

Las habilidades de liderazgo en un Scrum Master se refieren a la capacidad de liderar y guiar al equipo para que alcance sus metas y objetivos. Algunas de las habilidades de liderazgo esenciales para un Scrum Master incluyen:

Ejemplo: Durante un proyecto, el equipo se siente inseguro respecto a la nueva tecnología que están utilizando. El Scrum Master, reconociendo la necesidad de liderazgo, organiza una serie de sesiones de capacitación con expertos para familiarizar al equipo con la tecnología, estableciendo así objetivos claros y proporcionando apoyo y orientación.

👉 Tip
Recuerda que un buen líder no sólo dirige, sino también inspira y motiva. Ser un líder en Scrum significa servir al equipo, eliminando obstáculos y ayudando a cada miembro a dar lo mejor de sí.

Habilidades de facilitación

El SM logra que todas las acciones, procesos y tareas sean fáciles de entender para el equipo, además de asegurar que se cuente con el entorno y herramientas necesarias para trabajar. Es necesario que actúe de manera:

Ejemplo: Durante la retrospectiva, algunos miembros del equipo discuten sobre qué metodología de trabajo es la más eficiente. El Scrum Master, como facilitador, interviene para asegurar que todos tengan una oportunidad de expresarse y que la discusión se mantenga centrada en la mejora continua, evitando desviarse hacia debates improductivos.

El Scrum Master facilitando los eventos

El SM como facilitador debe tener en cuenta los siguientes aspectos al momento de moderar un evento:

Habilidades de comunicación

Las habilidades de comunicación en un Scrum Master se refieren a la capacidad de comunicarse de manera efectiva con todas las personas con las que trabaja. Algunas de las habilidades de comunicación esenciales para un Scrum Master incluyen:

Ejemplo: Uno de los desarrolladores, Juan, ha estado teniendo dificultades con una tarea específica. En vez de señalarlo abiertamente y ponerlo en una situación incómoda, el Scrum Master se acerca de manera privada, ofrece feedback constructivo sobre lo que ha observado y escucha activamente las preocupaciones de Juan, buscando soluciones conjuntas.

👉 Tip
Recuerda que la comunicación no es solo hablar, sino también escuchar. Establece canales de comunicación abiertos, promueve la retroalimentación constante y verifica siempre que los mensajes hayan sido entendidos correctamente por todos los miembros del equipo.

Habilidades para la resolución de problemas

Las habilidades de resolución de problemas en un Scrum Master se refieren a la capacidad de identificar y resolver problemas que puedan surgir durante el trabajo con el equipo, esto considerando que No puedes impedir que aparezcan conflictos o problemas, pero puedes gestionarlos para minimizar el impacto al equipo, para esto debes desarrollar:

👉 Tip
En lugar de brindar soluciones inmediatas, guía al equipo a través del proceso de descubrimiento de soluciones. Esto empodera al equipo y les ayuda a desarrollar habilidades de resolución de problemas por sí mismos.

El Scrum Master como Eliminador de impedimentos

Un impedimento es cualquier cosa que obstruye el flujo de trabajo generando retrasos.

Es importante que el SM pueda remover los impedimentos del equipo para garantizar el flujo y a su vez el éxito del Sprint.

Ejemplo: El equipo enfrenta un bloqueo técnico que ha detenido el progreso. El Scrum Master organiza una sesión de tormenta de ideas (brainstorming) donde todos pueden compartir posibles soluciones. Se anima al equipo a pensar de manera creativa, y juntos, logran encontrar un enfoque innovador que resuelve el problema.

Desafíos para el Scrum Master al eliminar impedimentos:

Desafío ¿Cómo lo puedes abordar?
El equipo Scrum no reporta el impedimento.
Por lo tanto el SM desconoce la situación real del ambiente y no puede solucionar oportunamente.		 - Preguntar para identificar falencias del equipo.
- Trabajar en conjunto para solucionar
- Fortalecer las habilidades de comunicación
El equipo se estanca con un impedimento fácil de resolver.
El SM puede actuar oportunamente, hablando con el equipo sin afectar el flujo del proceso, brindando soluciones en tiempo real.		 - Encontrar soluciones aplicables
- Hacer una pausa para despejar la mente
- Analizar el impedimento de manera creativa con el equipo
Falta capacidad y autoorganización en el equipo.
El SM debe conocer la cultura y el contexto organizacional, procesos, proyectos y otros equipos de trabajo para apoyarse y buscar una solución al impedimento.		 - Buscar personal idóneo para completar la capacidad del equipo
- Apoyarse en otros equipos para encontrar la solución al impedimento

Habilidades de enseñanza

El SM debe animar al equipo para aprender nuevos conocimientos, esto permite que el equipo sea multidisciplinario y no se estanque fácilmente. Es necesario que el Scrum Master:

👉 Tip
Aprovecha los momentos informales para enseñar y compartir conocimientos. En ocasiones, una conversación casual puede ser una oportunidad dorada para impartir una lección valiosa. Recuerda, el aprendizaje no siempre tiene que ser estructurado o formal; a veces, los momentos espontáneos dejan las enseñanzas más duraderas.

El Scrum Master como coach y mentor

Como SM sueles entrenar a todo el equipo según sus habilidades y su estilo de trabajo.

Como coach: Su enfoque está en enseñar a los demás a mejorar. Un coach no necesariamente sabe más, busca ayudarte a sacar lo mejor de ti, para que encuentres mejores soluciones con tus propias habilidades.

Como mentor: Su enfoque está en ayudar y guiar a quienes tienen menos experiencia. Un mentor sí es alguien que sabe más que los demás sobre un determinado dominio y usa su conocimiento para guiar a los demás.

Ejemplo: Sara, una nueva integrante del equipo, no está familiarizada con las prácticas de Scrum. El Scrum Master organiza sesiones individuales y grupales de capacitación para enseñarle los conceptos clave. A través de ejercicios prácticos y discusiones, el Scrum Master asegura que Sara comprenda no sólo los procesos sino también los valores y principios detrás de Scrum.

Habilidades complementarias

👉 Tip
Como Scrum Master, predica con el ejemplo en cuanto a la gestión del tiempo. Utiliza herramientas de planificación, establece prioridades claras, aprende a decir "no" cuando sea necesario para asegurarte de que las tareas cruciales se cumplan dentro de los plazos. ¡Recuerda, trabajar inteligentemente es tan importante como trabajar arduamente!

3.2 - Los valores del equipo

Es importante que entre los miembros del equipo se genere y mantenga una filosofía basada en valores que fomenten la confianza, la comunicación y la entrega de resultados. A continuación, se relacionan los valores que se deben promover en un equipo Scrum:

Nota: El Scrum Master promueve los valores en el equipo.

En un equipo Scrum, los valores juegan un papel central en la construcción de una base sólida para la colaboración y la entrega efectiva.

Ejemplo: Tras la planificación de un Sprint, el equipo se da cuenta de que una de las historias de usuario comprometidas es más compleja de lo que inicialmente pensaban. En lugar de relegarla o dividirla, el equipo decide organizarse de forma diferente, redistribuyendo algunas tareas para asegurarse de que todos los elementos comprometidos se entreguen a tiempo.

Ejemplo: A mitad de un sprint, la dirección de la empresa sugiere una nueva funcionalidad que considera urgente. El equipo decide mantenerse enfocado en las tareas comprometidas para ese sprint y propone discutir la nueva solicitud en la próxima reunión de planificación, asegurando que la dirección actual del sprint no se vea comprometida.

Ejemplo: Al final de un sprint, una característica desarrollada no cumple con los estándares de calidad esperados. En lugar de intentar "maquillar" los resultados o posponer la revisión, el equipo comunica abiertamente la situación en la Revisión del Sprint, expone las causas del problema y propone una estrategia de corrección.

Ejemplo: Un miembro nuevo se une al equipo con una forma diferente de trabajar y con herramientas con las que el equipo no está familiarizado. En lugar de resistirse o desestimar su enfoque, el equipo respeta y se toma el tiempo para entender las ventajas que podría traer este nuevo método, valorando la diversidad de experiencia que el nuevo miembro aporta.

Ejemplo: Después de varios días trabajando en una característica, el equipo se da cuenta de que la solución que estaban desarrollando no es óptima. Aunque revertir y cambiar de rumbo podría parecer desalentador, el equipo decide correr el riesgo, ya que creen que es lo mejor para el producto final. Hacen frente al desafío y trabajan juntos para encontrar una solución más adecuada.

Estos valores no sólo fortalecen la relación del equipo sino que también potencian su rendimiento, creando una cultura de excelencia. Cuando estos valores son asimilados por el equipo de Scrum (reforzados continuamente) y con las personas con las que trabajan, la teoría de Scrum que enfatiza en la transparencia, inspección y adaptación se materializa construyendo confianza.

3.3 - Los Pilares de Scrum

Si bien, los 12 principios del manifiesto ágil describen una orientación sobre los principios que se siguen en Scrum, hay 5 elementos que son clave para el buen funcionamiento de este marco de trabajo.

Estos pilares junto a los 12 principios del manifiesto ágil se deberían conocer y aplicar por los miembros del Equipo Scrum. El Scrum Master suele ser el responsable de que estos pilares hagan parte de la cultura del equipo.

1. Auto-gestión en el Equipo Scrum

Para Scrum, es altamente recomendable que el equipo tenga la capacidad de auto-gestionarse, esto significa que son los miembros del equipo quienes eligen la mejor opción de llevar a cabo su trabajo sin ser dirigidos por personas externas al equipo.

La auto-gestión es una característica definitoria de los equipos Scrum, centrada en la confianza, autonomía y responsabilidad de sus miembros. Aquí es donde los equipos no sólo toman decisiones sobre cómo abordar su trabajo, sino que también asumen la responsabilidad de esas decisiones.

A continuación, se listan algunos elementos clave que hace posible la Auto-Gestión del Equipo Scrum:

👉 Tip para el Scrum Master
Las mejores prácticas y herramientas evolucionan con el tiempo. Dedica tiempo para la formación continua y asegúrate de que el equipo esté al día con las últimas tendencias y técnicas en Scrum.

Propiedad y responsabilidad colectiva del producto

Para garantizar una colaboración constante y evitar con el tiempo la aparición de una cultura de la culpa, es importante fomentar una propiedad colectiva del producto, esto significa que todo el Equipo Scrum es dueño del producto, y por tanto cualquiera de sus integrantes podría contribuir al desarrollo de cualquier parte del producto aun cuando no haya sido quien lo desarrolló inicialmente.

Así mismo no deberían existir reconocimientos individuales a los miembros del equipo por sus contribuciones al producto.

👉 Tip para el equipo
Evita la cultura de la culpa: En lugar de buscar a quién culpar, enfócate en cómo resolver el problema.

Colaboración de equipo

La colaboración se da gracias a la constante comunicación que existe en los Equipos Scrum, tanto entre sus miembros como con las Partes interesadas del Proyecto, este concepto es parte integral del Manifiesto Ágil "La forma más eficiente y efectiva de transmitir información hacia y dentro del Equipo de Desarrollo es la conversación cara a cara".

El Scrum Master es el rol responsable de garantizar una sana comunicación entre todas las partes interesadas del proyecto, en especial de su Equipo de Desarrollo.

👉 Tip para el equipo
Fomentar una cultura de feedback constante puede simplificar muchos aspectos del trabajo. Las correcciones tempranas y la orientación adecuada evitan la complejidad de corregir errores más adelante.

Se debe considerar que, según la naturaleza del proyecto, las necesidades de la organización e incluso factores externos, se determinan la ubicación de los miembros del Equipo:

Equipos multifuncionales

Los equipos multifuncionales (también llamadas células ágiles) tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no formen parte del equipo.

Contrario a lo que piensa un equipo multifuncional, no se trata de que todos sus integrantes hagan de todo, se trata de que los integrantes adquieran conocimiento en distintas disciplinas (aplicables a los proyectos de la organización) y así puedan contribuir eficazmente con la colaboración.

La realidad es que incluso cuando un equipo sea experto técnico, siempre necesitarán capacitación adicional, así es que el Product Owner deberá decidir si aprobará el dinero y el tiempo para capacitarse o por el contrario serán los miembros del equipo quienes se encargarán del tema.

Colaboración con el cliente

En los proyectos tradicionales, los clientes por lo general se mantenían a distancia y solo se involucraban al principio y al final del proyecto. En Scrum es altamente recomendable que el cliente participe de las revisiones del producto y brinde retroalimentación en todos los puntos de "inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a las partes interesadas.

Por ejemplo, en otros Marcos Ágiles como XP, es obligatorio que el Cliente forme parte del equipo.

El cliente (o sus representantes) deberían trabajar junto al Product Owner para definir las historias de usuario y detallar dichas historias antes o durante las reuniones de planificación.

El cliente y las partes interesadas por lo general participan en la Reunión de Revisión de los Sprint y, dependiendo de la relación entre el cliente y el Product Owner, el Cliente incluso podría participar de algunas reuniones de Retrospectiva de los Sprint.

Gestionar el conocimiento

Dado que los equipos autogestionados se responsabilizan de su aprendizaje y crecimiento, la gestión del conocimiento se convierte en un aspecto crucial. Esto puede tomar la forma de compartir habilidades, aprender nuevas tecnologías o técnicas, o incluso la formación entre pares.

Gestionar el conocimiento permitirá identificar, recopilar, organizar, transferir y retener el conocimiento necesario para dar soporte a todo el personal en sus actividades laborales, para la toma de decisiones bien fundadas y para aumentar la productividad.

👉 Tip para el Developer
Si bien es esencial documentar, es fundamental preguntarte: "¿Esta documentación agrega valor?". Evita la creación de documentos extensos y en su lugar, apunta a documentaciones claras y concisas que sean realmente útiles.

Motivación del equipo

Los equipos Scrum se caracterizan por mantener un enfoque hacia la entrega frecuente de resultados; y aunque los miembros del equipo son conscientes de la responsabilidad que esto implica, existe un factor de fondo que facilita el impulso y el esfuerzo para cumplir con los objetivos: la motivación.

La motivación hace referencia a que los miembros del equipo mantengan determinada conducta y estado de ánimo que propicien las interacciones sanas y el alto rendimiento en el proyecto.

Según cómo se maneje la motivación en el equipo Scrum, eventualmente la motivación extrínseca tiende a convertirse en motivación intrínseca, pues los miembros del equipo van adaptando su conducta y mejorando su rendimiento para cumplir los objetivos sin necesidad de que todo el tiempo estén recibiendo recompensas o algo a cambio.

2. Simplicidad

Scrum no sería considerada una metodología ágil de no ser por su simplicidad, es por ello que se intenta al máximo reducir la burocracia en sus prácticas, se trabaja con los artefactos que son esenciales para el equipo y se sigue un flujo de prácticas simple, sin descuidar todos los elementos necesarios para la correcta gestión del producto, eliminando cualquier trabajo superfluo o que no aporte valor.

👉 Tip para el Product Owner
Simplicidad en la Arquitectura del Producto: Una arquitectura bien diseñada y simple facilita la adición de nuevas características y la corrección de errores. La sobrecarga arquitectónica puede ralentizar considerablemente el desarrollo.

A través de la simplicidad, se puede acelerar la entrega, mejorar la comunicación y reducir los riesgos asociados con la complejidad.

Algunos elementos que hacen posible la Simplicidad en Scrum son:

Maximizar el trabajo no realizado

La simplicidad no solo trata de hacer las cosas de manera simple, sino también de identificar y eliminar cualquier tarea que no sea esencial para alcanzar los objetivos del producto. Es una forma de ser eficiente y focalizado, dedicando recursos solo a lo que realmente importa.

Clara definición de "Hecho" (terminado)

Una definición clara y concisa de lo que significa "hecho" para un elemento del producto ayuda a evitar el trabajo innecesario. Si el equipo entiende perfectamente cuándo un ítem está completo, se evita el esfuerzo extra y las revisiones innecesarias.

Priorización

La simplicidad se logra también a través de una adecuada priorización de las tareas. Al centrarse en lo que realmente aporta valor al cliente o usuario final, el equipo puede evitar la complejidad y concentrarse en lo esencial.

Comunicación efectiva

Las soluciones simples a menudo emergen de una comunicación clara y efectiva. Al fomentar un diálogo abierto y honesto entre los miembros del equipo y con los interesados, se pueden identificar y eliminar obstáculos, malentendidos y redundancias.

👉 Tip para el equipo
Cuanto más dependencias existan entre tareas o equipos, más complejo se vuelve el trabajo. Al minimizar estas dependencias, no solo se simplifica el proceso, sino que se mejora la velocidad y fluidez del trabajo.

Refactorización continua

La simplicidad también está en el código. Refactorizar regularmente el código para mantenerlo limpio y manejable es esencial. Un código más simple es más fácil de entender, modificar y mantener.

Limitar el trabajo en progreso (WIP)

Al limitar la cantidad de trabajo en progreso, los equipos pueden centrarse en finalizar tareas antes de comenzar nuevas. Esto reduce la complejidad y facilita una entrega más rápida y eficiente.

Usar herramientas de software

Las herramientas de software dedicadas a la gestión de proyectos ágiles se han consolidado como elementos cruciales para simplificar procesos y tareas. Estas herramientas ofrecen diversas ventajas, entre las cuales destacan:

👉 Tip para el equipo
No todas las herramientas sofisticadas son las mejores. A veces, las herramientas más simples, pero funcionales, pueden ser más eficaces y fáciles de usar para el equipo.

3. Enfoque en el valor para los interesados

Dentro del marco Scrum, centrarse en entregar valor constante y significativo para los interesados es primordial. Este pilar se fundamenta en la premisa de que la satisfacción del cliente debe ser prioritaria y continua.

Para asegurarse de que el equipo está en la dirección correcta, es esencial tener en cuenta los siguientes puntos:

👉 Tip para el Scrum Master
Reconoce y celebra cuando el equipo entregue valor real a los interesados. Esto motiva al equipo y refuerza la cultura centrada en el valor.
👉 Tip para el Product Owner
Después de la entrega de un incremento o producto completo, realice encuestas para comprender qué tan satisfechos están los interesados y qué áreas se pueden mejorar.

4. Disciplina

La disciplina es esencial en Scrum para garantizar que el equipo trabaje armoniosamente y cumpla con los objetivos trazados. Esta rigurosidad no sólo asegura la satisfacción del cliente sino también el funcionamiento fluido del equipo.

Lineamientos que forman parte de la disciplina del equipo:

👉 Tip para el Scrum Master
La disciplina no significa rigidez: Si un lineamiento o práctica no está funcionando, el equipo debe sentirse empoderado para discutirlo y hacer los ajustes necesarios.

Lineamientos establecidos por el equipo Scrum

Estos son los acuerdos o reglas internas que el Equipo Scrum define para garantizar una colaboración y comunicación eficaces entre sus miembros. Por ser autoimpuestos, estos lineamientos refuerzan el pilar de auto-gestión y aseguran que el equipo se adueñe de su proceso. Gracias al pilar de la auto-gestión, son los miembros del Equipo Scrum, quienes establecen sus propios lineamientos, claro, considerando el cumplimiento de las reglas establecidas por la organización.

Los lineamientos del equipo suelen registrarse en un “Plan de Colaboración del equipo Scrum”. Estos lineamientos pueden abordar aspectos como los métodos y herramientas de comunicación preferidos, los horarios de las reuniones, la asignación de roles específicos dentro del equipo, penalizaciones por incumplimientos, los valores del equipo, o las normas sobre cómo y cuándo se realizarán ciertas tareas.

👉 Tip para el Scrum Master
Los lineamientos pueden requerir ajustes a medida que el equipo madura. Dedique tiempo en las retrospectivas para revisar y actualizar estos acuerdos.

Lineamientos establecidos por la organización (reglas de negocio):

Estas son las directrices o reglas que la organización establece, y que todos los equipos, incluidos los Equipos Scrum, deben seguir. Pueden abordar áreas como los estándares de codificación, las políticas de seguridad de la información, los procedimientos de aprobación y revisión, entre otros. Estas reglas aseguran que, aunque el equipo tenga autonomía, su trabajo sigue estando alineado con los objetivos y requisitos más amplios de la organización.

Bloques de tiempo (time-box)

El marco de Scrum hace un uso extensivo del concepto de time-boxing, donde cada evento tiene una duración máxima asignada. Este enfoque garantiza que las ceremonias o eventos no se prolonguen innecesariamente y que el trabajo se realice de manera puntual y eficiente. Respetar estos bloques de tiempo es crucial para mantener la disciplina y el ritmo del equipo.

Algunas ventajas de establecer y cumplir los Bloques de Tiempo asignado son los siguientes:

Recuerda los bloques de tiempo de los eventos de Scrum:

Definición de terminado (DoD) y criterios de aceptación

La Definición de Terminado es una lista acordada de criterios que deben cumplirse para que una tarea o característica se considere "terminada". Asegura que todo el trabajo cumpla con un estándar mínimo de calidad y esté listo para ser entregado al cliente o puesto en producción.

Los criterios de aceptación, por otro lado, son requisitos específicos que una tarea o característica debe cumplir para ser aceptada por el cliente. Estos criterios ayudan a aclarar las expectativas y garantizar que el equipo esté trabajando hacia el mismo objetivo.

👉 Tip para el Developer
Aunque puede ser tentador manejar múltiples tareas a la vez, la multitarea puede disminuir la calidad y eficiencia del trabajo. Enfócate en una tarea a la vez y asegúrate de que se complete según la Definición de Terminado.

5. Desarrollo iterativo

Dentro de Scrum, el proceso de trabajo se lleva a cabo mediante ciclos repetitivos conocidos como Sprints. Estos Sprints son el núcleo del enfoque iterativo de Scrum, permitiendo flexibilidad y adaptabilidad a lo largo del proyecto.

A diferencia de un enfoque de desarrollo tradicional, que busca tener un plan detallado desde el comienzo, el enfoque iterativo reconoce la naturaleza cambiante del desarrollo de productos y servicios. Al adoptar un enfoque de desarrollo iterativo, Scrum permite a los equipos responder a los cambios y adaptarse a las necesidades emergentes de los clientes, el mercado y la organización.

Ventajas del Desarrollo Iterativo:

👉 Tip para el Scrum Master
Promueve una cultura donde cada miembro del equipo esté comprometido con la mejora continua, no sólo en términos del producto sino también en términos de procesos y colaboración.

3.4 - El Scrum Master y los eventos

En Scrum cada evento (ceremonia) tiene un propósito específico, diseñado para maximizar la transparencia, la colaboración y la eficiencia. El Scrum Master, a menudo considerado como el guardián de la agilidad del equipo, juega un papel esencial en estos eventos. Su responsabilidad no se limita a la simple organización o facilitación; va mucho más allá, actuando como un catalizador que asegura que cada ceremonia genere el máximo valor, alineando al equipo con los valores de Scrum.

En esta sección, exploraremos en detalle cómo el Scrum Master navega por cada evento, qué se espera de él y cómo su participación activa puede marcar la diferencia en la dinámica y resultados del equipo Scrum.

El Scrum Master en la Planificación del Sprint

Caso práctico: Durante una sesión de planificación del sprint, algunos desarrolladores muestran confusión sobre una historia de usuario. El Scrum Master, Pablo, interviene: "Vamos a aclarar esta historia antes de continuar". Facilita una sesión de preguntas rápidas con el Product Owner, María, eliminando las dudas. Cuando llega el momento de las estimaciones, Pablo propone un "Planning Poker", logrando consenso. Al finalizar, recalca la importancia de mantener la comunicación abierta durante el Sprint.

👉 Tip para el Scrum Master
Asegúrate de que todas los elementos seleccionados para el Sprint estén claros y bien definidos. Si notas que hay dudas o incertidumbre, tómate un momento para clarificarlas con el Product Owner antes de que el equipo empiece a estimar.

El Scrum Master en el Daily

Caso práctico: Al tercer día del Sprint, los Developers se reúnen puntualmente para el Daily Scrum. Pablo, el Scrum Master, se asegura de que todos estén presentes y de que se inicie a tiempo. Cuando Sofía, una Developer, menciona que está teniendo problemas técnicos con una herramienta, Pablo toma nota del impedimento para tratarlo después del Daily. Aunque Pablo está trabajando en una tarea específica de este Sprint, mantiene su participación breve y centrada, como si fuera otro Developer. Al finalizar, Pablo recuerda a todos la importancia de ser consistentes con la hora y el lugar del Daily, reforzando la rutina y previsibilidad.

👉 Tip para el Scrum Master
Si durante el Daily un Developer empieza a profundizar demasiado en un impedimento, tú como Scrum Master debes intervenir amablemente y recordar al equipo que el Daily tiene una duración limitada. Sugiere abordar el impedimento en detalle justo después del Daily o programar un momento específico para tratarlo, asegurando que el foco del Daily se mantenga en la actualización rápida de cada miembro del equipo.

El Scrum Master durante el desarrollo del Sprint

Caso práctico: A mitad del Sprint, Pablo, el Scrum Master, nota que el equipo está un poco detrás de lo planificado. Un impedimento principal es la falta de acceso a un servidor que se identificó en el Daily. Pablo toma la iniciativa, habla con el equipo de infraestructura y resuelve el acceso al servidor al día siguiente.

Días después, observa una discusión entre Sofía y Jorge (dos Developers) sobre la mejor manera de implementar una función. Pablo facilita una breve sesión para comprender los puntos de vista y logra que ambos lleguen a un acuerdo, manteniendo el ambiente armonioso.

Finalmente, al aproximarse el final del Sprint, Pablo realiza pequeñas revisiones con los Developers para asegurarse de que todos los elementos del trabajo estén alineados con los criterios de aceptación y la Definición de Terminado (DoD).

👉 Tip para el Scrum Master
Mantente disponible y accesible. Los impedimentos pueden surgir en cualquier momento, y tu capacidad para actuar rápidamente puede hacer la diferencia entre un Sprint exitoso y uno problemático.

El Scrum Master en la Revisión del Sprint

Caso práctico: Al finalizar el Sprint, es momento de la revisión. Pablo, el Scrum Master, asegura que la sala de reuniones está lista y que todos los recursos tecnológicos funcionan correctamente para evitar interrupciones.

Mientras Carla, el Product Owner, se prepara para revisar las características que completaron los Developers durante el Sprint, Pablo se mantiene alerta para moderar y garantizar que se respeten los tiempos y que todos los miembros tengan la oportunidad de participar.

Pablo también se encarga de recopilar comentarios y preguntas que surgen durante la presentación, y se asegura de que, al finalizar, el equipo y los stakeholders (si los hay) discutan el progreso en relación con el Objetivo de Producto.

Una vez terminada la revisión, Pablo recoge feedback sobre la revisión, buscando oportunidades de mejora para las próximas sesiones.

👉 Tip para el Scrum Master
No te enfoques únicamente en lo que se completó: Asegúrate de celebrar los logros del equipo y reconoce los esfuerzos. Al mismo tiempo, fomenta una discusión abierta sobre lo que no se logró y las razones detrás de ello, para crear un ambiente de aprendizaje continuo.

El Scrum Master en la Retrospectiva del Sprint

Caso práctico: Tras la Revisión del Sprint, Pablo, el Scrum Master, organiza la Retrospectiva. Pablo comienza recordando la importancia de la sinceridad y el respeto mutuo durante el evento, y decide emplear la técnica "Estrella de Retro" para abordar distintas facetas del trabajo del equipo. Como facilitador, cuando un punto particularmente delicado sale a la luz, Pablo interviene para asegurarse de que la discusión sea productiva y enfocada en las soluciones, y va tomando notas de lecciones aprendidas y áreas de mejora. Al final, se asegura de que todos los acuerdos se registren y sean visibles para el próximo Sprint. Agradece al equipo por su compromiso y les anima a implementar las mejoras acordadas.

👉 Tip para el Scrum Master
Cultiva un ambiente seguro y de confianza: Recuerda que la Retrospectiva no es un espacio para señalar errores individuales, sino para identificar áreas de mejora como equipo. Fomenta la empatía y escucha activa, evitando juicios prematuros o asumir posturas defensivas.

3.5 - Técnicas útiles para el Scrum Master

Para guiar el Daily Scrum

Una de las dudas al momento de llevar a cabo el daily es saber quién se supone que debe hablar primero y en qué orden, cómo mantener la atención, por lo que se proponen las siguientes estrategias:

Pasa la ficha (token de habla)

Esta técnica busca estructurar la comunicación y asegurar una participación activa y ordenada de todos los miembros. Se utiliza un objeto (pelota, juguete, etc.) para determinar quién habla a continuación. Sólo la persona que tiene el objeto puede hablar y lo entrega aleatoriamente a otra persona para asegurar que todos prestan atención. Con esta estrategia se evitan interrupciones, se asegura que todos sean escuchados y puede agregar un elemento de diversión a la reunión que puede aliviar la tensión y hacer que la reunión sea más amena.

Toma una carta

Esta es una técnica útil para evitar la monotonía y dar a todos una oportunidad de hablar en diferentes órdenes cada día. Al comienzo del Daily, se reparten cartas numeradas a los miembros del equipo. El número en la carta determinará el orden de habla.

Caminar por el tablero

En lugar de que cada miembro del equipo simplemente responda las tres preguntas tradicionales, el equipo puede "caminar" por el tablero de Scrum, abordando cada historia de usuario o tarea, desde la más alta prioridad hacia abajo (será imprescindible que el tablero esté actualizado). Con esta estrategia se mantiene el enfoque en el trabajo real, se pueden identificar bloqueos de manera efectiva y se garantiza que las tareas más críticas sean discutidas.

Estas técnicas no son excluyentes y se pueden combinar según las necesidades del equipo. Lo más importante es mantener el propósito del Daily Scrum: asegurarse de que el equipo esté alineado, identificar bloqueos y tomar medidas para avanzar eficazmente hacia el objetivo del sprint.

Recomendaciones adicionales para el Daily Scrum

A continuación se presentan recomendaciones para mejorar la ejecución del daily, lograr que se cumpla con los objetivos de este evento, y mantener la atención del equipo:

Para guiar la Retrospectiva del Sprint

Es muy común que el equipo pueda perder el interés en participar en la retrospectiva por considerarla aburrida, por lo que existen diversas técnicas que facilitan la transparencia y la adaptación.

Retrospectiva de las 4L's

Algunos miembros del equipo suelen decir cosas como "si tan solo tuviéramos...", "Ojalá tuviéramos...", o tal vez digan cosas como "adivina lo que descubrí ...", "realmente me encantó ..."

La retrospectiva de 4Ls está diseñada para que las personas compartan esos pensamientos con el objetivo de mejorar continuamente.

Retrospectiva del barco rápido (speed boat)

Speed Boat es una técnica en la que los miembros del equipo simulan que son tripulantes en un barco, el cual debe llegar a una isla (que representa el Objetivo del Producto). Es una forma visual y metafórica de identificar lo que ayuda y obstaculiza al equipo.

Nota: Se pueden usar notas adhesivas para identificar cada aspecto.

Comenzar, Detener, Continuar (Start, Stop, Continue)

Los miembros del equipo escriben acciones que les gustaría que el equipo comience a hacer, detenga y continúe haciendo. Esta técnica es sencilla, pero efectiva, para identificar rápidamente áreas de mejora y aquellas en las que el equipo está yendo bien.

Mad, Sad, Glad

Esta técnica busca revelar las emociones del equipo sobre eventos, decisiones y circunstancias que ocurrieron durante el Sprint. Se prepara un tablero dividido en tres secciones: Mad (Enojado), Sad (Triste) y Glad (Feliz). Se puede usar un tablero físico con post-its o mediante herramientas digitales.

Cada miembro del equipo reflexiona sobre el sprint pasado y escribe en tarjetas o post-its individuales las cosas que les hicieron sentir enojados, tristes o felices (una tarjeta por cada sentimiento); y colocan sus tarjetas en la sección correspondiente del tablero. Cuando todos hayan terminado, uno por uno explica brevemente por qué escribió cada punto.

Una vez que todos han compartido sus sentimientos se discuten los patrones o temas recurrentes que surgen. ¿Hay muchos post-its sobre un tema particular en la sección "Mad"? Eso podría ser una señal de un problema que necesita ser abordado. Al profundizar en las causas subyacentes de los sentimientos, especialmente en los que generan emociones fuertes,puede revelar problemas más profundos o áreas de mejora.

Basándose en la discusión, se identifican las acciones específicas que el equipo puede tomar para abordar los problemas o circunstancias que causaron emociones negativas y para reforzar lo que causó emociones positivas.

Estrella de Retro (Starfish Retrospective)

Esta técnica ayuda al equipo a reflexionar sobre diferentes áreas y decidir qué deben comenzar a hacer, dejar de hacer, continuar haciendo, hacer más y hacer menos.

Dibuja una estrella o estrella de mar en un tablero con cinco secciones: "Comenzar", "Detener", "Continuar", "Hacer más" y "Hacer menos". Cada miembro del equipo escribe en tarjetas o post-its sus opiniones o comentarios sobre lo que el equipo debe comenzar a hacer, dejar de hacer, etc. y los colocan en la sección correspondiente de la estrella.

Se conduce una discusión sobre cada sección. ¿Hay consenso sobre ciertos puntos? ¿Hay ideas contradictorias? Se identifican y priorizan las acciones específicas que surgieron de la discusión.

3.6 - Emisores de información útiles para el Scrum Master

El término "emisor de información" no hace parte de los conceptos core de Scrum. Sin embargo, en el contexto de la comunicación y la gestión ágil de producto, los emisores de información son herramientas diseñadas para mostrar el estado actual de los Sprints o del producto en su totalidad.

Estos instrumentos ofrecen una visualización clara y concisa de tareas, progresos y obstáculos, facilitando la transparencia y permitiendo un seguimiento y control efectivos. Sirven como medios esenciales para que todos los involucrados, desde el equipo Scrum hasta los stakeholders, tengan una comprensión clara del avance y estado del trabajo.

El Scrum Board

El Scrum Board o también conocido como tablero Scrum es una adaptación del tablero Kanban que nos permite dar seguimiento a cada Sprint Backlog dentro del equipo Scrum.

El Scrum Board es un emisor de información que le permite al Equipo garantizar la transparencia en los Sprints, mantiene la coordinación y permite realizar al Scrum Master sus labores de Inspección.

Comúnmente está compuesto por 4 columnas: Pendiente (to do), En Progreso (in progress), En Prueba (testing), Terminado (done).

scrum-board

Cada elemento por desarrollar debe ponerse en una tarjeta individual, y dado que el Scrum Board se actualiza constantemente, todas las tarjetas deberán pasar por las 4 columnas. (No se pueden hacer saltos de columnas).

Aclaraciones sobre el Scrum Board

Burndown chart del Sprint

El “Burndown Chart” es un emisor de información que muestra la cantidad de trabajo pendiente en el Sprint actual en función del tiempo.

Es un emisor gráfico de 2 dimensiones:

burndown-chart

Al inicio del Sprint, la cantidad de trabajo restante es la más alta y, a medida que se avanza el Sprint, esta cantidad debería disminuir, "quemándose" (burn) el trabajo hasta llegar a cero al final del Sprint.

El Burndown Chart es una herramienta esencial para los equipos Scrum ya que les permite visualizar diariamente su progreso, identificar posibles problemas y ajustar su ritmo de trabajo si es necesario para cumplir con el Objetivo del Sprint (Sprint Goal).

Aclaraciones sobre el Burndown Chart

Diagrama de flujo acumulado

El Diagrama de Flujo Acumulado (CFD - Cumulative Flow Diagram) es un emisor de información bastante útil para la elaboración de informes y el seguimiento de los resultados del proyecto; y se originó a partir de la metodología Kanban.

Este emisor de información muestra el progreso del producto respecto a los ítems del Product Backlog, y se construye un único diagrama de flujo acumulado por producto.

Este gráfico se compone de dos ejes; el eje vertical "Y" muestra la cantidad de ítems (como tareas, características, user Historias de Usuario). El eje horizontal "X" muestra el tiempo, usualmente días, semanas o meses.

flujo-acumulado

Cada área coloreada en el gráfico representa un estado o categoría diferente del flujo de trabajo:

Aclaraciones sobre el Diagrama de Flujo Acumulado:

Registro de obstáculos/impedimentos

El registro de obstáculos, o también llamado registro de impedimentos es una herramienta que se utiliza para llevar un registro y seguimiento de los obstáculos o bloqueos que impiden o ralentizan el progreso del equipo Scrum. Estos impedimentos pueden ser cualquier cosa que obstruya el flujo de trabajo del equipo, desde problemas técnicos hasta cuestiones organizativas.

Un impedimento es cualquier factor que impide que el equipo alcance su productividad potencial. Puede ser algo interno, como un desafío técnico o falta de habilidades específicas, o externo, como la espera de una aprobación de otro equipo o departamento.

Mantener un registro de impedimentos ayuda a asegurar que los problemas no se pasen por alto y que se les dé la debida prioridad. También proporciona una visión histórica que puede ser útil para futuras retrospectivas y para identificar patrones o problemas recurrentes.

Aclaraciones sobre el registro de impedimentos

Registro de lecciones aprendidas

Registrar las lecciones aprendidas es una parte fundamental para la mejora continua de las prácticas Scrum dentro de una organización. En esta herramienta se registran las prácticas, experiencias, conocimientos y recomendaciones que favorecieron el desempeño del equipo en términos de costo, tiempo y calidad, también se registran aquellos errores que se cometieron y a los que se les dió solución. Estas soluciones hacen parte de las lecciones aprendidas, útiles para resolver problemas similares en el futuro.

Las lecciones aprendidas, además, favorecen el aprendizaje organizacional y la gestión del conocimiento. Así que las lecciones aprendidas deben almacenarse, alimentarse y transferirse de manera apropiada. Para esto, es importante que cada lección tenga una estructura para facilitar su búsqueda, como por ejemplo:

Aclaraciones sobre el registro de lecciones aprendidas:

Portafolio de proyectos

El portafolio de proyectos consiste en un registro de información histórica, esta información podría ser útil (por ejemplo) cuando la organización empieza un proyecto similar a uno que haya ejecutado en el pasado y por tanto algunos elementos sean similares, esto reduce el tiempo de planificación, desarrollo, revisión, implementación y/o cierre, además de hacer uso de las lecciones aprendidas y brindar los insumos para la gestión del conocimiento.

Al igual que las lecciones aprendidas, el portafolio de proyectos debería tener información detallada y organizada que permita su alimentación, almacenamiento y transferencia. Un software específico para la gestión del portafolio de proyectos es útil, por lo que una organización debería considerar esta posibilidad.

Algunos de los elementos que podrían incluirse en el portafolio de proyectos son: