Durante los años que llevo trabajando con empresas que buscan dar un paso dentro de su transformación a la Agilidad, he notado que uno de los principales obstáculos que aparecen es el del miedo a perder el control.

«De la noche a la mañana ya no voy a poder seguir controlando a mis subalternos y el trabajo que realizan, si ya no seguiré controlando las fechas de finalización de los proyectos, ¿entonces qué me está dando esta Agilidad que estamos trayendo a nuestra empresa?»

Me encuentro constantemente con este temor, en ocasiones con otras palabras, pero siempre resulta teniendo el mismo trasfondo:

• «Si pierdo el control, ¿qué sentido tendrá mi puesto en la empresa?»
• «Si ya no puedo controlar las cosas, ¿cómo podré estar tranquilo?»
• «Siempre hemos hecho las cosas de esta manera, y ahora, ¿cómo puedo controlar que las cosas se sigan haciendo?»

Dentro del modelo de gestión de proyectos en cascada, donde teníamos definidos todos los pasos y las fases del desarrollo, desde la elicitación de requisitos, pasando por el proceso de diseño de la solución, documentación de los casos de uso, firma de contrato, desarrollo, pruebas, correcciones, despliegue, estabilización y finalmente el mantenimiento de la solución, ¡todo estaba bajo control! ¡Sabíamos exactamente cuándo cumpliríamos cada hito del proceso! ¡Podíamos construir exactamente lo que se necesitaba, cumpliendo a cabalidad con todas las definiciones, manteniendo una calidad impecable en cada producto y hasta anticipando la fecha en que iniciaría nuestro ROI^[1]Retorno de la Inversión (Return On Investment).! ¡Conocíamos a la perfección el alcance, el costo y la duración de cada desarrollo!

¿O no?

Tengo más años desarrollando en este modelo de cascada de los que me hubiera gustado y, en mi experiencia, estas premisas de la gestión tradicional de proyectos lo único que lograban era demostrar que jamás se tuvo el control: una vez se lograba definir el producto, era común encontrar ambigüedades y contradicciones en la documentación, el diseño que se entregaba era solo un recuerdo de lo que se había visualizado al inicio del proyecto, el tiempo para realizar las pruebas solía ser la mitad del tiempo que se había planeado, generando que la calidad fuera, por mucho, la mitad de lo que se esperaba y, lo más importante, es que siempre sabíamos que la fecha de finalización del proyecto, era solo una fecha para presionar, pero jamás para cumplir.

Recuerdo incluso que de esta fecha final del proyecto o "deadline”, dio pie a algunas bromas como estas:
"El deadline es el momento en que el proyecto muere"
"El deadline marca la mitad del tiempo de ejecución de cualquier proyecto"
"Si para la fecha del deadline los desarrolladores no están a punto de morir, nunca terminarás tu proyecto"

En este modelo de cascada, ¡el control siempre fue una ilusión!

Los desarrolladores creían poder construir un producto al pie de la letra, sin ningún tropiezo, y por esto estimaban que en varios meses de trabajo podrían finalizar el producto.

Los managers creían poder controlar el desarrollo exigiendo a los equipos «ponerse la camiseta» o «da la milla extra», y creían que al brindar pizza a sus equipos, estos continuarían rindiendo más del 100% eternamente.

La gerencia creía poder controlar el costo de cada proyecto asignando un porcentual extra para cubrir los imprevistos, y creían que exigiendo a los managers que entregaran resultados dentro de las holguras calculadas del proyecto, el presupuesto no se afectaría y que los desfases serían cubiertos por el ROI que se calculó al inicio del proyecto.

Todo lo anterior estuvo siempre lejos de la realidad: cualquier ínfimo cambio no tenido en cuenta en el diseño generaba al equipo pérdida de tiempo y reprocesos; los desarrolladores no lograban dar su 100% después de haber comido pizza, pues estaban cansados y seguirían cansados al otro día sin poder alcanzar su nivel «normal»^[2]Debemos tener en cuenta que somos personas. No somos recursos o máquinas. Algunos días estamos inspirados y nos rinde más que los días en los que algo nos molesta o desestabiliza.; si la aplicación que se imaginó al inicio del proyecto y que se construyó durante todos esos meses de trabajo no era lo que realmente necesitaba el cliente, tal vez ese ROI nunca llegaría y la inversión se convertiría en una pérdida.

Ahora imaginemos a alguien que vivió en este modelo de gestión, en el que siempre pensó que tenía el control e, incluso así, las cosas se salían de sus manos. A este personaje le llegan de un día para otro y le dicen que debe empoderar al equipo. Y esto no es otra cosa que entregar a los desarrolladores el poder para que tomen decisiones y ejecuten todo lo que necesiten en su proceso. Esto significa que perderá poder, y junto con ese poder, ¡también perderá el control!

Para alguien que ha tenido el aparente control de su proyecto en un diagrama de Gantt o instrumento similar, es difícil cambiar de mentalidad: es complicado pasar de validar un fallo en alguno de los principios de la gestión tradicional de proyectos (tiempo, alcance o costo), a un nuevo esquema donde debe velar porque se entregue valor, que haya mejora continua, que exista un ambiente de trabajo con personas motivadas (el pasar de “no diste la milla extra” a “qué puedo hacer para que tu trabajo sea mejor”).

«¡¿Y todo eso cómo lo pongo en mi Gantt?!»

Para poder crecer en la Agilidad, no se pueden tener reglas inalienables. No se podrá exigir que para X fecha esté listo el producto, o que cada sprint tendremos que ir a producción con una nueva versión del producto. Las reglas estrictas son el enemigo de la Agilidad. Para poder mejorar, la Agilidad nos lleva a cambiar con cada paso que avanzamos. Cada vez que experimentamos algo nuevo en pro de nuestra mejora, podríamos estar reescribiendo las reglas.

Ahora el poder no está en un látigo para castigar a las personas, sino que ese poder está en manos de un grupo de desarrolladores.

Desde el lado del desarrollador también cambian las cosas. Es confuso para el desarrollador comprender que ahora no tiene que seguir a ciegas las indicaciones para construir lo que se le pide en los extensos y detallados casos de uso, sino que ahora es él quien tiene la responsabilidad de entregar valor, de mantener una calidad impecable en su trabajo.

Ahora es el equipo en pleno quien está teniendo control sobre el producto que está construyendo, y la manera en la que está recibiendo la retroalimentación de los usuarios.

El equipo de desarrollo debe tener poder sobre todo lo necesario para efectuar todas y cada una de sus tareas. Esto significa que, en el caso que se deba tomar una decisión relacionada con las tareas que se están efectuando, esta decisión no puede detener el desarrollo mientras se eleva a niveles superiores en la empresa y se espera a que la burocracia haga lo suyo, sino que el equipo debe tener la autoridad para tomar sus propias decisiones y ejecutarlas de inmediato. Ojo: no significa que se tomen decisiones irresponsables. Por el contrario, todas las decisiones se toman basándose en la experiencia, las mejores prácticas y los lineamientos de base del proyecto, del producto o de la empresa.

Desde la posición del Dueño de Producto, el poder que recibe el equipo es el de decidir cuál es el producto que se deberá construir, adaptándose a cada cambio y a cada retroalimentación recibida, e incluso a dar un paso atrás sobre alguna funcionalidad que no dio el resultado esperado.

Y para quien fuera manager, ahora tendrá la responsabilidad de velar por que la construccion de valor se logre. El poder que ahora tendra es sobre el equipo, buscando que haya crecimiento (excelencia tecnica) en el equipo y en las personas; sobre el producto, buscando que no hayan obstaculos en la entrega de valor; y sobre el proceso, buscando que se construya sin desperdicio y sin deuda técnica.

He tenido la oportunidad de participar en algunos proyectos en los que el control se ha convertido en empoderamiento y donde el desarrollo fluye sin necesidad de los obstáculos burocráticos. Proyectos en los que hemos podido decidir si queremos construir utilizando una tecnología o una combinación de tecnologías y herramientas, en los que hemos podido demostrar resultados en menos tiempo del que se esperaba, pues al no tener que esperar a que la burocracia respondiera ante cualquier petición básica, pudimos concentrarnos en el desarrollo y en la entrega de software funcional y de excelente calidad, en la retroalimentación temprana, y en la reacción rápida para optimizar nuestros productos.

Y tú: ¿Qué esperas para perder el control y obtener el poder?