Como introduje Scrum en un equipo novel.

Bueno, segunda semana con el equipo de noveles. Segunda semana de satisfacción y segunda semana de tensión para poder trabajar en el proyecto.

Después de varias instalaciones y mucha configuración tanto el servidor de SQL server 2005 como el TFS 2008 ya están funcionando ambos y con los permisos adecuados. Además, y por fin, nos  ha llegado la pizarra en donde hemos dibujado de forma inmediata un panel Scrum, olvidando –por ahora- Kanban. Ya que Scrum me es más útil tanto para la disciplina del equipo como para la visibilidad del proyecto ante los jefes y el cliente.

Como no tengo Product Owner, tengo que ejercer ese Rol y medio fusionarlo con el Scrum Master. La realidad siempre es más complicada que la teoría. Por lo cual para empezar el sprint cero defino el Product Backlog que es muy, muy corto, para así darle un ancho margen de beneficio al equipo. Ya que son bastante más nóveles de lo que me esperaba.

Una vez configurado el TFS, les explico lo que es un Sprint Planning meeting y empezamos a dividir el módulo principal para elegir las tareas del Sprint Backlog. Aún no les pido estimaciones de tiempo para no liarles mucho, pero si les empujo a realizar una subdividision de las tareas elegidas para el sprint para que miren más allá de la tarea general y descubran las actuaciones que constituyen la construcción de la misma. Así, más adelante podrán estimar con mayor seguridad y estarán acostumbrados a localizar la simplicidades y complejidades inherentes al desarrollo de una pieza del puzle.

Empezamos el sprint cero y les explico que nuestro trabajo debe generar métricas para su seguimiento y que para ello cada vez que se vaya a realizar un check-in de código, van a tener que elegir el workitem al que se va a asignar el mismo. Así obtenemos la métrica del trabajo realizado y por realizar y les muestro nuestra estrella de la métrica: el BurnDown Sprint.

Lo siguiente es un acto de fe: los Daily Meeting. Les veo emerger la duda en los ojos cuando les digo que son reuniones diarias, a la misma hora, de pie y de no más de quince minutos. Además, para reforzar su sensación de inutilidad, como están trabajando en pareja las respuestas  a las tres preguntas, ¿Que hice ayer?¿Que haré hoy?¿Que impedimentos tengo?,  son iguales.

El mejor momento llega después de la segunda reunión diaria cuando me señalan que yo no he respondido a mis tres preguntas… ya está la magia en acción !!  Al igual que en casos anteriores, las reuniones diarias se convierten en una costumbre que le encanta a los equipos y multiplica la comunicación.

El cuarto día del sprint cero la pizarra tiene un aspecto buenísimo. De un vistazo vemos el estado del sprint y, efectos de iniciar el proyecto con Kanban, se auto limitan las tareas sin que me tenga de preocupar de tener demasiadas abiertas y sin cerrar. Además, los test unitarios ya son parte del propio desarrollo y poco a poco están enseñando su gran ventaja. No los ven como el doble de trabajo, si no como un nivel más de seguridad y un reto intelectual.

La comunicación es muy buena y el ritmo, teniendo en cuenta que en mi previsión solo habíamos cogido tareas para el 50% del sprint, bastante aceptable.

La última alegría es cuando pongo mi flamante BurnDown Sprint Chart en la puerta del armario y se lo enseño a mis dos directores… los cuales lo entienden de forma inmediata. El tablero Kanban - ahora Scrum – ya lo están utilizando para saber como vamos. O sea, que todos contentos (y eso que la documentación CMMI la tengo un poquillo abandonada).

El viernes, medio sprint atrás ya, les enseño a iniciar y cerrar WorItem en el tfs. A crear nuevos, desde el Web Acess, relacionados con los demás. Y les dejo irse con un pequeño lio en la lógica de negocio pero con HAMBRE de hacer las cosas bien.

La próxima semana tengo que darle acceso a los informes del TFS/Cochango a los directores y explicarles qué están viendo. Preparar un servidor de desarrollo con acceso desde internet para publicar los desarrollos al que el cliente tenga acceso y que me dé el feedback lo antes posible y de forma continuada. Y preparar el fin del sprint, la retrospectiva, decidir la longitud del siguiente sprint, preparar la mudanza a las oficinas del cliente y vuelta a empezar.

Muy mal debe ir la cosa para que este proyecto no sea otro éxito.