Guía del líder para una transformación ágil exitosa: Cómo ir más allá de los equipos

por Matthew Jacobs | 29 de octubre de 2020 | Blog

Lo que tienen las organizaciones ágiles, y de lo que carecen las empresas tradicionales, es la capacidad de cambiar, inspeccionar y adaptarse constantemente. Las organizaciones ágiles son capaces de pivotar para aprovechar los mercados impredecibles, las demandas de los clientes y las condiciones del mundo real.

En resumen, tienen la capacidad institucional de hacer del cambio una ventaja competitiva. Atrás quedaron las jerarquías rígidas y la burocracia. Se sustituyen por un sistema operativo ágil y adaptable que impulsa la innovación, la velocidad y la entrega de valor.  

No sólo a nivel de equipo, sino en toda la empresa. 

Su organización puede mejorar con sólo añadir equipos Scrum. Pueden acelerar la capacidad de su organización para aportar valor rápidamente. Sin embargo, si no cambia los procesos centrales de su organización, la eficacia global de sus Equipos Scrum se verá limitada por las estructuras heredadas y las barreras institucionales. 

Estos son los obstáculos que hacen fracasar tantas transformaciones ágiles.

Al pasar por una transformación ágil, el sistema operativo actual de su organización y el nuevo sistema operativo ágil lucharán por el dominio. Trabajarán activamente el uno contra el otro. 

Hemos ayudado con éxito a muchas organizaciones a transformarse en empresas ágiles. No hay atajos, pero sí patrones conocidos de éxito. Alinear el sistema operativo de la organización con formas ágiles de trabajo aumentará en gran medida la probabilidad de que su transformación ágil tenga éxito. 

1. Participación de los líderes frente a aceptación

Muchas organizaciones creen que son ágiles. De hecho, sus equipos de productos o servicios pueden serlo. Pero más arriba en el organigrama clásico, sigue funcionando el viejo sistema operativo. Esa es la diferencia entre la participación del liderazgo y la simple aceptación. 

El problema de la implicación de los líderes es que por sí sola no basta para ser ágil. Si la dirección sigue operando con el sistema antiguo, provocará fricciones con los equipos. De hecho, les dificultará la consecución de los objetivos y resultados empresariales de los que son responsables. Está dando poder al viejo sistema para que domine y destruya el cambio que su organización necesita para prosperar. 

Una de las formas en que esto se manifestará es una comunicación ineficaz. Las órdenes, en lugar de la visión, llegarán del equipo directivo y los líderes esperarán informes de situación.

Su equipo directivo debe evolucionar hacia un equipo de liderazgo capaz de capacitar a los propios equipos Agile. La mejor forma de conseguirlo es que el propio equipo directivo adopte una mentalidad Agile.

Para emerger como líderes necesitan proporcionar la visión, dirección y priorización que permitan a los equipos ejecutar con Agilidad. Los líderes también deben capacitar a los equipos eliminando los obstáculos para su éxito y productividad. 

En el mejor de los casos, los directivos estarán tan bien formados en el marco Scrum, que podrán funcionar como entrenadores auxiliares.

Esto capacita tanto a la dirección como a los equipos. Al comprender cómo leer, interpretar y utilizar herramientas como Product Backlogs y gráficos de burn-down, la dirección adquiere una mayor capacidad para alinear la organización. Aumentan la transparencia y la visibilidad. La planificación se vuelve más fiable. 

Ojalá me hubiera sorprendido cuando un equipo directivo nos llamó a principios de este año expresando su frustración porque sus equipos Scrum no sólo habían dejado de mejorar, sino que parecían estar retrocediendo. Cuando fuimos a hablar con los equipos para identificar la causa de los problemas, se sorprendieron de que su equipo directivo hubiera pedido ayuda. 

El equipo dio ejemplos de lo que algunos de nuestros clientes militares denominan "tareas de pasillo". Los directivos solían intervenir para exigir que se hiciera otra cosa de inmediato. Cuando el Product Owner intentaba intervenir y pedir ayuda para establecer prioridades, el equipo directivo se negaba a participar. Estas "tareas de pasillo" consumían enormes cantidades de la capacidad del equipo. Los avances en productos que beneficiarían a la empresa se resintieron. 

Por otro lado, cuando el equipo identificaba impedimentos sencillos, no disponía de un canal de escalada. Cuando se planteaban problemas al Comité de Dirección Ejecutiva, la respuesta frecuente era "no me traigan problemas, tráiganme soluciones". Esto disuadía a cualquiera de plantear problemas con transparencia, especialmente los que requerían apoyo más allá de sus competencias. 

Puede que estos directivos se hubieran creído lo de ser ágiles, pero no estaban participando ni liderando. En cuanto a los impedimentos no resueltos, también perjudicaban a la productividad, la creatividad y la moral del equipo. 

Por suerte, un Director General recién nombrado empezó a impulsar un verdadero modelo de liderazgo de servicio.  

A medida que educábamos a la organización sobre Scrum@Scale, el nuevo Director General vio cómo el marco operacionaliza el liderazgo de servicio. Los Equipos Scrum empezaron a acelerarse una vez que el Scrum@Scale y el liderazgo de servicio se expandieron. Los resultados que buscaba la dirección no tardaron en llegar.

Como equipo directivo, si está pidiendo a su organización y a los miembros de su equipo que cambien y muestren un comportamiento Ágil, debería esperar lo mismo de usted mismo.

2. Agilice los ciclos de vida de sus productos

Con frecuencia, las empresas cuentan con procesos específicos para la gestión del ciclo de vida del producto. Estos procesos se integran en los marcos de aprobación de la organización y alimentan la financiación, la elaboración de informes, la comercialización y las inversiones futuras. 

Los equipos ágiles suelen tener problemas para que los proyectos superen las fases cuando este proceso heredado no se actualiza. Esto no significa que se puedan ignorar o se vayan a ignorar los requisitos reglamentarios. Tampoco significa que se supriman otros controles de seguridad y calidad. 

Lo que esto significa es que estos controles garantizan que sirven para el fin previsto y reúnen la cantidad mínima de sobrecarga necesaria para cumplir las normas de seguridad y reglamentación exigidas. 

Si no se modifican estos procesos, los proyectos que deberían haberse descartado por no cumplir las expectativas del cliente tienden a recibir más financiación simplemente porque ya cumplen los requisitos predeterminados del proceso del ciclo de vida del producto. Los nuevos productos y los pivotes que aumentan el valor se desechan por defecto. 

En este caso, puedo darles un ejemplo de una empresa de fabricación de la lista Fortune 100 a la que recientemente guiamos a través de una transformación Agile. Dentro de sus sistemas, habían creado informes automatizados para asegurarse de que todo "funcionaba correctamente". 

Existía un complicado proceso en el que equipos ajenos al grupo de desarrollo se encargaban de gestionar e informar de cualquier error del sistema a medida que surgía. Pero al implantar un modelo operativo ágil, los propios equipos habían asumido la responsabilidad directa del soporte del producto. 

Antes de la implantación, los nuevos desarrollos pasaban por una serie de fases en las que las aprobaciones avanzaban lentamente por el sistema. 

Los equipos Scrum bien formados tienen miembros con todas las habilidades necesarias para hacer el trabajo, incluido el apoyo en esta situación. Esto permitió al equipo centrarse en lanzar más rápido y crear pruebas automatizadas para detectar rápidamente los problemas, incluso antes de que los encontrara un cliente. 

Sin embargo, la organización mantuvo estos equipos de pruebas e informes manuales separados que habían formado parte de su modelo operativo anterior. Por eso, cuando se producían cambios, los guiones de las pruebas eran incapaces de seguir el ritmo de los cambios que surgían de los equipos de desarrollo. Estas pruebas obsoletas empezaron a fallar. 

Así que, como habían hecho todo el tiempo, el departamento de cumplimiento entró en acción. Enviaron informes de fallos a varios directivos, y estos empezaron a insistir en que se solucionaran lo antes posible los problemas que no existían en las aplicaciones que se habían refactorizado o eliminado. 

Los equipos produjeron los resultados adecuados para el problema y se desplegaron correctamente para apoyarlo. Sin embargo, el equipo de apoyo dedicó su tiempo a resolver problemas con el sistema de calidad que no tenían nada que ver con la tarea original. Si la organización hubiera reconocido la nueva forma de trabajar y hubiera aumentado su sistema operativo, habría disuelto estos equipos de pruebas externos y colocado esas competencias en los equipos Scrum para permitir una mayor agilidad general.

3. Utilizar un ciclo de planificación y presupuestación ágil

A veces se hace referencia al proceso de presupuestación financiera como el latido del corazón de la empresa moderna. Es fácil entender por qué. Definen el ritmo mensual, trimestral y anual de una organización. También desempeñan un papel importante en la planificación estratégica a largo plazo. 

Los proyectos necesitan financiación para avanzar y, por tanto, los equipos ágiles que necesitan presupuestos están en deuda con este proceso. Si los presupuestos solo se publican una vez al año y el proceso financiero no es ágil, los equipos tendrán dificultades para destinar fondos a los proyectos y problemas más prometedores.

En algunos de nuestros clientes, hemos observado que los proyectos Agile se promocionan interna y externamente como grandes ejemplos de éxito. Sin embargo, cuando se habla con los equipos, se oye que se enfrentan a una ardua lucha por los recursos necesarios en comparación con los proyectos tradicionales. 

El resultado es que los proyectos prometedores o los cambios necesarios quedan aplazados hasta el ciclo de financiación del año siguiente, mientras que los proyectos de escaso valor o que fracasan continúan y consumen dinero. El coste global para la empresa en estos casos es sencillamente asombroso.

Sin embargo, este es uno de los principales impedimentos identificados por los equipos con los que trabajamos. 

Para ser ágil y potenciar la agilidad en toda la organización, hay que pensar como un inversor de capital riesgo:

• Utilizar previsiones renovables - Aumentar la frecuencia de los circuitos de retroalimentación y crear un mecanismo de reconocimiento y planificación en torno al cambio.
• Considere la posibilidad de instituir la presupuestación de base cero cuando proceda - Con frecuencia, las empresas utilizan los presupuestos del año pasado como punto de partida para determinar el presupuesto del año siguiente. Esto suele conducir a una mentalidad de gasto de "úselo o piérdalo" que genera una enorme cantidad de despilfarro. La presupuestación de base cero adopta el enfoque opuesto. En lugar de empezar con el año pasado como punto de partida, se parte de cero y sólo se aumentan las asignaciones después de justificar cada gasto basándose en proyecciones de beneficios.
• Asignar recursos en pequeñas cantidades con más frecuencia - Reasignar en función de los resultados y la información recibida. Deje de asignar fondos a las iniciativas de menor rendimiento y redoble la apuesta por lo que funciona.  
• Financiar personas, no proyectos - La mayoría de las empresas trabajan con un modelo de financiación de proyectos: deciden el coste del proyecto, examinan el rendimiento previsto de la inversión y lo financian en consecuencia para alcanzar el objetivo de ingresos o ahorro de costes que quieran lograr. A continuación, crean un equipo para llevarlo a cabo. En Scrum abogamos por un modelo de financiación persistente. Financiar equipos de personas (hay varias formas de hacerlo) y hacerles llegar proyectos o, idealmente, problemas que resolver. No calculamos el coste del proyecto por separado, sino que priorizamos la asignación del esfuerzo del equipo.

Recuerde que la planificación anual es, en el mejor de los casos, una suposición. Debe utilizar circuitos cortos de retroalimentación y saber cómo utilizar los datos que recopila para ser ágil.

4. Refactorice su proceso de adquisición

Si sus equipos se mueven con rapidez y disponen de presupuestos dinámicos, identificarán con frecuencia nuevos elementos que necesitan para seguir realizando sus proyectos de alto valor. Si se tarda seis meses en conseguir el personal o los equipos necesarios, todo el proceso se ralentiza. 

A menudo vemos que los equipos Scrum se mueven a un ritmo que el proceso de adquisición heredado de la empresa no puede manejar. 

Muchos, si no la mayoría, de los procesos de contratación se establecieron para mitigar el riesgo de un posible gasto excesivo en un producto o servicio. Sin embargo, cuando se intenta eliminar todos los riesgos, a menudo se crean otros nuevos debido a la ineficacia. Si su equipo de compras y sus proveedores adoptan el Manifiesto Ágil, ambos valorarán más la colaboración con el cliente que las negociaciones contractuales. Se ha demostrado que esto aumenta la velocidad de entrega. También puede reducir los costosos residuos generados por la falta de comunicación. 

Una cuestión planteada durante una conversación reciente con un socio que trabaja con el sector de la construcción. Su equipo hablaba con uno de sus proveedores, que acababa de entregar un artículo de seis cifras en una obra. El proveedor explicó lo difícil que era conseguir que la pintura rosa se adhiriera al tipo de metal utilizado. Había que enviar por avión productos químicos especiales y pintura para que funcionara. 

Cuando nuestro socio se puso en contacto con la oficina de adquisiciones y preguntó por qué el artículo tenía que ser rosa, el responsable de adquisiciones dijo "sólo tenía que ser brillante, pero tenía que elegir un color específico dentro de nuestro sistema, así que elegí el rosa". 

Los procesos burocráticos de aprovisionamiento, basados en los requisitos, costaron a la empresa decenas de miles de dólares al valorar el proceso de contratación en lugar de limitarse a tener un acuerdo de trabajo verdaderamente colaborativo con el proveedor.    

5. Desarrollar Prácticas ágiles de personal y recursos

Para que las transformaciones ágiles se hagan realidad, los equipos de capacitación de las personas (RRHH en muchas empresas) desempeñan un papel fundamental. ¿Por qué querría yo asumir el duro papel de ser un Scrum Master si la organización no lo reconoce como un puesto de trabajo y las responsabilidades entrarían en conflicto con la descripción de mi puesto? ¿Cómo gestionamos el talento y el reconocimiento de las personas si el Scrum Master y el Product Owner no son mi jefe directo? ¿Cómo gestionamos la jerarquía de títulos con funciones laborales? 

Para que una transformación Agile se afiance y sea sostenible, la organización debe adoptar estos cambios e identificar respuestas que se alineen con los resultados empresariales deseados. 

Por ejemplo, los incentivos son herramientas poderosas. Una vez que Agile empiece a afianzarse y sus equipos Scrum estén acelerando, tendrá que cambiar su estructura de incentivos para recompensar los comportamientos y patrones que ahora valora su organización.

Si el reconocimiento se basa únicamente en los méritos individuales, ¿por qué habría de cambiar la mentalidad y el comportamiento a favor del equipo? Si el reconocimiento del equipo se basa en la finalización de un proyecto concreto, ¿por qué cambiarían de dirección incluso cuando está claro que necesitan pivotar? 

Su organización necesita incentivar y recompensar a los equipos que aportan un alto valor. Por lo tanto, las recompensas y la compensación de los equipos deben estar alineadas con los KPI que utilices.  

Un equipo de operaciones del departamento de cuentas a pagar de uno de nuestros socios implantó recientemente Scrum. Nuestro cliente no realineó su programa de incentivos. La estructura de incentivos de este equipo se centraba en mantener su cola de tickets abiertos lo más reducida posible. Así que persiguieron ese objetivo agresivamente. Sin embargo, al centrarse únicamente en el tamaño de la cola, el equipo se vio incentivado a resolver de inmediato las solicitudes fáciles de procesar. Los demás quedaban a la espera.  

Ahora que el plazo de pago se había reducido considerablemente, los equipos estaban cumpliendo su objetivo declarado. Sin embargo, algunos proveedores cobraban antes de tiempo, mientras que otros proveedores estratégicos tenían sus facturas en cola durante meses antes de cobrar. 

A medida que la organización cambiaba de enfoque, el Product Owner acabó reajustando sus objetivos para centrarse en el objetivo empresarial de más alto nivel de los pagos puntuales y volvió a centrar la priorización del equipo en los términos de cada solicitud de pago, en lugar de tratar cada pago de la misma manera. Si los incentivos no se ajustan a los resultados deseados y (o) a los comportamientos necesarios para conseguirlos, la estructura de incentivos provocará fricciones con la transformación Agile.

6. Diseño de la organización

Para que su transformación Agile tenga éxito, su organización debe estar configurada de forma que los equipos y sus miembros reciban la supervisión y el apoyo al desarrollo que necesitan para ser eficaces. Hay que plantearse preguntas difíciles ahora que estamos en nuestro nuevo modelo.

¿Qué debe estar en un servicio compartido y qué puede externalizarse? ¿Qué competencias deben repartirse entre los equipos? ¿Cómo tratar a los expertos en la materia? ¿Qué hacemos con
los mandos intermedios? ¿Cómo incorporamos a contratistas y proveedores? Y muchas cosas más.

Si el propio organigrama no es ágil y las vías de comunicación no están optimizadas, el organigrama se defenderá. Y adivina quién gana casi siempre. 

Cuando las organizaciones no reflexionan de antemano sobre su estructura, pueden acabar en una situación en la que el personal con competencias similares esté infrautilizado en un grupo y sobreutilizado en otro.

Tomemos como ejemplo una empresa en la que trabajamos del sector financiero que sufrió una gran reorganización descendente. Crearon sus equipos Scrum para trabajar únicamente en los proyectos y cargas de trabajo previstos, en lugar de forjar equipos verdaderamente interfuncionales.

Entonces, COVID-19 lo cambió todo de repente.

Rápidamente se dieron cuenta de que esos equipos no estaban construidos con la flexibilidad suficiente para adaptarse fácilmente a la nueva realidad y tuvieron que relanzar nuevos equipos que fueran interfuncionales y pudieran adaptarse a los cambios.

La moraleja es que hay que crear los equipos para que el trabajo fluya hacia ellos. No hay que crear continuamente nuevos equipos para acomodar el trabajo, pues de lo contrario se perderían todas las ventajas de las estrechas relaciones de trabajo y la experiencia práctica que el equipo ha desarrollado. 

 Luego está la cuestión del escalado. Uno de los mantras de Scrum@Scale es que no hay que escalar a menos que sea necesario. Las capas innecesarias ralentizan una organización. 

Pero cuando necesites escalar, asegúrate de hacerlo de forma unificada. No añadas complejidad introduciendo lo que equivale a otro sistema operativo que desencadena otra ronda de conflictos de suma cero. 

Esta es una de las razones por las que la Marco Scrum@Scale tan estrechamente con el marco Scrum. 

7. Crear el espacio de trabajo ágil adecuado 

El lugar de trabajo puede definir el trabajo que se hace. Los entornos y herramientas de trabajo adecuados aumentan la productividad, la colaboración y la creatividad. Permiten al equipo trabajar juntos a la perfección.

Esto es tan cierto para los equipos virtuales como para los que están ubicados en un mismo lugar. 

Un entorno de trabajo inadecuado crea distracciones constantes e impide que el equipo aporte valor. Esto ocurre de muchas maneras. Si un experto en la materia es tan importante que no puede sentarse con el equipo o comunicarse virtualmente con él cuando es necesario, ¿qué valor tiene? ¿Están las paredes de la oficina tan llenas de obras de arte que no podemos hacer visible nuestro trabajo? Si el equipo está disperso, ¿dispone de las herramientas virtuales adecuadas para colaborar en tiempo real a larga distancia? ¿Hay pasos innecesarios en los procesos que ralentizan todo?

Acabo de hablar con un equipo que utilizaba una herramienta que permitía a varias personas trabajar simultáneamente en diapositivas. Su director general estaba asombrado de lo rápido que trabajaban. Cuando terminó la prueba gratuita, el CEO retiró el producto por cuestiones de costes. 

¿Qué valor tiene la rapidez y la posibilidad de que sus empleados trabajen juntos? Las organizaciones deben recordar que su propósito es crear valor y apoyar ese proceso de creación de valor. 

Abrazar el viaje

Abordar estas cuestiones aumentará en gran medida la probabilidad de que su transformación Agile tenga éxito. Así es como se crean sistemas operativos dinámicos que impulsan la innovación y la entrega de valor. Pero recuerda siempre que la creación es sólo el principio de tu viaje Agile. Los principales puntos de fricción de hoy no serán los puntos de fricción de dentro de un año. 

La transformación ágil no es un estado final. No hay una línea de meta claramente definida.  

Tendrá que inspeccionar y adaptar periódicamente su organización. Agile te ayuda a hacerlo.