Este documento describe cómo la gestión visual puede aplicarse más allá del equipo de desarrollo en Scrum para proporcionar información relevante a otros roles como la dirección, propietarios de productos y equipos. Se presentan ejemplos de cómo tableros visuales podrían adaptarse a diferentes tipos de proyectos y roles para mejorar la comunicación y toma de decisiones.

1. Visual Scrum - What you see is What you get
Vanesa Tejada Mu˜oz
n
vatemu@gmail.com
Resumen La gesti´n visual es una potente herramienta que permite a
o
desarrolladores, scrum master, l´ıderes de equipo y personal de direcci´n,
o
conocer el estado de sus proyectos de una forma m´s r´pida y eficiente, de
a a
manera que la mayor parte de su tiempo se inviterta principalmente en la
prevenci´n de bloqueos en los equipos y toma de decisiones. Este art´
o ıculo
presenta un conjunto de ideas para trabajar la gesti´n visual, adaptadas
o
a los diferentes roles que existen en una empresa, y la informaci´n que
o
necesitan para desempe˜ar su trabajo.
n
´
Keywords: Agil, Scrum, Scrum board, mejora cont´
ınua, gesti´n, infor-
o
maci´n, estrategia, negocios, roadmap.
o
1 Introducci´n
o
Cuando las empresas contratan el desarrollo de un proyecto, ´ste forma parte de
e
una estrategia de negocio. Dados unos requisitos de un cliente, la empresa destina
el proyecto a un equipo de trabajo, quienes se responabilizan del desarrollo del
producto.
En esta simple definici´n de proyecto, vemos claramente la existencia de tres
o
roles: direcci´n de empresa, cliente, equipo de trabajo.
o
Las metodolog´ ´giles resaltan el papel que juegan los equipos de desarro-
ıas a
llo, un papel principal de todo el ciclo de vida del proyecto, quienes realmente
lo hacen realidad. La involucraci´n del equipo de trabajo en todo el proceso de
o
desarrollo debe ser completa. Esto quiere decir que el equipo debe conocer per-
fectamente qu´ desea el cliente, validar con ´l las tareas que han implementado
e e
para poder solucionar los fallos, conocer el alcance del producto y deben ser ellos
quienes principalmente, recojan este feedback para mejorar su siguiente entrega
del producto.
Durante el desarrollo del proyecto, equipos que trabajan con Scrum, utilizan
una pizarra para representar las tareas que deben llevar a cabo en un periodo
de tiempo concreto, un sprint. La pizarra de Scrum es un ejemplo perfecto de
gesti´n visual. En ella el equipo tiene claramente definidos sus objetivos a corto
o
plazo correctamente priorizados para alcanzarlos. Diariamente el equipo trabaja
sobre este panel, representando en ´l su flujo de tareas por hacer, en progreso
e
y completadas, se comunica y tiene la capacidad de coordinarse y gestionarse
por s´ mismo, gracias a que tiene claras las metas hacia las que camina, y est´
ı a
involucrado con el producto.

2. Al igual que el equipo de Scrum, el resto de los roles del proyecto necesitan
conocer con cierta periodicidad el estado del producto. Habitualmente, se rea-
lizan reuniones de seguimiento, se presentan documentos de texto, res´menes o
u
listado de puntos a tratar. Aunque esta informaci´n puede estar completamente
o
correcta, en este art´
ıculo se pretende mostrar el estado del proyecto con paneles
adecuados a la informaci´n que estos roles necesitan recibir, es decir, se desea
o
potenciar la gesti´n visual para el resto de los roles involucrados en el proyecto,
o
adapt´ndolas a su ´mbito de trabajo.
a a
2 Visual Management
La gesti´n visual permite tener una idea completa del trabajo que estamos e-
o
laborando de una forma muy clara y eficiente. Hoy en d´ en el mundo de las
ıa,
empresas de software, son muchos los proyectos que est´n en marcha al mismo
a
tiempo, cada uno de ellos tiene un equipo o varios trabajando para sacarlo
adelante. Cada proyecto es un mundo, algunos son nuevos partiendo de cero, en
otros casos los proyectos son evolutivos y tienen mantenimiento, incluso existen
proyectos que s´lo tienen mantenimiento, pero lo que todos tienen en com´n es
o u
la necesidad de una labor de gesti´n.
o
La gesti´n visual nos va a permitir mostrar las tareas que el equipo debe
o
abordar, de una forma clara, sencilla, para centrarnos en la gesti´n de las mis-
o
mas en funci´n del tipo de proyecto que tengamos, logrando dar una mayor
o
perspectiva y capacidad para llevar a cabo planes de acci´n.
o
3 Visual Scrum
El concepto Visual Scrum, es una idea que surge de la necesidad de ampliar
a otros tipos de proyectos y otros roles involucrados en el producto, la gesti´no
visual respecto la metodolog´ ´gil de Scrum. El objetivo es ofrecer a cada role
ıa a
la informaci´n que necesita sobre un proyecto en funci´n de su perspectiva.
o o
La figura 1 muestra los roles que van a tomar parte en algunas de las propu-
estas de la gesti´n visual:
o
Los roles que aparecen son: personal directivo de una empresa centrados en
los objetivos de negocio, los product owner encargados de facilitar los requisitos
de los proyectos a los equipos de desarrollo, y finalmente el equipo ´gil que
a
implementar´ el producto. La perspectiva de cada role para una simple tarea en
a
esta jerarqu´ es completamente diferente, partiendo de un objetivo de negocio,
ıa
que se desgrana en un conjunto de historias de usuario, que finalmente, se dividen
en un conjunto de subtareas que se deben implementar. Aunque todos los roles
tienen su implicaci´n en el proyecto, la informaci´n que estos precisan no tiene
o o
por que ser la misma para todos en cada momento, al igual que puede no ser
igual su forma de acometer el proyecto.
En funci´n de estos roles vamos a presentar diversos escenarios de trabajo,
o
con varios tipos de proyectos para ver c´mo podr´
o ıamos llevar a cabo una gesti´n
o
visual en cada caso.

3. Fig. 1. Jerarqu´ de roles
ıa
3.1 Scrum Board
Un equipo de desarrollo, lleva cabo un conjunto de tareas que se han planificado
para un sprint o iteraci´n. Las tareas pueden ser mejoras, nuevas funcionalidades
o
o errores en el producto que deben solucionarse cuanto antes. Los equipos pueden
adaptar el trabajo en una tabl´n que represente el ciclo de vida de una tarea,
o
desde que no hemos empezado a trabajar con ella, hasta que podemos decir
que est´ terminada. Dado que conocen el alcance del proyecto, en su secci´n de
a o
backlog ordenar´n las tareas a´n no planificadas. La figura 2 muestra un sencillo
a u
panel adaptado a esta situaci´n de trabajo.
o
Fig. 2. Pizarra de Scrum
Ahora imaginemos que el equipo decide que la persona que lleva a cabo el
desarrollo no sea la misma que haga la validaci´n final antes de la demostraci´n
o o

4. con el cliente. Esta situaci´n puede darse para mantener la transferencia de
o
conocimientos, ver c´mo se ha realizado la implementaci´n y corroborar que la
o o
tarea cumple con la definici´n de DONE (DoD) que se haya especificado a nivel
o
de equipo. De alguna manera ahora, se deben marcar las tareas para indicar
qui´n ha realizado su desarrollo y pruebas, y qui´n ser´ el responsable de validar
e e a
la tarea completamente.
Por otro lado, en ocasiones aparecen tareas no previstas, algo inevitable
muchas veces que se da en el d´ a d´ Puede deberse a alg´n problema grave
ıa ıa. u
en el producto o porque en la planificaci´n del sprint se ha pasado algo por
o
alto. En este ultimo caso, es muy probable que ante un sprint ya planificado no
´
exista tiempo restante para abordar una tarea no prevista, pero en caso de tener
que hacerla obligatoriamente, se deber´ identificar en nuestro panel y otra tarea
ıa
tendr´ que ser replanificada por este motivo. La figura 3 presenta como plasmar
a
en nuestro panel de Scrum los dos escenarios mencionados:
Fig. 3. Pizarra de Scrum con tareas personalizadas y mantenimiento
En en primer caso, las columnas de IN PROGRESS y TESTING identifican
la persona que tiene la tarea asignada. Cuando una tarea cambie de estado el
equipo decidir´ en la reuni´n diaria qui´n lleva a cabo la validaci´n seg´n la
a o e o u
carga de trabajo de cada miembro.
El segundo caso puede hacerse de dos maneras, bien dejando una seci´n o
separada en nuestro tabl´n para las tareas as soon as possible (ASAP), o bien,
o
poniendo la tarea no prevista encima de aquella que probablemente no se lleve a
cabo en el sprint, es decir, la tarea sacrificada. Es muy interesante evaluar en la
retrospectiva del equipo, si existe alguna forma de evitar esas tareas no previstas,
si durante varios sprints han sido este motivo el que no les ha permitido alcanzar
su objetivo o incluso si existe alguna forma mejor de que el equipo se coordine
para abordar estos casos sin que el sprint se vea afectado.
Al final de toda iteraci´n se obtiene como resultado un incremento del proyecto
o
tal, que permitir´ poder presentar estas mejoras como producto terminado al
ıa

5. cliente tan pronto como lo solicite. Generalmente en esta demostraci´n se eval´an
o u
las funcionalidades delante del cliente, pero quiz´, haya otras maneras de poder
a
hacer un seguimiento intermedio de c´mo va la aplicaci´n. Si nos imaginamos
o o
que vamos a hacer un nuevo proyecto web, para el cual se han definido unos
requisitos de usuario y se han llevado a cabo unos dise˜os, podr´
n ıamos a˜adir
n
algo m´s a nuestros paneles de Scrum que las tareas. Los elementos que van
a
a componer la web junto con sus correspondientes funcionalidades, son lo que
se definir´n como historias de usuario, que una vez completadas indicar´n que
a a
ese bot´n, tabla o pesta˜a de informaci´n ya est´ funcionando. En este caso
o n o a
podr´ıamos poner los dise˜os de la web en nuestro panel, inicialmente en blanco,
n
y los componentes tenerlos a parte recortados. Cada vez que terminemos una
historia de usuario, habremos completado la funcionalidad de uno de los compo-
nentes, por lo que lo a˜adimos a ese dise˜o en blanco. De esta forma innovamos
n n
el modo en que el equipo crea esa nueva p´gina web, incluso si alguien pasara por
a
nuestro panel o tuvi´ramos un seguimiento con el cliente, simplemente viendo
e
el dise˜o con sus piezas, podr´ evaluar el trabajo que se est´ haciendo y lo que
n ıa a
nos falta. En la figura 4 tenemos un ejemplo de c´mo ser´ el proceso:
o ıa
Fig. 4. User Story componen la web
3.2 Scrum of Scrum
Los proyectos en los que trabajamos no siempre se desarrollan dentro de un
mismo departamento, en numerosas ocasiones es necesaria la implicaci´n de o
otros equipos. En estas situaciones la coordinaci´n del proyecto es algo funda-
o
mental, ya que el objetivo no es s´lo que las tareas salgan adelante, sino que
o
podamos identificar una linealidad a la hora de la planificaci´n y trabajar para
o
la prevenci´n de bloqueos y cuellos de botella, situaciones que se dan cuando
o
hay muchas dependencias externas y la gesti´n no es la adecuada.
o
A continuaci´n vamos a presentar varios paneles de Scrum con diferentes
o
opciones para la gesti´n de un proyecto de estas caracter´
o ısticas. En estos paneles
s´lo se muestran tareas en un nivel de abstracci´n superior al de los paneles
o o
de equipo, es decir, en estos paneles no se muestran las subtareas que pueden
componer las historias de usuario.
La figura 5 presenta todas las acciones que debe llevar a cabo cada uno de
los equipos involucrados en el proyecto y el estado en que cada una de ellas se
encuentra. La visi´n es muy global en cuanto a las tareas que cada equipo debe
o

6. realizar, pero si existen tareas dependientes se pierde la relaci´n entre ellas, y por
o
tanto, existe una mayor dificultad a la hora de preveer situaciones de bloqueo.
Fig. 5. Scrum Multiproyecto
La figura 6, representa un diagrama de flujo de historias de usuario, con
diferentes colores para identificar las que pertenecen a diferentes departamentos.
En este caso s´ vemos las dependencias que existen entre ellas, por lo que podemos
ı
ir un paso por delante en la gesti´n de interrupciones.
o
Fig. 6. Scrum Multiproyecto con dependencias
Cada una de las tareas tiene una marca de estado, en este ejemplo se han
utilizado s´
ımbolos de progreso, realizada, bloqueo y ayuda, para las que no tienen
la definici´n de requisitos completa.
o

7. La figura 7, representa un escenario en el cual, tenemos un proyecto con una
determinada fecha de inicio y fecha de fin, se conocen todas las tareas que deben
llevarse a cabo para su finalizaci´n y esto nos permite, saber en cada sprint,
o
los objetivos que tenemos que completar. La visibilidad del proyecto en este
caso es completa (big picture), adem´s de permitir al equipo y product owner
a
revisar la planificaci´n de sprints posteriores. En este caso podemos tener una
o
segunda utilidad para este mismo panel: si todas las tareas est´n igual colore-
a
adas, podemos asociarlas a un mismo departamento, sin embargo, si las tareas
pertenecieran a diferentes departamentos, s´lo tendr´
o ıamos que identificarlas con
colores distintos.
Fig. 7. Planificaci´n completa de sprints de un proyecto
o
3.3 Scrum Roadmap Board
En esta ultima secci´n se propone c´mo elaborar un roadmap anual de una
´ o o
empresa. La visi´n de un gerente est´ centrada en los proyectos de negocio
o a
que proporcionan grandes beneficios a la empresa. Estos proyectos pueden estar
designados a un unico equipo de desarrollo o varios, y finalmente, cada uno de
´
estos proyectos se pretende completar un un trimestre en concreto.
El d´ a d´ de los equipos puede hacer que una tarea de negocio se termine
ıa ıa
en el tiempo estimado, no se complete en la fecha deseada o que, por otras
prioridades que han ido apareciendo no lleguen a empezarse. Lo importante en
estos casos, no son unicamente los motivos por los cuales esas tareas se han tenido
´
que replanificar, lo verdaderamente urgente es redefinir una estrategia, ver los
proyectos que se pretenden abordar en el a˜o y evaluar si, alguno de los que
n
no se han podido empezar son m´s importantes que los que est´n planificados
a a
para trimestres posteriores o si por el contrario, son m´s importantes los que
a
a´n no se han iniciado y el que se qued´ atr´s, se deja pendiente de planificar.
u o a
El gerente debe tener una visi´n m´s amplia, conociendo las tareas en curso y
o a

8. posteriores, podr´ tomar decisiones sabiendo el impacto de ellas en cada uno de
a
los proyectos. Para que esta evaluaci´n de cr´
o ıticas decisiones se haga teniendo
toda la informaci´n a la vista, podemos definir un panel de donde se muestren
o
todos los par´metros que necesitamos conocer. En la figura 8 se presentan las
a
tareas estimadas para cada Quarter 1 (QX) y su transici´n de estados. Para
o
diferenciar el proyecto al que corresponde, se pueden usar diferentes colores.
Fig. 8. Scrum Roadmap
La figura 9 se presentan las tareas estimadas para cada QX en funci´n del
o
proyecto, y para identifcar su estado se marcan con s´
ımbolos. Este ejemplo mues-
tra una foto del estado de proyectos de negocio al completo.
Fig. 9. Scrum Roadmap

9. 4 Conclusiones
Los equipos de trabajo mejoran en coordinaci´n e implicaci´n en el proyecto
o o
cuando obtienen una perspectiva mas amplia de todo el trabajo que tienen que
realizar. Podemos obtener resultados similares en otras areas de la empresa in-
corporando estas tcnicas en las reuniones de seguimiento. Es posible adaptar
nuestras pizarras de Scrum de muchas formas en funci´n de en qu´ queramos
o e
hacer incapi´. Hay m´ltiples tablones para que un equipo sepa en qu´ estado
e u e
est´ su trabajo y se involucre m´s, construyendo el camino hacia una meta.
a a
La informaci´n visual tiene mucho potencial, simplemente de un vistazo,
o
nuestros gerentes, directores de departamentos y product owners, podr´ saber
ıan
c´mo est´ un proyecto en un menor espacio de tiempo. Las reuniones de segui-
o a
miento ser´ m´s ´giles y productivas, dejando paso a pensar a futuro sabiendo
ıan a a
lo que tenemos en el presente. Aunque el agilismo aporte muchas mejoras a la
empresa, de cara a negocio, todos los agilistas, debemos realizar un gran esfuerzo
por transmitir los principios a este ´rea, para que no quede en un concepto y
a
sea algo que en el futuro nos defina como empresa y grupo.
Este art´ ıculo muestra otras formas de presentar un conjunto de situaciones
que podemos tener en el d´ a d´ y queremos gestionar de una forma m´s ´gil
ıa ıa, a a
y sencilla, donde no perdamos informaci´n. Se prentede con este conjunto de
o
paneles dar un ejemplo de mejora continua, abriendo otras posibilidades a los
equipos, scrum master, product owners, y responables de negocio, que pueden
estar al d´ del estado de los desarrollos de una forma m´s sencilla y f´cil de
ıa a a
asimilar.
Agradecimientos
Gracias a los miembros de Agile-Spain, por llevar a cabo eventos en los que
numerosas personas, apasionadas por mejorar su trabajo, se unen para compartir
experiencias y enriquecerse mutuamente. Gracias por permitirme escribir este
art´
ıculo, sobre una de las sesiones presentadas en el evento de la Conferencia de
Agile-Spain en Castell´n en 2011.
o
Bibliograf´
ıa
1. David Sibbett: Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can
Transform Group Productivity. John Wiley, Canada (2010)
2. Visual Management Blog. Using information visualization to manage agile projects.
http://www.xqa.com.ar/visualmanagement/