¿Scrum si o no?

Hoy mi anterior Jefe de equipo, una persona a la que tengo mucho cariño por todo lo que me ha enseñado, me ha dejado un comentario en mi último post que creo que es muy interesante.

"Cuando hay equipos que llevan mucho tiempo trabajando de la misma manera, cómo les convecerías o explicarías que deberían pasarse a Scrum para mejorar su productividad? Creo que no siempre es fácil y mucha gente es reacia a cambiar su forma de trabajar."

Primero, hay que comprender las necesidades de cada equipo y los retos a conseguir. Para ello una pregunta que podemos hacernos es ¿Qué problemas o bloqueos enfrenta la forma actual de trabajar? ¿Cómo se gestionan los cambios de requisitos y los imprevistos? ¿Cómo se evalúa la productividad del equipo?

Puede que haya problemas de comunicación entre las personas del equipo, con el cliente, etc. Problemas que luego dan lugar a mala planificación y muchos cambios de alcance.

Scrum lo que aporta, es que al ser iteraciones cortas, como equipo nos podemos adaptar rápidamente a los nuevos requisitos de los stakeholders. Además, cada iteración tiene su review, con lo que tenemos un feedback muy temprano de las funcionalidades por parte de los stakeholders y del Product Owner.

Segundo, la productividad es una de las áreas en las que Scrum puede ayudar, ya que aborda los siguientes puntos:

• Visibilidad y transparencia: tenemos varias ceremonias dentro de cada sprint como las dailies y las reviews donde todos (tanto equipo en las dailies, como stakeholders en las reviews) tenemos una mejor visibilidad del proyecto y su progreso.
• La adaptabilidad: se permiten cambios frecuentes, con lo que eliminamos la incertidumbre de si vamos a trabajar en un desarrollo durante meses que a lo mejor ya no es relevante cuando lo hayamos terminado.
• Feedback continuo: como he puesto en el primer punto, en las reviews tenemos un feedback temprano de los stakeholders y podemos adaptar y ajustar el trabajo evitando grandes errores.
• Motivación del equipo: al ser equipos autogestionados (o al menos este es el punto que se quiere lograr) aumenta la motivación de estos y la sensación de pertenencia.

Tercero, por supuesto no podemos hacer un cambio radical de hoy, por ejemplo, en Waterfall a mañana en Scrum. A mi parecer se debería de hacer un piloto durante un tiempo para que el equipo pueda experimentar si de verdad Scrum les beneficia o no.

Cuarto, podemos fijarnos en otros equipos o empresas que hayan implementado scrum y ver si les ha ayudado a mejorar la productividad y colaboración (obviamente, si).

Quinto, cada miembro del equipo es de su padre y de su madre, para que engañarnos. Y sobre todo, los más seniors o los que llevan más tiempo en el proyecto son los más reacios al cambio. Se genera esta resistencia por miedo a perder el control o no estar a la altura de las nuevas exigencias. Para solucionar este bloqueo, las retrospectivas son muy buen medio, donde se deberían de hablar estos temores de manera abierta. Así nos aseguramos que el cambio es gradual y que esta forma de trabajar no es ninguna amenaza, sino una herramienta para facilitar el trabajo de todos.

Sexto, normalmente los equipos rechazan nuevas formas de trabajo porque piensan que van a ser demasiado rígidos o que cambiarán su forma de trabajar radicalmente. Scrum no es necesario seguirlo al pie de la letra desde el principio, se pueden ir implementando elementos poco a poco y ajustarlos (como las dailies, las retros...). Al final se trata de encontrar que es lo que funciona mejor para nosotros.

Séptimo, para que todo lo anterior funcione es necesario ofrecer apoyo para que el equipo se sienta cómodo con Scrum. Se pueden proporcionar recursos, workshops, o guías que deberá proporcionar el Scrum Master para que el equipo se sienta más preparado para el cambio.

Y como octavo punto, es muy muy importante primero concienciar y enseñar a los stakeholders y a la compañía como utilizar este marco de trabajo. Es muy relevante que comprendan el funcionamiento de Scrum para que no haya fallos en la comunicación entre el equipo Scrum y ellos y no se produzcan futuros errores, bloqueos o incluso que el equipo se desilusione.

Al final, es clave mostrar que scrum no es una imposición, sino una opción que puede hacer que el equipo trabaje de manera más eficiente y disfrute más de su trabajo, y que tienen libertad para adaptarlo a sus necesidades.