SCRUM no es el culpable

¿SCRUM vuelve buenos programadores en programadores promedio?

Argumento inicial


SCRUM obliga a hacer reuniones diarias de seguimiento porque nadie confía realmente en que el equipo se vaya a gestionar solo. Los programadores suelen tomar las historias más sencillas sólo para mostrar avances en volumen pues los administradores no entienden, o no les interesa, entrar en el detalle de la dificultad de las historias. Por otra parte, las estimaciones se suelen inflar descaradamente y aunque se cumplan los estimados, lo que realmente se está haciendo es desperdiciar el dinero de la compañía y degradando la productividad porque la mayoría de las historias se pueden resolver en la mitad del tiempo o menos. El resultado de todo esto es que todos los miembros del equipo caen en un torbellino de mediocridad que los arrastra a ser peores, no mejores. Todo ello se lo debemos a SCRUM.

SCRUM es un marco de referencia, no una metodología formal. Cada empresa, proyecto y equipo tiene sus propias particularidades que obligan a adaptar SCRUM a la realidad de los proyectos, no al contrario.

Algunos ejemplos de adaptaciones:

Hacer seguimiento por el número de historias terminadas, no por la desviación entre las estimaciones y los tiempos de ejecución (#NoEstimates).
Hacer reuniones de temas de negocio y de temas técnicos de manera separada, con diferentes miembros del equipo.
Balancear las historias de desarrollo nuevo, historias de mejoras e incidentes de producción.
Adaptarse al trabajo remoto, diferencias geográficas e incluso culturales de los diferentes miembros del equipo.
En ese sentido, aunque hay lineamientos para los diferentes roles del equipo, el grado y características de la supervisión del equipo depende de muchos factores. Por ejemplo, los miembros senior seguramente requieren una supervisión menor que los miembros junior, quienes necesitan una guía constante y revisiones más profundas de calidad. Las reuniones diarias de SCRUM no están diseñadas realmente para un seguimiento individual de las personas sino del equipo en general. El éxito de ese seguimiento, de la cohesión del equipo, de la consecución de metas, incremento de productividad y mejoras en calidad, entre otros aspectos, dependen del equipo mismo y de la cultura que impongan el SCRUM Master (más enfocado a temas técnicos) y el Product Owner (más enfocado a los temas de negocio y cómo la tecnología los puede apoyar).

Pasar de agache con las historias fáciles
Los individuos no deberían decidir qué historias trabajan. Hay otros factores como la complejidad, experiencia y cargas de trabajo, entre otros aspectos. La asignación la debería dar el SCRUM Master basado en su criterio. SCRUM no tiene la culpa de que continuamente un individuo reciba siempre el trabajo fácil.

Inflando estimados
Primero, las estimaciones no son estrictamente necesarias (#NoEstimates). Aunque aún hoy, después de estar hablando de no hacer estimaciones por muchos años, los Project Managers y directivos en general, seguirán preguntando por los estimados y fechas de entrega. Si se usan estimaciones no se le puede creer a un individuo ciegamente. El equipo mismo, y más el SCRUM Master, deben tener criterio suficiente para controvertir estimados muy altos o muy bajos. Si las personas inflan sus estimados y el equipo y managers lo aceptan, están creando una cultura de trampa y mediocridad. SCRUM no tiene la culpa de ello.

Productividad baja
Nuevamente, si la productividad del equipo es baja, y un buen programador podría hacer lo que se compromete en la mitad del tiempo o menos, pero igual se echa el doble y los managers ni el equipo dicen nada, son los managers, especialmente el SCRUM Master que debe tener la visibilidad de lo que está pasando al interior del equipo, quienes son los culpables. Esto crea una cultura de mediocridad difícil de detener. SCRUM no tiene la culpa.

Conclusión
SCRUM no es ni el mejor enfoque ágil ni el único, aunque tal vez sea el más popular hoy en día. Como marco de referencia, no es una camisa de fuerza ni tampoco tiene todas las respuestas, yo diría que pocas en realidad, frente a los proyectos. Es por ello por lo que no se puede culpar a SCRUM del fracaso de los equipos. Es más, yo creo que tampoco del éxito. Todo depende de la gente.

Artículos relacionados

SIVIGILA 4.0

SIVIGILA 4.0

SIVIGILA 4.0, es una aplicación enfocada en el procesamiento y consolidación de la información generada por cada uno de los actores del sistema de...

leer más