¿Cuales son los principales errores que se cometen al implantar Scrum?

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 respectivas.

Y tiene sentido, ¿por qué hacer el mismo trabajo en bloques de tres semanas iba a mejorar la productividad? Scrum es mucho mas que hacer sprints o un tablero lleno de post-it. Vamos a repasar los errores más comunes que se cometen en estas primeras experiencias.

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

Quizás el error más recurrente y también el más importante. Asume que tu cliente no sabe 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. En la metodología tradicional se muestran los resultados al final del proyecto y se comienzan las modificaciones cuando ya no queda presupuesto.

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

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 clásico. Si te has equivocado en la estimación y no es viable finalizar los trabajos, ¿cuales son las posibles opciones?

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

b) Puedes rebajar la calidad y entregar algo que parece que funciona, pero sin hacer pruebas de regresión.

c)  Puedes rebajar el alcance y hacer menos funciones.

Debido a la inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por b). Sin embargo Scrum establece que la respuesta correcta es la c).

Una parte de los incrementos de productividad en Scrum proceden de eliminar la presión de trabajo de los consultores. Otra parte se consigue con menos incidencias en producción.

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

El Product Owner es una figura clave en Scrum y al él se debe también una parte del incremento de productividad.

Los programadores trabajan sin una especificación detallada, así que constantemente tendrán dudas sobre la funcionalidad a desarrollar. Es imprescindible que alguien familiarizado con el negocio esté con ellos durante todo el proceso de desarrollo.

Además el Product Owner es el guardián del funcional, quizás no sabe programar pero entiende el valor añadido que aporta cada función al negocio. Si es capaz de priorizar dentro del sprint aquellos desarrollos que aportan más valor, conseguirá un retorno de inversión más rápido en cada iteración.

Si el Product Owner no está integrado en el equipo, los programadores serán más lentos, las modificaciones a lo ya desarrollado serán más frecuentes y el valor para el negocio de cada sprint será menor.

Aunque estos sean los tres errores más habituales e importantes, hay otros muchos que se pueden cometer al comenzar a implantar Scrum. Sin ánimo de ser exhaustivos:

– Hacer una especificación pesada. En Scrum se pasa de una idea de alto nivel a la especificación de detalle que hacen los programadores. ¿Para que emplear meses en una especificación de bajo nivel si damos por sentado que el cliente no sabe lo que quiere?

– Solicitar que el cliente valide la especificación. Aunque firme la especificación, sigue sin ser lo que necesita, y lo sabe. Tu equipo puede estar varias semanas de brazos cruzados antes de que el cliente de su consentimiento. ¿No es mejor emplearlas en presentarle una parte del desarrollo?

– Mantener las jeraquías dentro de los equipos. Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. De hecho la figura de Líder Técnico desaparece; todos los programadores colaboran desde un plano de igualdad y ninguno puede imponer su criterio a los demás. El Jefe de Proyecto también se difumina; ya no es necesario negociar alcance y plazo de cada desarrollo, el control económico es mucho más sencillo y las funciones de motivación pasan al Scrum Master.

– No automatizar las pruebas a la vez que se hacen los desarrollos. Esto impedirá hacer pruebas de regresión y los sprints tendrán paulatinamente menos calidad, o menos funcionalidad. Si no automatizas las pruebas, ¿cómo piensas hacer DevOps?

– Tener a los equipos separados geográficamente. Recuerda que los equipos están creando la especificación mientras hacen el desarrollo. Si están separados ¿cómo van a transmitirse este conocimiento?

– No hacer retrospective. Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Si no hay estos espacios para la reflexión, ¿cómo van a mejorar en la aplicación de la metodología?