¿Trabajas en una empresa ágil? ¿Quiere tu empresa ser ágil?

 Ayer tuve una discusión con un colega que, más allá del contenido, me hizo reflexionar sobre el trasfondo sociológico en la gestión de proyectos y productos. Tradicionalmente, hemos gestionado proyectos basándonos en el "triángulo de hierro", compuesto por recursos, alcance y tiempo. Sin embargo, en los últimos años, este triángulo ha evolucionado hacia un cuadrado al incorporar la calidad como un factor negociable.

Parece que muchos hablan de agilidad, pero pocos han leído los principios del manifiesto ágil, que en uno de sus párrafos dice: “La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad”.

Actualmente, la falta de enfoque en la calidad de desarrollo de software y arquitectura puede llevar a productos menos estables y más costosos. En un mundo ideal con recursos ilimitados, las iteraciones constantes podrían funcionar, pero la realidad empresarial nos exige ser eficientes con nuestros recursos limitados.

El desarrollo iterativo debe tener objetivos claros y un destino bien definido. La ausencia de un plan de producto, junto con la falta de prioridad en la calidad, equivale a desperdiciar recursos valiosos. El concepto de "suficientemente bueno" solo es válido si estamos dispuestos a asumir la deuda técnica resultante.

Otro principio afirma: “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.” Sin embargo, hemos creado nuevos roles y artefactos que alejan al equipo de los stakeholders.

y Agrega: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” ¿Pasa eso en tu empresa?

Las premisas básicas del análisis funcional siguen vigentes. Modificar documentos en las etapas iniciales es más económico y eficiente que corregir software ya desarrollado. La metodología ágil nos enseña que, aunque valoramos más el software funcional que la planificación extensa, la documentación necesaria sigue siendo fundamental para cumplir con los criterios de aceptación y para la 'definición de terminado' o 'definition of done'.

Sin un 'definition of done', los equipos operan sin rumbo, equivalente a la caótica producción de los tiempos modernos de Chaplin. Documentar lo necesario de acuerdo con este concepto es esencial para alcanzar un software de calidad.

Las organizaciones deben definir claramente qué nivel de calidad es aceptable en términos de pruebas y documentación. La calidad es necesaria, no una burocracia innecesaria, y es fundamental en tiempos de crisis para evitar repetir errores.

En el contexto de startups y otras empresas, frecuentemente escuchamos excusas como: "No tenemos tiempo para eso", "No hay suficientes manos para hacerlo", "Nos vamos a fundir", "Con todos los problemas que tenemos, ¿para qué tanta burocracia?" Sin embargo, estas son solo miedos y excusas. Una startup siempre está al borde de no sobrevivir, por lo que es crucial priorizar y mantener el orden. Lo que algunos consideran burocracia puede ser clave para establecer orden y superar tiempos difíciles.

Finalmente, el único activo real que tenemos es la capacidad de trabajar bien. La autocrítica nos ayuda a transformar excusas en oportunidades de mejora. La decisión de aceptar una excusa como verdad o como un mecanismo de defensa define el camino hacia el crecimiento personal y organizacional. 

Les propongo que contrasten su día a día, frase a frase, con el manifiesto ágil que incluyo a continuación: 

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

- Individuos e interacciones sobre procesos y herramientas.

- Software funcionando sobre documentación extensiva.

- Colaboración con el cliente sobre negociación contractual.

- Respuesta ante el cambio sobre seguir un plan.

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

1. Nótese que la primera frase está escrita en gerundio, indicando que está sucediendo ahora. Así que, cuando alguien pide que el método que no cambie, ¿está siendo ágil?

2. ¿Llenaste el ticket, Notion, Jira, Monday, etc.? ¿Estamos siendo ágiles?

3. "No está en el PRD" ¿Estamos siendo ágiles?

4. "Esto no es parte del alcance" ¿Estamos siendo ágiles?

5. "No cumpliste con la fecha" ¿Estamos siendo ágiles?

En última instancia, una empresa para ser ágil es una que debe cambiar su forma de gestión y valores, apegarse a los objetivos y alejarse del método clásico de T&M. En una empresa ágil no deberían existir los señalamientos ni las apreciaciones externas al equipo.

Cuando empiezan los juicios de valor y críticas basadas en imposiciones externas no expertas, también comienzan los mecanismos de defensa. Y cuando se activan estos mecanismos de defensa, adoptamos prácticas que nos alejan de la verdadera agilidad. 

Una empresa puede considerarse realmente ágil cuando, incluso en tiempos de crisis, mantiene su agilidad porque entiende que la capacidad de adaptarse con rapidez es más valiosa que seguir un plan con rigidez. La esencia de la agilidad está en saber priorizar, comunicarse efectivamente, y mantener la calidad.

Entonces, te pregunto nuevamente, terminando como empecé:

¿Trabajas en una empresa ágil? ¿Y desea tu empresa realmente ser ágil?

Espero que estas reflexiones te sean de utilidad. ¡Hasta la próxima!