Reflexiones como parte de la junta de Agile Spain

Después de más de dos años en la junta directiva de Agile Spain quiero compartir algunas reflexiones.

Estos dos años

Allá por julio de 2017 se abría el período para presentar candidaturas para renovar la junta de Agile Spain. En ese momento lo que me llevó a postularme fue más bien una preocupación que una ilusión. Preocupación por que no hayan candidatos y no se pudiera continuar con la asociación. También estaban las ganas de “devolverle” algo a la comunidad de la que tanto había aprendido (y sigo aprendiendo). Y un poco de ilusión por hacer cosas chulas, seguir potenciando Agile Spain para que no solo sea un elemento administrativo/legal en el cual los eventos se apoyan, sino que también aporte otros elementos que ayuden con el propósito de Agile Spain(podes ver los fines de la asociación en el link). Algo que creo que la junta anterior había empezado a fomentar con el encuentro de socios y las acciones de mejoras distribuidas (votación electrónica, dossier de la asociación, etc.).

Una vez formamos la nueva junta y nos pusimos a trabajar, todos compartíamos motivaciones comunes que iban más allá del trabajo administrativo necesario. Hicimos algunas cosas al inicio (acá podes ver un poco de resumen de lo que hicimos hasta hoy), pero no tardamos en darnos cuenta que las tareas periódicas administrativas nos consumían el mayor tiempo teníamos disponible. Además personalmente son tareas que no me motivan mucho, lo que hace que tiendas a dedicarle menos tiempo.

Dentro de estas tareas administrativas, hago un apartado diferente para las que se tratan de dar soporte a un evento. La verdad que saber que gracias a la asociación y a nuestro trabajo administrativo estamos ayudando a que unos 15 eventos/conferencias se lleven a cabo cada año en distintos puntos de España es gratificante (en 2019 ya hemos apoyado a 12 eventos). Si bien sigue siendo trabajo administrativo (llevar la contabilidad, hacer pago y facturas, revisar los presupuestos, hacer el cierre del evento, etc. ), esta bueno saber que gracias a eso hay eventos muy buenos donde nuestra industria comparte conocimiento, nuevos paradigmas, momentos para crear comunidad, etc. Ya solo por eso vale la pena que Agile Spain exista y que alguien tenga que hacer trabajo administrativo 🙂

Queda claro que un punto importante a trabajar para asegurar la sostenibilidad de Agile Spain es conseguir que el trabajo administrativo no consuma la mayor parte del tiempo de la junta directiva. Esto es algo que hemos empezado a trabajar en la junta actual, pero no llegamos a ejecutar por no estar seguros de la viabilidad económica de contratar a alguien para descargarnos de esa parte del trabajo.

Ideas de sostenibilidad

La semana pasada nos juntamos con Xavi Albaladejo a compartir ideas acerca de este tema, ya que a él como uno de los fundadores de Agile Spain también le preocupa la continuidad y sostenibilidad de la asociación. Acá les comparto una imagen y algunas notas de las ideas que pusimos en común.

Ideas de para bajar carga de trabajo administrativo

Pensando en por qué es necesaria la asociación a nivel práctico vimos que está la parte de tener una entidad fiscal para poder facturar, también hay cierta parte de responsabilidad civil y el conseguir comenzar un evento sin necesidad de liquidez de dinero previa, ya que esa liquidez la aporta Agile Spain.

En cuando al trabajo de la junta está la parte administrativa y la parte mas aspiracional de desarrollar más el propósito de la asociación. Y como comentamos antes lo primero deja poco espacio al lo segundo.

Las ideas que se nos ocurrieron para poder tercerizar este trabajo administrativo son:

  • Continuar con trabajo voluntario (no cambia nada a menos que la junta tenga más gente o una disponibilidad de tiempo alta).
  • Que las CAS sea la que asegure el presupuesto de pagar a la gestoría y el trabajo administrativo.
    • Puede ser mucha exigencia para la CAS dar un beneficio de unos 12k.
    • Necesidad de hacer CAS’s más modestas.
  • Que alguna empresa lo “subvencione” como parte de su programa de RSC.
  • Cobrarle a los eventos un monto mínimo para que dispongan de la infraestructura de Agile Spain .
  • Investigar como lo hacen en otras comunidades (Ágiles latam, Francia, Alemania…).
  • Tener “patrocinadores globales”. Empresas que pagan una cuota anual para patrocinar todos los eventos en los que la CAS participa. O que les da derecho a descuento sobre los precios de patrocinio en eventos.
  • Abrir el debate a la comunidad para explorar más ideas.

Hay futuro

Si bien me alegra que hayan candidatura/s para continuar, lo que no me alegra tanto es que estas candidaturas estén motivadas por el miedo a que desaparezca la asociación (y creo que hay algo de eso). Es un síntoma claro de que hay que trabajar para asegurar su sostenibilidad. Me da esperanzas ver que en la postulación de Xavier Quesada el primer punto va orientado a resolver el principal problema de la junta a día de hoy (y espero que las ideas de arriba puedan servir para buscar un modelo que funcione y sea sostenible).

Personalmente me gustaría tener fuerzas para seguir ayudando a resolver estos temas. Pero tengo que ser sincero conmigo mismo y con la comunidad y entender que si en estos dos años que tuvimos la oportunidad de cambiarlo no lo hicimos… hay que dejar paso y apoyar a los que vengan con energía.

Anuncios

¿Cuándo crear y refinar las User Stories?

Después de haber hablado del por qué, qué y cómo de las historias de usuario, ahora nos toca entender el cuándo. Para eso hay que entender el proceso de escribir las Historias de Usuario a lo largo de un desarrollo ágil. ¿Cuándo y cómo obtener la primer gran lista de Historias? ¿Hasta qué nivel de detalle conviene llegar? ¿Para todas hay que llegar al mismo detalle? ¿En qué momentos conviene trabajar en el refinamiento?

Por si no viste los puntos anteriores, estos son los posts anteriores:

  1. User Stories – Entendiéndolas para poder usarlas lo mejor posible
  2. Por qué las User Stories en un contexto ágil
  3. Qué son las User Stories
  4. ¿Cómo escribir User Stories?

¿Dónde está el backlog?

El primer objetivo a la hora de crear las historias de usuario es tener la lista inicial de nuestro backlog, que nos permita empezar a construir y además sabiendo que empezamos por donde más valor aportamos. Es muy fácil decirlo, pero no tanto conseguirlo. Tenemos que conseguir no perdernos en los detalles y a la vez intentar no dejar nada clave fuera.

Una de las técnicas que más me gusta para esto es el User Story Mapping , ya que este ejercicio inicial nos permite identificar las actividades que los usuarios necesitan para conseguir su objetivo y a partir de ellas podemos detallar que tareas harán los usuarios como parte de estas actividades. Incluso si lo combinamos con un Impact Mapping, podemos comenzar el ejercicio a partir de qué objetivo/s queremos conseguir con el producto y de ahí identificar sus actividades, tareas y User Stories asociadas (no voy a entrar en más detalle porque da para otro post, pero en este video la gente de Kleer explica de forma fácil qué es un story map y como construirlo).

Ahora que ya tenemos más claro el conjunto de historias que contendrá nuestro producto, tenemos que pensar en las prioridades, para saber por dónde empezaremos y así poder detallar más las  historias más prioritarias. Para esto el User Story Map también nos ayuda, ya que el eje vertical representa la prioridad de cada historia para una actividad o tarea del usuario. Por lo que podemos definir cuáles serán los posibles releases del producto. Si estamos en el inicio del producto, nos centraremos en conseguir el “walking skeleton” de nuestro producto en los primeros sprints, por lo que podemos empezar priorizando y refinando el conjunto de historias que nos ayudan a conseguirlo.

¿Cuántas necesitamos? ¿Cuánto detalle tienen que tener?

Ahora sí! Tenemos un backlog bastante completo y priorizado. ¿Puedo empezar a desarrollar mi primera historia? Hmmm… Creo que no está lista…

Ahora es el momento de dejar de trabajar con vista de pájaro y pasar al detalle. Ya hicimos un buen trabajo de inception, pero ahora necesitamos hacer el refinamiento antes de empezar con el primer sprint. Lo que haremos es detallar las primeras historias hasta que estén listas y tengamos suficiente trabajo para el primer sprint (si trabajamos con Scrum).  Algo que suele pasar al crear el User Story Map es que el tamaño de las historias varía mucho y algunas son más bien épicas y otras historias pequeñas. Para esto habrá que dividir las historias como ya hablamos en el post anterior. ¿Cómo escribir User Stories?

Si estamos empezando nos podemos centrar en el walking skeleton, ya que te ayudará a tener una solución end to end que incluso técnicamente te haga trabajar en los principales componentes. A partir de ahí ya iras trabajando en los releases que hayas podido identificar en el User Story Map.

La cantidad de historias que el PO y equipo quieran tener listas va a depender de muchas variables. Lo mejor es ir aprendiendo. Lo importante es entender que lo que buscamos es minimizar la cantidad de trabajo que tenemos adelantado en el backlog, para reducir la posibilidad de desperdiciar tiempo de trabajo y tener la mayor flexibilidad que nos permita adaptarnos a posibles cambios, pero a su vez que el equipo no se quede sin historias lo suficientemente listas para comenzar a trabajar. Este es uno de los aspectos que el PO y el equipo tienen que ir trabajando juntos para encontrar su nivel adecuado.

El detalle que necesitamos en el backlog varía según la prioridad de las historias. Para las historias que se trabajarán en los próximos días o iteraciones  vamos a querer tener las historias listas (DoR), con toda la información que el equipo necesita para comenzar a desarrollarla. Para el resto el detalle ira disminuyendo. Algo importante a mencionar, es que mientras más extenso sea el DoR, antes necesitaras ponerte a refinar y detallar cada historia (en este post comento más en profundidad esto).

Algunas de las variables que pueden influir en cuando refinar las historias son:

  • Prioridad
  • Tamaño
  • Velocidad o burnRate
  • Cantidad de trabajo necesario para conseguir el DoR
  • Variabilidad de los requerimientos (qué tanto cambian y con qué frecuencia)
  • Dependencias en el refinamiento

¿Y cuándo es el momento de hacer todo esto?

El refinamiento es una actividad que se hace constantemente. Es el proceso de gestionar el backlog teniendo en cuenta todas las variables mencionadas (y más). Pero si bien esto es así y generalmente hay una persona responsable de que esto suceda (el Product Owner en Scrum), cómo el backlog es una herramienta más de comunicación entre producto y desarrollo, es importante que haya colaboración a la hora de refinar las historias. Es por esto que en Scrum es una  práctica común el hacer una reunión de refinamiento entre PO y equipo de desarrollo. Sirve para que el equipo no tenga que ser interrumpido constantemente durante el sprint, y para asegurar que el backlog y las historias son entendidas por todos. También es buena práctica hacer un taller de escritura de historias (“User Story writing workshop” para googlearlo 🙂 ) con cierta periodicidad, que nos permita ir extendiendo el backlog a medida que el producto evoluciona.

Lo importante de estas reuniones es entender que lo que buscamos es mantener un backlog con salud (que cumpla con las características DEEP: detailed appropriately, emergent, estimated, and prioritised).

Las actividades que se suelen hacer en estas reuniones son:

  •  Escribir nuevas User Stories
  • Dividir User Stories muy grandes en más pequeñas
  • Mejorar aquellas que no estén bien escritas o definidas
  • Estimar los nuevo ítems del backlog
  • Agregar criterios de aceptación
  • Mirar “en profundidad” para tener una idea a más largo plazo de lo que vendrá y sus implicaciones técnicas.
  • Etc.

El mayor desafío es encontrar el ritmo adecuado de trabajo que nos asegure no tener mucho desperdicio (trabajo hecho sobre el backlog que está en espera) y por otro lado que el equipo siempre tenga trabajo listo para empezar en caso de necesitar más. Es la comida que le llega al equipo, que tiene que haber suficiente, pero también tiene que llegarle fresca!

 

Aprendizajes de mí charla de la CAS 2017

En la pasada CAS, el 9 y 10 de noviembre en Sevilla, tuve la suerte de poder presentar una charla que me hacía mucha ilusión y qué por el feedback recibido creo que es un tema que es de gran ayuda para muchas personas que están empezando a andar o lleva no mucho tiempo en los zapatos de un Scrum Master. Me gustaría compartirles lo que aprendí de la charla y el reto que tengo ahora para que no se quede solo en una anécdota…

Guía de auto-crecimiento del Scrum Master

Antes que nada hago un pequeño resumen de mi charla para poner en contexto el resto del post.

Mi propuesta es hacer un trabajo de crecimiento profesional consciente (algo que no solemos hacer), que nos ayude a crecer más rápido, estar seguros que vamos en la dirección hacia la que queremos llegar y, sobre todo, que disfrutemos de ese camino. Ya que el ser un gran Scrum Master es un proceso, un recorrido… y no un estado en sí mismo. Sigue leyendo

Cómo viví la CAS 2017

 

Un año más he podido disfrutar de la Conferencia Agile Spain, que este año tocó en Sevilla. La CAS es el evento referencia a nivel España en el que sabes que vas a poder ver a la gente más potente a nivel nacional (y con alguna presencia internacional) y por eso siempre vale mucho la pena ir. Sobre todo para hacer comunidad y disfrutar de las personas que formamos este pequeño mundo de la agilidad.

Aquí les comparto mi experiencia sobre la conferencia en general y les dejo un mini-resumen de las charlas que más me gustaron.

Conferencia

Antes que nada quiero agradecer a la organización por haber logrado que un año mas disfrutemos de nuestra querida CAS!

Ubicación: el Fibes fue un gran acierto, salas muy amplias, espacios grandes ideales para hacer sociales, buena calidad de sonido y un auditorio imponente! Lo único a mejorar fue la comida… muy poca comida, por lo menos por donde yo estuve y la variedad muy mejorable entre un día y el otro y también para personas que no comemos carne y/o lácteos  Sigue leyendo

Retrospectiva XXL en tiempo XXS en el primer Agile & DevOps Day de GFT

Hace un poco más de un año en la CAS 2015, cenando con el equipo de GFT se nos ocurrió que para el 2016 teníamos que hacer un evento similar internamente… hoy ese evento ya es realidad, lo hicimos y fue todo un éxito.

Apenas empezamos a pensar en cómo sería el evento tuvimos claro que al final haríamos una retrospectiva y fui el elegido para facilitarla.

Así que me puse a leer un poco de cómo hacer una retro grande, leí varios posts y obviamente llegué a los de Thomas Wallet donde explica varias experiencias de retros XXL. Después supe que Thomas iba a venir a España e iba a dar un taller de Retrospectivas XXL en la CAS, así que ese fue el primer slot de la conferencia que tuve claro que iba a ir. ¡Qué mejor que hacer el taller y poner en práctica lo aprendido solo tres semanas después!

Resumen de las actividades

¡Estas son todas las actividades que hicimos en unos 40 minutos con 70 personas! Sigue leyendo

Agile y los sistemas complejos

La principal base “teorica” sobre la que Agile funciona está en entender al desarrollo de un producto como un sistema complejo y en cómo gestionar dicha complejidad.

Para un trabajo de un máster estuve re-leyendo un poco sobre el tema y se me ocurrió aprovecharlo para compartir un mini resumen de algunos de los principios más importantes para gestionar la complejidad y como se aplican en el desarrollo ágil de un producto.

Método empírico vs predictivo: en un sistema complejo es muy difícil (o casi imposible) poder predecir lo que sucederá, por lo que la mejor forma de controlar el sistema es aprendiendo de las acciones tomadas. El framework Cynefin es un modelo que describe cómo actuar y tomar decisiones dependiendo de la complejidad de las situaciones. Y para las situaciones complejas propone encontrar soluciones emergentes basadas en la prueba y aprendizaje empírico. Sigue leyendo

Mi primera CAS como ponente

 

 

Este año la CAS para mí tuvo un sabor especial ya que fue la primera que asistí como ponente a una conferencia. Y la verdad me gustó mucho, así que creo que me voy a animar más seguido!

Antes de la conferencia no me había parado a pensar qué diferencias podía haber en participar como ponente, pero la verdad es que se vive un poco distinta. Quieras o no pasas a ser un actor más activo dentro de la conferencia. La gente te pregunta cuando es tu charla, se interesan por saber de qué va a ser y gracias a eso se abren charlas interesantes que quizás no hubieran sucedido si hubiese ido como asistente. También hay un factor nervios o tensión que está ahí presente y va apareciendo y desapareciendo hasta que se expresa al máximo en el momento previo a la charla y disminuye (o por lo menos en mi caso) con la ejecución del taller o charla donde dejas todo (o por lo menos así creo que lo hicimos con @silviacalvet 🙂 ). Al terminar viene la liberación total y la satisfacción (y más si recibís un feedback tan bueno de los asistentes como fue en nuestro caso!). A partir de ese momento para mí la conferencia tomó un tono distinto, quizás más relajado, con la satisfacción del trabajo bien hecho y las ganas de seguir disfrutando. Sigue leyendo