En busca del auténtico norte.

Nos queremos adentrar en un concepto que no es nuevo en el desarrollo de producto o en el ámbito de la gestión de proyectos: la gestión y alineamiento de expectativas.

Pero, antes de nada, es necesario un paso atrás, en el que tomemos cierta perspectiva del porqué de este artículo.

Paradigma, como sabréis los lectores habituales del blog, es una compañía que nació allá por 2007. En ese momento “lo de Agile” no estaba en boca de todos como lo puede estar ahora, pero usar prácticas Agile como parte de nuestro éxito en el desarrollo de software es algo “Impreso a fuego en nuestro ADN”, tal y como dice nuestra página web.

Sin embargo, como contábamos recientemente al presentar Polaris (nuestro add-on al Agilismo en el que sumamos el resultado de años de experiencia desarrollando software para grandes compañías) hacen falta nuevos elementos que complementen las buenas prácticas ágiles.

Uno de estos elementos son las expectativas. ¿Por qué? Porque esto está ocurriendo en proyectos de software:

• Proyectos que pecan de un excesivo celo por la última tecnología, por encima de la solución tecnológica que realmente resuelve la funcionalidad.
• Conjuntos de Historias de Usuario desconectadas entre sí que difuminan el auténtico objetivo y visión del producto.
• Proyectos donde, tras 5 sprints, hemos empleado un 90% del presupuesto y el producto liberado hasta el momento es claramente insuficiente o desalineado con la expectativa.

Agile ya gestiona expectativas.

Si hacemos caso de los 12 principios detrás del Manifiesto Ágil encontraremos actitudes que van a ayudarnos en este asunto:

• Realizar una “Entrega temprana y continua de software con valor”, con una frecuencia entre 2 semanas y 2 meses, nos va a realizar una gestión forzosa de expectativas tras la entrega. Esta es la principal aproximación a la gestión de expectativas en el entorno Agile: las iteraciones frecuentes. Conforme se avanza en la entrega es más sencillo detectar puntos de desalineamiento. Ahora bien, cuántos proyectos siguen demorando la entrega o les sigue “costando” en exceso desplegar por la falta de buenas prácticas (como, por ejemplo, DevOps). Muchas veces, ejecutando Scrum en equipos, he tenido esa sensación de que los Sprints pasan uno a continuación de otro, sin descanso ni respiro, para echar la vista al frente y atrás, y coger la visión panorámica del camino recorrido.
• Conseguir que “Desarrollo y Negocio trabajen juntos de forma cotidiana durante todo el proyecto” es, desde luego, una manera de estrechar lazos entre los diferentes involucrados en el producto a desarrollar, si bien, es algo que se puede producir de una manera natural o no.
• Lo mismo ocurre con la “Comunicación cara a cara”: es la mejor manera de minimizar esta ausencia de expectativas, aunque sabemos que uno puede hablar mucho y comunicar poco… Y qué difícil se nos pone el trabajar codo con codo en tiempos de pandemia, en donde estamos tan cerca y tan lejos a la vez, y más aún cuando nuestra empresa no acaba de estar preparada.

El problema seguramente tiene que ver con una palabra citada anteriormente: la actitud. Hacer realidad estos principios o no está excesivamente ligado al entendimiento que los profesionales realicen de ello. Desgraciadamente, muchos mensajes van degradándose con el paso del tiempo y el boca a boca, y pierden su sentido original. Es ahí donde sentimos que hace falta algo más.

Recientemente, en el artículo de mi compañero Javi Navarro acerca de gestión de riesgos, hablábamos de los beneficios de “hacer un mojito de herramientas” (como diría Jurgen Appelo sobre combinar las mejores prácticas disponibles), incluso en enemigos aparentemente acérrimos como el de la gestión tradicional y el mundo agile. De igual manera puede suceder con este asunto.

Agile ya es Risk-focus oriented y también tiene foco en la gestión de expectativas, pero, en nuestra experiencia, son problemas habituales de los proyectos, dada la coyuntura cliente-proveedor en que normalmente nos movemos. Los contratos, los temidos contratos, son un elemento que atenaza a unos y otros y provoca lo peor que nos estábamos temiendo: la falta de transparencia, el empeoramiento de la comunicación, la pérdida de confianza mutua...

Nuestra solución: True North, un elemento para alinearlos a todos.

Es por eso que en el diseño de Polaris tuvimos claro desde el principio que el primer elemento a desarrollar debería ser un “alineador de personas”: nos lo imaginábamos como un DIN A4 que contenía toda la información relevante para tener una visión global del estado del proyecto; con la información suficiente como para no perder el norte acerca del futuro. Y a este elemento “para no perder el norte” lo llamamos True North.

Observándolo de un vistazo sabes por qué estamos en el proyecto, cuáles son las líneas rojas y las claves de éxito, cómo pensamos llegar al objetivo y el avance del presupuesto: es la brújula a la que hay que mirar cuando tenemos dudas.

Pero, ¿qué es el True North?

• Es una visualización que sintetiza la visión y la estrategia del proyecto en un documento vivo y claro, lo más automatizable posible.
• Sirve para crear una perspectiva compartida para todo involucrado respecto a lo que queremos hacer. Nos ayuda a cambiar de vez en cuando el foco de micro a macro para no perder el rumbo.
• En términos de implicación es también importante, ya que aporta al equipo de desarrollo el contexto necesario para entender cómo su trabajo contribuye a los grandes objetivos.

True North es una herramienta para gestionar expectativas mediante la gestión visual de la información. Para cubrir esta necesidad recomendamos al menos que contenga:

• Visión del proyecto: debe permitirnos identificar los objetivos y el estado del proyecto para ayudarnos a dirigir los esfuerzos del equipo en cada momento.
• El camino del producto: debe proporcionar información sobre el Roadmap del producto o Plan de Sprints para clarificar en qué punto nos encontramos.
• Estado del Delivery: son importantes los aspectos económicos del proyecto, así como otros aspectos que pudiesen poner en riesgo la viabilidad del mismo.

Un último aspecto importante: True North no es un elemento invasivo que llega para monopolizar la gestión del producto a desarrollar. No se puede entender este elemento sin abordarlo desde la perspectiva de cubrir las necesidades que tienen los proyectos (dar servicio por tanto) y sin incorporarlo en nuestro día a día de una manera natural en los eventos del marco de trabajo que ya utilizamos.

La gestión de expectativas nunca fue tan fácil. Estate atento a nuestro blog y suscríbete a nuestra newsletter porque próximamente tendremos una masterclass práctica donde contarte cómo crear tu propio True North.