Saltar al contenido
También puedes escuchar este post en audio, ¡dale al play!

Para los que hemos trabajado en transformaciones ágiles en empresas muy ligadas al mercado, de ámbito bancario o con productos y MVPs, instituciones como las Fuerzas Armadas nos resultan un reto laboral, de actitud y hasta de mentalidad.

Para trabajar con la Armada hemos tenido que hacer una nueva aproximación, “desaprender para aprender”, desligarnos de las creencias automáticas (como el perro de Paulov) para cambiar el mindset.

En el caso de los desarrolladores, algunos con más de veinte años de trabajo en Defensa, el reto ha sido implantar todo el ciclo de vida en un Sprint, más preparar y dejar listos requisitos para los Sprints sucesivos (Delivery & Discovery track).

Para el Product Owner, el reto ha sido embarcarse en el viaje de la entrega continua de valor, el paso de preparar especificaciones y “trabajo para hacer” para los equipos a escribir historias de usuario con valor funcional y acompañar el equipo en su día a día.

Para los acompañantes en la adopción de Scrum ha sido un pequeño “cortocircuito”. Fieles a la frase “Plans are nothing; planning is everything” de Eisenhower, el reto ha sido mantener el equilibrio entre toda la documentación que requiere la administración pública y la maximización del trabajo no hecho.

Para el cliente (stakeholder) hemos tratado de cambiar esa perspectiva rígida y tremendamente jerárquica de la Armada en una relación de confianza y transparencia respaldado con nuestro trabajo.

Si tratamos de hacer nuestro el manifiesto ágil aplicado a la Armada:
 

  • Individuos e interacciones sobre procesos y herramientas. Hemos aprendido a atenuar las jerarquías y a mantener una comunicación fluida con clientes y stakeholders.
  • Software funcionando sobre documentación extensiva. La documentación es necesaria y contractual en este sector, pero hemos maximizado la cantidad de trabajo no hecho y hemos conseguido limitar la creación y mantenimiento de documentación a la entrega del Sprint
  • Colaboración con el cliente al mismo nivel de negociación contractual. La forma de contratación por acuerdo marco y basados exige negociación contractual con hitos, pero también tenemos al stakeholder y al usuario final revisando la funcionalidad al final de cada Sprint y dándonos feedback continuamente.
  • Respuesta ante el cambio sobre seguir un plan. El diagrama de Gantt se ha tirado a la basura, planificamos, hacemos, revisamos y adaptamos tanto como sea necesario.

Si una organización tiene muy fuerte la disciplina pero no dispone de agilidad, el resultado es burocracia, retrabajo y estancamiento. Tener un producto correctamente documentado no te ayuda a saber si has hecho un buen producto. Por el contrario, la agilidad sin disciplina y unos mínimos puntos de control contractuales tampoco funciona en entornos más normativos.

Hay que apostar por un equilibrio para poder cumplir objetivos y adaptarse al entorno apostando por incrementos pequeños y evitando proyectos faraónicos.

No olvidemos que la agilidad es la capacidad de evolución (que no transformación) de las personas y organizaciones. No es un fin, es un camino de adaptación al entorno para subsistir en él.

Nuria  Caballero
Nuria Caballero Perfil en Linkedin

IAgile Coach en BABEL.

Más post de Nuria Caballero