Lo bueno y lo malo de las empresas pequeñas es que hay que compartir el tiempo entre varios proyectos y, además, a toda prisa. A mí me pagan para evitarlo. Para que la productividad de la empresa no decaiga a causa de las necesidades comerciales - trampa irreversible que ha llevado a muchas empresas a la quiebra o a la mediocridad.
Esto viene a cuenta de que he tenido que dejar a mi equipo prácticamente solo durante estas dos semanas, tutelándolos solamente con las reuniones diarias y “sacándolos del nido” mucho antes de lo que hubiera querido. Pero las cosas han ido bastante bien.
Finalizamos el sprint cero con una retrospectiva en toda regla. Tres columnas – positivo, negativo y propuestas – empezando por la más difícil: lo positivo. Me llamó la atención que una de las primeras cosas que saliera es el buen rollito del equipo y mi presencia como mentor técnico y de metodología.
Cuando llegamos a lo negativo, la tecnología se conformó como el bien y el mal del proyecto ya que al – por decisión mía - tener test unitarios, Linq to entities, arquitectura por capas y Scrum, lo ven como un auténtico “mal necesario”. También son conscientes de la necesidad de la autoformación y es una de las decisiones que se unió al listado de cosas que podíamos hacer para mejorar.
Al igual que me pasó en el Open Agile, es muy curioso como pequeños detalles se muestran con una prioridad inesperadamente alta cuando lo expones ante el grupo: la calefacción está demasiado alta. Y a gerencia hemos ido con la petición, y gerencia ha actuado de forma resolutiva.
Entonces empezamos el sprint 1 y aprieto un poquito más las tuercas. Un autentico Sprint Planning compuesto por dos fases diferenciadas: 1. Hablo un par de horas explicando la funcionalidades que quisiera cubrir en las dos siguientes semanas. 2. Cuatro horas en donde vamos detallando las tareas, estimando y comprometiéndonos con el Sprint Backlog. Como son noveles, subo de las 80 horas a 140 horas a cumplimentar en las dos semanas. Pero tened en cuenta que no son horas reales, son puntos de trabajo pero nombrados como horas para que les sea más fácil visionar que el objetivo es acercarse lo más posible al máximo de horas reales en dos semanas. También hay que notar que faltan mis horas, previstas finalmente en unas paupérrimas 20 horas, que finalmente no han cumplido.
Además, les pido que empiecen a insertar los errores en los Work Item para empezar a construir las métricas sobre errores.
Por último, y para ir cerrando este post, he encontrado un error en la lectura del BurnDown Sprint de Cochango. La estaba leyendo al revés. Lo malo es si la línea se queda por encima de las horas previstas. Y yo leía que era malo si se quedaba por debajo. Por lo cual mi equipo es aún mejor de lo que pensaba. Y he añadido un gráfico buenísimo para que sepamos aun mejor qué está ocurriendo: el Sprint Flow Chart. Me indica claramente qué hemos acabado, cuanto estamos en tarea y cuanto queda por iniciar.
Esta semana empezamos la segunda parte del sprint 1 con un retraso importante ya que uno de los dos está demostrando ser más novel de lo esperado. Pero he de sacar tiempo para echarles una mano, ya no tanto para que la tarea se cumpla en tiempos, si no para mantener su entusiasmo en alto.
Ah, el cliente esta CONTENTO de ver que en dos semanas ya tiene algo en las manos.
P.D. Los Daily Meeting SIEMPRE de pié. Se nota una barbaridad.
Cómo introduje Scrum en un equipo novel. Cap. 1
Kanban, Scrum, CMMI Light
No hay comentarios:
Publicar un comentario