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.

Relacionado
Scrum Master es uno de los trabajos más prometedores del 2017 según LinkedIn

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 por al menos dos miembros del equipo. Trabajar en pares. Muchas veces con poca efectividad, sobre todo si la carga de trabajo es alta.

La única manera de lidiar con esta situación es, lamentablemente, reducir la carga de trabajo. Paradójicamente, el ahorro de entregar más rápido se traduce en cuatro veces más para reparar la deuda técnica y de conocimiento que supone ese ahorro.

Además, cuando se maximiza la utilización, se tiende a perder valor. ¿Cómo? Aumentando el tiempo de entrega. Cuando el equipo se enfoca en entregar unas cuantas cosas bien hechas, quizás esté perdiendo eficiencia, pero se asegura de entregar, lo cual ya supone una gran diferencia con muchos equipos, que trabajan en cosas durante meses sin llegar a entregarlas… nunca.

 

Error 4: Falta de responsabilidad

En Scrum, el rol responsable de dar cuentas sobre el incremento es el equipo de desarrollo. Que el nombre no nos lleve a engaño. Todos los miembros del equipo de desarrollo dan cuentas sobre todo el incremento.

No existe la individualidad del desarrollador en Scrum. Desafortunadamente, eso lleva a muchos miembros del equipo de desarrollo a quejarse porque ellos sí hacen su trabajo.

La manera de actuar es la de dejar que el equipo se autoorganice y lidia con esos problemas. Y la del Scrum Master no es actuar sobre los miembros que consideramos destacados o vagos, sino mantener esa discusión dentro del equipo, sin que escale en la organización.

En el caso del Product Owner, él es el responsable de dar cuentas de la inversión que hace en el equipo de desarrollo cada Sprint. Y tiene que hacerlo con datos. Si la calidad técnica del producto falla, de rebote el Product Owner se convierte en responsable.

Relacionado
Cuatro herramientas básicas de un Product Owner

Error 5: Maximización de utilización o eficiencia

Este es, sin duda, uno de los peores que puede tener una organización. Enfocarse en que la gente trabaje muchas horas en lugar de generar valor.

No nos equivoquemos. Estos dos objetivos son totalmente incompatibles. El desarrollo de software, por su propia naturaleza, incurre en una variabilidad muy grande y no es posible estandarizar tareas, duraciones, problemas o buenas prácticas.

La realidad es que cada vez que hacemos algo en software, por muchas veces que creamos haberlo hecho antes, nos enfrentamos a algo totalmente nuevo, en un entorno nuevo, un sistema nuevo, que nunca habíamos hecho antes. Es ineficiente porque aprendemos sobre la marcha.

Las ineficiencias aparecen en forma de miembros que no tienen suficiente trabajo, otros que están sobrecargados y otros problemas intermedios. El temor a que la gente esté parada lleva a introducir trabajo no necesario para generar valor y que la gente esté ocupada. 

El resultado es que cuando el trabajo que tienen que hacer esos miembros es necesario, están ocupados haciendo otra cosa. Están siendo eficientes. Y haciendo perder dinero a la compañía.

Error 6: El equipo de desarrollo es el equipo de desarrolladores

El último es, quizás, el más desconocido. Debido a su nombre, los profesionales en Scrum piensan que un equipo de desarrollo tiene que estar formado por gente técnica: programadores, ingenieros de operaciones o calidad.

Nada más lejos de la realidad. El equipo de desarrollo tiene todos los perfiles necesarios para poder entregar un incremento de producto. Si eso supone que tienen que incorporar a un Business Analyst, un especialista en SEO o un diseñador, también son miembros del equipo de desarrollo.

Si ves que tu equipo se está acercando a alguno de estos errores o que el proceso de Scrum no está desarrollando adecuadamente, te recomiendo el artículo Cuatro señales de que Agile no funciona en tu organización.

Avatar for Jerónimo Palacios Vela

Posted by Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This