La semana pasada escribía sobre las lecciones que había aprendido en la gestión de mis propios proyectos. Les dejo esta semana con un vídeo de la charla que Jeff Sutherland dio a los ingenieros de Google sobre sus lecciones aprendidas en la implementación de Scrum en lugares como Nokia, PatientKeeper o la propia Google. Les cuento en este post algunas de las cosas que me parecieron curiosas:

• En Google se introdujo Scrum poco a poco por temor a la resistencia de sus ingenieros que podían pensar que introducir un proceso formal no les beneficiaría sino que les ralentizaría en su trabajo. Comenzaron la implementación de Scrum usando solo las prácticas más básicas.
• Hubo incluso resistencia para las reuniones diarias para las que también pensaban que sería un tiempo invertido en vano. Comenzaron por reuniones que duraban mucho más de 15 minutos ya que cada ingeniero tardaba mucho tiempo en explicar lo que estaba haciendo y los problemas que estaba teniendo. Después de un tiempo, cuando todo el mundo había explicado su trabajo y era consciente del de los demás, las reuniones fueron mucho más fluidas.
• La gráfica burndown les ayudaba a darse cuenta de cuál era el tiempo real que iban a emplear en desarrollar una funcionalidad. Para una funcionalidad a la que inicialmente asignaron un tiempo de 3 semanas y 40 puntos comprobaron que en la primera semana hicieron solo 8 puntos. En la segunda consiguieron terminar solo 7,5 puntos. Aún así, uno de los responsables pensaba que tendrían la funcionalidad lista en esas 3 semanas cuando la gráfica hacía evidente que no estaría en ese tiempo.
• En un proyecto para el sector sanitario, usado por cientos de doctores y usuarios online, la definición de Hecho (Done) se fue ampliando desde pasar inicialmente por los test unitarios y de aceptación para luego añadir a la definición de verdaderamente Hecho o Terminado algo como ésto: ‘Poner en producción y si el teléfono no suena con incidencias durante 1 hora la nueva entrega estaba completa’
• Para mi alivio, en su Scrum inicial simplificado no usaban gráfica burndown por cada iteración sino una por cada entrega. Esto me hizo sentir mejor ya que yo no había podido nunca mantener un tablero Kanban actualizado a diario para cada Sprint (sí, ya sé, Scrumbutophobia)