Visual Scrum - What you see is What you get

Vanesa Tejada Munoz

vatemu@gmail.com

Resumen La gestion visual es una potente herramienta que permite adesarrolladores, scrum master, lıderes de equipo y personal de direccion,conocer el estado de sus proyectos de una forma mas rapida y eficiente, demanera que la mayor parte de su tiempo se inviterta principalmente en laprevencion de bloqueos en los equipos y toma de decisiones. Este artıculopresenta un conjunto de ideas para trabajar la gestion visual, adaptadasa los diferentes roles que existen en una empresa, y la informacion quenecesitan para desempenar su trabajo.

Keywords: Agil, Scrum, Scrum board, mejora contınua, gestion, infor-macion, estrategia, negocios, roadmap.

1 Introduccion

Cuando las empresas contratan el desarrollo de un proyecto, este forma parte deuna estrategia de negocio. Dados unos requisitos de un cliente, la empresa destinael proyecto a un equipo de trabajo, quienes se responabilizan del desarrollo delproducto.

En esta simple definicion de proyecto, vemos claramente la existencia de tresroles: direccion de empresa, cliente, equipo de trabajo.

Las metodologıas agiles resaltan el papel que juegan los equipos de desarro-llo, un papel principal de todo el ciclo de vida del proyecto, quienes realmentelo hacen realidad. La involucracion del equipo de trabajo en todo el proceso dedesarrollo debe ser completa. Esto quiere decir que el equipo debe conocer per-fectamente que desea el cliente, validar con el las tareas que han implementadopara poder solucionar los fallos, conocer el alcance del producto y deben ser ellosquienes principalmente, recojan este feedback para mejorar su siguiente entregadel producto.

Durante el desarrollo del proyecto, equipos que trabajan con Scrum, utilizanuna pizarra para representar las tareas que deben llevar a cabo en un periodode tiempo concreto, un sprint. La pizarra de Scrum es un ejemplo perfecto degestion visual. En ella el equipo tiene claramente definidos sus objetivos a cortoplazo correctamente priorizados para alcanzarlos. Diariamente el equipo trabajasobre este panel, representando en el su flujo de tareas por hacer, en progresoy completadas, se comunica y tiene la capacidad de coordinarse y gestionarsepor sı mismo, gracias a que tiene claras las metas hacia las que camina, y estainvolucrado con el producto.

Al igual que el equipo de Scrum, el resto de los roles del proyecto necesitanconocer con cierta periodicidad el estado del producto. Habitualmente, se rea-lizan reuniones de seguimiento, se presentan documentos de texto, resumenes olistado de puntos a tratar. Aunque esta informacion puede estar completamentecorrecta, en este artıculo se pretende mostrar el estado del proyecto con panelesadecuados a la informacion que estos roles necesitan recibir, es decir, se deseapotenciar la gestion visual para el resto de los roles involucrados en el proyecto,adaptandolas a su ambito de trabajo.

2 Visual Management

La gestion visual permite tener una idea completa del trabajo que estamos e-laborando de una forma muy clara y eficiente. Hoy en dıa, en el mundo de lasempresas de software, son muchos los proyectos que estan en marcha al mismotiempo, cada uno de ellos tiene un equipo o varios trabajando para sacarloadelante. Cada proyecto es un mundo, algunos son nuevos partiendo de cero, enotros casos los proyectos son evolutivos y tienen mantenimiento, incluso existenproyectos que solo tienen mantenimiento, pero lo que todos tienen en comun esla necesidad de una labor de gestion.

La gestion visual nos va a permitir mostrar las tareas que el equipo debeabordar, de una forma clara, sencilla, para centrarnos en la gestion de las mis-mas en funcion del tipo de proyecto que tengamos, logrando dar una mayorperspectiva y capacidad para llevar a cabo planes de accion.

3 Visual Scrum

El concepto Visual Scrum, es una idea que surge de la necesidad de ampliara otros tipos de proyectos y otros roles involucrados en el producto, la gestionvisual respecto la metodologıa agil de Scrum. El objetivo es ofrecer a cada rolela informacion que necesita sobre un proyecto en funcion de su perspectiva.

La figura 1 muestra los roles que van a tomar parte en algunas de las propu-estas de la gestion visual:

Los roles que aparecen son: personal directivo de una empresa centrados enlos objetivos de negocio, los product owner encargados de facilitar los requisitosde los proyectos a los equipos de desarrollo, y finalmente el equipo agil queimplementara el producto. La perspectiva de cada role para una simple tarea enesta jerarquıa es completamente diferente, partiendo de un objetivo de negocio,que se desgrana en un conjunto de historias de usuario, que finalmente, se dividenen un conjunto de subtareas que se deben implementar. Aunque todos los rolestienen su implicacion en el proyecto, la informacion que estos precisan no tienepor que ser la misma para todos en cada momento, al igual que puede no serigual su forma de acometer el proyecto.

En funcion de estos roles vamos a presentar diversos escenarios de trabajo,con varios tipos de proyectos para ver como podrıamos llevar a cabo una gestionvisual en cada caso.

Fig. 1. Jerarquıa de roles

3.1 Scrum Board

Un equipo de desarrollo, lleva cabo un conjunto de tareas que se han planificadopara un sprint o iteracion. Las tareas pueden ser mejoras, nuevas funcionalidadeso errores en el producto que deben solucionarse cuanto antes. Los equipos puedenadaptar el trabajo en una tablon que represente el ciclo de vida de una tarea,desde que no hemos empezado a trabajar con ella, hasta que podemos decirque esta terminada. Dado que conocen el alcance del proyecto, en su seccion debacklog ordenaran las tareas aun no planificadas. La figura 2 muestra un sencillopanel adaptado a esta situacion de trabajo.

Fig. 2. Pizarra de Scrum

Ahora imaginemos que el equipo decide que la persona que lleva a cabo eldesarrollo no sea la misma que haga la validacion final antes de la demostracion

con el cliente. Esta situacion puede darse para mantener la transferencia deconocimientos, ver como se ha realizado la implementacion y corroborar que latarea cumple con la definicion de DONE (DoD) que se haya especificado a nivelde equipo. De alguna manera ahora, se deben marcar las tareas para indicarquien ha realizado su desarrollo y pruebas, y quien sera el responsable de validarla tarea completamente.

Por otro lado, en ocasiones aparecen tareas no previstas, algo inevitablemuchas veces que se da en el dıa a dıa. Puede deberse a algun problema graveen el producto o porque en la planificacion del sprint se ha pasado algo poralto. En este ultimo caso, es muy probable que ante un sprint ya planificado noexista tiempo restante para abordar una tarea no prevista, pero en caso de tenerque hacerla obligatoriamente, se deberıa identificar en nuestro panel y otra tareatendra que ser replanificada por este motivo. La figura 3 presenta como plasmaren 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 identificanla persona que tiene la tarea asignada. Cuando una tarea cambie de estado elequipo decidira en la reunion diaria quien lleva a cabo la validacion segun lacarga de trabajo de cada miembro.

El segundo caso puede hacerse de dos maneras, bien dejando una secionseparada en nuestro tablon para las tareas as soon as possible (ASAP), o bien,poniendo la tarea no prevista encima de aquella que probablemente no se lleve acabo en el sprint, es decir, la tarea sacrificada. Es muy interesante evaluar en laretrospectiva 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 alcanzarsu objetivo o incluso si existe alguna forma mejor de que el equipo se coordinepara abordar estos casos sin que el sprint se vea afectado.

Al final de toda iteracion se obtiene como resultado un incremento del proyectotal, que permitirıa poder presentar estas mejoras como producto terminado al

cliente tan pronto como lo solicite. Generalmente en esta demostracion se evaluanlas funcionalidades delante del cliente, pero quiza, haya otras maneras de poderhacer un seguimiento intermedio de como va la aplicacion. Si nos imaginamosque vamos a hacer un nuevo proyecto web, para el cual se han definido unosrequisitos de usuario y se han llevado a cabo unos disenos, podrıamos anadiralgo mas a nuestros paneles de Scrum que las tareas. Los elementos que vana componer la web junto con sus correspondientes funcionalidades, son lo quese definiran como historias de usuario, que una vez completadas indicaran queese boton, tabla o pestana de informacion ya esta funcionando. En este casopodrıamos poner los disenos de la web en nuestro panel, inicialmente en blanco,y los componentes tenerlos a parte recortados. Cada vez que terminemos unahistoria de usuario, habremos completado la funcionalidad de uno de los compo-nentes, por lo que lo anadimos a ese diseno en blanco. De esta forma innovamosel modo en que el equipo crea esa nueva pagina web, incluso si alguien pasara pornuestro panel o tuvieramos un seguimiento con el cliente, simplemente viendoel diseno con sus piezas, podrıa evaluar el trabajo que se esta haciendo y lo quenos falta. En la figura 4 tenemos un ejemplo de como serıa el proceso:

Fig. 4. User Story componen la web

3.2 Scrum of Scrum

Los proyectos en los que trabajamos no siempre se desarrollan dentro de unmismo departamento, en numerosas ocasiones es necesaria la implicacion deotros equipos. En estas situaciones la coordinacion del proyecto es algo funda-mental, ya que el objetivo no es solo que las tareas salgan adelante, sino quepodamos identificar una linealidad a la hora de la planificacion y trabajar parala prevencion de bloqueos y cuellos de botella, situaciones que se dan cuandohay muchas dependencias externas y la gestion no es la adecuada.

A continuacion vamos a presentar varios paneles de Scrum con diferentesopciones para la gestion de un proyecto de estas caracterısticas. En estos panelessolo se muestran tareas en un nivel de abstraccion superior al de los panelesde equipo, es decir, en estos paneles no se muestran las subtareas que puedencomponer las historias de usuario.

La figura 5 presenta todas las acciones que debe llevar a cabo cada uno delos equipos involucrados en el proyecto y el estado en que cada una de ellas seencuentra. La vision es muy global en cuanto a las tareas que cada equipo debe

realizar, pero si existen tareas dependientes se pierde la relacion entre ellas, y portanto, 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, condiferentes colores para identificar las que pertenecen a diferentes departamentos.En este caso sı vemos las dependencias que existen entre ellas, por lo que podemosir un paso por delante en la gestion de interrupciones.

Fig. 6. Scrum Multiproyecto con dependencias

Cada una de las tareas tiene una marca de estado, en este ejemplo se hanutilizado sımbolos de progreso, realizada, bloqueo y ayuda, para las que no tienenla definicion de requisitos completa.

La figura 7, representa un escenario en el cual, tenemos un proyecto con unadeterminada fecha de inicio y fecha de fin, se conocen todas las tareas que debenllevarse a cabo para su finalizacion y esto nos permite, saber en cada sprint,los objetivos que tenemos que completar. La visibilidad del proyecto en estecaso es completa (big picture), ademas de permitir al equipo y product ownerrevisar la planificacion de sprints posteriores. En este caso podemos tener unasegunda utilidad para este mismo panel: si todas las tareas estan igual colore-adas, podemos asociarlas a un mismo departamento, sin embargo, si las tareaspertenecieran a diferentes departamentos, solo tendrıamos que identificarlas concolores distintos.

Fig. 7. Planificacion completa de sprints de un proyecto

3.3 Scrum Roadmap Board

En esta ultima seccion se propone como elaborar un roadmap anual de unaempresa. La vision de un gerente esta centrada en los proyectos de negocioque proporcionan grandes beneficios a la empresa. Estos proyectos pueden estardesignados a un unico equipo de desarrollo o varios, y finalmente, cada uno deestos proyectos se pretende completar un un trimestre en concreto.

El dıa a dıa de los equipos puede hacer que una tarea de negocio se termineen el tiempo estimado, no se complete en la fecha deseada o que, por otrasprioridades que han ido apareciendo no lleguen a empezarse. Lo importante enestos casos, no son unicamente los motivos por los cuales esas tareas se han tenidoque replanificar, lo verdaderamente urgente es redefinir una estrategia, ver losproyectos que se pretenden abordar en el ano y evaluar si, alguno de los queno se han podido empezar son mas importantes que los que estan planificadospara trimestres posteriores o si por el contrario, son mas importantes los queaun no se han iniciado y el que se quedo atras, se deja pendiente de planificar.El gerente debe tener una vision mas amplia, conociendo las tareas en curso y

posteriores, podra tomar decisiones sabiendo el impacto de ellas en cada uno delos proyectos. Para que esta evaluacion de crıticas decisiones se haga teniendotoda la informacion a la vista, podemos definir un panel de donde se muestrentodos los parametros que necesitamos conocer. En la figura 8 se presentan lastareas estimadas para cada Quarter 1 (QX) y su transicion de estados. Paradiferenciar 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 funcion delproyecto, 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

4 Conclusiones

Los equipos de trabajo mejoran en coordinacion e implicacion en el proyectocuando obtienen una perspectiva mas amplia de todo el trabajo que tienen querealizar. Podemos obtener resultados similares en otras areas de la empresa in-corporando estas tcnicas en las reuniones de seguimiento. Es posible adaptarnuestras pizarras de Scrum de muchas formas en funcion de en que queramoshacer incapie. Hay multiples tablones para que un equipo sepa en que estadoesta su trabajo y se involucre mas, construyendo el camino hacia una meta.

La informacion visual tiene mucho potencial, simplemente de un vistazo,nuestros gerentes, directores de departamentos y product owners, podrıan sabercomo esta un proyecto en un menor espacio de tiempo. Las reuniones de segui-miento serıan mas agiles y productivas, dejando paso a pensar a futuro sabiendolo que tenemos en el presente. Aunque el agilismo aporte muchas mejoras a laempresa, de cara a negocio, todos los agilistas, debemos realizar un gran esfuerzopor transmitir los principios a este area, para que no quede en un concepto ysea algo que en el futuro nos defina como empresa y grupo.

Este artıculo muestra otras formas de presentar un conjunto de situacionesque podemos tener en el dıa a dıa, y queremos gestionar de una forma mas agily sencilla, donde no perdamos informacion. Se prentede con este conjunto depaneles dar un ejemplo de mejora continua, abriendo otras posibilidades a losequipos, scrum master, product owners, y responables de negocio, que puedenestar al dıa del estado de los desarrollos de una forma mas sencilla y facil deasimilar.

Agradecimientos

Gracias a los miembros de Agile-Spain, por llevar a cabo eventos en los quenumerosas personas, apasionadas por mejorar su trabajo, se unen para compartirexperiencias y enriquecerse mutuamente. Gracias por permitirme escribir esteartıculo, sobre una de las sesiones presentadas en el evento de la Conferencia deAgile-Spain en Castellon en 2011.

Bibliografıa

1. David Sibbett: Visual Meetings: How Graphics, Sticky Notes and Idea Mapping CanTransform Group Productivity. John Wiley, Canada (2010)

2. Visual Management Blog. Using information visualization to manage agile projects.http://www.xqa.com.ar/visualmanagement/