隆Bienvenido! puedes llamarnos en 馃嚮馃嚜 Caracas al +58 2126146695 – en 馃嚚馃嚤 Santiago de Chile al +56 (9) 9009 4875 S铆guenos en

Image Alt

CeaSoft

  /  Scrum Master   /  Mito: El Scrum Master debe resolver todos los problemas

Mito: El Scrum Master debe resolver todos los problemas

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 锘緾lic 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: 鈥淯n 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 锘緾lic para tuitear

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.

Cazadores de mitos de Scrum
Este es un art铆culo traducido al espa帽ol del art铆culo original Myth: The Scrum Master Must Resolve Every Problem de los amigos The Liberators

Si quieres aprender en idioma espa帽ol tenemos varias fechas por Centroam茅rica y Sudam茅rica en alianza con CeaSoft y Agile611 ambos partners de Scrum.org. Al lado derecho puedes visualizar r谩pidamente algunas fechas de las planificadas.

Para ver todas las fechas pincha en el bot贸n de abajo ver calendario

517{icon} {views}
Post a Comment

Abrir chat
隆 Hola ! 馃憢 Soy Yulibeth Palacio
En en que te puedo apoyar?
Powered by