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...