Por qué la agilidad va mal y cómo solucionarlo

Con el espíritu de adaptarse cada vez más, las organizaciones se han apresurado a implementar un desarrollo de software ágil. Pero muchos lo han hecho de una manera que, de hecho, los hace menos ágiles. Estas empresas se han vuelto ágiles solo de nombre, ya que el proceso que han puesto en marcha a menudo acaba perjudicando la motivación y la productividad de los ingenieros.

Los procesos ágiles salen mal, porque a medida que las empresas se esfuerzan por lograr un alto rendimiento, se vuelven demasiado tácticos (se centran demasiado en los procesos y la microgestión) o se adaptan demasiado (evitan los objetivos a largo plazo, los plazos o la colaboración interfuncional). La clave es equilibrar el rendimiento táctico y el adaptativo. Tanto si es ingeniero como director de producto, hay algunos cambios que debe tener en cuenta para encontrar este equilibrio: 1. El desarrollo de software debe ser un proceso colaborativo y sin concesiones. 2. La unidad de entrega del equipo deberían ser los experimentos mínimamente viables. 3. El enfoque del equipo debe estar centrado en los clientes. 4. Utilice las casillas horarias para centrarse en la experimentación y evitar pérdidas. 5. El equipo debe organizarse para hacer hincapié en la colaboración. 6. El equipo debería cuestionar constantemente su proceso.

••• Con el espíritu de ser más[adaptativo](/2017/10/there-are-two-types-of-performance-but-most-organizations-only-focus-on-one), las organizaciones se han apresurado a implementar un desarrollo de software ágil. Pero muchos lo han hecho de una manera que, de hecho, los hace menos ágiles. Estas empresas se han vuelto ágiles solo de nombre, ya que el proceso que han puesto en marcha a menudo acaba perjudicando la motivación y la productividad de los ingenieros. ### Desarrollo ágil de software Marcos para[desarrollo de software adaptativo](https://en.wikipedia.org/wiki/Adaptive_software_development) como Agile, existen desde hace mucho tiempo y se han manifestado de muchas formas. Pero en el centro de la mayoría de estos modelos hay dos cosas: formular hipótesis (por ejemplo, qué es lo que se supone que debe lograr una función) y colaborar en todos los ámbitos de especialización en experimentos, todo ello con el espíritu de impulsar el aprendizaje y no ir a toda velocidad por un camino que demuestre ser incorrecto. Cuando el desarrollo ágil de software nació en 2001, articuló un conjunto de[cuatro principios fundamentales](http://agilemanifesto.org/) para mejorar el arte del desarrollo de software y mejorar la motivación de los directores de ingeniería y producto. 1. Las personas y las interacciones a través de los procesos y las herramientas 2. Software funcional a través de una documentación completa 3. La colaboración con los clientes a través de la negociación del contrato 4. Responder a un cambio siguiendo un plan Durante los últimos tres años, en nuestra investigación sobre la motivación humana, hemos analizado las prácticas de los ingenieros en más de 500 organizaciones diferentes mediante una combinación de enfoques experimentales y basados en encuestas. Hemos descubierto que lo que ocurre en la práctica se aparta enormemente de estos principios declarados. Por ejemplo, en la práctica habitual, _procesos y herramientas_ se han convertido en el motor del trabajo, no _personas e interacciones_. En una gran empresa incluida en la lista Fortune 100, el director de productos digitales nos dijo: «No se nos permite cuestionar el proceso ágil». En otra organización de Fortune 500, los directores de producto e ingenieros se comunican exclusivamente a través de sus herramientas, que se utilizan principalmente para que los primeros den órdenes a los segundos. Del mismo modo, la documentación suele triunfar sobre el software que funciona. En una gran empresa de tecnología, su equipo de productos dedicaba una cantidad considerable de tiempo inicial a escribir pequeños requisitos (denominados «historias de usuario»). Estos requisitos se pusieron en una cola de billetes como tareas en las que podía empezar a trabajar el próximo ingeniero disponible. El listón de documentación para mantener la cola en movimiento se hizo alto. En última instancia, este proceso se convirtió en uno de los muchos pequeños»[cascadas](https://en.wikipedia.org/wiki/Waterfall_model)», donde el trabajo pasa del departamento de productos a los diseñadores y luego a los de ingeniería. Este proceso es exactamente lo que Agile pretendía eliminar. No es de extrañar que el director de tecnología de la empresa dijera: «Mis ingenieros son como cocineros de comida rápida en la parte trasera de un restaurante». Cuando se trata de «responder al cambio en lugar de seguir un plan», a menudo se malinterpreta como «no tengo un plan». Por ejemplo, en una empresa de tecnología en rápido crecimiento, los equipos ágiles no intentaron entender la estrategia más amplia de la organización. Como resultado, sus intentos de iterar a menudo se centraban en funciones de bajo valor o sin importancia estratégica. Sin un plan, los equipos no sabrán cómo priorizar las acciones ni cómo invertir en esas acciones de manera responsable. Este principio ha llegado a hacer creer a los ingenieros que no es apropiado tener plazos o hitos comunes. Una cosa sería que estas aplicaciones erróneas realmente mejoraran la motivación y el rendimiento de los ingenieros, pero hemos descubierto que en la práctica ocurre lo contrario. La agilidad, cuando se practica como se describe anteriormente, reduce la[motivación total](/2015/11/how-company-culture-shapes-employee-motivation) de ingenieros. Como no se les permite experimentar, gestionar su propio trabajo y conectar con los clientes, tienen poco sentido del juego, el potencial y el propósito; en cambio, sienten presión emocional y económica para triunfar o inercia. Dejan de adaptarse, aprender y poner todo su esfuerzo en su trabajo. Por ejemplo, un socio de capital riesgo compartió con nosotros la historia de cómo una empresa de desarrollo de videojuegos siguió creando un producto durante un año, a pesar de que todos los ingenieros pensaban que no valía la pena jugar al juego. La empresa se dio cuenta de que habían desperdiciado mucho tiempo y dinero. Los procesos ágiles salen mal, porque a medida que las empresas se esfuerzan por lograr un alto rendimiento, se vuelven demasiado tácticos (se centran demasiado en los procesos y la microgestión) o se adaptan demasiado (evitan los objetivos a largo plazo, los plazos o la colaboración interfuncional). La clave es equilibrar el rendimiento táctico y el adaptativo. Tanto si es ingeniero como director de producto, he aquí algunos cambios que debe tener en cuenta para encontrar este equilibrio, de modo que pueda mejorar la motivación y el rendimiento de su equipo de ingeniería (o de cualquier otro). ### 1. El desarrollo de software debe ser un proceso colaborativo y sin concesiones. En lugar de un proceso en el que una persona escriba los requisitos (incluso los más pequeños) mientras otra los ejecuta, todo ello sin una estrella polar estratégica que lo guíe, un equipo que se esfuerce por lograr una verdadera agilidad debería tener un _sin entrega_ proceso frente a un proceso en el que una persona escribe los requisitos y la otra los ejecuta. En un proceso sin traspasos, el director de producto y los ingenieros (y cualquier otra parte interesada) colaboran de principio a fin en el diseño de una función. En primer lugar, el equipo, incluidos los ejecutivos, debe articular los «desafíos» estratégicos del equipo. Los desafíos adoptan la forma de una pregunta, siempre centrada en mejorar algún tipo de resultado o impacto en los clientes. Piense en ellas como la misión detallada de un equipo en forma de pregunta para fomentar una reflexión expansiva. Todo el equipo, incluidos los patrocinadores ejecutivos (y los clientes), desarrolla y repite los desafíos en sí. Se pide a todas las personas del equipo (o de cualquier equipo, de hecho) que aporten ideas a cada desafío cuando quieran. Por ejemplo, en un banco, un desafío era: «¿cómo podemos ayudar a los clientes a estar mejor preparados para posibles crisis financieras?» Otra fue: «¿Cómo podemos hacer que sea más divertido y menos difícil para los clientes mantener hábitos financieros saludables?» Estos desafíos generaron docenas de ideas de muchas personas diferentes. Entonces, en lugar de que alguien escriba los requisitos mientras otra persona los ejecuta, estos equipos desarrollan y maduran una idea de forma colaborativa, desde un borrador hasta una hipótesis comprobable. ### 2. La unidad de entrega del equipo deberían ser los experimentos mínimamente viables. Los equipos suelen darse cuenta de que pierden tiempo adaptándose demasiado. Para evitarlo, no solo se deben formar ideas para un desafío estratégico, sino que también se deben ejecutar con experimentos rápidos destinados a aprender lo suficiente como para saber qué es lo que funciona para los clientes. En otras palabras, deberían maximizar su «velocidad hacia la verdad». Para reducir el esfuerzo desperdiciado y aumentar el derecho del equipo a tomar decisiones, los experimentos deberían ser breves. Si es posible, el experimento no debería durar más de una semana. A veces, esto requiere que el equipo minimice una función a lo que sea absolutamente necesario para poner a prueba su suposición más débil. A veces significa que el equipo no codifica, sino que completa un experimento «fuera de línea» mediante la investigación. ### 3. El enfoque del equipo debe estar centrado en los clientes. El proceso de creación de software (incluso el software de uso interno) debe estar totalmente centrado en los clientes. En el más simple de los casos, estos principios deberían ser válidos: - Los «desafíos» siempre se enmarcan en torno al impacto en los clientes. - Las reuniones de resolución de problemas siempre comienzan con una actualización de los clientes, y en estas conversaciones se incluye con frecuencia a representantes de primera línea. - Cada experimento se basa en una hipótesis centrada en los clientes. De esa manera, el equipo puede hacerse responsable del resultado pronosticado por el experimento. Sin embargo, lo que es aún más importante es que los ingenieros vean con sus propios ojos cómo los clientes utilizan sus productos. Esto requiere que la primera línea y los ingenieros trabajen juntos para comprobar si el producto está teniendo un impacto en los clientes. ### 4. Utilice los plazos para centrarse en la experimentación y evitar el desperdicio. Curiosamente, el desarrollo de software adaptativo fomenta los plazos como una forma de garantizar que en el experimento se realiza la inversión justificada y de indicar el nivel de calidad aceptable de una función determinada. Por otro lado, los profesionales habituales de la metodología ágil evitan los plazos o plazos, por miedo a que los plazos se utilicen para generar presión emocional. Una de las peores sensaciones para un desarrollador de software es pasar unos meses trabajando en algo que acaba no siendo útil. Esto lo llena de presión emocional («Decepciono a todo el mundo») y de una sensación de inercia («¿por qué hago esto?»). Para evitar este resultado, querrá tener claro hasta dónde debe ir un ingeniero antes de comprobar si la dirección sigue siendo correcta. Cuanto mayor sea la incertidumbre en la hipótesis de un equipo y mayor sea el riesgo, más corta debería ser la pista. Con eso en mente, el plazo no es una fecha límite. Es una restricción que debería guiar el nivel de profundidad y calidad de un experimento antes de una prueba real. De esta manera, los plazos pueden aumentar la motivación total. ### 5. El equipo debe organizarse para hacer hincapié en la colaboración. Para garantizar que se acabe con un proceso sin traspasos, las distintas partes interesadas involucradas deberían funcionar como un solo equipo multifuncional, también conocido como módulo. El objetivo del módulo es impulsar la colaboración. Cada módulo debe contener el conjunto completo de expertos necesarios para ofrecer un gran producto. Esto puede incluir a los altos ejecutivos. En una organización, por ejemplo, los grupos de productos incluyen un director de producto, un ingeniero de front-end, un ingeniero de back-end, un diseñador, un ingeniero de calidad y un representante a tiempo parcial del servicio de atención al cliente y un alto ejecutivo de una función de control. En muchas organizaciones, hay señales reveladoras de «cápsulas falsas», equipos que se hacen llamar cápsulas pero que en realidad no funcionan de esa manera. Las señales de cápsulas falsas incluyen: - Los expertos están en equipos «alineados» diferentes, no en el mismo equipo. Por ejemplo, un equipo de producto tiene «equipos de sprint» dedicados a la ingeniería. No son cápsulas. - El equipo utiliza herramientas que impiden una colaboración real. Por ejemplo, cuando preguntaron a un equipo de ingeniería por qué habían elegido las herramientas de software ágiles que utilizaban, dijeron: «Estas herramientas _impedir_ ejecutivos por participar en nuestro trabajo». Todo lo que hace es perpetuar un ciclo de desconfianza. - De hecho, las funciones de ingeniería y producto tienen objetivos diferentes a los de arriba. Los ejecutivos de ambas funciones utilizan su poder jerárquico para que sus empleados prioricen los objetivos de la función por encima de todos los demás, incluidos los objetivos de su grupo. En última instancia, estos conflictos provocan choques en los equipos de trabajo que impiden un verdadero trabajo en equipo. - Los procesos de talento rígidamente jerárquicos, como las calificaciones de rendimiento, los títulos jerárquicos, la presión para conseguir un ascenso y los sistemas de subida o baja destruyen el trabajo en equipo necesario para que las cápsulas funcionen bien. Estos sistemas harán que los miembros del equipo estén más en deuda con su jefe que con el cliente de su equipo o harán que los miembros del equipo compitan entre sí. De cualquier manera, no funcionarán como un equipo. Dicho de otra manera, cuanto más fuertes sean los silos de una organización, más personas resolverán las necesidades de su silo en lugar de las necesidades de su equipo. Esto hace que la colaboración y el consenso sean muy difíciles de lograr sin una escalada constante. ### 6. El equipo debería cuestionar constantemente su proceso. Una famosa máxima del diseño de ingeniería se conoce como Ley de Conway. Dice: _cualquier organización que diseñe un sistema producirá un diseño cuya estructura sea una copia de la estructura de comunicación (es decir, procesos) de la organización._ En otras palabras, si es una organización monolítica, producirá diseños monolíticos. Si está organizado por segmentos de usuarios, su producto se optimizará para esa estructura. Si quiere anular la Ley de Conway, la mejor práctica es ajustar constantemente su estructura y sus procesos para adaptarlos al problema en cuestión. Esto requiere equipos que tengan procesos y estructuras simples y ligeros que cuestionen y modifiquen constantemente. Por lo tanto, en lugar de crear la «agilidad» como una religión que no pueda cuestionarse, los equipos de ingeniería deberían tener el hábito de diagnosticar e iterar constantemente el modelo operativo de su propio equipo. En los mejores ejemplos que hemos visto, mensualmente, los equipos diagnostican su modelo operativo y deciden si es necesario cambiarlo para producir un producto mejor. *** La capacidad de atraer, inspirar y retener el talento en productos digitales se está convirtiendo en una misión fundamental para las organizaciones. La mayoría de las organizaciones han sido víctimas de un mensaje simple: implementen la metodología ágil como una serie de ceremonias y todo mejorará. Lamentablemente, este no suele ser el caso cuando se pierde el lado humano de la ecuación. Volviendo a lo básico de[motivación](/2015/11/how-company-culture-shapes-employee-motivation) y[rendimiento adaptativo](/2017/10/there-are-two-types-of-performance-but-most-organizations-only-focus-on-one), puede crear una organización que sea verdaderamente ágil.