Pensar que Scrum es una navaja suiza
Scrum no es la solución mágica y es por pensar lo contrario que muchas empresas quieren implementarlo por:
1. Escuchar las historias del éxito de Scrum, entregas cortas y valor agregado que da desde una “temprana” instancia de implementado.
2. Quiere sólo estar a la vanguardia o a la “moda” y mantenerse actualizado con lo nuevo.
3. Pensar que Scrum va a salvar al proyecto o empresa de las arenas movedizas por sí solo.
Antes de implementar Scrum hay que analizar si realmente es necesario, viendo el tipo de proyecto y estructura de la organización. Que una empresa esté utilizando Waterfall (cascada) no implica que necesite Scrum o metodologías ágiles.
Aquí quiero dejar una experiencia personal que me sucedió en una empresa Internacional, la cual quería cambiar a Scrum y el proyecto era, lo que se llama, un enlatado. Este tipo de modalidad se basa en un software ya desarrollado que se le pueden hacer ciertas modificaciones o, incluso a veces, agregar una nueva funcionalidad. Luego se instala o implementa en el cliente, pero desafortunadamente la esencia del producto queda igual. Un ejemplo de esto podría ser un software contable. Dependiendo del país de procedencia de la empresa en la cual se implementará, se deberán cumplir ciertas normas impositivas y contables. De este modo el software puede permitir pequeñas modificaciones relativas a estos puntos, pero nada más.
En este caso en particular, Waterfall es el aproach correcto. Si se falla en el cumplimiento de los tiempos, no significa que Waterfall sea ineficiente, sino que hubo otros factores como, por ejemplo, una mala estimación de tiempos o incluso, que el cliente limite la fecha que quiere que se implemente y el proveedor acepte por miedo a perder el negocio.
En definitiva, lo primero que se debe de hacer, es entender si es realmente necesario y si se está estructuralmente preparado. Sin estas condiciones básicas, no se podrá aprovechar de manera adecuada lo que ofrece el marco de trabajo (Framework) de Scrum y, en definitiva, se culpará a Scrum por no haber obtenido los resultados que promete.
No medir el desempeño del equipo de la manera adecuada
Al momento de ver los resultados se Scrum suelen medir en relación al tiempo o cantidad de trabajo de un Sprint, se confunde la mejora del equipo por la cantidad de requerimientos o ítems que se hacen dentro de un Sprint, mientras más, mejor. Esto puede indicar cierta mejora o eficiencia de tiempos, pero no es determinante para decidir si el equipo mejoró o no.
Las cosas que más hay que tener en cuenta a la hora de entender el desempeño son:
- Comparar la deuda técnica entre los Sprints.
- Comparar los puntos de mejora detectados en las retrospectivas contra los que se implementaron efectivamente.
- Efectividad a la hora de cumplir el Sprint goal. Esto está relacionado con una estimación más certera, lo cual deviene también de la experiencia del equipo ensí.
Por ende, estos puntos descritos son los que deberían incluirse en reportes a la alta gerencia o al directorio para que puedan ver el progreso del equipo en su totalidad. Esto representa el verdadero valor agregado que da Scrum para con los equipos y es lo que hay que siempre hay que resaltar. Un equipo unido, no solo genera más eficiencia en su trabajo, sino que forma un espacio relajado y propicio para el desarrollo.
Es por esto la famosa frase de los creadores de este Framework, Scrum es muy fácil de entender, pero muy difícil de implementar.
Tratar de implementar Srcum demasiado rápido
Esto pasa a menudo. Todos escuchan sobre Scrum, que aporta valor agregado rápido y entregas en plazos cortos y sienten que apenas se comience a trabajar con este framework van a tener resultados inmediatos.
Con el correr de los años se ha demostrado que el cambio en las organizaciones toma su tiempo. Srcum también y necesita que se haga de forma firme y de a un paso a la vez. Cambiar de Waterfall (Cascada) a Scrum en algunas semanas, es poco probable que funciones. En Scrum hay cambios fundamentales para los equipos que no sucederán de un día para otro.
Para esto es necesario que la empresa, el sponsor y todos los stakeholdesrs conozcan que deben de pasar 3 y hasta 6 meses para ver resultados tangibles (no solo por la experiencia de vivirlo, sino también por expertos a nivel mundial), esto dependiendo de la dimensión del equipo y la aceptación de todos los interesados.
Implementar Scrum al paso adecuado permite a los integrantes del equipo no solo entender, sino ver cómo funcionan los conceptos y cómo Scrum hace a un grupo más unido y eficiente.
Hay que tener en cuenta que cada equipo es distinto, con tiempos de adaptación y aprendizajes propios. Es por esto, que si en un equipo, al usar Scrum se vieron resultados buenos en un determinado tiempo, no significa que al aplicarlo en otro equipo se tendrán esos resultados en el mismo lapso de tiempo.
Con esto en mente, se debe dejar a Scrum fluir dentro cada equipo, y esperar a que los resultados se muestren por sí solos. Porque si se implementa adecuadamente, indefectiblemente se comenzarán a verán resultados.
Falta de experiencia y habilidades sobre métodos ágiles
A veces sucede que el equipo no conoce o tiene una vaga noción de lo que es Scrum, incluso no entender los roles y responsabilidades de cada parte. Esto decanta en “Implementamos Scrum, pero no sirve”. El problema que noté, en mi experiencia, es que al pasar a Scrum u otros frameworks ágiles, como ser Kanban, es que se extrapolan los roles de la vieja estructura usada. Muchos ven al PO (Product Owner) como el jefe, ya que decide/define los requerimientos del negocio para que sean implementados y el equipo de desarrollo debe de hacer lo que él diga. En scrum, esto no puede estar más lejos de la realidad. El PO es el que sabe/tiene la visión de negocio y tiene en claro cómo debe ser el resultado final (para un proyecto) o como debe ir incrementando las funcionalidades (en caso de un producto, como ser una app como Instagram o tiktok, que se amoldan a las constantes necesidades de las personas). El DT/ED (Development Team o Equipo de Desarrollo) es el encargado dentro de cada sprint de llegar al Sprint Goal, cumpliendo con lo pactado en el Sprint Backlog al inicio de cada uno y así dar valor agregado. El PO (Product Owner) no tiene injerencia en qué es lo que deberá hacerse en cada Sprint. Entre el PO y el ED se deben poner de acuerdo en lo que se hará o puede hacerse en dicho sprint, ya que el que sabe el tiempo que le llevarán las tareas son los que las ejecutarán, así que por más que el PO quiera hacer muchas cosas en un mismo Sprint, quizás demasiadas, es el equipo de desarrollo el que debe estar de acuerdo y así armar el Sprint Backlog.
Sin comprender los roles, estas extrapolaciones de “cargos” o “cadena de mando” lo único que generan es escribir con la mano y borrar con el codo a la hora de tratar de implementar Scrum. Éste, se basa en una estructura más horizontal, dónde cada parte tiene un rol no debe interferir con los otros. Es responsabilidad del Scrum Master hacer entender los roles en su totalidad como así la modalidad de trabajo de Scrum, si esto se respeta/cumple, deja vía libre para tener una implementación de Scrum exitosa.