sábado, agosto 04, 2012

Planificando en Scrum

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.: