archivo

Archivo de la etiqueta: retrospectiva

No se trata solo de tirar hacia adelante sino de hacerlo con intención buscando la mejor solución disponible en cada momento y eliminando resistencias que nos impiden progresar como debiéramos.

El día a día nos limita la perspectiva, solo nos deja ver los problemas que nos afectan en ese momento que, pudiendo ser importantes, pueden tener su origen en otras circunstancias que siguen vigentes tras su resolución.

La retrospectiva con su análisis de lo que hemos hecho, de dónde estamos y de en qué podemos mejorar nos permite recuperar la perspectiva, atacar a la raíz de los problemas y detectar desviaciones y riesgos que no tenemos presentes.

La retrospectiva no debe hacerse solo cuando parezca que la cosa no marcha sino que debe hacerse de manera periódica porque siempre es posible mejorar y porque no siempre van las cosas como parecen. Y siempre dispuestos a escuchar y a la autocrítica.

Una de las claves para sacar adelante cualquier trabajo (y un proyecto no es más que un tipo de trabajo más), con su complejidad y sus características inherentes, es dividirlo en una serie de tareas que sean manejables: divide y vencerás.

El enfoque clásico o predictivo supuso el primer avance en ese sentido, si bien lo que hizo fue darle formalidad a lo que carecía de ella porque la división en tareas más simples en el desarrollo de software existe desde sus mismos inicios.

Esa división en procesos, actividades y tareas la podemos ver en Métrica v3, en versiones anteriores, en cualquier otra metodología basada en enfoques clásicos o en las propias definiciones genéricas de esa estrategia.

El inconveniente que se plantea es que divide en partes las actividades pero no el producto. Sobre esa aproximación inicial surgieron nuevas estrategias que tenían como objetivo descomponer el producto en partes y sobre cada una de ellas realizar una división de las actividades. Esto dio lugar a enfoques de tipo teórico como los desarrollos en espiral o más tangibles como los desarrollos iterativos incrementales.

Con este tipo de estrategias se puso en primer plano los conceptos de feedback y retrospectiva: conocimiento adquirido como consecuencia de la experiencia sobre versiones reales del producto (ya sea en producción o no) y la mejora continua de las prácticas y enfoque del proyecto.

El siguiente paso fue hacer que la descomposición del producto fuera en trozos más pequeños definiéndose para ello sprints de duración fija o variable pero que en cualquier caso iban a ser de corta duración. En este contexto el feedback y la retrospectiva ganan en intensidad, se realizan cada poco tiempo y el producto está preparado para adaptarse al cambio.

En esta evolución se ha pasado de la especificación del producto a su visión: se tiene una colección de tareas a realizar que se va modificando conforme avanza el proyecto y solo se estudian en detalle cuando se está preparando la siguiente iteración.

Un aspecto que me parece muy interesante para ser analizado en las retrospectivas son las contingencias o incidencias que se han producido en la última iteración o que se están produciendo de un tiempo a esta parte en el proyecto y que han tenido un impacto significativo en él, de tal forma que han puesto en riesgo o directamente han impedido que se alcancen los objetivos marcados hasta la fecha (a nivel de sprint o a más alto nivel).

Dentro de ese análisis me parece fundamental hacer autocrítica sobre esas incidencias y determinar para cada una de ellas si se han podido prever o no. No se trata de hacer un juicio sumarísimo sobre quien o quiénes se hayan podido equivocar sino de tratar de poner medidas para reducir el riesgo de que este tipo de situaciones se vuelvan a repetir en el futuro porque lo que es evidente es que si no se hace nada, otros problemas similares a estos o incluso estos mismos volverán a producirse.

En ese análisis nos daremos cuenta que en la mayoría de los casos se podría haber previsto el problema, es duro pero hay que asimilarlo, insisto, si no se asumen los errores es imposible mejorar.

Dentro de los previstos habría que diferenciar los casos en los que siendo previsibles no han podido serlo debido a que la carga de trabajo era excesiva o a que la atención estaba centrada en otros aspectos como consecuencia de prioridades marcadas desde más arriba, ya que el problema en estos casos no es de una falta de atención, previsión, despiste, exceso de confianza, falta de conocimiento o negligencia y las actuaciones a realizar para tratar de evitarlos en un futuro son distintas.

Sea cual sea el enfoque, estrategia o metodología que apliques en un proyecto, van a aparecer riesgos o problemas que pueden afectar en mayor o menor medida al proyecto y al cumplimiento de los compromisos y expectativas y que no deberíamos ignorar, en unos casos porque su materialización puede poner todo patas arriba y en otros porque una vez materializados suponen una resistencia importante en el propio proceso de desarrollo.

La gestión de riesgos en los enfoques ágiles está implícita en la propia dinámica de trabajo y en las prácticas que se vienen a aplicar. Esto no quiere decir que sea menos importante o que se le dedique menor atención, solo que ya se entiende, de base, que es necesario trabajar en ello.

Es importante tener en cuenta que se presta principal atención a los impedimentos o resistencias que son contingencias u obstáculos que bloquean o afectan a la velocidad real del equipo, lo cual no quiere decir que se ignoren riesgos a más alto nivel.

En un enfoque ágil de desarrollo se debe tratar que los problemas, resistencias y errores salgan a la luz lo antes posible porque se entiende que cuanto más cerca de su origen se aplique de manera efectiva cada solución, menos daño provocará al proyecto al ser menor su impacto en el producto y en las personas (si no se hace por eliminar o paliar determinadas resistencias, afectará al ánimo y moral de las mismas, agudizando el efecto que sobre la productividad provocan esos impedimentos) y, por tanto, menor el esfuerzo que se necesitaría para volver de nuevo a una situación de equilibrio.

Un ejemplo de ello lo tenemos en las reuniones diarias o Daily Scrum en las que cada participante, además de indicar lo que hizo la jornada anterior y lo que pretende realizar en esta, comenta qué impedimientos, obstáculos, resistencias o problemas se están encontrando en la realización de sus tareas. Se habla de ello para poner estas contingencias encima de la mesa con el objeto de que se le proporcione una solución que lo mismo puede ser inmediata o requiere de tareas (o incluso sprints específicos) para abordarlas.

No olvidemos que la comunicación entre las personas ni empieza ni termina con el Daily Scrum, por lo que aplicando los principios de transparencia que deben regir en un proyecto ágil, en cualquier momento se puede y se debe levantar la mano para comunicar un riesgo o un problema que puede afectar al desarrollo.

En cualquier caso, tenemos otro punto de sincronización en las retrospectivas, en las que se analiza en qué aspectos se puede mejorar y cómo y qué resultado están dando las medidas aplicadas hasta ahora para tratar otros puntos de mejora detectados en sprints anteriores. Este es otro punto donde se puede y se deben discutir sobre todo aquello que afecte a lo que sería un normal desarrollo del proyecto.

Estas resistencias, se pueden inventariar en una pila de impedimentos o Impediment Backlog con el objetivo de hacerlas visibles y poder hacer un seguimiento de las mismas.

¿Por qué hacer retrospectivas? A veces es necesario pararse a analizar si las decisiones, estrategias y comportamientos que se han adoptado están produciendo los resultados esperados, así como para analizar qué problemáticas y riesgos tenemos en el proyecto con el objeto de establecer una serie de medidas que permitan la mejora continua.

La vorágine de los proyectos nos llevan a tener un ritmo frenético de manera que, a veces, pararnos a analizar qué está pasando, nos puede hacer pensar que estamos perdiendo el tiempo, cuando justamente es al contrario porque la pérdida de tiempo, de esfuerzo y de dinero se produce precisamente por continuar políticas, estrategias o prácticas que no producen buenos resultados.

Se trata por tanto de adquirir conocimiento a través de la experiencia y con la objetividad (y subjetividad) de los resultados que estamos obteniendo. Una idea que teóricamente es muy buena en la práctica no tiene por qué proporcionar los resultados esperados en el contexto en el que estamos trabajando y a partir de ahí, si tenemos capacidad de autocrítica y de asumir nuestros errores, llegaremos a varias conclusiones interesantes: tener siempre en cuenta el contexto a la hora de tomar una decisión y de adoptar una determinada estrategia, que la idea en cuestión puede seguir siendo válida pero no resulta adecuada en estos momentos en el proyecto (y puede que también en otros proyectos con unas variables parecidas al nuestro) y, que por tanto, es necesario buscar otras soluciones.

Decía Heráclito que: “Nada es permanente a excepción del cambio”.

Tenlo siempre presente en los proyectos de desarrollo de software, de ahí la necesidad de ir realizando ajustes y evaluarlos en base a una evolución (los últimos trabajos o sprints realizados) que viene a ser lo que seria la retrospectiva. Ésta tiene como referencia las personas y el proyecto.

La adaptación al cambio no solo se debe realizar mirando para atrás, sino también debe considerar el presente y lo próximo que nos vamos a encontrar (lo que podemos analizar más objetivamente), la perspectiva y lo que puede suceder más adelante, las prospectiva.

En los proyectos es muy frecuente encontrarnos con que se obvia la retrospectiva confiando en que el método por sí solo, sin tener en cuenta la efectividad que está proporcionando, será uno de los instrumentos (el principal) que permitirá conseguir unos resultados satisfactorio.

Pero lo más curioso es encontrarnos también con que se obvia la perspectiva, lo que está pasando. Esto es así porque no se quiere hacer el esfuerzo de levantar la cabeza y ver lo que está sucediendo. Es cierto que el conocimiento y la experiencia permiten detectar riesgos en situaciones no tan evidentes pero también lo es que resulta mucho más complicado hacerlo si no se intenta y simplemente nos dejamos ir por los continuos fuegos que salen en los proyectos o por no querer hacer ese esfuerzo adicional.

Recordemos también que la perspectiva es diferente en cada individuo por lo que no está de más contar con todas aquellas opiniones que puedan proporcionar valor.

La prospectiva es más complicada. Cuanto más nos alejemos del presente más nos encontraremos en el marco de la hipótesis y es ahí donde las experiencias pasadas y nuestra lectura del contexto dentro y fuera del proyecto pueden marcar la diferencia.

En resumen la adaptación al cambio requiere mirar hacia detrás y hacia adelante sin olvidar el presente (es más, en los proyectos es lo más importante, es el ahora, donde tenemos la capacidad de tomar decisiones que a corto, medio y/o largo plazo puedan permitir realizar cambios que permitan conseguir nuestros objetivos).

Lo que sí es seguro, como decía Heráclito, que el cambio llegará y mejor que estés preparado para adelantarte a él y/o reaccionar cuanto antes.

Se puede ver de esa manera pero es tan diferente el enfoque que ambos términos chirrían. Es cierto que cuando te planteas una iteración haces todas las actividades que sean necesarias sobre cada historia de usuario, no obstante la principal diferencia la tenemos en que al plantearse un desarrollo por incrementos, existe la posibilidad de realizar evaluaciones, sobre versiones en funcionamiento, desde el punto de vista del resultado (feedback) y de cómo se hacen las cosas (retrospectiva), las cuales permiten ir incrementando el valor del producto y adaptarse a los cambios que puedan producirse tanto desde el punto de vista del producto como de los métodos y organización del trabajo.

En un enfoque clásico o en cascada pueden existir revisiones intermedias del producto (más comunes) y también se puede obtener feedbacks y realizar retrospectivas (menos comunes), aplicar esas estrategias que podríamos considerar ágiles tienen sus ventajas, sin olvidar que siguen sin solucionar los principales inconveniente del desarrollo en cascada:

– El tiempo de puesta en marcha de versiones efectivas del producto.
– Su orientación al cumplimiento de una agenda: costes y plazos, lo que resta flexibilidad a la hora de realizar cambios sobre las especificaciones iniciales.