Esta mañana estaba preparando una megamaleta para viajar durante las próximas semanas a Japón, México, Portugal y Alemania cuando me he encontrado el tuit que puedes leer más arriba. Desde el aprecio y el cariño que le tengo a José Manuel Beas, al que en muchas ocasiones he referenciado desde mi blog y esta newsletter, me he preguntado: ¿Qué lleva a una persona que tiene muchos años de experiencia en Agile a pensar que en Scrum se hace planificación por lotes?
El cuchillo la mató, señor juez
Tenemos una tendencia terrible a usar herramientas sin entender muy bien para que funcionan o qué beneficios nos aportan. Cuando le hemos arreado en la cabeza a todo el mundo con ellas y hemos generado daño, entonces le echamos la culpa a la herramienta.
Da igual que sea Scrum, Kanban, Docker o Kubernetes. La culpa nunca es de la herramienta, sino de aquellos que la usan.
En este caso, si tenemos una organización que está acostumbrada a organizar por lotes por una cuestión de economía de costes (eficiencia de los recursos) y les damos Scrum como una nueva herramienta., la usarán de la misma forma que venían trabajando hasta ahora. O lo que es lo mismo, si tenemos un mono furioso y para reducir su estrés le damos un martillo para que haga carpintería, ¿Que hará el mono? Utilizar el martillo para golpear en la cabeza a todos sus congéneres, y si no somos cuidadosos, a nosotros también.
Los cuchillos no matan personas, las matan otras personas empuñando cuchillos. Scrum no es planificación por lotes, son las personas las que utilizan Scrum para planificar por lotes.
¿Y como usan los Sprints para trabajar por lotes?
De manera resumida, cuando alguien que está acostumbrado a trabajar por fases o lotes durante toda su carrera profesional ve Scrum, piensa que los Sprints son fases de 30 días o menos en los que se utilizan el Sprint Planning y Sprint reviewrespectivamente para gestionar el proyecto y hacer seguimiento.
¿Que hay de la retrospectiva? Pues en estas organizaciones se ve como el momento en el que el Scrum Master entretiene un poquito al equipo para que no se aburran o se vayan.
El flujo continuo en Scrum
En Noviembre del 2018 se actualizó la guía de Scrum para hacer explícito lo que ya se sabía desde hace mucho tiempo: En Scrum hay que entregar al menos una vez por Sprint, pero no está limitado a una sola entrega. De hecho, somos muchos los que trabajamos con equipos que despliegan 50, 100 o 500 veces por Sprint. Los defensores de DevOps dicen que en Scrum no se puede hacer Continuous Delivery, cuando es precisamente al revés.
El papel del Sprint Planning no es el de planificar todo lo que se va a hacer en el Sprint, sino que sirve para marcar un objetivo y aportar foco a ese Sprint, centrando el trabajo que vamos a hacer en torno a ese objetivo. Eso permite flexibilidad a la hora de conseguir el objetivo de negocio y estabilidad para stakeholders, que saben que existe una cadencia mínima de entrega.
En la práctica, esto supone que un equipo que usa Scrum, se centra en un Sprint Goal que es un objetivo de negocio y deja más o menos libre el alcance para conseguir ese Sprint Goal. Una vez que tienen una hipótesis y un mínimo de trabajo para comenzar el Sprint, utilizan el Daily Scrum para inspeccionar y revisar su acercamiento o alejamiento del Sprint Goal y planifican de manera diaria para alcanzarlo de acuerdo a la Definition of Done, que aporta la transparencia necesaria.
Mientras tanto, el Product Owner puede seguir trabajando en el Product Backlog durante la duración del Sprint, identificando cuales son los temas más valiosos para trabajar a continuación. En el Sprint Review el Product Owner muestra el incremento del Sprint (que no es más que la suma de todo el producto desarrollado este Sprint integrado con todo lo que se hubiera hecho anteriormente) a los stakeholders y como ha resultado en la consecución del Sprint Goal. Todos juntos analizan la situación y con ello vuelven a decidir que será lo más importante a realizar el siguiente Sprint.
El incremento suele estar ya en producción y también se muestran las métricas de negocio asociadas.
En la retrospectiva, el equipo Scrum analiza como ha sido su trabajo y sus herramientas y deciden mejoras para implementar el siguiente Sprint.
A diferencia de Scrum, en la planificación por lotes se traza un plan en el que se decide todo lo que se va a realizar, se parte en trozos que se van entregando independientemente. Cuando están todos los trozos se unen y se acaba el proyecto.
¿Creéis ahora que Scrum se haga planificación por lotes?