Sobre NoEstimates: gestión adaptativa de proyectos

Tiempo aproximado: 6 min.

Yo no soy un fan del movimiento #NoEstimates, normalmente me suelo mantener al margen, pero creo que las cuestiones que mi admirado Rodrigo Corral planteaba esta semana en Twitter eran más que razonables y he pensado que seguramente habrá más gente que opine igual. Así que voy a comenzar una serie de artículos sobre este asunto.

Para resumir: Rodrigo arranca con estos dos tweets.

Y en un momento dado, la conversación (de Rodrigo con más gente) ha derivado a los presupuestos, que es donde yo me incorporo para decir esto:

Desde mi punto de vista, el problema es que, si la empresa se organiza en torno a un plan predictivo, trabajar sin estimar se hace muy muy complicado aunque, como ya expliqué en otro artículo, no es imposible.

La alternativa es que todos se enfoquen en conseguir unos objetivos bien conocidos, a los que se ha dotado de un presupuesto. Lo ideal sería que pudiera contar aquí (en público) lo que estoy actualmente trabajando para mi actual cliente. Prefiero ser discreto y no desvelar detalles, en parte por respetar la confidencialidad, y en parte porque aún es un trabajo en curso con el que no sabemos si tendremos éxito o no. Sin embargo, no creo que provoque ningún conflicto explicando los fundamentos teóricos de lo que estamos trabajando.

Así pues, voy a desgranar mi explicación en cuatro entregas:

  • Primero explicaré la diferencia entre planificación predictiva y adaptativa. Fundamental para entender el resto. Te lo puedes saltar si ya te lo sabes, aunque igual te sorprendo.
  • ‎Luego explicaré qué es una planificación estratégica y la diferencia con la planificación operacional (u operativa).
  • ‎Nos acercaremos a los problemas reales que plantea Rodrigo en la tercera entrega, en la que quiero explicar cómo se hace una planificación estratégica predictiva y cómo afecta a esto de #NoEstimates.
  • ‎Y finalmente acabaré explicando cómo se puede hacer una planificación estratégica adaptativa y cómo trabajar sin estimaciones.

Planificación predictiva vs adaptativa

Cuando hacemos cualquier introducción a las metodologías ágiles explicamos esta diferencia fundamental en la manera de gestionar los proyectos. Personalmente, creo que quien mejor lo cuenta es @HenrikKniberg, con su metáfora del cañón y el misil teledirigido. Voy a aprovechar que ya la escribí para el libro ELS2013 (España Lean Startup 2013, editado por @nodosenlared) para extraer ese párrafo.

Cuando un equipo construye software siguiendo estos principios [los principios del Agile Manifesto], obtenemos el feedback de los usuarios poniendo a su disposición software funcionando, en un ciclo continuo de entregas frecuentes, incrementando así el valor del software porque incorporamos lo aprendido en las entregas anteriores.

Os propongo la siguiente metáfora. Suponed que tenéis que disparar a un objetivo a varios kilómetros de distancia. Apenas lo podéis ver a simple vista y para acertar sólo tenéis una única bala y un cañón. Seguro que, conscientes de la importancia de realizar bien los cálculos, os tomáis vuestro tiempo, medís las distancias, los ángulos, el peso de la bala, ajustáis bien el cañón, lo dirigís hacia el objetivo y disparáis, confiados en que vuestros cálculos han sido perfectos. Pero no habíais contado con que el viento no era constante ni con que el propio objetivo se desplazaba lentamente hacia el oeste. El resultado… fallo.

Si os dieran una segunda oportunidad, ¿qué mejoraríais en la “gestión del proyecto”? La respuesta más inmediata es complicar el modelo de los cálculos e introducir todas esas nuevas variables para poder ejecutar un disparo aun más preciso. Sin embargo, un agilista respondería que cambiaría el cañón por un misil teledirigido. Así, en vez de realizar unos precisos cálculos iniciales, él lo lanzaría inmediatamente en la dirección del objetivo, sin necesidad de precisar demasiado porque ya sabe que éste se va a mover o que habrá imprevistos que lo desviarán, como el viento, por ejemplo. El misil, sin embargo, cada pocos segundos se encarga de reorientarse a sí mismo, incorporando a su nueva dirección las posibles desviaciones sufridas durante ese intervalo. El resultado, como podéis prever es… éxito.

Esta conocida metáfora de Henrik Kniberg nos ayuda a entender la diferencia entre una gestión de un proyecto predictiva y una adaptativa. Las metodologías ágiles se basan en una gestión de proyectos adaptativa como estrategia para incorporar el aprendizaje obtenido tras cada ciclo BUILD/MEASURE/LEARN. Al final de cada ciclo inspeccionaremos, es decir, pondremos el producto en la calle y mediremos, y en función del feedback recibido nos adaptaremos. Igual que el misil.

@HenrikKniberg es autor, entre otros, del libro “Scrum y XP desde las trincheras”. Presentó esta metáfora en la Conferencia Agile-Spain en 2010. Éstas son las diapositivas y el video (min. 22 en adelante).

Creo que esta historia transmite poderosamente el fundamento experimental de la gestión ágil del trabajo. Tratamos todo el rato de establecer hipótesis (más o menos explícitas) y trabajamos un breve lapso de tiempo para, al final del mismo, inspeccionar el resultado y corregir nuestros planes si fuera necesario. Esto, en el medio y largo plazo es más productivo que una gestión predictiva del trabajo, especialmente en un contexto donde la incertidumbre dificulta el desarrollo de planes detallados.

Complejidad

Cuando hablamos de incertidumbre, casi inevitablemente hablamos de complejidad.

La matriz de Stacey

Es típico explicar con la matriz de Stacey que los métodos ágiles son más adecuados a entornos de alta incertidumbre que los tradicionales, que requieren de muchas más certezas para ser eficaces. Jerónimo Palacios lo explica en su blog. A mí también me gusta usar Cynefin para explicar la diferencia entre los problemas complicados y complejos, y por qué la gestión adaptativa funciona mejor en estos casos. Ya referí hace tiempo este artículo de Martín Alaimo donde explica Cynefin muy fácil.

Otra buena reflexión de @jbrains sobre cómo la complicación accidental (la incertidumbre) domina sobre la complicación esencial (la dificultad). Si te cuesta seguir a J.B. en su exposición de 7 minutos y 26 segundos (clavados), quizás prefieras leer este artículo.

Una conclusión de esta charla es que refactorizar el código reduce la complicación accidental oculta en nuestro código. Yo la llevaría fuera del código, al backlog por ejemplo, y diría que podemos reducir la incertidumbre de nuestros desarrollos refactorizando las historias de usuario y el backlog en su conjunto. A esto lo llamamos refinamiento.

El caso es que, tanto desde un punto de vista teórico como práctico, basar la gestión del trabajo en estimaciones parece poco fiable. Sin embargo, seguimos haciéndolo, seguimos sintiendo la necesidad de evaluar si algo es grande o pequeño, si tendremos dinero o no para abordarlo, si habrá que buscar más gente para terminarlo a tiempo… En artículos posteriores veremos de dónde viene esta necesidad y qué alternativas tenemos.

Una vuelta de tuerca: NoProjects

Es posible que hayas pensado que, si se trata de abrazar la incertidumbre y el cambio, y si la razón por la que nos piden estimaciones es porque alguien define proyectos, la manera más extrema de resolver el problema es dejar de pensar en proyectos, es decir, en “asignaciones temporales de recursos para conseguir un valor añadido determinado”. Es lo que se conoce como NoProjects, un movimiento cuya propuesta es que trabajemos en un flujo continuo de valor añadido. Creo que este artículo lo explica bastante bien.

Como con #NoEstimates, hay un movimiento alrededor del hashtag #NoProjects. Incluso una web con varios artículos e incluso libros.

Personalmente no soy amigo de los #noloquesea porque, aunque en el fondo apenas son formas más o menos provocadoras de poner encima de la mesa un debate interesante, se llevan fácilmente al terreno del fundamentalismo con titulares como “Si aún haces X, ya lo estás haciendo mal”, lo cuál no parece la manera más empática de atraer a la gente que crea las condiciones que, en la práctica, provocan estas disfunciones o ineficiencias en las organizaciones.

Por supuesto que esta moda del #noloquesea nos puede llevar al nihilismo y poner de moda el #noatodo. 🙂

En el siguiente artículo explicaré dónde chocan estas iniciativas con “el mundo real”, es decir, con los procesos que derivan de las decisiones que se toman a nivel estratégico, y que terminan siendo las razones últimas por las que se definen proyectos y se piden estimaciones.

LA FOTO: Por supuesto, un homenaje al maravilloso Forges. Descanse En Paz.