Cinco errores al escalar Agile
Las grandes empresas buscan especialmente formas rápidas y sencillas de hacer la transición del desarrollo tradicional al ágil. Cuanto más rápido deba producirse una transición, más peligrosas son las trampas que se pasan por alto. El desarrollo ágil se basa más en la sostenibilidad que en simplemente hacer las cosas rápido. Por lo tanto, la dirección tiene una gran responsabilidad en el éxito de la transición ágil. Desde fuera, la transición parece exitosa, pero por dentro, los beneficios de la transición no se materializan.
Aquí hemos resumido cinco errores comunes en el camino hacia una organización ágil:
1. Agilidad fundamental
La transición a procesos ágiles es fácil. Se desregula un poco y se envía a algunas personas a formación. Después, la gente puede "hacer Scrum" – o elegir otro enfoque ágil. Pero visto en su conjunto, puede que hayas alcanzado el 1% – el 99% del camino aún está por delante. El viaje es largo todavía. En el corazón de la agilidad está el proceso de Inspeccionar+Adaptar.
Para que funcione, necesitas una mentalidad especial. Todos deben cuestionar implacablemente lo que está sucediendo – y hacer cambios cuando las cosas van en la dirección equivocada. Para anclar Inspeccionar+Adaptar de manera significativa en la organización, se necesitan dos cosas:
Primero, se debe desintoxicar la forma de trabajo existente. Los elementos de la cultura corporativa que desalientan a los desarrolladores a apropiarse de sus procesos deben ser eliminados. Para ello, muchos procesos de Comando+Control deben ser descartados y la gestión de los desarrolladores debe ser repensada fundamentalmente. ¡El cambio solo ocurrirá si se permite!
Después se debe crear una forma saludable de trabajar. Necesitas un sistema de gestión que anime a los desarrolladores a asumir la responsabilidad de sus propias acciones, decisiones, cambios, fracasos y éxitos. Esto requiere la creación de estructuras y procesos que valoren honestamente la contribución individual de cada persona – independientemente de si la dirección está satisfecha con la dirección en la que van o no. ¡Las personas solo harán su contribución si se les permite!
Hasta que se establezcan los cimientos de la agilidad, no habrá agilidad. Los equipos sin agilidad fundamental no se beneficiarán ni contribuirán a la escalabilidad ágil.
2. Herramientas y técnicas
Introducir las ceremonias de Scrum lleva solo un día, incluyendo la formación y la decisión. Esto te da la base para el "trabajo ágil". La planificación a corto plazo, las actualizaciones regulares del plan, el feedback del producto y la mejora incremental del proceso son esenciales. Con el tiempo, los desarrolladores pueden encontrar la forma óptima de trabajar. Solo hay que planificar mucho tiempo para la optimización si las prácticas de ingeniería aún no están establecidas. Los desarrolladores necesitan estar familiarizados con conceptos como el control de versiones, la integración continua, la automatización de pruebas, el diseño emergente, TDD, BDD, pair programming, convenciones de código – y mucho más que XP tiene para ofrecer. Deben decidir conscientemente cuáles de estas prácticas les son útiles en el contexto actual. Mientras los desarrolladores no estén familiarizados con estas prácticas, pueden ser "ritualmente ágiles", pero no practicar la agilidad. Un equipo sin las herramientas adecuadas puede incluso ralentizar la implementación del desarrollo escalado.
3. Espíritu de equipo
El espíritu de equipo, a menudo visto con sonrisa condescendiente como algo esotérico, es inmensamente importante para la mejora sistémica en la escalabilidad ágil. Muchos directivos piensan que los objetivos personales (hasta el stack ranking) son útiles para obtener empleados de alto rendimiento. La escalabilidad ágil, sin embargo, sirve principalmente para construir un sistema complejo y adaptativo en el que muchas personas contribuyen. La necesidad de contribuir al panorama general es mucho más importante que contribuir a tus propios objetivos. Aquí, "espíritu de equipo" significa que los individuos siempre deben subordinar sus propios intereses para impulsar la misión de la empresa. El espíritu de equipo no se trata tanto de "hacer cosas divertidas con otros" (por ejemplo, eventos de equipo como rafting, karting o paintball). Se trata principalmente de disfrutar haciendo cosas que ayudan a avanzar juntos.
Los desarrolladores necesitan dos cosas para esto: Primero, necesitan saber cómo pueden contribuir. Como esto depende mucho del caso individual, la contribución es principalmente autoorganización y motivación intrínseca. Segundo, deben saber que ser útil vale la pena. Cualquier cosa que cree una desventaja personal al ayudar a otros a lograr un objetivo común debe ser eliminada. Un ejemplo clásico de "espíritu de equipo" es el fútbol: hemos visto a menudo que el partido no lo gana el mejor jugador. El ganador es el mejor equipo. Es lo mismo en el desarrollo: los ases que se superan unos a otros no ganan. Se gana combinando fuerzas, reuniendo ideas y avanzando juntos. Los grupos de desarrolladores sin espíritu de equipo desperdician su energía en "empleo". ¡Un grupo escalado que no es un equipo utiliza solo una fracción de su potencial para lograr el objetivo común!
4. Transparencia
Muchas organizaciones fracasan debido a la falta de conocimiento del sistema global. No pueden optimizar globalmente. Los obstáculos clásicos a la transparencia existen en todos los niveles: desde el desarrollador que no sabe cómo el trabajo de un colega le afecta, hasta el directivo que no puede decir cuál es la Prioridad Absoluta 1. Esta falta de transparencia conduce a muchos problemas. Comienza con el desarrollador que inconscientemente torpedea el trabajo de sus colegas, y se extiende a equipos enteros trabajando en las cosas equivocadas. Nada de esto es deseable y cuanto más a menudo ocurre algo así, más crítico e importante es aumentar la transparencia.
Algunas organizaciones desperdician casi toda su capacidad gestionando problemas causados por la falta de transparencia. En tales situaciones, "trabajar arduamente" es probablemente una descripción más precisa que "escalar". Hay muchas palancas para aumentar la transparencia hasta el punto en que escalar tiene sentido. Algunas de ellas son:
¡Pon un Kanban – que todos puedan ver!
Un backlog central del que todos los equipos se sirvan
Propiedad colectiva del código como base para la "comunicación a través del código"
Andons: Monitorización de builds y "Detener la línea" basado en pruebas automatizadas
Planificación conjunta y revisiones conjuntas en las que solo se muestra el producto integrado
La transparencia es anti-proporcional a la sobrecarga y los problemas. En otras palabras: con la escalabilidad ágil, la transparencia es proporcional al ROI. Los equipos ágiles que carecen de transparencia no hacen una contribución significativa a los objetivos de negocio.
5. Foco
En muchas organizaciones, uno de los principales problemas es un enfoque equivocado en la carga de trabajo: se gestiona el trabajo y se llevan tareas a los empleados. La suposición básica aquí es que se crea valor manteniendo a todos "ocupados" al máximo. En una organización ágil, es al revés: llevamos personas al trabajo que vale la pena hacer. Sabemos que no hay correlación positiva entre la creación de valor y la carga de trabajo. Nos enfocamos en entregar un producto utilizable – terminar las cosas. Un problema clásico en muchas organizaciones es que al intentar que las personas trabajen a plena capacidad, muchas cosas están "en progreso": esto requiere cambio de tareas y coordinación. Pero incluso en los escenarios más triviales, la pérdida de foco resultante conduce a un ROI masivamente reducido y tiempos de entrega significativamente aumentados: gastamos demasiado tiempo tratando de averiguar por qué nada se termina – y muy poco tiempo tratando de terminar algo.
La idea principal detrás del foco es: cuesta mucho menos hacer primero lo incorrecto y luego lo correcto – que hacer dos cosas al mismo tiempo. Por trivial que suene, es difícil de implementar: toda la organización necesita una lista claramente ordenada de objetivos, y cada objetivo debe estar claramente priorizado. Hay exactamente una sola Prioridad 1. Luego, el "Work in Progress" debe estar estrictamente limitado. El foco requiere que los directivos repiensen fundamentalmente su actitud: aceptar que la "ociosidad" cuesta menos que la sobrecarga. Tampoco se puede obtener todo a la vez. Los equipos sin foco pueden estar "bien utilizados" pero son altamente ineficaces. Cuanto menos enfocados, más tiempo tardan en crear valor.
Resumen
La "escalabilidad ágil" que no se preocupa por las trampas mencionadas anteriormente probablemente se convertirá en un culto cargo. Desde fuera, la transición parece exitosa, pero por dentro, los beneficios de la transición están ausentes. Para transiciones ágiles exitosas, un enfoque común es incorporar expertos experimentados que hayan "luchado en primera línea" y ya conozcan las trampas.
Para evitar las trampas en un entorno escalado, recomendamos:
Apoyo de la dirección para la transición. Para cerrar las trampas, algunas cosas en la organización deben ponerse patas arriba. Esto requiere el pleno apoyo de la dirección.
Construir un Equipo de Transición Ágil (ATT) en el que participen tanto directivos como desarrolladores. El ATT tiene un backlog de cambio claro en el que todos trabajan juntos.
Coaching ejecutivo para las personas clave en la transición. Esto incluye a los responsables de línea, así como a Product Owners y Scrum Masters. ¡El coach externo necesita experiencia en escalabilidad ágil!
Coaching técnico ayuda a los equipos a obtener las herramientas adecuadas más rápido: ¡esto se amortiza muy rápidamente con un producto de mayor calidad!
Contratar un consultor para liderar la transición. Esta persona debe saber exactamente lo que está haciendo y debe trabajar sin concesiones. Debe tener el poder de impulsar incluso cambios impopulares.
Formación para todos en agilidad. En un entorno de formación seguro, el impacto de la transición es mucho más fácil de comunicar.
