Ciertamente, te puedo asegurar que, día sí y día no, me encuentro una cantidad de extraños usos y adaptaciones de Scrum, por intentar adaptar Scrum a la manera de trabajar de toda la vida, o por no entender bien qué es, que lo deforman hasta tal punto que… de Scrum solo le queda el nombre. Además, son adaptaciones de las que no tengo muy claro su eficiencia… pero desde luego mucho ingenio sí que tienen.
Yo siempre digo, cuando veo una de esas adaptaciones que te dejan de piedra… “de verdad, es muchísimo más fácil trabajar en Scrum tal y como es, en comparación con lo que habéis montado, para intentar hacer lo de siempre pero como si fuese Scrum”.
En gran parte, en muchas organizaciones, la mayoría de las adaptaciones extrañas de Scrum vienen de seguir pensando y trabajando en modo proyectos. Como este tema es un poco largo, probablemente de para más post en el futuro, hoy vamos con el primero, el de ojo con “confundir versión a entregar al cliente con final de sprint”.
Un Sprint no tiene obligatoriamente que terminar con una versión final entregada al cliente o usuario o puesta en producción.
Hay quien hace “Sprints” (entre comillas) en función de entregables finales a sus clientes, como si el Sprint fuera un proyecto único y final, adaptando la temporalidad del Sprint a la temporalidad que tendría un proyecto, con un único Sprint. Cierra fechas de entregas con el cliente y de ahí para atrás “monta el Scrum” con un sólo Sprint.
Es decir, que si pacta que con el cliente que va a entregar una primera versión del desarrollo dentro de dos meses… va y hace un Sprint de dos meses (que ya con lo de dos meses no sería Sprint), si la versión 2 se ha acordado que debe estar lista en 3 meses… pues Sprint de 3 meses. Y, normalmente, dentro de esos supuestos Sprints todo acaba en un desarrollo cascada: 3 semanas de diseño, 6 de codificación, 2 de pruebas, etc.
Un Sprint, manteniendo su temporalidad de menos de un mes, termina con “un incremento” o un “producto potencialmente entregable”, es decir, una versión del producto, que hay quien llama prototipo, con un incremento de valor (por ejemplo, para que se entienda, con más funcionalidad incorporada que el anterior) y en condiciones “técnicas” para entregarse al usuario o cliente si el Product Owner así lo decide.
Recuerda que el ciclo de vida es iterativo e incremental, muchos Sprints, normalmente fijos, de menos de 30 días, y sus correspondientes prototipos, los cuales podrían ser necesarios para llegar a tener tu «versión final a antregar al cliente». La suma de muchos Sprints y sus correspondientes incrementos acbarán en una versión entregable (si así lo decides).
Si no ves Scrum así, como realmente es, entonces no te va a cuadrar nunca el uso de los Sprints, Sprints de los de verdad, de los de menos de 30 días, que terminan siempre con un incremento. Marcan un ritmo, una manera de trabajar de un equipo.
NO todo Sprint tiene que terminar con una versión puesta en producción o entregada al cliente final
En esta línea, NO necesariamente todo Sprint tiene que terminar con una versión puesta en producción. Puede que sí o puede que, incluso, en el lado contrario, se pasen cosas a producción antes de terminar el Sprint, o que sepasen al final del Sprint o puede que se necesiten muchos Sprint para hacerlo.
La decisión de cuándo hay ya un MVP (producto mínimo viable), es decir, algo con la funcionalidad mínima para entregarlo a los usuarios finales, es del Product Owner, él es quien decide cuándo se libera, cuándo hay release, cuándo se entrega la versión al usuario, qué se pasa a producción (o como quieras llamarlo). La responsabilidad del equipo es tener siempre el producto listo para que si el Product Owner lo decide… se libere.
Lo que no quita, no te vayas ahora al otro lado, que un final de Sprint termine con algo terminado, potencialmente entregable.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Resumen de mi 2023 en imágenes - 28 diciembre, 2023
- ¿Por qué el Scrum Master está en PELIGRO de extinción? - 21 diciembre, 2023
- Probando la generación de vídeo por IA para difundir conocimiento libre - 14 diciembre, 2023
Crítica constructiva: un análisis ortográfico y otro gramatical no venía mal
Y que el día tuviera 30 horas tampoco 🙂
Hola Javier, buena aclaratoria de un tema que genera mucha confusión. Un abrazo.
Hola Javier,
¿Cómo crees que casa Scrum, que propugna la generación de incrementos de valor de un producto al final de cada sprint, con DevOps, que promueve el despliegue continuo de nuevas características? ¿Existen los sprints en DevOps o cada historia de usuario tiene su ciclo de vida que acaba en producción independientemente de la existencia de los sprints?
Creo que hay bastante confusión al respecto y podría dar para un buen post 😉
Un saludo.