Scrum está pensado como un marco simple pero suficiente para la entrega de productos complejos. Scrum no es una solución única, una bala de plata o una metodología completa. En cambio, Scrum proporciona los límites mínimos dentro de los cuales los equipos pueden autoorganizarse para resolver un problema complejo utilizando un enfoque empírico. Esta simplicidad es su mayor fortaleza, pero también es la fuente de muchas malas interpretaciones y mitos que rodean a Scrum. En esta serie de publicaciones, nosotros, sus ” Cazadores de mitos “, Christiaan Verwijs & Barry Overeem, abordaremos los mitos y malentendidos más comunes. 

PD: Las grandes imágenes son de Thea Schukken.

Hoy abordamos un mito bastante persistente. El mito se hace evidente en declaraciones como “Scrum es inflexible porque las nuevas versiones o nuevos releases solo son posibles después de que el Sprint se complete” o “DevOps o Kanban son más adecuados para nosotros porque nos permiten liberar más rápido”. De cualquier manera, el núcleo del mito es que Scrum solo permite a los equipos liberar software funcionando al final de un Sprint, lo que reduce la velocidad y la flexibilidad si los equipos son capaces de hacerlo más rápido.

Rompiendo el mito

Este mito es un ejemplo de hacer que un marco sea más importante que el objetivo, a pesar de que se basa en un malentendido del marco en este caso. El propósito del marco Scrum es desarrollar productos y resolver problemas complejos mediante el uso de un proceso empírico que promueve el feedback rápido. En iteraciones cortas, usamos feedback (internos y externos) para aclarar el problema y descubrir la mejor solución. Al hacerlo, evitamos resolver el problema incorrecto y / o implementar una solución subóptima. Dado ese objetivo, ¿qué tan probable es que Scrum obligue a los equipos a entregar software funcionando solo al final de un Sprint?

El propósito de cada Sprint es darle tiempo y enfoque al Equipo de Desarrollo para transformar una selección de trabajo del Product Backlog en un incremento “Terminado”. Esta selección se hace transparente en el Sprint Backlog y está guiado por un objetivo valioso que el Product Ower quiere lograr. Este objetivo se captura en el Sprint Goal y es creado por el Equipo Scrum durante el Sprint Planning.

El tipo de trabajo necesario para lograr un incremento de “Terminado” varía según el equipo, y se hace transparente en una Definición de Hecho (DoD). Algunos equipos incluyen tipos específicos de documentación, otros equipos incluyen capacitación de usuarios, implementación en un entorno provisional o incluso la validación de nuevas funciones a través de métricas de clics basadas en el uso real. De cualquier manera, solo podemos trabajar empíricamente de verdad si “Terminado” incluye al menos todo el trabajo requerido para llevar el Incremento a un estado en el que se pueda liberar inmediatamente después del Sprint si el Product Owner del producto decide hacerlo.

Cuanto menos capaces sean las organizaciones de ofrecer un incremento de “Terminado” en cada Sprint, menos ágiles serán. Después de todo, los incrementos solo son realmente valiosos cuando están en manos de los usuarios y pueden generar feedback de la vida real. Cualquier otra cosa menos significa que la calidad y la exhaustividad de los comentarios por parte de los usuarios, los clientes y lo que sucede en el entorno después del lanzamiento se reducirá considerablemente.

Con respecto al mito, el Marco Scrum define el Sprint como un límite mínimo para cuándo entregar un incremento “Terminado”. No hay nada en el Marco de Scrum que impida a los Equipos Scrum lanzar software de trabajo en todo el Sprint, siempre y cuando el Product Owner del producto esté involucrado en la decisión de liberarlo. De hecho, Scrum lo alienta. Después de todo, esta es la mejor manera de optimizar el valor del proceso empírico que está detrás de Scrum. Permite que los comentarios lleguen antes y lo hace cada vez más útil y realista. Y permite a los equipos generar valor para las Stakeholders más rápido. ¿Cómo puedes no querer eso?

Orígenes del mito

Un origen de este mito es un malentendido de lo que constituye un “Incremento”. La Guía Scrum simplemente lo define como la suma de todos los elementos del Product Backlog completados durante el Sprint. Aunque el incremento puede ser un paquete de nuevas características que se implementarán de una vez al final de un Sprint, no tiene que ser así. Un incremento también puede ser la suma de Items desplegados en todo el Sprint.

Un segundo origen radica en el uso de terminología como “Incremento de producto potencialmente liberable” o “Incremento de producto potencialmente usable”. Aunque no se pretende de esta manera, los calificadores pueden apoyar la creencia de que los incrementos son solo (potencialmente) “liberables” o “liberados” al final de un Sprint.

Un tercer origen, y más reciente, radica en la distinción que a veces se hace entre Scrum y DevOps. Usando alguna versión de este mito, se argumenta que DevOps es superior a Scrum porque permite a los equipos liberar software de trabajo más rápido. Debido a que DevOps no conoce el concepto de Sprint, se argumenta que el trabajo del software se puede liberar siempre que el equipo lo considere “Terminado”.

Pero Scrum y DevOps son amigos cercanos, ambos intentan implementar un proceso empírico con un ciclo de feedback lo más corto posible. Donde Scrum tiene un fuerte enfoque en el proceso que se necesita para construir lo que los Stakeholders ​​necesitan, DevOps trata con prácticas y habilitadores técnicos que lo hacen posible. En cierto sentido, Scrum proporciona una brújula y un destino para viajar, mientras que DevOps proporciona botas resistentes para hacerlo sin ampollas o pisar cosas afiladas. Realmente son dos caras de la misma moneda.

¿Qué pasa con el Sprint Review?

Pero, ¿Cuál es el propósito del Sprint Review si ya se ha liberado todo durante el Sprint? Si su Sprint Review solo consiste en una demostración, sí, el evento se convierte en una simple repetición de cosas que ya sabe. Pero echar un vistazo al software o producto en funcionamiento es solo una pequeña parte del Sprint Review. El propósito principal de este evento es inspeccionar lo que se hizo durante el Sprint y decidir que será lo próximo que se puede hace para optimizar el valor.

“Cuanto más” Terminado “sea el incremento, más útil será la información recopilada”.

Entonces, si el equipo ya libero un trabajo de software durante el Sprint, esto hace que el Sprint Review sea una excelente oportunidad para inspeccionar el feedback de usuarios reales y adaptarse en función de los conocimientos que surjan de eso. El valor del Sprint Review en realidad aumenta debido a esto ya que el enfoque cambia de mirar hacia atrás a tomar decisiones estratégicas sobre el futuro (cercano).

Consejos

• Como Scrum Master, entrene a su equipo para expandir continuamente su Definición de Terminado (Definition of Done). En términos más simples, ayude al equipo a reducir la cantidad de trabajo que queda por hacer después de que lo consideren realizado (por ejemplo, pruebas, control de calidad, deploy, documentación);
• Invierta en aprender sobre DevOps y sus prácticas asociadas, como pruebas automatizadas, infraestructura como código, virtualización e integración continua. Son habilitadores críticos para liberar más rápido sin comprometer la estabilidad y la calidad;
• Si su Sprint Review es solo una demostración, y su equipo puede liberar en todo el Sprint, use el Sprint Review para su propósito previsto: recopilar comentarios (Feedback) sobre el incremento entregado, el Product Backlog, las condiciones del negocio y promover la colaboración entre todos los Stakeholders;
• Con su equipo y dentro de su organización, reflexione sobre la cantidad de trabajo que debe hacerse después de que un equipo considere un incremento “hecho” (QA equivalente, despliegue). Ayudar a la organización y al equipo a cambiar procesos y prácticas para disminuir esta cantidad de trabajo ‘deshecho’;

Si quieres profesionalizarte en agilidad a través de Scrum te invitamos a las próximas fechas abiertas al público

Conclusiones

En este post discutimos el mito de que los equipos Scrum liberan el mejor software funcionando al final de un Sprint, lo que limita a los equipos que son capaces de liberar más rápido. Mostramos que el Framework Scrum en realidad alienta a los equipos a mejorar sus procesos, infraestructura y prácticas hasta el punto en que se puedan realizar liberaciones en todo el Sprint. Esto maximiza la calidad del feedback del proceso empírico que Scrum intenta implementar. También ofrecemos algunos consejos para ayudarlo a avanzar hacia este punto.