Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem  , abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

El mito de hoy tiene que ver con cómo se resuelven los problemas que dificultan el trabajo de un equipo de desarrollo. Desde un router de wifi hasta un flujo constante de solicitudes de reunión desde fuera del equipo. Y desde aclarar el trabajo poco claro hasta resolver un conflicto entre miembros.

Nos hemos reunido con unos cuantos equipos en los que Scrum Master tiene un trabajo de tiempo completo para resolver este tipo de problemas o “impedimentos”, como se los llama. Algunos Scrum Masters hacen todo lo posible para crear su propia ‘Junta de Impedimentos’ e invitan al Equipo de Desarrollo a poner nuevos impedimentos para que los resuelvan. Hoy rompemos el mito de que es responsabilidad de Scrum Master resolver todos los problemas que dificultan el Equipo de Desarrollo.

Rompiendo el mito

La Guía Scrum describe claramente los diversos servicios que proporciona un Scrum Master. Uno de ellos es eliminar los impedimentos al progreso del Equipo de Desarrollo. A primera vista, esto parece apoyar el mito de hoy pero ‘impedimento’ es una palabra clave importante aquí. Con demasiada frecuencia, se supone que los impedimentos son los problemas que surjan durante el Sprint. Pero no es así como debe entenderse esta responsabilidad.

¿Qué hace que algo sea un ‘impedimento’?

Los impedimentos son aquellos problemas que obstaculizan el progreso de un Equipo de Desarrollo y se encuentran fuera de su capacidad para resolver por sí mismos. Esto vincula fuertemente los impedimentos con otro concepto que es fundamental para Scrum: la autoorganización. El trasfondo aquí es que, dado que el desarrollo de software es una tarea muy compleja e impredecible, es probable que surjan todo tipo de problemas inesperados durante un Sprint.

Ejemplos de tales problemas inesperados son:

• Miembros del equipo se enferman
• Problemas con el entorno de desarrollo.
• Una laptop dañada
• No disponibilidad del propietario del producto
• Conflicto entre los miembros del equipo
• Errores en el entorno de producción.

Se hace una gran demanda a los Equipos de Desarrollo para que utilicen su experiencia profesional, creatividad e inteligencia colectiva para resolver los problemas a medida que surgen. Dentro de Scrum, la naturaleza auto-organizativa de un Equipo de Desarrollo puede entenderse por su capacidad para resolver los problemas que enfrentan, sin tener que delegar la propiedad del problema a personas ajenas al equipo. En ese sentido, preferimos explicar los impedimentos como aquellos problemas que, cuando se resuelven, mejoran las posibilidades de que el Equipo de Desarrollo pueda resolver problemas similares por su cuenta la próxima vez que ocurran.

Los equipos de desarrollo pueden resolver muchas categorías de problemas, como aclarar especificaciones poco claras, solucionar problemas en una implementación o incluso la resolución de un conflicto dentro del equipo.

La diferencia puede parecer trivial, pero las consecuencias no lo son. 

¿Es un equipo de desarrollo realmente auto-organizado cuando todos los problemas que surgen necesitan un Scrum Master para resolverlos? 

¿Qué sucede cuando solo el Scrum Master puede resolver un conflicto entre los miembros del equipo? 

¿Qué sucede cuando solo el Scrum Master puede ayudar al equipo de desarrollo a aclarar las especificaciones poco claras con el Product Owner, o desglosar grandes porciones de trabajo? 

¿Qué sucede cuando solo el Scrum Master puede resolver problemas de infraestructura? 

Un Scrum Master que resuelve la mayoría de los problemas que surgen no le está haciendo ningún favor a un Equipo de Desarrollo. Él o ella está impidiendo activamente la capacidad (crecimiento) del Equipo de Desarrollo para resolver sus propios problemas.

Algunos ejemplos reales de problemas e impedimentos.

Toda esta charla sobre “autoorganización” e “impedimentos” sigue siendo bastante abstracta. Así que vamos a desglosarlo en algunos ejemplos concretos con los que trabajar.

Ejemplo # 1: Problemas de infraestructura

Supongamos que un equipo de desarrollo tiene problemas con su infraestructura. Al no poder implementar aplicaciones por su cuenta, dependen de un equipo externo. El día anterior a la revisión de Sprint, el equipo de desarrollo está teniendo problemas con una implementación. Se levanta un impedimento durante el Daily Scrum, y Scrum Master se encarga de resolverlo.

El problema que se plantea es solo un síntoma de un impedimento más profundo.; la incapacidad del Equipo de Desarrollo para realizar sus propias implementaciones o, al menos, resolver problemas relacionados con la implementación. Al resolver solo el problema en cuestión, el Scrum Master no ayuda al Equipo de Desarrollo a mejorar su capacidad para resolver problemas similares por su cuenta. En su lugar, el Scrum Master puede abordar el impedimento real ayudando al equipo a encontrar formas de resolver los problemas de implementación por su cuenta. Una solución podría ser agregar las habilidades o las personas al Equipo de Desarrollo que se necesitan para hacer esto. Otra solución podría ser que el equipo configure y administre su propia infraestructura (DevOps). Una solución más de baja tecnología podría ser crear canales de comunicación entre el Equipo de Desarrollo y las personas capaces de resolver problemas en implementaciones (por ejemplo, enlaces). Cualquiera que sea la solución.

Ejemplo # 2: Conflicto de equipo

Otro ejemplo. Supongamos que un Equipo de Desarrollo está tratando con dos miembros que no pueden soportarse entre sí. En lugar de hablar sobre el problema en sí mismos, se delega al Scrum Master para que lo resuelva. El impedimento real aquí es la incapacidad del equipo para lidiar con sus propios conflictos. Quizás no haya seguridad psicológica dentro del Equipo de Desarrollo para hablar de ello. O las personas no saben cómo plantear conflictos o carecen del coraje para hacerlo. Al resolver solo el problema, Scrum Master no ayuda al Equipo de Desarrollo a mejorar su capacidad para resolver problemas similares por su cuenta. En su lugar, Scrum Master podría facilitar una sesión donde se ventilen las frustraciones y donde el equipo medie las soluciones (en lugar de entregar una). Scrum Master puede modelar el tipo de comportamiento necesario para la resolución de conflictos,

Ejemplo # 3: No hay suficiente trabajo

Un último ejemplo. Supongamos que un Equipo de Desarrollo se encuentra en la posición donde la mitad del equipo no tiene nada que hacer. Esto se plantea como un impedimento durante el Daily Scrum, y Scrum Master tiene la tarea de encontrarles algo de trabajo. El impedimento real aquí es que, aparentemente, el Equipo de Desarrollo no está colaborando de manera que todos puedan contribuir a lograr el Objetivo Sprint. En lugar de encontrar trabajo, Scrum Master haría bien en investigar por qué sucede esto. Él o ella podría abordar esto durante una retrospectiva Sprint temática. O tal vez el Equipo de Desarrollo no esté al tanto de las prácticas que promueven la colaboración, como la programación en parejas o en público, rompiendo grandes porciones de trabajo o pruebas de trabajo realizadas por otros (“dos pares de ojos”). O tal vez hay personas en el equipo que están actuando como ‘Torres de conocimiento’, y ocupar la mayor parte del trabajo, mientras que el resto trabaja en las migajas. De cualquier manera, Scrum Master puede ayudar al Equipo de Desarrollo a ser más autoorganizado al encontrar soluciones para estos impedimentos, no para el problema (sintomático) que surge durante el Scrum diario.

Ser un Scrum Master exitoso significa …

Los Scrum Masters exitosos ayudan a los Equipos de Desarrollo a aumentar su capacidad para resolver problemas por su cuenta. Esto es algo que los equipos tienen que aprender, y Scrum Master les ayuda a hacerlo. Lo que puede considerarse un impedimento durante el Sprint 1, puede haberse convertido en un problema que el equipo puede resolver fácilmente por sí mismo durante el Sprint 5. Si desea saber si está haciendo un buen trabajo como Scrum Master, monitoree la capacidad de un Desarrollo. Equipo para resolver problemas por su cuenta a lo largo del tiempo. Si esto está aumentando, probablemente estás haciendo un buen trabajo.

¿Entonces los Scrum Masters nunca resuelve problemas?

¿Significa esto que un Scrum Master nunca resuelve problemas? Por supuesto que no, los Scrum Masters sigue siendo parte del Scrum Team. Quizás un Scrum Master arregle ese router del wifi si el Equipo de Desarrollo está totalmente enfocado en resolver un problema técnico mayor, o un Scrum Master puede facilitar una sesión para desglosar grandes porciones de trabajo con el Equipo de desarrollo para que puedan hacerlo más fácilmente dentro del Sprint. La solución de problemas para el Equipo de desarrollo es totalmente aceptable si se realiza por los motivos correctos. No lo hagas de rutina. Antes de resolver un problema, considere si realmente está ayudando al Equipo de Desarrollo a crecer en su capacidad para resolver problemas similares por su cuenta. Una buena guía para recordar es:

Un Scrum Master debería revelar, no resolver Clic para tuitear

Consejos

• No espere hasta que el Daily Scrum para levantar un impedimento. Considere el Daily Scrum como la oportunidad más mínima para discutir impedimentos. Bloqueadores reales para el progreso del equipo deben ser discutidos inmediatamente.
• Cuando el equipo plantee un impedimento potencial, considere qué pasaría si no hace nada. ¿Alguien más en el Equipo de Desarrollo se encargará de eso?
• No hay nada de malo en una ‘Junta de Impedimentos’ para hacer transparentes los impedimentos que se han eliminado con el tiempo. Pero asegúrese de usarlo para impedimentos reales, no solo para cualquier problema que el Equipo de Desarrollo tenga la intención de delegar en Scrum Master. Y asegúrese de que la junta sea propiedad de todo el Equipo Scrum, y que no sea para el Scrum Master;
• No todos los impedimentos son importantes. Usa un objetivo Sprint como una brújula y guía. Como Scrum Master, debe actuar especialmente sobre los impedimentos que impiden que el Equipo de Desarrollo logre el Objetivo Sprint. Concéntrese en estos impedimentos antes de resolver cualquier otra cosa;
• Sé valiente y creativo en la eliminación de impedimentos. Recuerde: “Un buen Scrum Master solicitará permiso para eliminar impedimentos a la productividad del equipo. Un gran Scrum Master estará preparado para pedir perdón “. (Geoff Watts – Scrum Mastery)
• Una de las herramientas más poderosas de un entrenador es el uso del silencio. Quédate en silencio y mira qué pasa después. Lo mismo ocurre con cómo debería actuar un Scrum Master. Como experimento, no actúes sobre un impedimento y veas lo que sucede;
• Colabora con el Product Owner. Muy a menudo, los impedimentos estarán relacionados con la gestión del producto y la colaboración con las partes interesadas y los proveedores. El propietario del producto es un jugador clave en esta área. Por lo tanto, asegurar una relación sólida con el propietario del producto.
• Comprender la diferencia entre ‘bloques’ y ‘impedimentos’. Un bloque afecta solo una tarea, mientras que un impedimento actúa como un paracaídas, lo que ralentiza el progreso general. Muy a menudo, el Equipo de Desarrollo puede arreglar los bloques ellos mismos, mientras que los impedimentos deben ser solucionados por el Scrum Master ( Ilan Goldstein – Atajos de Scrum con esquinas de corte )
• Céntrate en el problema real, no en el primer problema. Haga preguntas para entender la situación. Compruebe si realmente es un impedimento o una oportunidad de aprendizaje para el Equipo de Desarrollo.

Concéntrese en el problema real, no en el primer problema Clic para tuitear

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Conclusiones

Hoy rompimos el mito de que Scrum Master es responsable de resolver todos los problemas que dificultan que el Equipo de Desarrollo logre el Objetivo Sprint. En su lugar, el Scrum Master debería ayudar al Equipo de Desarrollo a ser cada vez más capaz de resolver problemas similares por su cuenta (autoorganización). El Scrum Master lo hace abordando los problemas que ‘actúan como paracaídas’ para el equipo, no solo lo que aparece. En esta publicación, ofrecimos un par de ejemplos concretos y aclaramos qué tipo de problemas debería resolver un Equipo de Desarrollo y qué problemas son “impedimentos” que el Scrum Master debe detectar. También ofrecimos algunos consejos sobre cómo hacer esto.

¿Qué te parece este mito? ¿Estás de acuerdo? ¿Cuáles son tus lecciones aprendidas?

¿Quieres separar Scrum de los mitos? Puedes unirse a nuestros cursos profesionales Scrum Master o Scrum Master Advanced (en idioma holandés o inglés). Garantizamos una experiencia única y reveladora que es 100% libre de PowerPoint, altamente interactiva y seria pero divertida.