Visual Management: 7 ideas para organizar el trabajo de tu equipo

Antes de hablar sobre el Visual Management, quería recordar una historia que me ocurrió hace años. Participé en el arranque de una transformación digital en la que íbamos a trabajar con una Escuela de Negocios. Hicimos un assessment para evaluar su estado de digitalización. Para ello, realizamos una serie de entrevistas a varios miembros de la organización. Entre ellas, tuvimos una conversación muy interesante con el Presidente Honorífico. El Presidente era sacerdote y nos dijo que prefería hablar, a usar un ordenador. Durante la charla, nos comentó que uno de los problemas que tenían era que, cuando se reunían para tomar decisiones, los datos que tenían no eran correctos (datos sobre matriculaciones, alumnos activos etc). Es vital para poder tomar decisiones que todos tengamos la misma información. 

En inglés se utiliza el término sharing understanding. Se traduce por “entendimiento compartido”, es decir, que todos entendamos lo mismo cuando estemos trabajando. Y para esto, tenemos el Visual Management. Dentro de él, existen muchas prácticas que podemos utilizar: 

• Graphic Recording, como acta de una reunión o evento para recordar lo ocurrido
• Facilitación Gráfica, para usarlo durante una reunión 
• Herramientas Visuales como User Story Map o Impact Map, para organizar un producto
• Visual Metrics, para tener métricas en lugares clave de la empresa

En Kanban, lo tienen claro sobre el Visual Management

Hemos retrasado este artículo porque con la pandemia los tableros físicos y el trabajo en el mismo espacio no eran posibles. Podemos usar el Visual Management en formato digital, pero casi nunca es igual. En el método Kanban explican que, aunque se puede usar una herramienta digital para organizar un Kanban Board, los equipos que utilizan tableros físicos suelen llegar a soluciones más originales y más útiles. 

Vamos a explicar varios tableros físicos que hemos utilizando en diferentes equipos y cómo organizaremos la información. Lo importante es que sirva de inspiración para crear los tuyos propios.

Idea 1: To-doing-done

Este tipo de tablero es el más típico y clásico. En mi opinión, no es de los mejores para gestionar un equipo, porque mezcla tareas y dificulta la capacidad de autogestionarse de los developers. El motivo es simple, este tipo de tableros gozan de sentido cuando todos “hacemos de todo” y eso ocurre pocas veces. 

Además, otro de los problemas de este tipo de tableros es la columna “QA”, Este tipo de columnas suele derivar en un pensamiento de “silo”, en lugar de un pensamiento colectivo. Lo ideal es que QA sea una tarea dentro de cada Item, y que se aborde cuando sea necesario. 

Ideas 2: Flechanban

Este es uno de los tableros más completos que podemos encontrar. Representamos un equipo Kanban con diferentes partes que merecen la pena comentar. En la zona de la izquierda, vemos un “embudo” dividido en tres colores. Esta zona la utiliza el Product Owner / Service Request Manager para gestionar las peticiones. Cada una de ellas tiene un límite, y permite priorizar.

En la zona superior, el equipo creó el carril “cagando leches”, un carril para tareas urgentes y que se usaba para situaciones especiales. 

Cada miembro del equipo tenía su propio carril, que se usaba para repartir tareas. Por otro lado, había una zona final llamada “Demo”, ya que había que presentarle una demostración al cliente antes de subir a producción. 

Además, cada columna tenía sus propias políticas de trabajo en la zona inferior, lo que se conoce también como “Definition of Done de columna”. 

Este equipo prestaba servicio a varias aplicaciones. Para diferenciarlas, crearon una leyenda de colores que está a la derecha. De esta manera, podrían ir quitando y poniendo en función del tipo de aplicación. 

Idea 3: Multicaminos

Muchas veces, un equipo dispone de diferentes tareas (items en Kanban) que usan caminos diferentes. Por ejemplo, una incidencia puede ser resuelta cambiando un dato en la base de datos de Producción, mientras que otras peticiones pueden desembocar en un proceso completo de desarrollo. 

En este tablero, podemos apreciar diferentes caminos en función de la tipología de la petición. Este tablero, además, estaba dividido por países ya que el equipo prestaba servicio a varios, dentro del mismo cliente. De esta manera, podrían identificar el equilibrio dentro del equipo con respecto a los países. 

Otra característica era la zona de “cancelado”.  En cualquier momento, se podía cancelar un determinado item, por tanto, se creó una línea roja horizontal para marcar la zona de cancelación. 

Para visualizar los bloqueos, este equipo optó por usar postits rosas. De hecho, era muy habitual tener un porcentaje de items activos bloqueados. Medir este dato les permitió tener conversaciones sobre cómo mejorar la operativa con el cliente. 

Como última curiosidad, este equipo eligió avatares para organizarse. En concreto, decidieron usar princesas disney. 

Idea 4: Visual Management para Equipos multiservicio

Muchas veces tenemos equipos que prestan servicio a muchos clientes  de diferente índole, incluso a compañeros de la propia empresa. En este tablero, reflejamos el trabajo de un equipo de Sistemas interno de una organización, que prestaba servicio a clientes y a peticiones internas de los compañeros. Disponían de un tablero sencillo, con una columna “next” y otra “doing” donde gestionaban el trabajo actual y el futuro de peticiones internas. 

Una de las principales características era los colores. Todos los peticionarios siempre queremos las cosas lo antes posible pero sabemos que, si todos pedimos rapidez, eso afectará al sistema de entrega. Por eso, pusimos un código de colores donde la petición era “pronto”, “muy pronto” y “cuanto antes”. Esto dejaba la responsabilidad en los peticionarios, que debían actuar con responsabilidad. 

Como comentábamos, este equipo también prestaba servicio a clientes. Cada cliente disponía de su propio tablero de trabajo, por tanto, no se vio  sentido incluir esas tareas en la operativa del grupo. Sin embargo, sí se vio  la necesidad de reflejar la ocupación de los miembros del equipo. Por eso, se creó un tablero de ocupación, donde cada miembro reflejaba en qué proyectos estaba colaborando. Así, podíamos conocer la capacidad real del grupo de cara a nuevos compromisos o clientes. 

Además, existían muchas interrupciones diarias cuando alguien se acercaba al grupo para buscar a una persona. Para mejorarlo, añadieron visualizadores como “de baja” o “teletrabajo”. 

Idea 5: Sprint por días

En Scrum, se comenta que usualmente los equipos dividen su trabajo en trozos de un día o menos de duración. Una técnica que podemos usar para generar autogestión en el equipo es dividir el Sprint por días y, aproximadamente, tratar de llenarlo con las tareas que creamos que haremos. 

Muchos equipos califican  este tipo de tableros tradicionales. Nada más lejos de la realidad. Cuando usamos una visualización por días, estamos tratando de reflejar nuestra capacidad real de hacer cosas. Además, este tipo de paneles nos permiten hacer un seguimiento en la daily mucho más acertado sobre cómo vamos. Por ejemplo, si llegado un día, los postits no se han cumplido, habrá que reorganizar el panel, lo que puede habilitar una conversación de los Developers para organizarse. De hecho, si llegan a la conclusión de que no alcanzarán el Sprint Goal, podrán incluir en dicha conversación al Product Owner. 

La parte negativa de este tipo de tableros es la conexión entre tareas. Si un determinado trabajo lo dividimos entre varias personas, es más complicado visualizar dicha relación. 

Idea 6: Sprint por Semanas

Uno de mis paneles favoritos es el Sprints por semanas, muy útil sobre todo cuando los equipos tienen Sprints largos (3 o 4 semanas). Consiste en dividir en columnas cada semana y llenarlas con el trabajo que creemos que haremos. Así, reducimos la complejidad y combatimos el síndrome de creer que el tiempo es infinito y que nos dará tiempo a hacerlo todo. 

En este panel, cada pósit  amarillo representa un elemento del Product Backlog, y cada rosa es una tarea de trabajo de dicho posits. Cuando todas las tareas pertenecientes a un determinado item se termina, el item se considera completado. 

Este equipo optó por tener una flecha “Wip” que marcaba el último item completado en el momento. De esta manera, querían trabajar el concepto de “trabajo terminado en equipo” y evitar que cada miembro se centrara en “su parte” obviando el trabajo real terminado por todos. 

Idea 7: Visual Management para el Refinamiento

Uno de los aspectos que se pueden trabajar con visual management son los tableros de refinamiento. Recordemos que el Product Backlog es una magnífica  herramienta para poner orden al trabajo. Sin embargo, es complicada a la hora de gestionar todo el trabajo que hay que hacer para que los items estén ready de cara a un Sprint. 

En un tablero de refinamiento, tratas de ubicar, en varios Sprints vista, el trabajo que tienes que   refinar. De esta manera, puedes investigar items que no estén claros, resolver dependencias o tener conversaciones con interesados antes de que llegue el Sprint y sea demasiado tarde. 

En este equipo, definieron varias partes a la hora de refinar. Por un lado, el negocio determinaba lo que quería o necesitaba. Después, los developers hacían una valoración técnica de la solución. Por último, una compañera con experiencia en ambos mundos analizaba si todo tenía sentido y era coherente. El trabajo refinado estaba listo para ir a una Sprint Planning. 

Conclusiones

Estos son solo algunos ejemplos de cómo la gestión visual nos puede ayudar a tomar decisiones. En digital estoy encontrando algunas herramientas que me permitan el mismo nivel de sensación, sin embargo, cada como trabajar unidos para la entrega de valor.

Y tú, ¿cómo organizas la información?