6 errores evitables que cometen los equipos Scrum

El otro día alguien me preguntó cuales eran los errores típicos que veía en equipos Scrum que empezaban.
Mi respuesta fue sorprendente: ¿Los que empiezan? Los que más problemas tienen son aquellos que ya llevan mucho tiempo funcionando.

Error 1: Mucho Work in Progress

Acaba la primera parte del Sprint Planning y el equipo empieza a desgranar los PBIs en tareas, los estiman y cada uno de los miembros del equipo empieza a trabajar en un ítem distinto.

Eso provoca que luego haya problemas de integración y silos en los cuales el equipo no tiene ni idea de que está pasando. Los equipos maduros empiezan algo y no empiezan lo siguiente hasta que no lo terminan, manteniendo una o dos tareas en paralelo al mismo tiempo.

Cuando llega el final del Sprint, la mayoría de las cosas están a medio acabar y no da tiempo a integrar. Sin embargo el Product Owner aprieta para mostrar cuanto más mejor en el Sprint Review y el equipo de desarrollo añade la “deuda técnica” al backlog, para re visitarla… nunca.

Error 2: Falta de Sprint Goal

El Sprint Backlog se convierte en un cajón de sastre en el que entran decenas de cosas que no tienen nada que ver las unas con las otras, lo que hace que no haya coherencia y se pierda el desarrollo iterativo e incremental y la transparencia.

El Sprint Goal es una dirección general que ayuda al equipo a mantener el foco en cual es el objetivo de este incremento. El Sprint Backlog puede cambiar, el Sprint Goal no. Eso permite flexibilidad para lidiar con cosas que no estaban planeadas y un mejor enfoque en las necesidades de negocio.

Cuando no tenemos un Sprint Goal que de dirección, perdemos una herramienta muy potente que promueve dos de los valores de Scrum: Coraje y Compromiso. Entonces Scrum se convierte en un proceso más dentro de la compañía, además de perder foco en el valor de negocio entregado en cada incremento.

Error 3: Asignación individual de tareas

Los miembros del equipo de desarrollo trabajan individualmente en tareas hasta que las completan y luego pasan a trabajar en otra cosa. Eso provoca, de nuevo, falta de integración y posibles problemas de dependencias.

Algunos equipos tienen normas para lidiar con esto. Por ejemplo, tiene que haber un code review