Tablero Físico vs Digital ¡Lo analizamos!

Hace año y medio tuve la oportunidad de debatir con mi compañero Manu Záforas sobre tablero físico o digital. Hicimos una encuesta, y curiosamente perdí, a pesar de que defendía la opción del tablero físico. 

A pesar de que perdí la votación final quería aprovechar para contar un poco mi experiencia ahora que he podido analizar más equipos trabajando con herramientas visuales. En este tiempo, he aprendido gracias a Jeff Patton que quizás cada herramienta (sea virtual o física) tiene un sentido. Para trabajar en el día a día un tablero físico es lo mejor, pero para almacenar detalles es mejor un software como puede ser Jira o Trello.

Lo mejor de cada uno

A día de hoy, lo que mejor veo funcionar es utilizar una herramienta digital para gestionar el producto (Product backlog) y una herramienta física para gestionar el trabajo del día a día (Sprint Backlog). Tener duplicidad me parece una pérdida de tiempo y generalmente acaba provocando que se abandone el físico. Si tienes los items de trabajo en digital, las tareas técnicas solo en físico. ¿Para que quieres digitalizar tareas que tienen una vida tan corta? La mayoría de argumentos a favor de digitalizar todo están más cerca del control que de otra cosa.

¿Y qué hacemos con los KPIs? Si tenemos KPIs deberían estar enfocados al producto y ya hemos dicho que el Product Backlog es digital por lo que se calcula perfectamente. Los KPIs de proceso son difíciles de calcular en un tablero físico, sin embargo, debemos de huir de ellos ya que buscan más el control que la mejora contínua.

Histórico del producto

Otro de los aspectos que podemos destacar es el histórico. El histórico una vez más debemos centrarlo en el producto donde nos puede interesar estudiar su evolución; qué elementos se han ido añadiendo, que elementos se han eliminado o que rendimiento han aportado. Sin embargo, un histórico de las tareas que ha realizado el equipo no tiene sentido ya que con el tiempo las tareas que se hicieron dejan de tener valor para nadie. Un compañero arquitecto decía que la mejor documentación es tu propio código y cómo lo hubieras generado.

Una de las grandes ventajas del físico es la construcción del mismo. Conseguir que se haga en grupo ayuda a sentir la unidad del equipo. Una de las técnicas que he probado con equipos es construirlo de pie entre todos en cada Sprint. El objetivo es evitar una situación poco productiva como es abrir un programa software que sólo maneja un miembro del equipo (generalmente el Scrum Master) y todos mirando a la pantalla. En este tipo de situaciones se genera un sentimiento de apalancamiento que acaba por destrozar el sentido de una planificación de Sprint.

Otra gran ventaja del físico es que, se renueva en cada Sprint. Esto es bueno porque el producto evoluciona y los retos cambian con el tiempo. Si los retos cambian ¿No debería cambiar mi plan para ajustarse a ellos? Por ejemplo, hemos tenido un equipo que en cada Sprint hacía tableros físicos diferentes, unas veces los orientaba a un hito muy concreto que tenían mediante una planificación por días, y otras veces lo enfocaban con el clásico todo-doing-done porque el objetivo era ampliar una funcionalidad lo máximo posible.

La clave es la libertad

Por tanto… ¿Cuál es mejor? Creo que no hay una solución a esta pregunta. Si eres Scrum Master deja que tu equipo descubra la mejor opción. He visto a equipos durante 18 meses cambiar 5 veces de tipo porque el equipo crecía o se enfrentaban a retos que requerían un cambio. El mejor consejo: ¡Deja que el Scrum Team decida! Una vez colaboré un equipo y les forcé a un tablero físico cuando realmente no querían. Actúe mal, y es algo que descubrí con el tiempo. Puedes enseñar ambas alternativas y dejarles que descubran las que mejor les aplica en cada momento. Y sobre todo, sea la alternativa que sea, que analicen y sean crítico sobre si de verdad les está funcionando y si deben plantearse un cambio. ¡La mejora continúa es fundamental!