¿Por qué no me gusta scrum?

Y ¿cómo identificar si lo usas mal en tu equipo?

Si tuviera que resumirlo en un Tweet diría:

Scrum es agile de palo. Nos preocupamos tanto por seguir el proceso, que a veces perdemos de vista el objetivo final.

En parte, este tweet está pensado para que los defensores de scrum salten a mi cuello y cuenten lo ágil y bien que sus equipos trabajan en scrum. Y no os voy a engañar, a la mitad les creo. He visto cómo compañeros de mi (antigua) empresa, hacían algo que a mis ojos era scrum de manual, sin dejar de ser “ágil”. Es decir, conseguían mantener al equipo involucrado, hacían todas las ceremonias, los clientes estaban contentos y al resto de equipos nos preguntaban por qué no lo podíamos hacer así de bien.

-       ¡Ajá! No te gusta scrum porque se te da mal. – Pensaréis.

Puede ser, no me duele decirlo. Sin embargo, tras haber probado scrum en varias empresas, con distintas iteraciones sobre el proceso de desarrollo con el equipo, creo que nada (ni scrum, ni ningún otro framework) supera a la capacidad del equipo de adaptarse a cambios, incluso del propio marco de trabajo. Y esta cualidad no aparece ni se desarrolla en un equipo simplemente por el hecho de implementar una metodología, por muy buena que sea, y para mi está es la mayor ventaja de trabajar ágilmente.

Reflexionando sobre mi aversión por scrum, creo que el problema principal reside en la aplicación inadecuada y masiva. Agile fue diseñado específicamente para el desarrollo de software, y los procesos y prácticas que se utilizan son inherentes de su contexto. Scrum nace de la necesidad de implementar procesos ágiles en tu equipo. Es una forma de llevarlo a la práctica, ni la mejor, ni la peor. Cuando aplicas scrum a otras industrias fuera del desarrollo de software, se pueden generar más problemas que soluciones. Las empresas deben evaluar que enfoques agile son los más adecuados para su contexto y objetivos, y adaptarlos según sea necesario. Si tras ese análisis, scrum encaja, bienvenido sea. Desgraciadamente, muchas veces por falta de tiempo, no se evalúan las necesidades del proceso ni se prueban distintos procedimientos, sino que se adopta directamente una solución generalizada, que en la mayoría de los casos no resuelve las particularidades de muchos equipos.

Antes de empezar, ¿qué es Scrum?

Mucho se ha escrito sobre este tema. Mi recomendación si no sabes nada es que:

• Preguntes a ChatGPT

• Leas el Scrum Guide

• Busques algún artículo con la duda que se te haya quedado

Tres síntomas de un mal uso de scrum en tu empresa

Procesos y herramientas sobre individuos e interacciones

Uno de los principios del agilismo es priorizar a las personas y a la interacción sana entre ellas, sobre documentos, procesos y herramientas de trabajo. Esto es así para fomentar la colaboración y priorizar el trabajo realizado, sobre procesos que no añaden valor. A la hora de implementar scrum en una organización, la secuencia de ejecución debería ser así:

• Organización al equipo directivo: como empresa tenemos que ser más ágiles para seguir siendo competitivos.

• Equipo directivo al equipo de desarrollo: necesitamos ser más ágiles. Organizaros para poder entregar más valor al cliente final.

• Equipo de desarrollo: por las aptitudes del equipo, el contexto y objetivos actuales de la empresa, queremos usar scrum.

Cuando normalmente es así:

• Organización al equipo directivo: como empresa tenemos que ser más ágiles para seguir siendo competitivos.

• Equipo directivo al equipo de desarrollo: el próximo lunes tenéis un taller con un coach que nos va a enseñar a trabajar en sprints.

• Equipo de desarrollo: aparece en el taller y les dicen de la noche a la mañana que tienen que empezar a hacer reuniones, y gestionar un backlog, trabajar con Jira, etc.

No impongas scrum como forma de trabajo si tu objetivo es ser más competitivo. Empieza por priorizar la autogestión y delegar tus métricas de negocio en los equipos de producto. Promover la agilidad para este objetivo haciendo que toda la organización trabaje en scrum, sólo te generará frustración.

Reunionitis programada

Dos horas de sprint planning, dos horas de sprint review, dos horas de refinement, diez plannings de diez minutos. Eso hace casi un día de trabajo cada dos semanas invertido en reuniones. Digo invertido, porque las reuniones en sí mismas no son malas, es una inversión que el equipo tiene que hacer para conseguir ciertos objetivos.

Si en tu equipo….

• Notas ausencia de los participantes.

• Necesitas crear reuniones adicionales para tratar temas que ya estaban cerrados.

• Sientes que tienes que coordinarte con el equipo fuera de estas reuniones

Parece que has podido caer en este problema. Scrum, como cualquier marco de trabajo, requiere que todo el equipo esté comprometido en participar activamente y desempeñar su rol. Para ello, es importante que las reuniones tengan agenda y contenido, de lo contrario haremos bien en cancelarlas, para evitar la desmotivación del equipo.

Rolling sprints

El sprint planning es un momento en el que el Product Owner, junto con el equipo de desarrollo, eligen el objetivo del sprint. Un desarrollo concreto que, en dos semanas, estará en manos de los usuarios. Trabajar por sprints es uno de los grandes atractivos de scrum, ya que obliga a fijar un foco de trabajo para todo el equipo. Para poder tener la certeza de que en dos semanas se puede desarrollar una funcionalidad específica, es necesario que el Product Owner haya refinado bien el Product Backlog y que las historias de usuario estén validadas por el equipo de desarrollo en alcance y complejidad técnica.

Cuando este trabajo no se realiza, suele quedar trabajo pendiente que acometer al acabar el sprints. Por lo que el sprint planning, se convierte en una reunión de mover tarjetas del sprint anterior al nuevo y añadir un poco más de trabajo a la iteración actual.

Esto pervierte la finalidad de scrum de entregar valor al usuario al acabar el sprint para poder validarlo. Si entregas la funcionalidad a mitad del siguiente sprint, ¿cuál es el foco del nuevo sprint? ¿validar esa funcionalidad o ponerse con la siguiente? Por lo general, esto acaba generando desconfianza fuera del equipo por retrasos sistemáticos y una frustración dentro del equipo de desarrollo, al verse forzados a acometer objetivos inalcanzables de manera continua.

Pero Álvaro, ¿tenemos que dejar de trabajar en sprints?

¡Claro que no! Tenéis que dejar de usar sprints, si después de un tiempo, no estáis aprendiendo qué quiere tu usuario y no sois flexibles a la hora de cambiar vuestra hoja de ruta. Scrum proporciona un framework para trabajar de forma más ágil. No obstante, este framework requiere de un aprendizaje y un cambio cultural, que, si no se gestiona debidamente, puede provocar una frustración generalizada y una falta de confianza en la dirección de la empresa.

El motivo por el que a mí no me gusta scrum, es porque priva al equipo de producto de poder definir su propio marco de trabajo. Forzar a un equipo a seguir un proceso, acompañado (muchas veces) de unas herramientas fijas, puede no resolver los vicios existentes y peor aún, enmascararlos en agilismo dificultando su resolución. Una vez entiendes la base y cómo trabajar bien en agile, sus herramientas tienen muchas ventajas. Montar una retrospectiva para que el equipo identifique puntos de mejora o crear un backlog de historias de usuario para gestionar la carga de trabajo, mejora las dinámicas de trabajo y fomenta la eficiencia.

En última instancia, la clave para el éxito con agile es comprender su naturaleza y objetivos, aplicar los procesos y prácticas adecuados de manera rigurosa y estar dispuesto a adaptarse y cambiar según sea necesario. El resto de frameworks son sólo ejemplos de cómo poner estos principios en práctica.