August 17, 2017

Scrum no es una metodología es un Framework

Scrum se ha convertido en el marco ágil de trabajo más usado en el desarrollo de software en el mundo. Uno de los beneficios de Scrum es la entrega de incrementos de producto en periodos de tiempo cortos. El trabajo se basa en la colaboración y trabajo en equipo. Algunos aspectos como el descubrimiento, el empirismo y la inspección continua son claves para lograr un proceso de mejora continua y de innovación en el producto a construir.  Scrum está basado en un proceso de control empírico y sirve construir productos complejos de forma sostenida.

En muchos casos se usa el termino metodología para referirse a los marcos ágiles como Scrum. La agilidad implica una transformación cultural mientras que la metodología implica un proceso basado en pasos predefinidos. La metodología no fomenta y por el contrario puede impedir el descubrimiento y empirismo. Un mal entendimiento del enfoque ágil puede llevar a aspectos disfuncionales de Scrum como la adopción de un enfoque "mini cascada" en el cual los Sprints se convierten en periodos cortos de tiempo donde se aplica un análisis, diseño, codificación y pruebas en pasos sucesivos y predefinidos. Esto también se puede llamar "water scrum fall". El objetivo de cada Sprint es la entrega de incrementos de producto usables. Sin embargo, algo está sucediendo debido a que en muchos casos solo se cubre la etapa de desarrollo con Scrum y la etapa de operaciones que implica el despliegue del producto se convierte en algo separado y que atenta contra la entrega de producto funcionando.

En algunas situaciones se puede observar organizaciones que en teoría adoptan Scrum, pero esa adopción no se refleja en un cambio cultural en el cual el desarrollo del software trabaje de la mano de operaciones para lograr la entrega de software funcionando en cada Sprint. Por el contrario, se percibe como algo natural que la adopción ágil implica solamente un cambio en los nombres a usar más no en la cultura de la organización misma. Estimaciones con tiempo fijo, carencia de priorización del Product Backlog, etapa de análisis y diseño definidas dentro un Sprint, la falta de un Product Owner, la falta de un Scrum Master, la carencia de un refinamiento de producto que fomente el empirismo y el descubrimiento, Jefes de Proyecto tradicionales con un enfoque de control sobre el equipo o los proveedores de software que no fomentan la colaboración y van en contra de las principios ágiles, sólo por mencionar algunos factores son los que llevan a finalmente no entregar producto funcionando listo para ser usado y en lugar de eso se entreguen productos incompletos y con errores que son rechazados por los clientes en cada Sprint y con ello se provoque la insatisfacción del equipo, la empresa y los usuarios involucrados. Esto nos podría indicar que la adopción ágil se ha convertido en un cliché mas no en un convencimiento real de cambio de la organización. Scrum es un marco ágil que requiere de un impulso de la organización que busca una necesidad de mejora a la forma tradicional en que hace las cosas.

Es decir, Scrum está siendo usando en una gran cantidad de organizaciones, pero el resultado final y el que realmente importa que es la entrega de producto funcionando y que da valor al negocio no se logra en su totalidad. ¿Pero qué está sucediendo, que falta? Uno de los factores más importantes que dificulta la adopción ágil es el cambio cultural. Es más fácil entender la agilidad como una metodología y actuar en función de ello evitando el cambio cultural que se busca con la adopción ágil.