Guías de Agilismo

Introducciones a conceptos, términos y prácticas relacionados con prácticas y metodologías ágiles.

Tablero físico vs tablero virtual

Tablero físico de un equipo haciendo Scrum

Este artículo tiene su origen en una pregunta realizada en la lista de correo de Agile-Spain. Gracias a todos los que participan en esta comunidad. No me cansaré de aprender en ella.

Los tableros físicos para un equipo Ágil

En general, me voy a referir a los tableros que empleamos para representar el trabajo en curso. También podemos usar tableros (físicos o virtuales) para representar otra información. Si te interesa este tema, te recomiendo acercarte a los blogs de Xavier Quesada y de Vanesa Tejada.

Un tablero físico tiene varias propiedades:

  • Es el tótem de la tribu. El equipo se reune alrededor del tablero para organizar el trabajo, contarse unos a otros los avances e impedimentos… De hecho, si la distribución del espacio de trabajo nos permite trabajar junto al tablero, éste se convierte en la bandera del fuerte. Dice: “¡Ey, aquí estamos los agilistas! ¡Aquí se trabaja de una manera diferente!”. Sé que suena muy simbólico, pero el hecho es que el tablero es algo más que una herramienta.
  • Sirve para demostrar uno de nuestros valores más poderosos: la transparencia. No tenemos miedo de mostrar a todo el que quiera acercarse cuál es el estado de nuestro trabajo en curso. Tanto si va bien como si va mal mostramos el trabajo en curso y, siempre que podemos/sabemos, gráficas de evolución como el burn-up chart.
  • Si el equipo hace Scrum, podemos saber si ha comenzado el sprint hace poco (la mayoría de las historias sin empezar), si está a punto de terminar (la mayoría de las historias acabadas), si ha tenido problemas (muchas tarjetas marcadas como que han tenido impedimentos o tarjetas que han surgido durante el sprint), si no están respetando la prioridad del backlog (historias planificadas arriba que no están acabadas o ni siquiera empezadas, mientras que hay historias más abajo empezadas o incluso acabadas)… Si el equipo hace Kanban, también podemos ver de un vistazo las colas, los incumplimientos del WIP, etc… Esta propiedad de ver de un vistazo el trabajo en curso es, en mi opinión, muy poderosa porque ayuda mucho a diagnosticar (incluso a autodiagnosticar) qué está sucediendo en tiempo real. Bueno, en tiempo real si todos somos autodisciplinados y movemos los post-its frecuentemente. Pero incluso si no los movemos y dejamos que se caigan al suelo de puro aburrimiento (sí, los post-its también se aburren) tendremos una señal muy interesante sobre qué sucede en el equipo.
  • Esta capacidad de ver mucha información de un vistazo nos permite encontrar más fácilmente cuál es el layout más eficaz del propio tablero. Esto es especialmente útil cuando el equipo es nuevo o estamos en un proceso de transición, donde los procesos y acuerdos de trabajo están aún emergiendo.
  • Cada vez que un miembro del equipo mueve una tarjeta en el tablero está haciendo un poco de jefe de proyecto: asigna tareas (eligiendo la que pone “en curso”), actualizando el plan (moviendo la tarjeta al estado correspondiente), informando del plan actualizado (con el mismo movimiento, pues el tablero es visible para todo el mundo que se acerque), eliminando interrupciones (del tipo “¿en qué estáis?”), y aunque suene un poco raro, está cargandose a sí mismo de energía positiva cuando indica a todo el mundo que ha acabado una tarea. No es lo mismo irte a casa con varias tareas acabadas al 80% que una al 100%, ¿verdad?

Los tableros virtuales para un equipo Ágil

Sobre los tableros virtuales tengo que decir:

  • Los uso. Soy especialmente fan de Trello.
  • Aunque soy un gran fan de los tableros físicos, entiendo que los tableros virtuales pueden ser necesarios.
  • Mientras el tablero físico es tremendamente intrusivo (y eso está bien), el virtual es demasiado fácil de ocultar. No podemos hablar de máxima transparencia si para acceder a un tablero tengo que conocer una URL o incluso tener una contraseña. Son pequeños inconvenientes, pero ninguno comparable al inconveniente de que no lo estoy viendo y tocando durante mi jornada laboral. Si cuando voy a tomar café, o separo la vista de mi monitor para descansar un poco, me encuentro con el tablero y, de un vistazo, veo que no estoy en el foco o, simplemente, que pertenezco a este equipo, estaremos perdiendo mucho de lo que nos aporta el tablero físico. Si al menos podéis mostrarlo en un monitor para tenerlo presente, junto al estado de la Integración Continua, p.ej., estaréis mitigando en parte esa falta de presencia del tablero físico.
  • Otra cualidad del tablero virtual es que puede crecer hasta el infinito, lo cuál impide que veamos de un vistazo el estado de nuestro trabajo en curso. Para mí éso es una señal de que estamos planificando demasiadas historias, o las historias son demasiado grandes y requieren desgranarlas en demasiadas tareas, o que tenemos demasiadas tareas simultáneamente en alguno de los estados (ya sea Scrum o Kanban). En el tablero físico es fácil de detectar porque “el tablero se nos hace pequeño”, en el virtual esto se puede traducir por “no nos cabe todo en una sola pantalla”. Estos olores nos deberían poner en alerta y reflexionar sobre ello en las retrospectivas.
  • Reconozco las virtudes de las herramientas virtuales para recopilar y agregar datos, especialmente para las PMO o departamentos de Finanzas, pero esto también es resoluble sin necesidad de inmiscuirse en cómo trabaja un equipo. Ahí tenemos que entender mejor qué información necesitan realmente estos departamentos y responder con la precisión necesaria. A nadie le interesa cuántas horas ha empleado un equipo en una tarea en particular sino cuántas jornadas x persona (es decir, cientos o miles de euros) está costando un proyecto.

Tablero físico o virtual

Hay diferentes escenarios en los que nos podemos ver empujados a emplear un tablero virtual. En ese caso, mi consejo es que sea una decisión consensuada por el equipo. Se puede tratar como un acuerdo de trabajo más.

Seguramente podrás ayudar a que el equipo tome esa decisión con estas reflexiones:

  • Si el equipo está empezando como equipo (ya sea haciendo Kanban o Scrum), mi consejo siempre es NO prescindir del tablero físico, aunque sea más trabajo porque alguien nos obligue a tener la misma información en otro soporte. (Ojo, el equipo suele usar a quien hace de ScrumMaster para que actúe como secretario (transcribiendo todas las historias y tarjetas de un tablero a otro) y no se hace cargo del sobresfuerzo. Es una excelente oportunidad para que todo el equipo asuma un poco de ese rol de ScrumMaster).
  • Si el equipo está distribuido y no hay manera de que trabajen con el mismo tablero físico, no queda más remedio que usar un tablero virtual. Esto ya no es una imposición de alguien externo sino una decisión del propio equipo. Una de las características del trabajo distribuido geográficamente es que requiere de todos un mayor esfuerzo en comunicar. Encontrar los canales adecuados para que se produzca esa comunicación es difícil y tarda tiempo en encontrar las herramientas y acuerdos de trabajo que funcionan para cada equipo. El tablero virtual es una herramienta más, pero ni tiene por qué ser la única ni tiene por qué ser sustitutiva del tablero físico. Lógicamente, si en ninguna de las sedes físicas hay más de 2 personas, parece que no tiene mucho sentido tener un tablero físico.

Si quieres contribuir a esta conversación con tus experiencias, dudas o sugerencias, puedes usar los comentarios en este artículo o en la entrada de la lista de correo a la que me refería más arriba.

Gestión ágil de proyectos

Para entender cómo se gestiona un proyecto con una metodología ágil es necesario entender antes la diferencia entre una gestión predictiva y una gestión adaptativa. En este artículo, además, puedes conocer las ventajas de este tipo de gestión de proyectos y cuándo es más adecuado aplicarla.
Sigue leyendo…

Burn-up chart

El burn-up chart (literalmente “gráfico de quemado hacia arriba”) muestra el trabajo aportado por un equipo, o varios, a un proyecto ágil. Aunque resulta poco conocido, es uno de los gráficos más útiles para gestionar el trabajo de un equipo haciendo Scrum porque nos permite tomar decisiones realistas acerca del trabajo pendiente y las expectativas alrededor del mismo.
Sigue leyendo…

Tablero kanban para trabajo no planificable

Cuando la organización no puede permitirse el lujo de tener “en una urna de cristal” al equipo que está haciendo Scrum y debe asignarle trabajo no planificable suelo recomendar que apliquen Kanban para manejar este último.
Sigue leyendo…

Póster de Scrum

En este póster tienes un resumen gráfico del proceso de desarrollo que suelo explicar en mis cursos y en los acompañamientos a los equipos. En él se describen los roles (el dueño del producto, el ScrumMaster y el equipo), los artefactos y todas las reuniones. Para cada reunión se representa destacado el rol que debería liderarla. Además, también incluye el resumen de valores que yo transmito a mis equipos y que, en mi experiencia, resultan más fáciles de recordar que los del Manifiesto Ágil:

Autoexigencia, autodisciplina y ritmo sostenible.

Sigue leyendo…

User personas

La user persona es una técnica que nace en los 90 entre expertos en marketing y diseño centrado en el usuario y que se enriquece con el uso de otras técnicas como la investigación etnográfica o la segmentación de mercados. Alan Cooper es el primero que comienza a usarla para el diseño de software y de experiencia de usuario (UX). Se basa en la idea de conocer a los usuarios del sistema que vamos a construir mediante arquetipos descritos como personajes de ficción.
Sigue leyendo…

User Story Mapping

Es una técnica descrita por primera vez por y consiste en representar el product backlog en dos dimensiones en vez de en una. Sigue leyendo…

Retrospectiva

Es una reunión que realiza el equipo regularmente para reflexionar juntos y buscar acciones de mejora sobre su manera de trabajar juntos, independientemente del producto. La Retrospectiva es la técnica más poderosa que aporta el agilismo al desarrollo de equipos porque les permite reflexionar de manera regular y buscar acciones de mejora concretas que, por pequeñas que sean, siempre suman.
Sigue leyendo…

Manual del buen Dueño de Producto (Product Owner)

El Dueño de Producto es uno de los roles que define Scrum y lo sitúa entre el equipo y el resto de interesados en el proyecto (el cliente, expertos del negocio, etc). ¿Cuáles son sus responsabilidades? ¿En qué reuniones participa? ¿Cómo podemos encontrar a un Dueño de Producto dentro de nuestras organización? ¿Hay malas prácticas que debemos evitar?

Sigue leyendo…

Agile Inception

Agile Inception, también conocida como Inception Deck o simplemente Inception, es un conjunto de dinámicas orientadas a enfocar a todas las personas involucradas en un proyecto hacia un mismo objetivo, reduciendo muchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes y poniendo en común las expectativas de todos. Sigue leyendo…

« Older Entries