El año pasado uno de los equipos de mi programa apenas entregaba incremento de producto. Llegaba el final del Sprint y el equipo sólo compartía problemas, quejas, frustración y desgana. En cada Sprint el equipo trataba de realizar aquello a lo que se había comprometido el anterior sumado a más cosas que querían hacer para ‘recuperar el tiempo perdido’. El equipo no se encontraba bien, esto afectaba directamente al producto que desarrollaban y a nuestros clientes.

Aunque en mi día a día trabajo más con Product Owners, Stakeholders y CxO, mi jefe y yo tuvimos una conversación en la que decidimos que pusiera el foco en el equipo para entender qué pasaba y cómo podíamos ayudarles.

En aquel momento mis objetivos eran responder a tres preguntas:

  • ¿Qué le ocurre al equipo?
  • ¿Qué va a hacer el equipo al respecto?
  • ¿Cómo demuestro a mi jefe que ya no tiene por qué preocuparse?

Para los dos primeros puntos, las retrospectivas nos ayudaron a empezar a tener respuestas y definir acciones para mejorar la situación actual. Para el último punto necesitaba algo que fuera sencillo, visual y que presentara la evolución del equipo en el tiempo, donde se pudiera apreciar cómo estábamos antes y cómo estamos ahora.

The Team Journey

«The Team Journey» fue un experimento que surge para visualizar cómo un equipo vuelve a entregar incremento de producto al final de cada sprint, a un ritmo sostenible gracias a sus acciones de mejora.

 

VanesaTejada_TheTeamJourney

Este diagrama se compone de la información que en aquel momento consideré útil respecto la situación que tenía entre manos.

Velocity Chart

Decidí hacer uso de las métricas existentes en el equipo y por ello elegí tomar una foto al final de cada Sprint con la fecha del mismo y el ‘Velocity Chart’ de JIRA. No mostraba los ‘story points’ para evitar comparaciones sin sentido y porque nuestro objetivo final era volver a entregar valor a un ritmo sostenible.

Acciones de mejora

Este diagrama se usaba en las retrospectivas. Visualizar la diferencia entre el compromiso y la entrega nos abrió las puertas a muchas conversaciones sobre la manera de trabajar. En cada Sprint mostraba las decisiones más relevantes que tomaba el equipo.

Hechos que afectan al equipo

La capacidad de entrega del equipo varía por factores externos y/o internos del equipo, a veces pasan cosas que impactan en tu plan inicial y lo mejor que puedes hacer es lidiar con ello de la mejor manera posible. Otras veces la capacidad de entrega se ve afectada porque hay personas que enferman o se van de vacaciones.

Algo en lo que hice mucho hincapié durante las retrospectivas con el equipo era que necesitábamos ser conscientes de las cosas que nos pasaban para poder aprender a tomar decisiones.

Conclusiones

Visualizar la evolución del equipo en cada iteración generó interesantes conversaciones que ayudaron al equipo a reflexionar y a decidir por ellos sus acciones de mejora.

Visualizar toda las iteraciones de un cuatrimestre en una única imagen fue bienvenido por el equipo y mi jefe. Es fácil apreciar que la hay un cambio en la tendencia de las entregas. La misma imagen la compartía con ambos lo que me permitía que si entre ellos hablaban de este asunto tuvieran la misma información y hablaran en el mismo idioma.

Algunas de las cosas que afectaban al equipo fueron un feedback muy valioso para mi jefe sobre cómo algunas decisiones de la empresa impactaban en el trabajo del día a día.

El hecho de trabajar en una línea temporal nos permitió comparar el antes y después. El equipo empezó a entregar incremento al final de cada Sprint, pero lo más importante fue aprender a inspeccionar su iteración y a cuestionarse a sí mismos.

Si volviera a repetir este experimento, me gustaría añadir el valor e impacto que genera cada incremento de producto, pues de nada sirve entregar frecuentemente si no hay valor.

Tras esta experiencia, definiría «The Team Journey» como una manera de representar visualmente cómo un equipo evoluciona hacia un objetivo dejando constancia de sus decisiones y cambios.

4 pensamientos

    1. Hola Raúl,

      Ejemplo 1:
      Se asume que cada item del backlog puede impactar en unas métricas más que en otras del producto, pero que el producto como tal tiene unas métricas principales que nos dicen si el cliente está satisfecho (NPS) y obtenemos beneficios (Profit). Asumimos que otras actividades alrededor del producto pueden impactar en sus métricas principales ocasionalmente (caída de los nodos que soportan la plataforma). A pesar de todo esto, decidimos visualizar las métricas principales sobre las barras de capacidad de cada Sprint o justo debajo de los comentarios/decisiones del equipo con texto breve:
      NPS +2%
      Profit -3%

      Ejemplo 2:
      No todos los items de un Sprint impactan igual, a veces algún item sí tiene una métrica muy concreta donde vamos a ver si hemos tenido éxito. A lo mejor quieres resaltar sólo ese valor, donde el mensaje sería como: «gracias a esto hemos conseguido XXX», de nuevo puedes poner sobre las barras o debajo de los comentarios/decisiones del equipo un breve texto:
      Num. Clicks +25%

      Pero, cada equipo es un mundo, cada producto es otro, y lo que cada persona/equipo necesita ver para mejorar en su trabajo es diferente, por lo que la gráfica puede variar. Como decía en el artículo, hice uso de esta visualización para un caso muy concreto.

      Un abrazo,
      Vanesa

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s