100 días en Agile (III)

El Tablero
     ¿Para qué leches quiero yo un tablero lleno de post-it? Esto fue lo primero que pensamos en el equipo, y como somos unos kamikaze empezamos sin tablero. Total ya teníamos JIRA, como excusa nos venía al pelo, cuando lo cierto es que nos daba algo de vergüenza saber que íbamos a estar de paseos con el tablero de un lado a otro.
     El primer día que el Product Owner (o sea yo) se empeñó en montar el tablero, y empezar a usarlo, nos dimos cuenta de la potencia del mismo. Y el primer comentario fue: "Madre de dios, nos hemos pasado planificando". Nuestra columna de "To Do" estaba cubierta de arriba a abajo de post-it con tareas técnicas, y ya llevábamos medio Sprint consumido.

    Es cierto que las herramientas como JIRA ayudan a tener controlado todo el proyecto, poder ir haciendo seguimiento de los cambios, generar un Burn Down del Sprint, sacar algún informe o gráfico, pero no tiene la presencia visual del Tablero. Quizás no sepas de que va el proyecto, pero cualquiera se pone delante de un Tablero donde esté planificado el Sprint, y tienes claro la cantidad de trabajo pendiente, en curso, y realizado de un solo vistazo.
     Por medio de post-it más pequeños con los nombres de cada persona del equipo Scrum puedes saber quién está con cada tarea y se puede controlar, de una forma muy simple, cuantas tareas puede tener asignada una persona a la vez. Para realizar las Dayli es fundamental, en seguida se ve y actualiza el trabajo realizado cada día, lo que queda pendiente, si hay impedimentos que paren o bloqueen una tarea, y muchas más cosas que no fuimos conscientes hasta que empezamos a usarlo.
     Lo malo es que ahora los bandarras de nuestro equipo no me actualizan el estado en JIRA...
     Aparte de la visión del Sprint, se puede utilizar para tener información adicional a mano. En nuestro caso para las dependencias con terceros que aún tenemos pendientes, y acciones que hayan salido de la Retro, principalmente. También tenemos el DoR y el DoD, pero la verdad que no le hacemos ni caso a esos 2 post-it (voy a arder en la hoguera para sacrílegos de Agile por esta frase).
     Esta es una foto de nuestro tablero tras finalizar un Sprint del primer Program Increment:

     En uno de los Item Backlog tuvimos un montón de trabajo extra y se nos acumularon un poco. La teoría del equipo (con 1 voto en contra) es que el experto en Google Analitics cobra por post-it y ese Sprint comió caviar iraní todos los días.

     Por la parte la otra cara del Tablero tenemos el Product Backlog no planificado, y el Sprint Backlog previsto para cada Sprint tras la última Planificación de PI:

     Incluso los colores de los post-it tienen un significado:

• Verde: Epics del Proyecto
• Azul: User Story o Product Item Backlog. Llevan además el número de la Epic a la que pertecen (abajo izquieda) y la estimación (abajo derecha).
• Fusia: US o PIB a refinar y dividir en otras más pequeñas.
• Naranja: Dependencias con terceros que afectan a US de la Epic
• Amarillas: Tareas técnicas de cada US o PIB.

     En resumen, el Tablero es una de las mejores herramientas para hacer Agile, que se  complementa perfectamente con aplicaciones de seguimiento y gestión.

100 días en Agile (II)

Intensa y Exigente
     Decía, en la entrada anterior, que Agile es intensa y exigente. Llevo cerca de 3 años en este puesto de trabajo (sin Agile), y he participado en proyectos que se consideraban críticos y con una gran presión. Y sin embargo, nunca he necesitado estar al 100% para desarrollar mi trabajo y sacarlos adelante.
     En estos 100 días en Agile como Product Owner (PO), no he parado. Cada Sprint, es justamente eso, un sprint de 2 semanas. Comienzan los miércoles y finalizan los martes dos semanas después, y tienen:

• Todos los días: Daily de 15m, a las 9:45h.
• Cada 2-3 días: revisamos el Scrum Master (SM) y yo: impedimentos, dependencias que aún tenemos que resolver, información nueva o actualizada que tengamos referente al proyecto, y cambios que hayan surgido por el camino.
• Cada 2 semanas los viernes: Comunidad de Product Owner, 1:30h.
• Día 1: Planificación del Sprint, unas 2h de media.
• Día 7: Refinamiento del Backlog, de 1:30h a 2:30h.
• Día 14: Sprint Review, de 30m a 1h
• Día 14: Retro del Sprint, de 1h a 1:30h.

     Además cada sesión hay que prepararla, si no es tiempo desaprovechado. 

     Cuando no hay una sesión planeada, como PO hay que ocupar el tiempo en averiguar que quieren y esperan los stakeholder (SH), entregar producto finalizado en cada Sprint y obtener feedback, recoger las nuevas necesidades de los SH, incluirlas en el Backlog priorizadas y explicadas, mantener actualizado JIRA (herramienta de seguimiento que utilizamos para proyectos Agile), perseguir al equipo Scrum para que lo actualice.

     Sesiones y charlas con los Coach: para aprender, para saber si estás aplicando bien Agile, para pedir apoyo, para el proceso de control de la ira, para que se enteren de verdad de que ocurre en esta "santa casa"...

     El equipo Scrum no va mucho mejor. Cierto es que estamos siendo optimistas en la planificación de los Sprints, y queremos hacer más de lo que realmente podemos, como consecuencia siempre van con la lengua fuera y justitos, justitos. Algún Sprint Review, vemos cosas que se han acabado una hora antes. 

    De todas formas, incluso planificando menos por Sprint, hay que hacer todo el trabajo que implica un desarrollo de software en 2 semanas: analizar, diseñar, codificar, probar, documentar, cambios de última hora, puesta en entornos de prueba y producción, cumplir con la metodología del banco, hablar con terceros, etc... Y tienen las mismas sesiones que yo durante el Sprint, cambiando la comunidad de PO, por la suya de desarrolladores o SMs.

    ¿Dan las 2 semanas para esto? Si, dar lo que se dice dar, dan. Pero lo cierto es, que no paramos. Yo sólo los viernes de 2 a 3, me permito el lujo de relajarme y monear.

    Agile exige mucho de ti, del equipo, de todo el que de una forma u otra esté involucrado. Si alguien baja la guardia o el ritmo, el Sprint se resiente, a corto-medio plazo lo hará también la cantidad de producto entregado, y por lo tanto no se cumplirán los compromisos adquiridos con los SH.

    Como recompensa a esa intensidad, exigencia y compromiso, entregamos producto viable y funcionando cada 2 semanas. A veces gusta más, a veces menos, a veces la DEMO falla, pero hace que siempre tengas sensación de avance.

    Personalmente me encanta y da esperanzas, y estoy viendo que lo mejor de las personas y los equipos sale cuando hay intensidad, cuando hay exigencia, y van unidos a la cooperación y la confianza. Y es Agile quién está provocando que se trabaje de esa forma.
    También entiendo que ahora mismo estamos en pleno aprendizaje, y según vayamos cogiendo experiencia, todo irá más rápido y fluido.
    Y bueno, si hay algo que me asusta un poco. Tengo la sensación de estar aplicando algo menos del 50% de Agile. Cuando lo hagamos al 100%, va a ser mucho más divertido, y, espero, un reto mayor...

100 días en Agile (I)

De Waterfall a Agile
     En la entidad financiera que en estos momentos dispone de mis servicios, estamos en un proceso de transformación de metodología de trabajo, para la construcción de software. Estamos cambiando de "Waterfall" (sigo sin entender el por qué de este nombre) a Agile con SAFe y Scrum. Ahí es ná...
     No quiero entrar en cual es mejor o peor, cada una es aplicable en un momento y proyecto determinados, sólo voy a decir que son diametralmente opuestas en cuanto a filosofía y cultura en la forma de trabajar.

    Nuestro (iba a poner mi, pero ya entenderéis por que no) equipo Scrum lleva alrededor de 100 días trabajando en Agile-Scrum, adaptándonos a y aprendiendo este nuevo estilo de trabajo. Algo más si contamos el primer mes y medio de arranque en el que "hicimos Agile". Y creo que, igual que a los gobiernos, es el momento de hacer un pequeño balance y sacar algunas conclusiones.

¿Qué me está pareciendo Agile?
     En 2 palabras: me entusiasma.

     Sin dejar de tener claro que no deja de ser una metodología más, con sus pros y contras, para alguien que se ha pasado casi 20 años haciendo proyectos de software con un método y formas de trabajar que sabes que no funcionan bien y que tiene deficiencias, y que ya sea por desidia, desconocimiento, impedimentos, o cualquier otro motivo, tienes que seguir aplicando una y otra vez, intentando no repetir los mismos errores, o al menos que sean diferentes en cada proyecto, supone una corriente de aire fresco muy muy esperada y necesitada.

     ¿Es la panacea? ¿Idílica? ¿Utópica? No, por supuesto. Si fuera perfecta, sería aburrida. Pero es intensa, exigente, orientada al cliente, y comprometedora. Cuando se aplica tal y como está definida, sin hacer híbridos que nos llevarán a la frustración, da grandes resultados.

100 días

     No es nada fácil hacer Agile. Cuanto más voy conociendo de esta metodología, más claro lo tengo. Sobre todo por el cambio cultural tan brutal que implica, y ahora empiezo a entender porque puede costar años su aplicación completa en una gran empresa.

     ¿Cuales son los pilares de Agile? Desde mi corta experiencia son 4:

• Autogestión
• Responsabilidad
• Cooperación
• Confianza

      La importancia de todas ellas es la misma. Alguno dirá "Pues vaya, como en cualquier trabajo en equipo". Si, pero no. Puedes trabajar con el sistema actual o cualquier otro sistema basado en Cadenas de Mando, pero si quieres hacer Agile en tu empresa, ve concienciándote que sin estas 4 palabras, vas a fracasar.

     En una de las daily uno de los desarrolladores hizo este comentario: "A ver no me volváis loco, que si tengo que hacer todo eso a la vez no termino ninguna", y me di cuenta de algo muy importante, nos hemos habituado a esperar a que alguien nos mande. Estamos acostumbrados a trabajar en una cultura de Cadena de Mando, donde el escalón superior va ordenando al siguiente qué debe hacer, e incluso quién y/o cómo debe hacerlo, dando un margen de libertad de decisión al siguiente escalón, más o menos amplio.

     Agile nos pide una Cadena de Responsabilidades, parece igual pero no es lo mismo. La relación entre los diferentes niveles es de Confianza en la Autogestión del trabajo que se es Responsable, y todos juntos Cooperando conseguirán el objetivo común: construir el Producto final con la mayor calidad. El éxito o el fracaso, es Responsabilidad de todos.

     ¿Qué bonito verdad? ¿Quién no está pensando en una comuna hippie? 

     Volviendo a nuestro desarrollador. Queremos que él mismo se gestione su trabajo. Hay una serie de tareas que realizar durante el Sprint, tú decides sobre cual vas a trabajar, tratando de seguir las prioridades establecidas, y cuando la acabes coges otra.  Es decir, le estábamos pidiendo que se responsabilizara de gestionar su tiempo, se autogestionara.
     Esto mismo se va llevando a cada nivel:

• El equipo Scrum es responsable de cumplir con los objetivos a los que se ha comprometido en la planificación del Sprint: se realizó siguiendo las prioridades marcadas por el PO, y negociando con él qué se podía incluir y finalizar en el Spint.
• El Scrum Master (SM) es responsable de facilitar las sesiones de Scrum (dayli, planificaciones, retrospectiva, ...), ayudar a quitar los impedimentos que encuentre el equipo Scrum, y guiar al equipo hacia la autogestión.
• El PO es responsable de conocer perfectamente el Producto a construir, de negociar con los Stakeholder las prioridades del Producto, de explicar al equipo Scrum el Producto a construir, que el Backlog de Producto esté priorizado y bien definido, de colaborar con el equipo Scrum para planificar, revisar y detallar cada Sprint de forma que lo construido aporte valor al Producto final.

     Cada uno es responsable de su parte y de cooperar con el resto del equipo de proyecto (PO, SM, equipo Scrum) para lograr el objetivo común de construir el Producto esperado por el Stakeholder.

     Y esto sólo funcionará si cada uno de los componentes confía en los demás.

     Nadie "ordena" que hay que hacer, se establecen necesidades y prioridades.

     Cada uno se responsabiliza de su trabajo y entre todos se controla que se está haciendo.

     No hay una figura que marque ni un cuánto ni un cuándo, se negocia y colabora para hacer lo máximo en cada Sprint.

     Se me ha hecho largo, seguiré otro día. Ahí os dejo la semilla del cambio cultural propuesto por Agile...