Disfrútalo y compártelo a tus contactos
1) Solo números de tickets
Las actualizaciones son genéricas y tienen poco o ningún valor para los demás. (``Ayer trabajé en la historia de usuario X-123. Hoy, trabajaré en X-129``), sin impedimentos.
3) Asignaciones
El Product Owner, o incluso el ``Scrum Master``, asigna tareas directamente a los miembros del equipo.
2) Abarrotado
El Daily Scrum es ineficaz debido a una gran cantidad de participantes activos. (Existe una razón por la que la Guía Scrum recomienda limitar el número de miembros del Scrum Team hasta 10 personas o menos).
4) Pollos parlanchines
Los “pollos” participan activamente en el Daily Scrum. (Se supone que los Stakeholders deben escuchar y no distraer a los Developers durante su inspección).
5) Statler y Waldorf (la pareja de personajes de Los Muppets)
Algunos miembros del equipo comentan cada tema. (Por lo general, esto no es solo una pérdida de tiempo sino también condescendiente y molesto).
6) No se utiliza el work-item age (edad del elemento de trabajo)
Un developer experimenta dificultades para resolver un problema durante varios días consecutivos y nadie ofrece ayuda. (Esta es una señal de que es posible que las personas no confíen entre sí o que no se preocupen por los demás. Alternativamente, la carga de trabajo del equipo de desarrollo ha alcanzado un nivel improductivo, ya que ya no pueden apoyarse entre sí).
7) Orientación perdida
El Daily Scrum tiene un propósito ya que responde a una pregunta simple: ¿Seguimos en camino de alcanzar el Sprint Goal? ¿O necesitamos adaptar el plan o el Sprint Backlog o ambos? A menudo, los developers no puede responder a esa pregunta de inmediato. (En ese sentido, visualizar el progreso hacia el Sprint Goal es un ejercicio útil. Eliminar la tarea de los Developers de mantener un gráfico de evolución obligatorio de la Guía de Scrum hace unos años atrás no implica que un gráfico de evolución sea obsoleto).
8) Desorientación
Los miembros del equipo no están preparados para el Daily Scrum (``Estaba haciendo algunas cosas, pero, no recuerdo qué. Aunque era importante``).
9) Reporte de estatus
El Daily Scrum es una reunión de Reporte de estatus, y los Developers están esperando en línea para ``informar`` el progreso al Scrum Master al Product Owner o incluso a un stakeholder.
10) Resolución de problemas
Las discusiones se activan para resolver problemas, en lugar de aparcarlos para que puedan abordarse después del Daily Scrum.
11) Reunión de planificación
El equipo secuestra el Scrum diario para discutir nuevos requisitos, refinar las historias de los usuarios o tener una especie de reunión tipo planificación (Sprint).
12) Monólogos
Los miembros del equipo violan el límite de tiempo, iniciando monólogos. (60 a 90 segundos por miembro del equipo debería ser más que suficiente tiempo en el aire).
13) Comencemos el turno
El Daily Scrum actúa como una especie de sirena de fábrica artificial para iniciar el siguiente turno. (Este es un artefacto común del taylorismo en el que falta la confianza en la capacidad del equipo de desarrollo para autoorganizarse).
14) ``Una palabra, por favor``
Los gerentes de línea están esperando hasta que termine el Daily Scrum y luego se comunican con los miembros individuales del Scrum Team para obtener informes específicos de ellos. (Buen intento. Sin embargo, este truco también es un comportamiento no deseado y distrae a los Developers)
15) Trabajo adicional
El Product Owner o incluso otras Stakeholders intentan introducir un nuevo trabajo en el Sprint actual durante el Daily Scrum. (Este comportamiento puede ser aceptable para errores de alta prioridad, aunque los Developers deben conocerlos antes del Daily Scrum. De lo contrario, la composición del Sprint Backlog es responsabilidad exclusiva de los Developers).
16) Comando y control por parte de la gerencia
Los gerentes de línea asisten al Daily Scrum para recopilar ``datos de desempeño`` de los miembros individuales del equipo. (Este comportamiento desafía el propósito mismo de los equipos autoorganizados).
17) Feedback excesivo
Los miembros del equipo critican a otros miembros del equipo de inmediato, lo que genera una discusión en lugar de llevar su crítica fuera del Daily Scrum.
18) Falta de respeto I
Otros miembros del equipo están hablando mientras alguien comparte su progreso con el equipo. (El uso de fichas parlantes entre adultos para evitar este comportamiento no califica como una solución en mi opinión).
19) Falta de respeto II
Los miembros del equipo llegan tarde al evento o no se presentan en absoluto (esto representa un riesgo masivo para el equipo de desarrollo ya que está inspeccionando y probablemente adaptando el plan basándose en información incompleta, lo que reduce la probabilidad de lograr el Sprint Goal.
20) Y por último ...
Algunos equipos les gusta tener su Scrum diario en Slack, particularmente aquellos que no están colocados. El uso de Slack no manifiesta un antipatrón per se; Es prerrogativa del Equipo de Desarrollo ejecutar el Scrum diario de cualquier manera que cumpla su propósito: inspeccionar el plan durante las próximas 24 horas para cumplir con el Objetivo del Sprint. (Incluso estaba trabajando con un equipo de Scrum ubicado en el mismo lugar que usaba Slack como su forma preferida de tener un Scrum diario. Funcionó).
