La paradoja de la agilidad

A inicios de 2019, asumí un nuevo reto: dirigir las operaciones diarias de todo el back office y, a la par, armar un equipo dedicado a ver mejoras de cara hacer más eficientes los procesos del día a día.

Reto no menor, hoy comentaré sobre lo segundo: armar un equipo de mejora de procesos. Rápidamente, con el equipo asignado comenzamos a pensar en cómo abordar las mejoras, instalamos un tablero kanban para visualizar mejor el avance, tratamos de separar los tipos de servicio que atendíamos. A la par, nos ayudó mucho comenzar a tener reuniones con otras áreas (Arquitectura, Business Process Engineering, entre otros) y contarles de nuestro objetivo como equipo, es así que hacía mediados de año y luego de casi 3 iteraciones llegamos a un modelo de equipo en el cual trabajábamos de la siguiente manera: (i) reunión semanal para ver los avances con actas, (ii) kanban para visualizar las tareas, (iii) separación de los servicios que ejecutábamos.

Sin embargo, una de las cosas que observé en el tercer trimestre del año y ya con este modelo, es que siempre había pendientes, revisar el acta se volvía a veces un mal rato y, los más importante, es que no sabíamos cuánto valor entregábamos como equipo. Asimismo, sabía que no estaba siendo el mejor líder al imponer muchas veces lo que se debía hacer, esto me lo hacía recordar bastante la agile coach que habían designado al área. Coincidentemente, por esas fechas me inscribí en la Ruta 1 de Colectivo 23 sobre Liderazgo de Productos Digitales y dentro de los diversos módulos que llevé me impactaron dos: (i) el futuro del trabajo e (ii) implicancias tech en el diseño de productos.

Del primero me quedé con que uno puede adaptar prácticas ágiles a casi todos los equipos, independientemente, de las funciones o entregables que tenga ya que los rituales son replicables. También, me quedé con algo muy potente, nos mostraron un estudio que realizó Google sobre las características de los equipos exitosos siendo la principal: "psychological safety" en la cual los equipos se sienten seguros de tomar riesgos y mostrarse vulnerables y me hizo dar cuenta que uno puede decir mucho y dar libertad a los equipos, pero ciertas acciones pueden, también, mellar en lograr que los equipos se expongan, en mi caso eran las actas.

Del segundo me quedé con que todo debe ser medido inclusive los feedbacks de un scrum en el cual el equipo ve el rendimiento que tiene sprint a sprint y esto fue lo que más me llamo la atención y lo asocie mucho con los problemas que tenía el equipo sobre todo si el fin de tener un kanban es no tener work in progress (wip) o pendientes y es, sin duda, el mayor problema en las organizaciones que es la falta de ejecución y entrega de valor a los usuarios.

Con todos estos pensamientos en mente, tomé una de las últimas decisiones bajo el modelo regular de management en la cual uno dice y el otro ejecuta. La decisión fue volvernos ágiles bajo el modelo de lean agile y todas las ceremonias y roles que ello implica (dailys, demos, retros, sprint planning, process owner y kanban master) El equipo lo tomó con cierta sorpresa e incredulidad, tuvieron una semana para diseñar su nuevo modelo de trabajo.

A la semana, me presentaron el modelo y las personas seleccionadas para el rol de PO y KM, en lo sucesivo mi rol pasaría más a estar en retros y feedbacks directos con cada miembro del equipo. Sin embargo, con el cambio no tuvimos tanta suerte al inicio pues observaba que el KM no generaba las ceremonias y en la primera retro aun contábamos con WIP con lo cual tuve que intervenir nuevamente (estar durante algunos días en todas las ceremonias como una autoridad presente) para empujar a que esta nueva dinámica se instaure en el equipo. Como resultado para el siguiente sprint el WIP bajo al mínimo y todas las retros se volvieron numéricas de cara a la evaluación global de cada sprint.

Es difícil sin duda pasar a este modelo pues viví en carne propia lo que muchas veces leía de otros autores y es esa "pérdida de control y decisión" de lo que se ejecuta pero, también, rápidamente comencé a ver resultados: (i) un equipo mucho más animado, (ii) una explosión de ideas que se querían ejecutar y que se comenzaron a ejecutar, (iii) entregas más frecuentes y de alto impacto para el día a día, (iv) las preguntas de otros equipos de querer comenzar a trabajar en esa línea, (v) ser el primer equipo en lograr la máxima medición de agilidad en Perú bajo el modelo corporativo y ser felicitados a nivel de Comité de Dirección.

Luego de todo este viaje con el equipo de mejoras confirmé que toda ola sobre agilidad tiene que ver mucho más con la cultura que con el modelo de trabajo en sí mismo y, también, con el convencimiento de quien lidera de tener la intención de hacerlo realmente, pero es difícil pues como Heifetz (1) menciona ante un cambio lo único que el sistema (persona o grupo de personas) ve son las pérdidas ante el mismo mas no los beneficios.

Lo anecdótico de toda esta historia es que el llegar a ser ágil donde el grupo decide, es más autónomo y las decisiones ya no pasan por una única persona sino por el equipo, se dio por decisión del líder y un seguimiento estricto de las ceremonias. En esa línea es que le doy el título a este articulo pues me deja pensando cuántos realmente de los que hoy lideran y comentan sobre este tema realmente tomaron la decisión de serlo.

Fuente de la imagen: https://images.app.goo.gl/1oosqoJLndSZsqrZ6

(1) Heifetz, Grashow, Linsky (2009) The Practice of Adaptive Leadership