Tableros ágiles sospechosos

Está claro que la gestión visual, muy de la mano de la agilidad, frente a otro tipo de gestiones, como, por ejemplo, la que se basa en diagramas Gantt, ha calado mucho, y hoy es frecuente que te encuentres un gran número de organizaciones que han creado tableros, visibles, para gestionarse (o auto-gestionarse).
Los puedes ver pegados en paredes (lo más recomendable) o en herramientas tipo JIRA.
Más allá de lo decorativo y molón que ello pueda ser, no debes olvidar nunca la verdadera esencia y motivo de los mismos, que como te contaba en Diagramas Gantt (que cumplen 100 años) cómo arma de destrucción masiva (reloaded) y te resumo aquí es:
– La gestión visual y los tableros son simples y eso da acceso a más gente a la auto-organización.
– La gestión visual y los tableros están pensados para que los vea todo el mundo (radiador de información) sin pedirlo.
– El tablero da “feedback” constante a mucha gente (potencia la transparencia).
– El tablero casi obliga al flujo continuo, simple y sin complicados Workflows.
Así, resumidamente, sintetizando los más importantes. Y dicho lo anterior, también te tengo que decir que es tan fácil colgar un tablero como mal usarlo y enmascarar bajo el mismo una gestión tradicional.
Hay muchos indicios de gestión tradicional enmascarada bajo gestión visual. Por ejemplo, un clásico es la de “un tablero por proyecto” en vez de “un tablero por equipo”, sobre esto incluso te dejé un vídeo que grabe un día mientras hablaba con un grupo de personas sobre este tema (de lo dejo de nuevo abajo).

Y hoy quiero hablarte de otro uso sospechoso de los tableros, los tableros que, frente al clásico de tres columnas (To Do – Doing – Done) tienen una pinta como la siguiente:
Tablero agil sospechoso
Ya visto así, el anterior tablero tiene una pintaza a cascada que no puede con ella. Pero aún así, el anterior tablero es un clásico que me encuentro día sí y día no.
¿Por qué este tipo de tableros no son lo más recomendable?
Bueno, vamos con algunos usos sospechosos a los que puede llevar el anterior tablero…

Fases vs Tareas, predictibilidad y Testing al final

En su día te hablé de ello, te recomiendo ampliar este punto con aquello de Gestionas proyectos por fases… o por tareas.
El anterior tablero pone columnas con pinta de fases, lo que merma usar tareas en la columna del “To Do” que luego van pasando al Doing y llegan al Done.
Las tareas, a diferencia de las fases, son un concepto que todos entendemos que es de menor alcance temporal (más cortitas), más espontáneas, ocurren muchas más veces que las fases y raramente se planifican de manera predictiva.
Además, deja el Testing para el final, cuando el Testing debiera empezar cuanto antes (¿Por qué es mejor empezar el testing antes que el desarrollo?)
El anterior tablero te puede llevar a la Predictivilidad y a tener un mini cascada dentro del sprint.

No potenciar el Swarming

De nuevo, para ampliar este punto leete El importante y desconocido Swarming, “flujo continuo de una sola pieza” o One-Piece Continuous Flow.
La idea del Swarming es dedicar todos los esfuerzos a una única historia antes de empezar con otra, y todo lo necesario para completarla se hace tan en paralelo como sea posible. Además, todo el mundo debe ayudar a que se termine la historia (item mejor dicho) de mayor prioridad.
El anterior tablero no potencia el Swarming porque se irán haciendo tareas de las primeras columnas, abriendo cosas, que no estarán cerradas hasta que lleguen a las últimas, tendremos muchas cosas abiertas, no pondremos el foco en cerrar algo cuanto antes.

Mermar la multifuncionalidad

Recuerda aquello de Habilidades en forma de T, la multifuncionalidad, recuerda que la idea es que todos hagamos algo más que aquello en lo que somos especialistas y el anterior tablero tiene pinta de que hay gente por columna, cada uno centrado solo en resolver lo de su columna cuando le llegue.
Más aún en sitios que ponen responsables por columnas, más aún cuando tras el tablero, más si se usa una herramienta, hay un Workflow, con permisos incluso para pasar una tarea de una columna a otra.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

3 comentarios en “Tableros ágiles sospechosos”

  1. Se me cae una lagrimilla al leer el artículo ;_) Una conclusión que saco de mi experiencia y después de leer el post, es que no es recomendable tener tareas de tus historias de usuario en columnas de tu tablón que dependan de otros equipos o departamentos, son claramente impedimentos para la velocidad y entrega del equipo. En mi opinión, este tipo de tablones que pertenece al equipo, lo mantiene y trabaja el equipo, va con la idea de la autosuficiencia del equipo a la hora de coger una historia de usuario y ponerla en producción sin depender de nadie. Salu2

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *