Seamos realistas, Agile ha tenido un éxito notable en una transformación ágil de la forma en que las organizaciones piensan sobre que fabrican y cómo entregan productos y servicios.
Lo que comenzó como una forma para que los ingenieros de software entregaran software de mayor calidad de manera más predecible, ahora se ha convertido en el sistema operativo predeterminado para la mayoría de las organizaciones. En su manera de trabajar.
Las “transformaciones” ágiles que estas organizaciones han emprendido normalmente comienzan con los equipos de ingeniería de software (supongo que no es una gran sorpresa para nadie) y luego se extienden para incluir otros equipos de productos digitales, diseño y UX, marketing, recursos humanos y, en algunos casos, incluso legales y finanzas.
El manifiesto Agile originalmente se escribió para el desarrollo de software. La guía Scrum original se escribió pensando en los desarrolladores de software. El 100% de los autores originales del manifiesto eran ingenieros de software o estaban relacionados con la indústria del software.
A medida que el alcance de la agilidad organizacional y, quizás más importante, crece más allá de los equipos de tecnología, otros departamentos se están asimilando en un proceso que nunca fue diseñado para incluirlos. Y evidentemente tiene muchas lagunas y problemas.
Se ven obligados a pensar de manera diferente, a replantear su trabajo y sus formas de trabajar en formas alienas que no se alinean naturalmente con la forma en que siempre han hecho las cosas.
No es de extrañar entonces que muchos equipos no tecnológicos hayan comenzado a sentir que se les está imponiendo “hacer agilidad”, en muchos casos en contra de su voluntad o de su manera de trabajar.
Esos equipos se resienten. Lo rechazan. En algunos casos incluso lo odian.
Empieza a tomar forma una mentalidad de víctima. “No pedí esto. Todo estaba bien de la forma en que trabajábamos antes”. Y se acaban planteando “Por qué cambiamos?”
El resentimiento crece y pronto hay una clara mentalidad de nosotros contra ellos en el lugar donde “ellos” están “haciendo esto” a “nosotros”. Eso es lo que nos impide hacer el mejor trabajo que podemos. Esto nos hace quedar mal y no mejorar.
Mi consejo genuino y profundo, detente. No hay víctimas en una transformación ágil. Ni buenos ni malos.
¿Es Agile la solución mágica para todo lo que aflige al mundo empresarial? No. Ni mucho menos.
¿Puede una aplicación de principios ágiles diseñados para fomentar el aprendizaje, la mejora continua y un enfoque en el cliente ayudar a todos en la empresa a ofrecer más valor a sus clientes? Absolutamente sí. No hay discusión aquí.
En primer lugar, usted, sus colegas de ingeniería, su jefe y su director ejecutivo están interesados en hacer que sus clientes tengan éxito.
¿Podemos estar de acuerdo en eso? (Eso espero, de lo contrario, tiene peces más grandes para freír y problemas más complejos que atender.).
En segundo lugar, una comprensión más profunda de su cliente, una mejor gestión del riesgo, una mayor flexibilidad (también conocida como agilidad de negocio) en lo que está trabajando y cuándo cambiar de rumbo.
Todo esto contribuye en la entrega de valor más rápida, ¿no? (Nuevamente, supongo que estamos de acuerdo aquí).
Ahora, soy consciente de que la forma en que se implementan Agile, Scrum, Kanban y SAFe no siempre refleja estos valores.
Sin embargo, aquí es exactamente donde se encuentra su oportunidad de colaborar con sus colegas para construir un proceso ágil mejor y más inclusivo dentro de su organización.
En lugar de cruzar los brazos, pisar fuerte y decir: “No es así como trabajamos y yo me niego a participar en esto”, considere este enfoque: “El trabajo que hacemos normalmente lleva más de dos semanas.”
En cada sprint creemos que podemos entregar el 30% de nuestra contribución total, pero a medida que la retroalimentación llega de un sprint a otro, podemos ajustar continuamente el 30% posterior que contribuimos al producto / proyecto / servicio que estamos construyendo “.
Lo que está haciendo allí es reconocer que el proceso, tal como está diseñado actualmente, no es compatible con su forma de trabajar actual explicando lo que puede hacer dentro del marco existente y cómo lo usaría en el futuro para ajustar las contribuciones futuras.
Más importante aún, ha iniciado un diálogo con sus colegas sobre la mejor forma de colaborar en este nuevo mundo de la agilidad de negocio.
No eres una víctima. Eres un socio. Los socios negocian. Experimentan. Miran retrospectivamente y ajustan el curso basándose en los aprendizajes. Y sobre forman parte del mundo, no son un mundo aparte.
Encuentro que los equipos a menudo pasan por alto la aplicación del mantra scrum, “inspeccionar y adaptar” al proceso en sí. ¿Algún proceso es 100% correcto la primera vez que un equipo lo prueba? No.
La versión de ágil de su empresa (o equipo) será diferente a la de otras empresas. Si no le gusta la forma en que está funcionando, lleve esas preocupaciones a sus retrospectivas. La transformación ágil siempre es contextual.
Rechazar una nueva forma de trabajar con una mentalidad de víctima conduce con negatividad, una pared que sus colegas ahora tienen que escalar para superarla.
Liderar con positividad, objetividad y la voluntad de aprender juntos sienta las bases para la colaboración continua y la salud del equipo. Si no es así como se está acercando a tu departamento, no responda de la misma manera.
En tu lugar, ofrece tus inquietudes, posibles impactos y sugerencias para experimentos de proceso. Si mi suposición anterior aún se mantiene, todos ustedes tienen el mismo objetivo en mente: lograr que el cliente tenga éxito.
Y si ese es el caso, nadie es una víctima. Todos somos colegas buscando continuamente una mejor manera de trabajar juntos.
