Muchas de las personas tienen una visión romántica sobre Scrum. Muchos de ellos entran en conmoción al escuchar decir que el dueño de producto es una persona que sólo piensa en el dinero.
Las personas tienden a pensar que todo en Scrum es romántico, no tiene nada de presión, la colaboración es hermosa, el dueño del producto es paciente, las cosas fluyen naturalmente, el ScrumMaster es un líder tierno y querido, es simplemente pegar post-it en un cuadro, entregar iteraciones, entrar en débito técnico, comer pochoclo en la planificación y vivir felices para siempre.
Desafortunadamente, Scrum no es así. Precisamos entregar el proyecto! Sabemos que muchos CSMs, CSPs, CSTs, nos van a querer quemar en la hoguera de Scrum Alliance con lo que vamos a decir ahora, y vamos a dejar en claro aquí: la Reunión Diaria de Scrum es el mejor mecanismo de cobranza que existe.
Cuando tuve los primeros contactos con Scrum en 2005 (y antes de eso aplicaba las prácticas iterativas de gestión de proyectos de RUP), yo estaba trabajando en un proyecto internacional que sería implantado en más de mil hospitales de Japón*. El primer proyecto de nueve dígitos que nunca uno olvida. El proyecto iba bien con las prácticas de RUP, pero ¿todos sabemos como es un niño con un juguete nuevo? Yo estaba loco por aplicar Scrum y la transición fue muy tranquila (el equipo era senior). En este turno, tomé una de las decisiones más sabias de mi carrera: delegue el papel/función de ScrumMaster a otra persona. Y actué como un miembro del equipo.
Tomé esta decisión de no ser ScrumMaster porque veo que muchas de las prácticas que descienden de la gestión la mayoría de las veces no tienen sentido para los equipos. Quería probar Scrum, en todos los aspectos. Actuar como miembro del equipo antes de servir como ScrumMaster fue una valiosa experiencia. Un ScrumMaster jamás será un buen ScrumMaster si él nunca actuó como miembro del equipo en un proyecto de Scrum.
En los primeros días, vi que las reuniones diarias mostraban una cosa claramente: me faltaba foco en la ejecución de las tareas. Era arquitecto, y con frecuencia no cumplía las tareas del proyecto, simplemente porque estaba corriendo detrás de algún capricho arquitectónico o perdía el día leyendo e-mails y haciendo cosas en Internet. Cuando vi que estaba "viajando" demasiado, recuerdo que a las 15:00 hs. tenía la reunión diaria, y yo no había completado la tarea bajo mi responsabilidad. Me sentía cargado porque la reunión diaria se acercaba y no tenía trabajo para mostrar a los demás miembros del equipo.
¿Se acuerdan de las preguntas de la reunión diaria?:
- ¿Qué has hecho desde la última reunión de los días?
- ¿Qué quiere hacer hasta el próximo día de reunión?
- ¿Hay algo que obstaculizan su trabajo? o mejor aún en positivo (Que es lo que te haría acelerar tu trabajo)
En las preguntas 1 y 2, el equipo no está reportando al ScrumMaster! En estas preguntas el equipo se refiere a sí mismo de una forma auto-gerenciable. ¿Y sabes lo que es interesante? El compromiso del equipo es mayor con el propio equipo que con los niveles jerárquicos superiores. Cuando estás hablando de lo que hiciste para el propio equipo sabes que están en el mismo barco que tú. No hay ninguna razón para la vergüenza, disimular y para los conflictos.
Es muy fácil engañar a un gerente de proyecto que pasa con un diagrama de Gantt preguntando "- Ya terminó la tarea? ¿Cuánto porcentaje todavía le falta". Ahora, no es tan fácil engañar a los miembros del propio equipo ... Pasaron todo el día con vos. No intentes decir que no cumpliste con la tarea porque tuviste problemas con RichFaces, porque los demás miembros vieron que pasaste toda la mañana en busca de tu coche nuevo en DeAutos. No intentes decir que no has podido hablar con el usuario - el equipo vio que estabas discutiendo sobre TDD en DosIdeas. No intentes reclamar que el build demora - el equipo sabe que estuviste ejecutando las pruebas sólo para hablar con esa rubia del proyecto de al lado.
La reunión diara está llegando, entonces, mostra servicio! Por más romántico que quieras ser con Scrum y con auto-organización/gestión, por debajo de los tableros de Scrum hay mecanismos de cobranza, y son mecanismos mucho mejores que un gerente de proyecto preguntando "porcentajes de conclusión".
