Agile Delivery: Reducir el tiempo de entrega de valor

¿Qué podemos hacer para reducir el tiempo y mejorar la entrega de valor en nuestro producto? En torno a esta pregunta giró el meetup que impartió Ramón Molina, Agile Delivery Manager (ADM) en Codurance, en el que repasó algunos conceptos importantes a la hora de hacer delivery y ofreció herramientas útiles para entregar valor de forma rápida y eficaz. 

Empezó con la definición de Agile Delivery:

Es un enfoque iterativo para la entrega de software en el que los equipos involucrados crean software de forma incremental y validada por los stakeholders desde el principio de un proyecto. 

A continuación explicó que, para que el agile delivery tenga éxito, es necesario contar con la opinión de todo el equipo y de los stakeholders, de manera que todos los implicados puedan aportar su visión. Una parte esencial para permanecer alineados y motivados es la comunicación y el feedback: el continuo experimentar y la apertura a los cambios. Así evitamos arrastrar funcionalidades o malos diseños de las primeras fases y, en su lugar, iterar sobre algo que realmente tiene valor para todos. 

Piezas que hacen posible el Agile Delivery

A partir de su experiencia, el ADM nos ofreció valores o piezas clave que nos ayudan a implementar con éxito agile delivery: 

  • Colaboración

La colaboración abre la puerta a la mejora continua, ya que a través del intercambio de ideas se pueden identificar puntos débiles y áreas de acción. Es importante que esta colaboración tenga coherencia, es decir, que se base en un objetivo claro en el que sepamos cuál es nuestro papel. Al mismo tiempo, va de la mano de la confianza, tanto dentro del equipo como la que mostramos a los clientes. No es fácil de construir y requiere tiempo y apertura. 

  • Calidad de código

La velocidad de entrega no debe primar sobre la calidad. La calidad nunca debe sacrificarse por la excusa de que una entrega debe ser rápida. Para mantener la calidad del código sin perder agilidad, hay varias prácticas útiles que ayudan como: pair programming, code review, test planing y TDD.

  • Team mission

Es esencial tener clara la misión, el propósito y las responsabilidades del equipo durante todo el proyecto. También es importante contar con las capacidades necesarias para afrontar los problemas, y establecer los puntos fuertes y débiles del grupo. En definitiva, el equipo debe dejar un legado, es decir, el código que han creado, sus mejores prácticas o las relaciones que han construido; lo que permanecerá tras su disolución.

  • Wellbeing
Hay elementos básicos que permiten a todos los miembros de un equipo sentirse a gusto y centrarse en su desarrollo. Tener sus necesidades cubiertas significa, por ejemplo, un salario con el que se sientan cómodos y un horario de trabajo flexible para cumplir con sus obligaciones personales. También es conveniente alimentar la motivación del equipo con acciones como un career path, programas de formación, evaluaciones salariales y el reconocimiento de su trabajo.
  • Sesgos y mochilas

Cuando llegamos a un proyecto, traemos nuestros prejuicios o modus operandi que pueden no estar alineados con el nuevo equipo. En ocasiones, se produce una resistencia al cambio que puede bloquear y alargar el tiempo de entrega. Por eso, lo primero es entender que cada uno viene con sus propias ideas y que es necesario promover una conversación para llegar a acuerdos conjuntos sobre cómo va a funcionar el equipo y cuáles son sus valores. 

  • Enfoque en el cliente o producto

Cuando trabajas en un desarrollo o proyecto, lo haces en función de una necesidad por parte del cliente. Por eso, es importante que tus esfuerzos se centren en satisfacer esa necesidad o de lo contrario el proyecto estará mal encaminado. Hay que ser pragmáticos y buscar soluciones sencillas que respondan al éxito del producto. 

  • Planificación y priorización

Se habla mucho de la flexibilidad en las prácticas agile, pero eso no significa que no haya una planificación y un camino claro. Es importante trazar un plan con objetivos definidos que guíen hacia dónde va el proyecto.

  • People first

A veces hay que tomar decisiones difíciles pensando en la dinámica del equipo. Si una pieza no funciona, hay que intentar reconducirla para que el equipo no se vuelva disfuncional o se rompa. 

Herramientas

Pero, ¿cómo logramos todo lo anterior? Ramón nos presentó algunas herramientas para hacer frente a esas situaciones y que pueden ayudarnos a cumplir con buenas prácticas:

One to one - Sesiones individuales que proporcionan un entorno seguro en el que hablar de tus sensaciones en el equipo o impedimentos que afectan a tu trabajo diario. Nos permite saber el estado real del equipo y encontrar puntos de mejora.

Discovery - prototipo - planning - Son tres herramientas que para Ramón van de la mano porque muchas veces el cliente no sabe del todo lo que quiere, con lo cual primero se puede definir la necesidad, luego lanzar un prototipo sencillo que sea testable y después, a través del feedback real, evaluar y planificar. 

Performance review -  Evaluar el rendimiento e identificar puntos fuertes y las áreas de mejora. 

Feedback - El feedback es una excelente práctica siempre que sea asertivo, omnidireccional, directo y con ejemplos tangibles. No sólo con críticas negativas o positivas, sino con razones claras de lo que se comunica.

All hands - Una reunión periódica en la que se promueven los valores de la empresa, se replantea la estrategia y se discute el estado de la organización. Es un buen lugar para que la gente se sienta conectada a la compañía. 

¿Y cómo reducimos el tiempo para entregar valor? 

Agile_blog_image

Para concluir la presentación, Ramón explicó que, en última instancia, para mejorar la creación de valor, es necesario unificar el equipo, el producto y los stakeholders. Para que un equipo haga Agile Delivery, primero es necesario que tenga claro su propósito, que esté motivado y que busque la mejora continua. El producto debe tener expectativas definidas, ser desarrollado con calidad y requiere de una validación constante. Sobre este último punto, el ADM destacó que la validación continua marcaba la diferencia entre un proyecto waterfall y uno agile, ya que en el agile un proyecto no se presenta al cliente al cabo de 3 o 4 meses, sino a medida que va evolucionando. Por eso es muy importante que los stakeholders se sientan involucrados en el proceso de la toma de decisiones, para que las iteraciones de funcionalidades tengan un valor real para todos. Esta práctica de apertura aumentará la confianza en el equipo y fomentará un flujo constante de ideas. Si conseguimos alinear al equipo, el producto y los stakeholders, el desarrollo ganará en agilidad y se podrá reducir el tiempo de entrega.

Agradecemos la colaboración de Ramón y de la comunidad Agile Sur en esta entrega. Os dejamos un link a la presentación para que podáis repasar conceptos y si queréis ver la sesión completa os dejamos el vídeo a continuación:

 

Revisa también nuestra sesión sobre Pair Programming: sus fundamentos y aspectos claves.

 


New call-to-action