July 9, 2020

Scrum no es una metodología, es un marco de trabajo

Scrum

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 para mejorar el aprendizaje de los clientes y el mercado con el propósito de mejorar los resultados de negocio a través de la innovación de productos. Scrum promueve la autoorganización, trabajo en equipo, mejora continua y la entrega de un incremento de producto con valor en cada Sprint. Scrum está basado en un proceso de control empírico y ayuda a la gestión del desarrollo de productos o servicios. Al usar el empirismo aceptamos el hecho de que las cosas pueden cambiar en cualquier momento y que la mejor forma de enfrentar estos cambios es a través del uso de la transparencia, inspección y adaptación ayudando a mejorar la respuesta al cambio, reducir los riesgos de negocio y aprovechar nuevas oportunidades de negocio que se pueden identificar al escuchar continuamente a los clientes al descubrir la brecha de satisfacción que se puede cubrir con nuevo producto.

Scrum no prescribe, no receta y no define como se deben llevar a cabo las cosas, que herramientas o prácticas usar para desarrollar un producto o servicio. No hay fórmulas o pasos establecidos que seguir y adoptar al usar Scrum. Tampoco existen las mejores prácticas que deben usadas una y otra vez sin cuestionar, las mejores soluciones emergen de los equipos autoorganizados de acuerdo al contexto y el problema a resolver, algo que funciona muy bien en una empresa y situación no es necesariamente la mejor solución a seguir en otras situaciones.

Una metodología implica usar un proceso predictivo basado en pasos predefinidos que se tienen que seguir. La metodología no fomenta y por el contrario puede impedir el descubrimiento, empirismo y el aprendizaje de los clientes y el mercado que puede llevar a distorsiones en el uso de Scrum como la adopción de un enfoque 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.

Scrum es un contenedor para otras prácticas o métodos como Test Driven Development, Integración continua, despliegue continuo entre otros. Complementar Scrum con otras prácticas que mejoren el uso de sus tres pilares como son la transparencia, inspección y la adaptación mejora las posibilidades de lograr la entrega de valor.

Scrum tiene un contexto cultural que se basa en los valores de Scrum como son la valentía o coraje, foco, compromiso, apertura y respeto.

Cuando se viven los valores de Scrum se crea la confianza para generar transparencia que permite usar la inspección y adaptación. Scrum es ligero porque la intención no es definir pasos específico en detalle sino definir las reglas de juego, cada equipo auto organizado debería definir como jugar el juego basado en esas reglas y seleccionar las prácticas, métodos a usar.

En algunas situaciones se puede observar organizaciones que en teoría adoptan Scrum, pero esa adopción no se refleja en un cambio cultural junto con la mejora de las capacidades para lanzar producto en corto tiempo con la intención de mejorar el aprendizaje 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. Proyectos con alcance, costo y tiempo fijo, Product Backlog gestionado en forma aislada por el Product Owner con poca colaboración del equipo de desarrollo, etapa de análisis y diseño realizadas en un Sprint cero, Sprint de desarrollo y pruebas sin entrega de producto terminado, Sprints de estabilización y despliegue que mantienen el uso de un enfoque predictivo que reduce la capacidad de ser ágiles y responder a los cambios, Scrum Masters que controlan el cumplimiento de tareas y horas y le dicen al equipo de desarrollo la receta de cómo hacer Scrum en lugar de promover la autoorganización y la creatividad, la carencia de un refinamiento de producto que fomente el empirismo y el descubrimiento continuo, Jefes de Proyecto tradicionales con un enfoque de control sobre el equipo, solamente 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é más 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 mejorar la forma tradicional en que hace las cosas.

Finalmente Scrum no es un marco de trabajo donde se busca hacer más cosas en menos tiempo, es decir buscar eficiencia. Scrum se basa en el empirismo y si queremos potenciar sus beneficios se requiere que exista foco en le entrega de valor de negocio,  Scrum es una herramienta para lograr la agilidad empresarial.