Errores más frecuente al implantar Scrum

Vamos a repasar en este artículo los errores más frecuentes al implantar Scrum y sus consecuencias.

Muchos de los proyectos en los que participamos han comenzado su transición a las metodologías ágiles. El resultado más visible es que hacen ‘sprints‘ de tres o cuatro semanas, pero los incrementos de productividad siguen siendo una promesa; los proyectos continúan con sus dinámicas previas.

Y tiene sentido. ¿Por qué hacer el mismo trabajo en bloques de tres semanas va a mejorar la productividad? Scrum es mucho mas que sprints o tableros con post-it.

1. No subir los desarrollos a producción después de cada sprint.

Quizás el error más frecuente y también el más importante. Asume que tu cliente no puede saber lo que quiere y que tendrás que modificar el trabajo realizado. Cuanto antes descubras lo que en realidad necesita, más productivo será el proyecto.

Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades en tres semanas, su retorno de inversión -ROI- es mucho más rápido. Música celestial para cualquier CFO.

En las metodologías tradicionales los desarrollos se entregan al final del proyecto. Esto no solo retrasa el ROI. Comienzas las modificaciones cuando ya no queda presupuesto.

La única forma de comprobar que has acertado es poner el software en manos de sus usuarios finales.

2. Obligar a que se finalicen todos los trabajos planificados para el sprint.

El segundo error clásico. Si te has equivocado en el sprint planning y no es viable finalizar los trabajos, ¿cuáles son las posibles opciones?

a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.

b) Puedes rebajar la calidad y no hacer las pruebas de regresión.

c)  Puedes rebajar el alcance y entregar menos desarrollos.

Por inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por añadir la opción b). Scrum establece que la respuesta mas apropiada es la c).

Buena parte de los incrementos de productividad asociados a Scrum proceden de eliminar la presión de trabajo de los consultores.

3. No tener un Product Owner integrado en el equipo.

El Product Owner es una figura esencial en Scrum, y es otra de las vías del incremento de productividad.

Los programadores trabajan sin una especificación detallada, así que constantemente tienen dudas sobre la funcionalidad a desarrollar. Es necesario que alguien procedente del cliente les explique las Historias de Usuario.

El Product Owner es también el guardián del ROI. No sabe programar, pero entiende el valor que aporta cada Historia al negocio. Si prioriza adecuadamente los desarrollos, conseguirá un mayor retorno de inversión en cada iteración.

Si el Product Owner no está con su squad, los programadores no interpretan bien las Historias, las modificaciones son más frecuentes y el valor para el negocio de cada sprint es menor.

¿Hay más errores típicos?

Aunque estos sean los tres errores más frecuentes al implantar Scrum, hay otros muchos que puedes cometer. Sin ánimo de ser exhaustivos:

Hacer una especificación pesada.

En Scrum se pasa de una idea de alto nivel al desarrollo que hacen los programadores. ¿Para que emplear meses en una especificación detallada si damos por sentado que el cliente no puede saber lo que quiere?

Solicitar que el cliente valide la especificación.

Aunque el cliente firme la especificación, sigue sin ser lo que necesita. Y lo sabe. Tu equipo puede estar valiosas semanas esperando a que el cliente dé su consentimiento. ¿No es mejor emplearlas en desarrollar un prototipo?

Mantener las jerarquías dentro de los equipos.

Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. La figura del Líder Técnico desaparece. Los programadores colaboran desde un plano de igualdad y ninguno impone su criterio a los demás.

El Jefe de Proyecto también se difumina porque ya no es necesario negociar alcance y plazo de cada desarrollo.

No automatizar las pruebas a la vez que se hacen los desarrollos.

Si no automatizas las pruebas, ¿cómo piensas hacer DevOps? No podrás hacer pruebas de regresión y con cada sprint tus desarrollos tendrán menor calidad.

Tener a los equipos separados geográficamente.

No es solo que no puedan hacer el daily. Recuerda que los equipos están creando la especificación a la vez que hacen el desarrollo. Si están separados ¿cómo van a construir ese conocimiento?

No hacer retrospective.

Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Potencia estos momentos de reflexión para que crezcan en la aplicación de la metodología.