• Smoking Brains

Prácticas Agile cuando la presión sube

Actualizado: 2 de may de 2019

Ya sabemos que las prácticas ágiles nos pueden ayudar mucho en nuestro trabajo... cuando tenemos tiempo de aplicarlas. Pero cuando la presión sube, es otra historia. Y en cualquier negocio, la presión para entregar puede cambiar mucho según el contexto o las demandas de los clientes.


La presión aumenta por ejemplo cuando:


  • El volumen  de trabajo aumenta con la llegada de nuevos clientes

  • Tenemos que entregar un proyecto grande, la deadline se acerca y nos estamos topando con problema imprevisto tras problema imprevisto que nos provoca trabajo adicional

  • Uno de nuestros mayores clientes amenaza con no renovar su contrato si no implementamos algunas mejoras específicas


En esos casos, el nivel de estrés dentro del equipo y de la organización aumenta. Vemos nuestro backlog de trabajo crecer cada vez más y el tiempo que tenemos para entregarlo va cada vez es menor. Los clientes o stakeholders representando el negocio nos trasladan más presión, y a pesar de nuestras dudas sobre las posibilidades reales, nos comprometernos a más. Muchas veces, no llegamos a entregar todo lo prometido...

Y poco a poco, estas prácticas ágiles de las que estábamos tan orgullosos parecen estarnos frenando. Nos empezamos a hacer preguntas sobre la metodología.


¿Para qué hacer retrospectivas si no tenemos tiempo de implementar nuevos cambios en este momento? ¿Para qué perder tiempo con las reuniones de planning si el scope cambia de todos modos y tenemos más trabajo de lo que podemos hacer?¿Para qué hacer pair programming y compartir conocimiento en el equipo si cada uno ya está sobrepasado con sus propias tareas?¿Para qué perder tiempo en hacer entregas incrementales de funcionalidades completas y colaborar para desplegar cada funcionalidad por separado cuando mejor nos enfocamos cada uno en su tarea y ya lo integraremos todo al final cuando esté todo listo?


A corto plazo puede parecer que saltándonos esas prácticas estamos ganando un poco de ese tiempo que tanto necesitamos para ir más rápido, pero a la larga esto tiene un precio cumulativo importante.


Las retrospectivas

“If you are not getting better, you are getting worse”

Muchas veces, vemos la retrospectiva como algo opcional, algo que quizás nos aporte algo positivo en el futuro, pero también tiene un efecto muy inmediato que es de ver lo que nos frena ahora mismo y nos impide ser más eficaces. Al saltarnos las retrospectivas, perdemos este mecanismo de control de nuestro día a día y empezamos a acumular malos hábitos que a la larga nos hacen perder más tiempo que la retrospectiva en sí.


Estimación y Planning

Cuando estamos bajo presión para entregar, parece que esas reuniones no nos aportan bastante beneficio como para invertir tiempo en ellas, pero son clave para poder mantener una visión más real de lo que podemos entregar y lo que no.

Aunque el cliente o el negocio siempre nos pedirán que lo entreguemos TODO, unas estimaciones y planificaciones de calidad nos permitirán a la vez de gestionar las expectativas mejor, negociar plazos y scope, y más importante aún, entregar un mejor producto al final ya que nos permitirá trabajar con mucha más calidad.


Pair programming y compartir conocimiento

Es verdad que esas prácticas no nos aportan una ventaja inmediata, pero si no mantenemos esas prácticas, a largo plazo nos vamos a encontrar en situaciones donde estamos bloqueados o perdemos tiempo porque algún conocimiento o competencia que podríamos haber compartido no está presente o bastante difundida en el equipo.


Entrega incremental de funcionalidades completas

Por último, es muy tentador de cortar el proceso de entrega en etapas que nos permiten enfocarnos sólo en un tipo de tarea y así tener cada persona del equipo siempre “produciendo” lo que hace mejor: por ejemplo dedicarnos sólo el desarrollo de toda una parte grande de producto y dejar el testing y la integración de todo para el final…

Pero en este caso también, aún que parezca que estamos ganando en eficacia en el momento de desarrollar, ya que parece que ejecutamos todas nuestras tareas mucho más rápidamente, vamos a pagar un alto precio más tarde.

A veces será un precio muy obvio, tal como problemas importantes al momento de integrar los diferentes elementos.

Otras veces, será un precio casi invisible en forma de tiempos muertos perdidos cuando una tarea pasa de un equipo a otro, o en pérdida de control sobre la calidad de lo que estamos desarrollando ya que ni siquiera podremos tener trazabilidad de donde salen todos los problemas ni de donde estamos realmente perdiendo tiempo en el proceso.


Todo eso no quiere decir que nos vamos a atrincherar en nuestra posición y seguir siempre todas las prácticas a la letra independientemente del contexto, pero tenemos que buscar una manera de retener los beneficios de esas prácticas aún en los periodos de alta presión.


Veamos algunos ejemplos de cómo podemos mantener la metodología adaptada a las necesidades propias de tiempos de presión:


  • Podemos hacer retrospectivas más cortas y mucho más enfocadas en temas específicos lo más relevantes posibles a la situación actual.

  • Pensemos en hacer un seguimiento regular al final de cada Sprint para tener una idea precisa de cómo fluctúa nuestra velocidad.

  • Quizá podemos limitar el tiempo de pair programming y enfocarlo siempre a los temas que más riesgo suponen para el proyecto

  • Otra posibilidad es experimentar con agrupar algunas tareas midiendo el tiempo total de entrega para ver con números reales lo que nos permite entregar un máximo de valor lo más rápidamente posible


Te animamos a que, antes de tomar la decisión de prescindir de estas prácticas, pienses que todas tienen una razón de ser, y antes de desechar alguna considera si puedes ajustarlas y sobre todo que si prescindes de ellas quizá a la larga pagues un precio por ello que quizá no compensa.




Barcelona © 2015 - 2019