spinner

Ocho mitos de Scrum y cómo corregirlos

Durante los años en los que he ido aplicando Scrum en diferentes equipos he observado que con frecuencia caemos en una serie de mitos y falacias que son aceptados como válidos y hacen que Scrum pierda eficacia.

He recopilado los más comunes para dar luz a algunos de estos mitos con el fin de ir “desactivándolos” y así mejorar el valor que aporta Scrum a las organizaciones. Aquí os dejo los ocho primeros:

Mito #1: El Scrum Master debe estar presente en la daily

Este es uno de los mitos que se ve con más frecuencia. El Scrum Master se asegura de que la daily tenga lugar, que sea efectiva, que dure como máximo 15 minutos y que nadie externo al equipo de desarrollo interrumpa la reunión. Es el equipo de desarrollo quien se responsabiliza de facilitar la reunión. Una vez que el equipo de desarrollo se ha habituado a realizar la daliy (eficazmente) el Scrum Master ya no debería ser necesario en la misma.

Lo que puede pasar en la daily es que no se use para lo que es: el equipo de desarrollo inspecciona el avance hacia el objetivo del sprint (Goal) y se autoorganiza para alcanzar ese objetivo.

Otra cosa que se ve con frecuencia es que asisten managers que además suelen interrumpir al equipo de desarrollo, les dirigen y usan la daily como un punto de control cargándose la finalidad del evento (ya no es una daily pero se sigue llamando así).

Mito #2: El Product Backlog debe estar compuesto por historias de usuario

Este mito también se encuentra con frecuencia. Recordemos lo que dice Scrum al respecto. En el Product Backlog lo que tenemos son Product Backlog Items (PBIs), es decir, una lista ordenada por prioridad de elementos o “cosas” por hacer. Estos PBIs pueden ser de distinta naturaleza: mejoras de rendimiento, tareas técnicas de investigación, funcionalidades nuevas (por ejemplo en formato historia de usuario), bugs, incidencias, deuda técnica, etc.

Usar historias de usuario es una práctica excelente pero en algunos casos no aplicará y es mejor no forzar a que todo sean historias de usuario o terminaremos definiendo cosas sin sentido. Las historias de usuario definen una funcionalidad desde el punto de vista del usuario y tienen un formato específico: el título de la historia, el rol (como), el objetivo (quiero) y la motivación (para).

Mito #3: En Scrum no se planifica

En Scrum se planifica continuamente. Por ejemplo se planifica al principio de cada sprint. El Product Owner negocia con el Equipo de Desarrollo el objetivo del sprint (Goal) y se define la estrategia o plan para alcanzar ese objetivo (representado, finalmente, en el sprint backlog).

Hay que tener en cuenta que:

  • Planificar es muy útil.
  • Los planes ayudan.
  • Los planes a largo plazo muy detallados son un “desperdicio” de tiempo y energía.

Por ejemplo, en cada daily el equipo de desarrollo inspecciona cómo va de cara a conseguir el objetivo del sprint y adapta el sprint backlog (actualiza el plan). La planificación es continua (el plan se va actualizando cada día).

Mito #4: El Scrum Master debe resolver todos los problemas

El Scrum Master debe asegurarse que se resuelven los impedimentos que bloquean al Equipo de Desarrollo a la hora de conseguir el objetivo del sprint, pero tiene que tratar de que sea el Equipo de Desarrollo (si es viable) quien los solucione por sí mismos. Esto me ha pasado muchas veces y lo que hago como Scrum Master es hacerles ver que el problema lo pueden resolver por sí mismos y si hace falta les enseño con el ejemplo.

Por otro lado hay que tener en cuenta que cada cosa que haga el Scrum Master que pueda hacer el equipo de desarrollo por sí mismo, es una oportunidad perdida para que se autoorganice. Desde mi experiencia la mayoría de impedimentos los puede gestionar el Equipo de Desarrollo por sí mismo.

Mito #5: En la demo el Equipo de Desarrollo muestra lo realizado durante el sprint

En Scrum no hay demo, lo que hay es un evento llamado «revisión del sprint» (Sprint Review). En esta reunión asiste todo el Equipo Scrum al completo y algunos stakeholders invitados por el dueño del producto.

En la reunión, resumiendo, se hace lo siguiente:

  • El dueño de producto explica qué PBIs se han terminado y cuales no se han terminado.
  • El Equipo de Desarrollo hace una demostración del trabajo que ha terminado y responde preguntas acerca del incremento.
  • El grupo completo colabora acerca de qué hacer a continuación de modo que la revisión del sprint (Review) proporcione información de entrada valiosa para reuniones de planificación de sprints subsiguientes.
  • No olvidar que uno de los puntos más importantes es obtener feedback de los stakeholders.

El resultado de la sesión es el propio feedback, que ayuda a actualizar el Product Backlog y también permite hacer la retrospectiva del sprint con mayor y mejor información.

Mito #6: El Scrum Master facilita la retrospectiva

Si preguntamos a los integrantes de varios equipos Scrum: ¿Quién es el encargado de facilitar la retrospectiva? El 90% dirán que es el Scrum Master.

Muchos Scrum Master cometen el error de pensar que facilitar la retrospectiva es parte de sus responsabilidades. Lo que sí es responsabilidad del Scrum Master es que el evento tenga lugar, sea eficaz y que el proceso de mejora continua se lleve a cabo.

Por otro lado el Scrum Master puede participar en la retrospectiva como un integrante más del equipo Scrum y aprovechar el evento para hacer inspección y adaptación de, por ejemplo, cómo está trabajando del equipo.

Mi manera de evitarlo es la siguiente. Lo primero que hago es dejar claro al equipo que el Scrum Master es uno más en la retrospectiva. También recuerdo en todas las retrospectivas cual es el objetivo de la reunión: la mejora continua y que es responsabilidad de todos impulsarla. Por otro lado las primeras retrospectivas las facilito yo para mostrar al resto del equipo la manera de hacerlo.

Mito #7: El Sprint Backlog no puede modificarse durante el Sprint

Este es uno de los mitos en los que caigo con más facilidad incluso conociéndolo. Como comenté anteriormente el “plan” (Sprint Backlog) para alcanzar el objetivo del sprint (Goal) va modificándose durante el sprint. El problema viene cuando cada PBI del Sprint Backlog es un objetivo en sí mismo y por lo tanto no tiene sentido modificar el Sprint Backlog.

Se debería hacer teniendo un único objetivo. En la daily, el Equipo de Desarrollo inspecciona cómo va de cara a conseguir ese objetivo del sprint y, si es necesario, adaptará el “plan” (actualiza el Sprint Backlog). Por lo tanto, si que puede ser modificado el Sprint Backlog siempre que no afecte al objetivo del sprint.

Para que se produzca esta adaptación es necesario inspeccionar y para que esa inspección sea eficaz tiene que haber transparencia. Y aquí tenemos los tres pilares de Scrum: transparencia, inspección y adaptación. Si os fijáis de los tres pilares la palabra clave es la adaptación (la inspección sirve a la adaptación y la transparencia sirve a la inspección).

Por otro lado para mejorar la transparencia suelo usar radiadores de información como por ejemplo un scrum board, un burndown, etc. Por cierto mucho más eficaces si son físicos que digitales (los digitales tienden a mirarse mucho menos y se pierde transparencia).

Mito #8: La daily es una reunión de control de estado

Si leemos la Guía de Scrum veremos que especifica que la daily es una reunión donde el Equipo de Desarrollo inspecciona el progreso para la consecución del objetivo del sprint (Goal), sincronizarse y crear un plan para las próximas 24 horas. La reunión la facilita y es para el equipo de desarrollo.

La daily promueve la transparencia y la autoorganización, este último un elemento clave en la eficacia de Scrum. Si a la daily asisten managers estos tenderán a dirigir al equipo, preguntar por el estado de las tareas y a eliminar impedimentos que perfectamente podría resolver el Equipo de Desarrollo.

Llegados a este punto la autoorganización desaparecerá. Es responsabilidad del Scrum Master que esto no suceda y que el evento sea eficaz. Para ello tendrá que evitar que asistan personas externas al Equipo de Desarrollo a la daily (o por lo menos que no interrumpan).

Si un manager quiere enterarse del estado de los PBIs puede preguntar al equipo de desarrollo en cualquier otro momento del día, teniendo en cuenta en no ser intrusivo y terminar dirigiendo la ejecución de esas tareas.

Conclusiones y algunos recursos extra

Como hemos visto, hay todavía muchos mitos por desmontar a la hora de aplicar Scrum y, poco a poco, podemos ir corrigiéndolos entre todos. Espero que con este artículo lo tengamos un poco más claro y podamos aplicar Scrum cada vez mejor. Aunque estos mitos a priori, parezcan detalles sin importancia, a medio plazo terminan haciendo que Scrum pierda eficacia.

Para los que estéis interesados en ampliar información os dejo algunos enlaces que me han servido como inspiración y aclaración para redactar el artículo.

Foto principal: Unsplash

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?

Utilizamos cookies propias y de terceros para mejorar nuestros servicios, brindarle una grata experiencia y mostrar a los usuarios publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando por este sitio web, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información accediendo a nuestra política de cookies aquí.