Adopción de una cultura ágil

Si hay una lección que se debe aprender de la última década de "transformaciones ágiles", es que no existe una solución única para adoptar o implementar un enfoque ágil. Cada organización tiene necesidades, restricciones y requisitos diferentes. El seguimiento ciego de una receta no dará lugar al éxito.

El movimiento agile consiste en encontrar continuamente formas de mejorar la práctica de crear software. No se trata de un standup o retrospectiva diario perfecto. En su lugar, se trata de crear una cultura en la que lo correcto sucede más a menudo que lo contrario. Las actividades como standups y retrospectivas tienen su lugar, pero no cambiarán la cultura de una organización.

En este artículo se detallan los elementos fundamentales que cada organización necesita para crear una mentalidad y una cultura ágiles. Las recomendaciones no deben seguirse ciegamente. Cada organización debe aplicar lo que tiene sentido en un entorno determinado.

Programación y ritmo

No hay una longitud perfecta de sprint. Los equipos han tenido éxito con duraciones de sprint que van de una a cuatro semanas. Lo que más importa es la coherencia.

Seleccione una longitud de sprint que funcione para la cultura, el producto y el deseo de proporcionar actualizaciones de su organización. Por ejemplo, la división Herramientas para desarrolladores de Microsoft (aproximadamente 6000 personas) funciona en sprints de tres semanas. El equipo directivo no eligió esta longitud de sprint; proviene de comentarios directos de los equipos de ingeniería. Toda la división opera en esta programación de sprint de tres semanas. Los sprints se han convertido desde entonces en el latido de la organización. Ahora todos los equipos marchan al ritmo del mismo tambor.

Es importante elegir una longitud de sprint y mantenerla. Si hay varios equipos ágiles, todos deben usar la misma longitud de sprint. Si los comentarios impulsan un cambio, entonces sea receptiva. Se aclarará cuando el término correcto esté en vigor.

Una cultura de envío

Peter Provost, director de programas del grupo principal de Microsoft, dijo "No puede hacer trampas en el envío". La simplicidad y la verdad de esa declaración es una piedra angular de la cultura agile. Lo que Peter significa es que publicar tu software te enseñará cosas que no puedes comprender y no comprenderás a menos que realmente publiques tu software.

La naturaleza humana es retrasar o evitar hacer cosas hasta que sea absolutamente necesario. Esto no puede ser más cierto cuando se trata del desarrollo de software. Los equipos posponen los errores hasta el final del ciclo, no piensan en la configuración o actualización hasta que se ven obligados a hacerlo y, normalmente, evitan cosas como la localización y la accesibilidad cuando sea posible. Cuando este patrón surge, los equipos crean deuda técnica que tendrá que pagarse más adelante. Las operaciones de envío exigen que se pague toda la deuda. No puedes hacer trampas en el envío. Para establecer una cultura ágil, empiece por intentar enviar el producto al final de cada sprint. No será fácil al principio, pero cuando un equipo lo intenta, descubre rápidamente todas las cosas que deberían estar sucediendo, pero no.

Equipos saludables

No hay receta para el equipo ágil perfecto. Sin embargo, algunas características clave facilitan mucho el éxito.

Ubicar equipos juntos siempre que sea posible

¿Puede un equipo encontrar éxito con personas distribuidas en diferentes zonas geográficas? Sí, pero es más difícil. Cuando la gente está co-localizada y se sienta en la misma habitación, las conversaciones adecuadas tienden a ocurrir. Todavía es posible tener éxito con equipos ubicados en todo el mundo y diferentes zonas horarias. ¿Pero no tendría ese mismo equipo una ventaja sin todos esos obstáculos?

Mantener intactos los equipos durante un período de tiempo razonable

Permite a los equipos dominar el arte de crear software juntos. Cuando los equipos están desorganizados, se interrumpe cualquier química que hayan desarrollado. A veces es adecuado reorganizar, pero los equipos suelen ser más productivos cuando se les da tiempo para aprender a trabajar juntos. Como norma, intente mantener intactos los equipos durante al menos 12 meses.

Trabajo de equilibrio de carga, no personas

A veces, los equipos se retrasan y necesitan ayuda. Una táctica común para abordar esto es prestar a una persona de un equipo a otro. Sin embargo, eso puede ser contraproducente. Una mejor solución es distribuir la carga de trabajo a otro equipo, en lugar de equilibrar la distribución de las personas entre ellos. Extraer a una persona de un equipo para ayudar a otro equipo, lo que interrumpe a ambos equipos, puede frustrar a la persona que es trasladada, incluso si es temporal. Todo esto afecta a la productividad del equipo y, con toda probabilidad, impacta negativamente en la capacidad de recuperar el calendario.

Equilibrar la carga de trabajo en lugar de las personas permite a un equipo ya establecido avanzar y ayudar. Se convierte en una conversación sobre las prioridades, no sobre las personas.

Permitir que los equipos gestionen áreas funcionales, en lugar de capas de arquitectura

Esfuérzate por crear equipos verticales que posean áreas de funciones. Estos equipos son responsables del trabajo necesario para agregar características a su área, desde la base de datos a los cambios de la interfaz de usuario. El equipo está capacitado para ofrecer y gestionar una experiencia integral.

Cuando los equipos horizontales poseen capas de arquitectura, ningún único equipo es responsable de la experiencia de un extremo a otro. La adición de una característica requiere que varios equipos se coordinan y requiere un mayor nivel de administración de dependencias. La resolución de errores requiere que varios equipos investiguen si poseen el código necesario para corregir el error. Los errores se producen a medida que los equipos determinan que no es su error y lo asignan a otro equipo.

Los equipos de funcionalidades no tienen estos problemas. La propiedad y la responsabilidad son claras. Puede haber un lugar para algunos equipos basados en la arquitectura. Sin embargo, los equipos centrados verticalmente son más eficaces.

Pasos siguientes

A medida que los equipos se embarcan en su propia transformación ágil, tenga en cuenta estos principios fundamentales. Recuerde que no hay una receta única que funcione para cada organización. Las transformaciones ágiles son un recorrido. Realice cambios y aprenda de ellos. Con el tiempo, la organización desarrollará la cultura ágil que necesita.

Microsoft es una de las empresas ágiles más grandes del mundo. Obtenga más información sobre cómo Microsoft adoptó una cultura ágil para la planeación de DevOps.

Obtenga información sobre cómo Azure DevOps permite a los equipos adoptar y escalar una referencia cultural ágil.