Para que dirías que sirve este evento de Scrum?
No me considero un ultra especialista de Scrum, por aquello del síndrome del impostor tan común en el sector de la agilidad (otro día hablamos de esto), pero le veo algunos beneficios importantes.
Sirve:
Para tener una conversación abierta entre equipo y PO sobre “qué hacemos a continuación”.
Para equilibrar adecuadamente la capacidad de desarrollo con el tamaño del trabajo que vamos a acometer. (dígase tamaño en todas las acepciones que podamos pensar en el sector del software)
Para establecer las expectativas del PO al respecto de lo que el equipo espera entregar a lo largo de la próxima iteración.
Para aislar al equipo de desarrollo de toda la complejidad del backlog completo y del ruido que se genera cuando hablamos de cosas que no sabemos seguro de si queremos o no hacer. Para enfocar.
El punto de equilibrar la capacidad con el WIP que inyectamos al sistema es fundamental, porque de ahí se deriva en gran parte la viabilidad de cumplir con los objetivos y que el equipo esté alineado con las expectativas establecidas al principio del sprint.
Algo así como decir que
En el sprint plan calibramos el tamaño del trabajo, priorizamos con la PO y seleccionamos juntos lo que vamos a abordar, la PO está de acuerdo con esa selección y espera recibir eso durante la iteración; el equipo se enfoca y todos trabajan en pro de conseguir ese objetivo común.
Si esos objetivos se cumplen de manera consistente, la PO sentirá que el equipo es predecible, lo que lleva a fortalecer los vínculos de confianza. Eso hace que la PO pueda, por su parte, adquirir compromisos con otras partes de la organización e ir preparando todo lo que desencadena una entrega de nuevas funcionalidades a Negocio: modificación de procesos de negocio, gestión del cambio, comunicación, comunicación a cliente final, variación de contratos o, incluso en alguno de los casos que estoy conociendo de primera mano, reestructuración de los espacios físicos para adoptar las nuevas maneras de trabajar.
Es decir: aguas abajo hay muchos grupos de trabajo que dependen del cumplimiento de las expectativas generadas en un Sprint Plan.
-- Hay incertidumbre en el desarrollo.
-- Ya lo sé.
-- Estamos en un mundo complejo, la organización y el software forman un sistema adaptativo-complejo que lo hace de todo menos predecible.
-- También lo sé. Y por eso no pido adherencia al 100%, pido trabajo continuo en pro de la mejora.
Cuanto más puedas reducir la desviación que hay entre lo que te propones hacer en un sprint y lo que consigues, la organización funcionará mejor aguas arriba (en la relación entre los POs y el resto de personas interesadas en aquello que se desarrolla) y aguas abajo (la relación que todas esas personas tienen con el incremento).
Como le decía Batty a Deckard minutos antes de morir, “he visto cosas que vosotros no os creeríais”. He visto muchos equipos que se toman la planificación del sprint como un “trocear el trabajo en bloques de 15 días”, pero también los he visto que planean y comunican aguas abajo para que todo el flujo vaya suave.
Hay gente ahí fuera que lo hace de película: esos son los imprescindibles, esos son aquellos de los que debemos aprender.
PS: Te dejo un par de preguntas para que le des a la reflexión:
¿Qué factores influyen en la predictibilidad de tu(s) equipo(s)?
¿Cómo influye la cantidad de información disponible al respecto de un determinado PBI sobre la capacidad que tenemos de cumplir la meta del sprint?
¿Cuál es el valor del refinamiento en todo esto?
Estimar o no estimar... esa es la cuestión.
¿Tiene sentido generar ocupación al 100%? ☠️
No hay comentarios:
Publicar un comentario