Y de repente con los indicadores, «hay MAGIA…»
Imagino que a todos nos gustan los buenos trucos, así que os voy a desvelar uno muy bueno para que los miembros del equipo sientan su propio compromiso al medir indicadores durante el sprint.
En otras publicaciones anteriores, he hablado de indicadores a largo plazo e indicadores a medio plazo. Así que esta vez me toca hablar de las que considero, los de corto plazo. ¿Y cuáles son? Los que medimos, publicamos y analizamos sprint a sprint.
¿Qué os puedo contar?
Pues supongo que nada que no sepáis. Normalmente cada ciclo de trabajo (sprint estándar para SCRUM o bien quizá cada quince días si trabajamos en KANBAN), se analizan indicadores como por ejemplo:
- El porcentaje de tareas/puntos de historia en el DONE. No hace falta decir que si son tareas procuraremos que más o menos suelan ser siempre del mismo tamaño.
- El número de incidencias que entran o el porcentaje respecto al total que dedicamos a ellas.
- Las interrupciones.
- … (y todo lo que pueda servir al equipo para mejorar)
Lo que he notado es que al final los equipos llegan a un punto en el que piensan que ya está bien como trabajan y les cuesta mejorar…que en algunas ocasiones harán más, en otras menos, pero que al final se compensa y tenemos una velocidad media que procuramos sea constante.
Como persona inquieta que soy 🙂 necesitaba más…estaba segura que en algún lugar había equipos que medían su compromiso de otra forma.
Y entonces llegó el mago de los indicadores a corto plazo
Como para este caso de indicadores a corto plazo veía que no podía explicarlo todo desde mi propia experiencia, y como no me gusta hablar desde la teoría, me he ayudado de un apreciado compañero (Marc Ferret Font) también Scrum Master, que me ha contado sus trucos. Entre ellos uno que a mi misma me fascinó.
Me reuní con él y esta fue su visión:
Qué se mide
Burndownchart
Procuramos rellenarlo manualmente día a día. Descargamos una plantilla desde la web http://www.burndowngenerator.com/
La tenemos colgada al lado de la pizarra y cada día en el daily la vamos actualizando manualmente. Se anotan como van bajando los puntos en función de las tareas que han pasado al DONE. De esta forma el equipo es consciente de lo que se avanza. En ocasiones, a medida que va avanzando el sprint, ya vemos que no conseguimos que la línea siga el progreso estándar, y de repente sucede…¡HAY MAGIA! El propio equipo se vuelca en concentrarse y acabar el trabajo por el que se comprometieron. Esa es una reacción que se asume en tiempo real para alcanzar el compromiso. No hace falta esperar a la retrospectiva para analizar qué fue lo que no nos permitió llegar a nuestro objetivo, sino que lo analizamos in-situ e intentamos no perder el foco.
Ventajas e Inconvenientes
Alegría y/o frustración
Es posible que en algún sprint concreto el hecho de ver que no puedes conseguir tu compromiso pueda causar frustración. A priori esto parece un inconveniente, pero tiene una parte buena, la de que el propio equipo sepa de antemano aquello que hay que afrontar en la retrospectiva.
Tiempo en Historias de Usuario
Trabajamos historias de usuario en paralelo con tareas técnicas, ya que uno de nuestros objetivos compartidos con negocio es mejorar el rendimiento de la aplicación. Mientras creamos el gráfico diariamente, vemos si el tiempo que dedicamos a las historias de usuario es correcto o nos desviamos con las tareas técnicas. Al fin y al cabo, nuestro objetivo también es entregar el máximo de funcionalidad.
De ahí hemos aprendido también algo importante. Antes empezábamos el sprint con las tareas más grandes. La idea era que al ocupar más, era necesario empezarlas primero. Pero como durante el sprint nos pueden entrar tareas muy urgentes, al final pasaba que no nos daba tiempo a entregar ni las más grandes ni las más pequeñas, y quizá ni siquiera las historias. Así que, asumiendo que dentro del sprint todo es igual de prioritario y no tenemos identificado un sprint goal, ahora nos vamos organizando en función de las necesidades que vemos mientras vamos trabajando.
Saturación de algunos perfiles
El hecho de tener que participar diariamente en la elaboración del gráfico, en ocasiones deja latente si hay perfiles que se están saturando. Por ejemplo, si hace días que no pasamos nada al DONE, quizá hay algún perfil que está afectado por algo. Normalmente en un daily se puede hablar, pero cuando ves que la línea que estamos dibujando sigue permanentemente recta…es muy evidente que algo pasa.
Transparencia
Somos transparentes; este gráfico es público. Al tenerlo al lado de la pizarra no nos escondemos de nadie.
Agradecimiento
Desde mi punto de vista, siempre he pensado que no hay que obsesionarse con los indicadores a lo largo del tiempo.
A veces se miden acciones que pueden aparecer en la retrospectiva. Cuando esas acciones dejan de funcionar o bien se han asimilado y funcionan perfectamente, ya no tiene mucho sentido seguir midiéndolas ¿Por qué? Porque normalmente se focalizan en resolver un problema puntual.
Otros indicadores que no sean para resolver problemas puntuales, sino para medir por ejemplo la acción del cliente sobre nuestro producto, igualmente son caducos, cuando tengamos el resultado, mediremos otra cosa, pero habremos sacado conclusiones que nos habrán ayudado.
Pero durante esta explicación me he dado cuenta que en este caso hay algo que no pasa, ni caduca, ni resuelve un problema puntual. Me encanta pensar que el propio equipo se hace dueño de su avance y se implica de esta manera. En este caso el burndownchart para mi no es un indicador más, sino un punto de motivación extra. Muy bien sabido llevar por el Scrum Master. ¡Felicidades Marc! Y muchísimas gracias por aceptar colaborar en el blog.
Si os ha gustado el post lo podéis compartir con quién queráis. Si tenéis alguna idea a aportar o queréis comentar algo de lo que no estéis de acuerdo, no dudéis en comentarlo. Seguro que entre todos lo hacemos todavía mejor.