Biblioteca de antipatrones
A continuación se muestra el listado de los principales antipatrones, agrupados por categoría.
El backlog "Agujero negro"
El product backlog se ha vuelto tan grande, desorganizado y desactualizado que nadie confía en él, es imposible de gestionar eficazmente y actúa como un sumidero de ideas que nunca ven la luz.
Sprint sin objetivo
El equipo comienza el Sprint sin haber definido un sprint goal claro y coherente, lo que resulta en un conjunto de tareas inconexas en lugar de un esfuerzo enfocado hacia la entrega de un Incremento valioso.
Acumulación de deuda técnica
El equipo prioriza de forma sistemática la velocidad de entrega a corto plazo sobre la calidad del código y la arquitectura, tomando atajos que generan problemas, retrabajo y mayor coste a futuro.
El "Casi hecho"
Al finalizar el sprint, muchas de las tareas o historias de usuario están casi terminadas pero no cumplen completamente la Definition of Done (DoD), resultando en un Incremento que no es realmente "potencialmente desplegable".
Guerrilla de stakeholders
Los stakeholders se saltan al product owner y acuden directamente a los miembros del equipo de desarrollo para solicitar cambios, nuevas funcionalidades o reportar bugs, alterando las prioridades y el flujo de trabajo planificado.
La planning interminable
La sprint planning se alarga excesivamente, a menudo superando el timebox recomendado, debido a discusiones demasiado detalladas, falta de preparación del backlog o intento de planificar cada tarea al milímetro.
La daily de reporte
La daily scrum se convierte en una sesión donde cada miembro reporta su estado individual a una figura de autoridad (como el scrum master o un jefe), en lugar de ser una reunión de sincronización rápida para el equipo.
La review "Demo para el jefe"
La sprint review se convierte en un evento formal y unidireccional donde el equipo presenta únicamente lo que ha funcionado perfectamente, a menudo por miedo a la crítica o al feedback negativo, perdiendo la oportunidad de inspección y adaptación.
La retrospectiva quejumbrosa
La sprint retrospective se convierte en una sesión recurrente de quejas y lamentos donde se identifican problemas pero no se generan acciones de mejora concretas, realizables y con seguimiento.
El product owner ausente
El product owner no está disponible para el equipo, no participa activamente en los eventos scrum clave ni proporciona feedback rápido sobre el trabajo realizado o las dudas.
El product owner "escriba"
El product owner actúa principalmente como un intermediario que transcribe las peticiones de los stakeholders al product backlog sin analizarlas, priorizarlas estratégicamente ni aportar una visión de producto.
El scrum master "policía"
El scrum master se enfoca de manera excesivamente rígida en el cumplimiento literal de las reglas y mecánicas de scrum, a menudo perdiendo de vista los principios ágiles y el objetivo de entregar valor.
El scrum master "secretario"
El scrum master asume tareas administrativas o de gestión que el equipo de desarrollo debería autogestionar, como actualizar artefactos, convocar reuniones o tomar notas.
Héroes solitarios
Uno o varios miembros del equipo asumen de forma recurrente la carga principal del trabajo, resuelven todas las crisis y acaparan el conocimiento crítico, desincentivando la colaboración y la responsabilidad compartida.
Equipo de especialistas aislados
Los miembros del equipo se centran exclusivamente en tareas de su área de especialización (por ejemplo, backend, frontend, QA) y no colaboran activamente en el trabajo de los demás, generando silos y dependencias.