Manejo de Anti-Patrones Comunes
Reconocer y abordar la disfunción de Scrum.
1Scrum Pero...
"Hacemos Scrum, pero..." generalmente significa que no se está haciendo Scrum realmente.
Variantes comunes:
- "Pero no tenemos un Product Owner real" (sin autoridad, múltiples personas)
- "Pero no podemos hacer sprints de 2 semanas" ('Sprints' de 3 meses)
- "Pero omitimos las retros cuando estamos ocupados"
- "Pero el liderazgo establece el alcance del sprint"
Enfoque:
- Entender por qué se están desviando
- Explicar qué están perdiendo
- Abordar las causas raíz (a menudo organizacionales)
- Experimentar con hacerlo "según el libro"
2Scrum Zombi
Seguir los movimientos sin el espíritu. Todas las ceremonias ocurren, pero nada mejora.
Síntomas:
- Los standups son reportes de estado
- Las retros no conducen al cambio
- Los Objetivos del Sprint se ignoran
- Nadie habla con los stakeholders
- Al equipo no le importan los resultados
Tratamiento:
- Reconectar con el propósito: ¿Por qué estamos construyendo esto?
- Involucrar usuarios/stakeholders reales
- Hacer que las métricas sean visibles y significativas
- Experimentar con formatos para reenergizar
El Scrum Zombi A Menudo Apunta a Otra Parte
Los equipos siguen los movimientos cuando se sienten impotentes. La causa raíz suele ser organizacional—sin responsabilidad real, soluciones impuestas o liderazgo desconectado.
3Water-Scrum-Fall
Scrum solo de nombre, intercalado entre fases tradicionales.
Patrón:
- Fase de requisitos (meses) → Sprints "Scrum" → Fase de QA (meses)
Por qué falla:
- Sin retroalimentación hasta el final
- La salida del sprint no está verdaderamente "terminada"
- Los equipos no son dueños del trabajo de principio a fin
Enfoque:
- Impulsar equipos multifuncionales
- Expandir la Definición de Terminado para incluir pruebas
- Obtener participación de stakeholders durante todo el proceso
- Empezar pequeño—una porción verdaderamente de principio a fin
4La Velocidad como Garrote
Usar la velocidad para medir la productividad o el desempeño de los desarrolladores.
Por qué es dañino:
- Incentiva inflar estimaciones
- Desalienta ayudar a compañeros de equipo
- Ignora el valor entregado
- Crea miedo y ocultamiento
Mejores enfoques:
- Usar la velocidad solo para pronósticos
- Medir resultados, no producción
- Dar seguimiento al valor entregado a los usuarios
- Enfocarse en la salud del equipo, no en métricas individuales
Ley de Goodhart
Cuando una medida se convierte en un objetivo, deja de ser una buena medida. En el momento en que la velocidad se convierte en una métrica de desempeño, los equipos la manipularán.
- Los anti-patrones generalmente tienen causas raíz que vale la pena entender
- El Scrum Zombi indica desconexión del propósito
- Water-Scrum-Fall ocurre cuando los equipos no son dueños de principio a fin
- La velocidad es para pronósticos, no para medición de desempeño