¿Hagamos Scrum? | Anti patrones



Anti patrones

Los anti patrones en Scrum son hábitos que se exhiben con frecuencia, pero en general son ineficaces o incluso dañinos.

Estos patrones anti ocurren a lo largo de todas las ceremonias Scrum y, en última instancia, dificultan su ejecución (oportuna).

Además, incluso los profesionales ágiles (como el Scrum Master o el Product Owner) pueden sufrir algunas de estas deficiencias. Esto hace que sea aún más complicado para ellos.


Durante el evento de Planning de Sprint.

Producto acumulado sin refinar: Uno de los pecados más grandes del PO (ya que él / ella es responsable de administrar el trabajo atrasado del producto) es venir a la reunión de Planning del sprint tratando de descubrir los detalles de las próximas tareas de sprint. Esto le quitará un valioso tiempo de reloj que debería dedicar a planificar el próximo sprint.

Faltan interesados clave: Solo podemos planificar en consecuencia cuando el esfuerzo de las tareas se puede estimar en consecuencia. Como tal, necesitamos toda la experiencia de dominio necesaria para ayudarnos a hacerlo. Esto puede conducir a muchos problemas, como:


● El PO empuja demasiadas tareas al sprint.

● Es posible que el equipo de desarrollo no imponga el tiempo necesario para la corrección de errores y el trabajo ad-hoc (a través de los llamados objetivos de estiramiento).

● El equipo de desarrollo no puede comprometerse con su disponibilidad para el próximo sprint (en caso de que falten algunos de los miembros de su equipo).


Durante el daily Scrum.

Ruido exterior: El equipo tolera a los stakeholders externos para que participen activamente en la lucha, lo que finalmente termina en discusiones inútiles sobre el trabajo a realizar.

Otros problemas pueden incluir:


● Miembros del equipo interrumpiéndose mutuamente.

● Los miembros del equipo hablan entre sí mientras alguien más habla.

● Los miembros del equipo llegan tarde a ponerse de pie, creando así distracción para los demás compañeros.

●El entorno en el que se celebra la reunión (por ejemplo, en el medio de la oficina) provoca interrupciones.


El Daily Scrum no se debe utilizar para provocar debates acalorados (o cualquier otro tipo de esto:

  1. Evitará que los miembros de su equipo sean no productivos.

  2. Afecte negativamente la moral.

  3. No esté en línea con el propósito de esta reunión.

  4. Reservarlos para después de la reunión es el camino a seguir.

Problemas en curso: Los miembros del equipo no pueden resolver problemas actuales o simplemente no ofrecen ayuda. Esto a menudo muestran falta de confianza, tiempo, competencia o incluso una combinación de todos ellos.


Omisiones por completo: El Daily Scrum se lleva a cabo a la misma hora y ubicación todos los días para reducir la complejidad. Hacer la reunión con poca frecuencia le roba al equipo la oportunidad de ponerse al día y elaborar estrategias para el día que se avecina.


Falta de preparación: Los miembros del equipo simplemente no pueden recordar en qué estaban trabajando o dejarle detalles importantes para los demás. La falta de preparación también puede conducir a la violación del límite de tiempo de 15 minutos.


Consejo: Escribe en un Post lo que hizo el día anterior y utilícelo como su fuente de información guía.


Durante la Review del Sprint.

Falta de asistencia. Las personas, ya sean internas o externas, simplemente no aparecen en las revisiones de sprint. Esto puede deberse a un par de razones, por ejemplo:


● Falta de información presentada, por lo tanto, las partes interesadas no sienten que pueden recopilar la información necesaria.

● La reunión se siente muy repetitiva y la agenda realmente no cambia mucho

● Las mismas caras aparecen una y otra vez.

● Estilo de presentación aburrido en el que las personas simplemente leen un par de diapositivas.


Además, si bien puede haber un buen nivel de asistencia, las partes interesadas pueden sentirse desconectadas y, por lo tanto, no formularán ninguna pregunta. Eso se debe a que no siente la necesidad o la libertad de hablar es algo que debe investigarse y solucionarse, ya que crea discusiones y percepciones fructíferas.


● Stories inconclusas: El equipo de desarrollo presenta elementos de trabajo que no cumplen con la DoD, creando así una falsa sensación de logro.

● Falta de preparación: Los miembros del equipo que terminan las diapositivas minutas antes o las partes interesadas que no conocen el propósito del evento pueden ser algunos de los factores que pueden dificultar la efectividad de la reunión. Nuevamente, esto podría culminar en que las partes interesadas no se presenten la próxima vez o simplemente se desconecten durante la reunión.


Durante la retrospectiva de Sprint.

● Conseguir diálogo fructífero: Los miembros del equipo se atacan entre sí durante el retro, causando fricción e incomodidad. Según lo definido por los valores de Scrum, los equipos deben tratarse entre sí con respeto sin perder el coraje de hablar sobre los problemas subyacentes.

● Corriendo o saltando retro. El equipo se apresura o se salta la retrospectiva por completo. Esto es a menudo una señal de la falta de comprensión de la importancia de esta reunión. Además, los equipos no podrán cosechar sus amplios beneficios reflexivos.

● Scrum Masters debería intentar hacer que el retro valga la pena el tiempo del equipo. Podemos darle vida a la reunión a través de una diversidad de maneras, donde puede ser un cambio de ubicación y técnicas o simplemente pedir algunas donas y café en el camino.

● No se tomaron medidas: A pesar de señalar problemas persistentes y elaborar planes de acción, nadie los sigue. Esto podría deberse a varios factores, que incluyen:

○ Nadie en el equipo se siente responsable.

○ El Scrum Master o el coach ágil no es capaz de reflexionar y seguir adelante. con los puntos de acción discutidos.

● Nadie actúa: Nadie está tomando notas y, por lo tanto, no recuerda lo que se ha discutido.

● Fuga: Los miembros del equipo comparten los puntos discutidos con las partes interesadas externas. Esto crea una gran violación de la confianza y el miedo a la ramificación. Por lo tanto, los miembros del equipo perderán su coraje para hablar.

● Falta de apertura: Ya sea que la empresa carezca de un lugar adecuado para los retro o haya interesados externos (por ejemplo, managers) invitados a la reunión, la falta de apertura anula por completo el propósito de la retrospectiva. Esto a menudo conduce a la pasividad sin que nadie sienta la necesidad de hablar.


Scrum Master.

Además de los eventos, hay una multitud de anti patrones que tanto el Scrum Master como el PO pueden sufrir.


●Usando múltiples sombreros: Esto ocurre a menudo en organizaciones que están acostumbradas a un estilo en cascada de entregar trabajo. Los ejemplos incluyen ex gerentes de línea o líderes de equipo que se convierten en Scrum Master mientras continúan administrando sus tareas cotidianas. Esto simplemente no funciona, tanto desde el punto de vista del tiempo como de la auto organización.

●Evitar conflictos: Como humanos, tendemos a evitar situaciones incómodas siempre que podemos. En cambio, nos esforzamos por la seguridad y la estabilidad, especialmente en entornos que involucran grupos. Buscar orientación externa, por ejemplo, a través de entrenadores o psicólogos, puede ayudar a guiar al Scrum Master sobre cómo resolver conflictos de manera efectiva.

●Demasiada libertad: El hecho de que Scrum se base en equipos independientes y auto organización, no debería significar que sus miembros tengan un boleto gratis para hacer lo que quieran. Más bien, él entrena a todos los involucrados sobre cómo organizarse en los ámbitos de las ceremonias mientras dirige a la organización hacia la adopción efectiva de Scrum.

●La competencia como motivación: Usar el desempeño de otros equipos para desafiar y motivar puede ser perjudicial para la moral del equipo. Esto puede ser a expensas de ofrecer incrementos de alta calidad, lo que causa estrés a los miembros del equipo y pone a todos en la organización en el acto. El Scrum Master debe motivar a su equipo a través de una sensación de logro, no el miedo a ser peor que otra persona.

●Falta de experiencia. Solo podemos repetirnos: Scrum es fácil de aprender, pero difícil de dominar. Tener un Scrum Master sin experiencia puede llevar a un fracaso en la adopción y ejecución de métodos ágiles. Dicho esto, mientras su equipo progrese, puede ser suficiente tener un poco más de paciencia.


Product Owner.

PO inaccesible: El PO no está siempre accesible para que el equipo responda las preguntas cada vez que surgen. Esto puede deberse a varios factores, que incluyen:


● La organización decidió emplear solo un PO a tiempo parcial.

● El PO gestiona múltiples productos.

● El PO asume otras funciones (por ejemplo, Scrum Master) al mismo tiempo

● Un grupo de personas (es decir, un comité) representa el rol de la PO para poder enfocarse en su trabajo diario.

● En cualquiera de estos casos, tanto el equipo de desarrollo como la organización en su conjunto carecen de una fuerza de guía constante que los guíe hacia la maximización del valor del producto.

● Mala gestión del product backlog. Una vez más, la mala gestión de la cartera de productos viene en muchas formas y formas. Los ejemplos implican:

○ Sobredimensionar la cartera de pedidos, lo que hace que el equipo no pueda entregar a tiempo.

○ PBI´s obsoletos que simplemente ya no son relevantes.

○ Los PBIs no están refinados y no incluyen descripciones detalladas de la historia del usuario (por ejemplo, solo agregar títulos a cada historia del usuario).

● Faltan criterios de aceptación en la historia del usuario (DoD).

●Todas las historias de usuario se estiman con semanas de anticipación, lo que puede causar un trabajo adicional innecesario para todos los miembros del equipo (ya que estas historias de usuario pueden quedar desactualizadas en el transcurso de los siguientes Sprints).


... y muchos más. En cualquiera de estos casos, es recomendable tener un Scrum Master fuerte que pueda guiar y enseñar a la PM sobre la gestión eficaz de la cartera de pedidos.


●PO egoísta: El Product Owner se lleva todo el crédito por los logros de su equipo. Esto afectará indefinidamente la moral del equipo y obstaculiza la influencia positiva que el PO puede tener en el rendimiento del equipo.

●PO irreflexivo: El Product Owner no reflexiona críticamente sobre su trabajo en los últimos Sprints. Interpretan los fracasos como conspiraciones contra ellos porque “¿Cómo podría ser mi culpa si no estoy haciendo el trabajo?"

● Falta de visión: el PO no piensa más allá de lo que es posible y emplea una visión que es:

○ Poco inspirador y no único.

○ Evitando riesgos.

○ Pasos faltantes sobre cómo lograr la visión.



Y tú, ¿Cuáles más has vivido?

246 visualizaciones0 comentarios

Entradas Recientes

Ver todo