… de personas y sistemas.
Entradas etiquetadas con Experiencias
Resultado del AO La Plata 2009
22 jun
El Sábado 20 de Junio se realizó el evento Agile Open La Plata 2009, donde contamos con la presencia de 65 personas.
Luego del desayuno realizamos la Apertura, que me tocó facilitar a mí. Una experiencia increíble: fue mi primer facilitación de un evento Open Space. El principio fue como suele suceder en este tipo de eventos: la gente no termina de digerir el formato sino hasta unos 10 minutos luego de que ponen manos a la obra, el resultado fue cerca de 40 propuestas de sesiones, una votación bastante fluida y la siguiente definición de agenda:
Agenda AO La Plata 2009
Destaco algunas sesiones en las que pude participar, todas de un excelente nivel:
Introducción a Lean (facilitada por Juan Gabardini) e Introducción a las Metodologías Agiles (moderada por Nicolás Paez) fueron las dos sesiones que dieron el puntapié inicial. A la gente se la vio muy enganchada con los temas y reconozco que me costó bastante cortar las mismas en tiempo, debido al entusiasmo de los presentes.
Las estrellas del segundo track fueron Introducción a SCRUM (propuesta y moderada por Marcelo Belnicoff) y Comunicación en Equipos Ágiles (moderada por Nicolás y Esteban).
El almuerzo se realizó a tiempo, se generó un excelente clima donde la gente siguió compartiendo inquietudes, experiencias, dudas, opiniones. Un gran contexto para el networking.
La tarde comenzó con el Juego del Pajarraco, del cual tengo un par de fotos del proceso (sacadas con el celular) y con muchas otras sesiones paralelas, ya más avanzadas en las que tuve la suerte de participar: CMMI+PMI+Agile, Equipos MUY chicos, Testing Ágil, Cómo vender ágil al cliente, metodologías ágiles fuera de la industria IT, etc.
* Fotos Pajarraco:
Luego de un coffee break que llegó para amenizar la tarde de muchos desde el punto de vista gastronómico 
, se debatió bastante sobre Retrospectivas (discusión abierta) y hubo una presentación de Arquitectura Ágil (por Diego Fontdevila).
Llegamos al cierre con una considerable cantidad de gente (arriba de 40). El mismo fue facilitado por Diego con resultados excelentes, a los que estamos acostumbrados en todo Open Space: gran interacción personal, mucha participación activa en general, temas realmente interesantes, debatir sobre metodologías ágiles en una conferencia organizada en forma ágil, experiencias vivenciales, etc. El Resumen fue más que positivo:
Resultado AO La Plata 2009
Los próximos pasos a nivel “La Plata” son organizar encuentros mensuales para discutir sobre metodologías ágiles replicando el modelo que lleva meses funcionando en Buenos Aires mientras que a nivel nacional tenemos por delante la organización y realización de los Agile Open Rosario, Mar del Plata y Bahía Blanca. Y cualquier otra nueva ciudad que quiera sumarse.
Pasó un nuevo Agile Open, que como todos los anteriores también ha dejado su huella.
Post-Its Voladores
11 may
Hace unos días, en la lista de la comunidad ágil (http://tech.groups.yahoo.com/group/foro-agiles/message/1738), se planteó el tema de los Post-Its Voladores, que se despegan, se caen, se vuelan, etc. de los ScrumBoards o TaskBoards.
Las opciones recomendadas fueron varias; como por ejemplo:
- el uso de Post-Its super sticky,
- cinta Scotch Magic,
- pegamento UHU Tac
- Pizarras Magnéticas.
En mis últimas experiencias de aplicación de Scrum en equipos de delivery hemos experimentado utilizando pizarras de corcho, post-its comunes y chinches para sujetarlos. La primer implementación de este tipo surgió de forma casual; estábamos a la espera de la llegada de la pizarra mientras utilizabamos rota-folios unidos en su lugar (Fig.1). Frente a la demora de su llegada, tomamos una pizarra de corcho que no estaba siendo utilizada y comenzamos a pegar los post-its allí. No pasó mucho tiempo hasta que comenzaron a despegarse, a lo que reaccionamos sujetándolos con chinches (Fig.2).
Al hacerlo de esta manera, hemos encontramos al menos 2 beneficios: 1) poder sujetar un conjunto importante de post-its encimados (Fig.3), ocupando menos superficie de la pizarra (por ejemplo en la sección “pendientes”), y 2) utilizar chinches de colores diferentes para cada miembro del equipo (Fig.4), facilitando la identificación de la persona que está trabajando en cada post-it.
Referencias:
Fig.1: Pizarra de Rota-folio @ Accenture - SCM Team
Fig.2: Convertida en Pizarra de Corcho @ Gorricho
Fig.3: User Story + Tasks en Sección de "Entregados"
Fig.4: Cada Miembro un Color.
Tareas no planificadas
11 abr
Implementando SCRUM en un cliente, como parte de una consultoría en gestión de proyectos, descubrimos que trabajaba bajo dos modalidades que deliberadamente decidimos llamar Tareas Planificadas y Fires.
El concepto era que las Tareas Planificadas eran todas aquellas que salían del BackLog y se incluía en el Sprint durante la reunión de planificación, mientras que los Fires eran las tareas que se incluían durante el Sprint, sin previa planificación.
La razón detrás de esta decisión fue que el cliente trabajaba con iniciativas de identidad, entregas planificadas, compromisos previamente acordados con cierta anticipación y, en paralelo, con mantenimientos a los cuales asignaba una determinada cuota de horas mensuales, carente de previsibilidad alguna.
La decisión inicial
Inicialmente decidimos tomar items del BackLog y transformarlos en Story Cards, los cuales a su vez se descomponían en Tareas Planificadas. Esta actividad se realizaba durante la segunda mitad de la reunión de planificación, donde el equipo de trabajo mismo determinaba esa descomposición. A medida que se realizaba, los miembros del equipo iban llenando con Tareas Planificadas la columna correspondiente al To-Do (segunda columna) en el TaskBoard, dejando la primera para los Story Cards, llamada Commited BackLog.
Si eventualmente surgía una tarea de mantenimiento y/o urgencia que no podía esperar al próximo Sprint para ser resuelta, se ingresaba un Fire en el TaskBoard.
¿Cuándo agregarlas?
El primer desafío que nos encontramos fue determinar cuándo esas tareas Fires debían ser agregadas al TaskBoard. Evaluamos cuatro posibilidades:
1. En cualquier momento: La idea es agregar los Fires inmediatamente luego de que son detectados o se determina que hay que trabajar en ellos. La contra que encontramos fue que agregarlos en medio del día no les da la visibilidad esperada, y recién son conocidos por la totalidad del equipo en la próxima Daily Standup Meeting.
2 y 3. Antes/Durante la Daily Standup Meeting: Agregarlos al TaskBoard 10 minutos antes de la Daily Standup Meeting o durante ella para darles mayor visibilidad. El perjuicio de ello era el de alargar innecesariamente la reunión que debía durar no más de 15 minutos, discutiendo los nuevos Fires que aparecían, en lugar de enfocarse en el verdadero contenido de la reunión.
3. Luego de la Daily Standup Meeting: Evaluamos también agregar dichas tareas una vez terminada la reunión para no alargarla, el inconveniente que detectamos fue que el hacerlo cambiaba automáticamente la realidad del resto del día, por lo cual lo discutido en la Daily Standup Meeting perdía su sentido.
Finalmente nos volcamos por la primer opción: “los Fires se agregan al TaskBoard a medida que van apareciendo”. La forma que hallamos de morigerar la falta de visibilidad consistía en que el miembro del equipo que lo agregaba debía primero notificar a sus compañeros que lo iba a agregar en breve. Una opción un poco más efectiva y ruidosa que evalué fue la de poner una bocina para ser tocada cada vez que un Fire apareciera… pero por el momento, me la guardo en el BackLog.
¿Cómo distinguirlas?
El segundo desafío a resolver -previo a su implementación- consistía en cómo distinguir a las tareas entre si. En primera instancia, evaluamos una solución interesante que plantea Xavier Quesada Allue en su blog Visual Management: dejar un workstream vacío arriba de todo para hacer el seguimiento de este tipo de tareas. El post se llama Unplanned Items and Legacy Issues.
Luego de discutir un buen rato, decidimos que si bien la solución de Xavier funciona en la mayoría de los casos, la particularidad en esta ocación resultaba en que los Fires tenían cierto buffer que permitía terminar primero una o varias Tareas Planificadas, y nosotros debíamos poder reflejar eso.
Finalmente, decidimos utilizar Post-Its de diferentes colores: Amarillos para las Tareas Planificadas y Naranjas para Fires, preservando de esta manera la dimensión vertical con el objetivo de reflejar prioridades.
Resultado:
Si bien en la implementación de este enfoque encontramos temas mínimos a mejorar (que voy a comentar en sucesivos posts, y cómo efectivamente los mejoramos) el resultado fue el siguiente:
1. Si un Fire aparece, se crea un Post-It de color anaranjado.
2. Se avisa a todo el resto del equipo que un nuevo Fire va a ser ingresado en el TaskBoard.
3. Se determina su prioridad con respecto al resto de las Tareas Planificadas existentes en el TaskBoard.
4. Se ingresa en la columna To-Do, sin StoryCard, representando verticalmente su prioridad (más alto, más prioritario).
En la práctica:
En blanco los StoryCards, en amarillo las Tareas Planificadas y en Naranja los Fires:
