Uno de los temas que muchos comentan pero del que realmente pocos se ocupan es
de planificar en Scrum. En vez de hablar de ese tema hay que ponerse a trabajar
y armar un plan, lo suficientemente bueno como para poder llegar a satisfacer
al cliente. Sin embargo el objetivo de Scrum no es tener un plan, es entregar
features completos de un producto. Un plan nos ayuda a manejarnos en el corto y
largo plazo.
En Scrum hay muchas oportunidades para planificar, ejecutar y entregar
software. La razón para usar Scrum es simple: la necesidad de entregar algo de
valor para el cliente, reduciendo riesgo, entregando periódicamente,
inspeccionando y adaptándonos a las necesidades.
Se puede hacer planificación a largo plazo en el Product backlog mediante Release
planning. Se puede hacer planificación a corto plazo a nivel de Sprint backlog
mediante Sprint planning. Finalmente se puede hacer planificación diaria y
ajustes mínimos en el Daily Scrum. Y el progreso de todo esto se puede seguir
en diferentes Burndown charts.
¿Que quiere el cliente realmente? Quiere que le entreguemos software que
funcione, que haya cumplido con el criterio establecido para determinar que lo
que entregamos este realmente completo. Pero también es necesario planificar en
Scrum.
¿Le importa al cliente el plan? No si uno falla con los compromisos de
fechas que se asumen. En ese momento el plan se convierte en un problema que
atenta contra la confianza entre el equipo, el cliente y todos los interesados.
Project Managers tradicionales luego utilizan el plan para atacar a miembros
del equipo por no cumplir con las fechas.
Hay que detener ese ciclo, hay que planificar lo suficiente. Esta es una
de las conversaciones difíciles que hay que tener con el cliente y tus
superiores. No es fácil.
¿Quien es responsable de entregar software que funcione en un equipo
Scrum? El equipo. Como ScrumMaster uno es responsable de facilitar el framework
de Scrum, asegurar que el equipo comprenda los roles, que se hagan las
ceremonias establecidas, trabajar con el product owner y el resto de los
interesados, entre otras cosas. Pero en la realidad, en las empresas, un
ScrumMaster es el Project Manager y es el máximo responsable.
¿Cómo podemos asegurarnos el éxito? Entregando software y cumpliendo con
los compromisos. Las conversaciones con
el cliente y todos los interesados se convierten en algo increíble cuando esto
pasa, créanme.
Al principio va a ser difícil. Scrum no es una bala de plata, entregando
software se construye y fortalece la confianza entre las partes. Hay una estadística
que nos dice que hay que un equipo tiene que trabajar junto varios Sprints para
que sus estimaciones sean productivos. El primer plan del Sprint no se va a
cumplir. El primer Release plan que se prepare va a estar muy lejos de la
realidad. Hay que aclarar esto al principio, manejar las expectativas
correctamente. También hay que revisar nuestras estimaciones iniciales al hacer
el segundo Release plan, y el tercero, hasta lograr un plan a largo plazo que
nos sirva a todos.
Se puede. Inténtenlo.
No hay comentarios.:
Publicar un comentario