Scrum Boards, Workflows y mentalidad de equipo

Estuve investigando sobre cuál podría ser el tablero más beneficioso para nuestro equipo. En este investigar, me topé nuevamente con la filosofía del impacto visual que tienen los tableros...alguna vez escucharon esto de que el tablero físico tiene más impacto que uno digital sobre el equipo?

Bueno particularmente esta teoría luego de haber trabajado en un equipo distribuido en un entorno bastante ágil, me parece que personalmente no estoy de acuerdo del todo. Para mi lo que influye en una dinámica de trabajo con respecto a visualizarlo, es la portabilidad y el acceso a la info de todas las personas interesadas con la facilidad de un click...y la dinámica de las relaciones se construye, justamente por medio del vínculo humano (igual creo que este debate "si mejor físico o digital" lo terminó de definir la pandemia por fuerza mayor).

Luego de unos dias de leer y consumir youtube, encontré un nuevo entendimiento a esta teoria, desde una perspectiva mas de transfondo de lo que implica una gestión visual.

Alguna vez sintieron esa satisfacción de terminar lo que prometiste que ibas a hacer?el placer de tachar un ítem de la lista de compras, ó de las cosas para empacar en la valija antes de viajar?. Y la culpa de saber que no cumpliste con lo q te prometiste? (toda moneda tiene sus dos caras, no?)

En fin, esta satisfacción de terminar las cosas y la distribución de un tablero cómo veo que se relacionan?

Un tablero puede afectar la mentalidad y/ó comportamiento de un equipo?

Cómo bien marco en el título, pensando como mejorar el tablero del trabajo, me dí cuenta que había algo que para arrancar estabamos tomando como sinónimos, y no son lo mismo....

Scrum Board != Workflow

(ojo existen los Kanban Boards que se manejan dentro de la agilidad pero con otra estrategia donde por ejemplo se define un WIP por columna, hoy me voy a centrar en el marco Scrum)

Un workflow nos sirve para reflejar las fases de un desarrollo en el ciclo de vida a producción, al menos en nuestro caso, para saber en que ambiente se encontraba el pbi (por ejemplo desa, test , prepro o prod). Y un Scrum Board es para visualizar como va el progreso de nuestro sprint midiendo el avance de los pbis comprometidos.

La principal difrencias está en el foco que ponemos para medir nuestro porgreso. Cómo debríamos focalizarnos en un Scrum Board?

1) por trabajo terminado?

ó

2) por fases del workflow?

1) Al definirlo por entrega de valor terminado (working software) , deberiamos tener como unas 4 columnas (backlog, todo, doing y done) entonces vemos el progreso de nuestros pbis al empezar el sprint en dos saltos: uno hacia doing y otro hacia done.

Pero como equipo que intenta ser lo mas multifuncional, somos responsables del despliegue a producción de nuestros desarrollos, necesitamos esa info de estados , cómo hacemos simple el seguimiento del ambiente en que se encuentran? Una opción es reflejandolo la fase "en la tarjeta" del pbi que implique seguir ese workflow, entonces mas allá de en qué nivel de progreso está el desarrollo (todo-doing-done), podemos identificar su estado en un campo e ir actualizandolo.

2) Cuando trabajamos midiendo el avance del pbi por su fase, ponemos en el Scrum Board muchas columnas, cada una reflejando una instancia del workflow. Lo que generamos en este formato es una sensación individual de "está terminado" , por ejemplo, si mi desarrollo está hecho, ahora para que siga su camino a producción le debo pasar la posta al tester, con lo cual yo puedo hasta desentenderme con naturalidad de la responsabilidad de terminar el ciclo de esa historia por agarrar otra (y se empieza a oler de a poco la multitarea al enfocarnos mas en abrir que cerrar pbis).

Y ademas tengo mi mini-done-cuota de autosatisfacción, mientras el tester se le va acumulando trabajo los últimos días del sprint, generando que probablemente no se llegue en las condiciones normales de presión y temperatura a la review.

Que no eramos un equipo?Entonces la sensación de "está listo" debe ser mas bien grupal, o sea "unificada" en ese salto de Doing a Done. En el caso 2) estamos de alguna forma poniendo el foco y naturalizando como equipo a que esta coordinación de tareas sea secuencial, pero esto en el fondo no sería mas que hacer mini-cascadas.

Así, como un programdor puede abrir varios hilos de ejecución para que se corran en paralelo y así optimizar rendimiento y tiempo, lo mismo podemos hacer como un equipo que se enfoca en la entrega del working software. Así es como estamos reduciendo en gran parte desperdicios y rompiendo de raíz los peligrosos silos que probablemente terminen en cuello de botella.

Pero cómo se logra ejecutar estos "hilos" humanos en paralelo? Con práctica, con swarming , con comunicación, con un foco unificado en el valor de lo que se está construyendo, y por supuesto, autoreflexionando, investigando y aprendiendo todo el tiempo. Despues de todo nos la pasamos hablando de TDD, BDD, devOps , entre tantas otros conceptos que siempre en el fondo comparten el valor de la colaboración, que en definitiva ser un equipo colaborativo te hace mucho mas ágil, que hacer scrum con mini-cascadas.