Adopción de una cultura ágil

Si hay una enseñanza que ha dejado la última década de "transformaciones Agile", es que no existe una solución única cuando hablamos de adoptar o implementar un enfoque Agile. Cada organización tiene necesidades, restricciones y requisitos diferentes. Seguir meramente instrucciones sin pensar no llevará al éxito.

El movimiento Agile se refiere a la búsqueda continua de formas de mejorar el enfoque y la práctica de la creación de software. No se trata de un perfecto standup diario o de una mirada retrospectiva. Se trata de crear una referencia cultural en la que se haga lo correcto la mayoría de las veces. Las actividades como standups y miradas retrospectivas son importantes, pero no cambiarán la cultura de una organización.

En este artículo se explican los elementos fundamentales que todas las organizaciones necesitan para crear una mentalidad y una cultura Agile. Las recomendaciones no deben seguirse sin más. Cada organización debe aplicar lo que resulte lógico en un contexto determinado.

Programación y ritmo

No existe el sprint de duración perfecta. Hay equipos que han tenido éxito con sprints que oscilan entre una y cuatro semanas. Lo más importante es la coherencia.

Seleccione una duración de etapa de trabajo que se adecue a la cultura, el producto y el deseo de la organización para realizar actualizaciones. Por ejemplo, la división de Herramientas de desarrollo de Microsoft (que integran aproximadamente 6000 personas) trabaja con sprints de tres semanas de duración. El equipo directivo no eligió la duración del sprint, sino que es el resultado de los comentarios directos de los equipos de ingeniería. Toda la división opera con la misma programación de sprints 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 decidir la duración del sprint y respetarla. Si hay varios equipos de Agile, la duración del sprint deberá ser la misma para todos. Si los comentarios impulsan un cambio, entonces sea receptivo. Cuando el periodo que se aplique sea el adecuado, se verá con claridad.

Una cultura de envío

Peter Provost, Administrador principal de programas del grupo Microsoft, dijo: "No se puede engañar al transporte". La simplicidad y la verdad de esa declaración es una piedra angular de la cultura Agile. Lo que quiere decir Peter con esto es que el envío del software le enseñará cosas que de otra manera no comprenderá.

Está en la naturaleza humana 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 tareas hasta el final, no piensan en la configuración o actualización hasta que se ven obligados a hacerlo y habitualmente evitan cosas como la localización y la accesibilidad siempre que sea posible. Cuando este patrón surge, los equipos crean una deuda técnica que deberán pagar más adelante. El envío exige que se pague toda la deuda. No se puede engañar al transporte. Para establecer una cultura Agile, comience 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 suceder, pero no suceden.

Equipos saludables

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

Junte a los equipos siempre que sea posible

¿Puede ser exitoso un equipo con personas distribuidas en diferentes zonas geográficas? Sí, pero es más difícil. Cuando la gente se encuentra en una misma habitación, surgen las conversaciones correctas. Sin embargo, es posible tener éxito con equipos ubicados en todo el mundo y en diferentes zonas horarias. ¿Pero no sería mejor si ese equipo no tuviera todos esos obstáculos?

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

Permita a los equipos dominar el arte de crear software juntos. Cuando los equipos se mezclan, cualquier química que hayan desarrollado entre sí se interrumpe. 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 los equipos intactos durante al menos 12 meses.

Equilibre la carga de trabajo, no las personas

En ocasiones, hay equipos que se retrasan y necesitan ayuda. Una forma habitual de abordar esto es que un equipo preste a uno de sus miembros a otro equipo. Sin embargo, puede resultar contraproducente. Una mejor solución es equilibrar la carga de trabajo con otro equipo, en lugar de equilibrar la carga de las personas de los equipos. Sacar a una persona de un equipo para ayudar a otro genera una interrupción en ambos equipos y puede frustrar a la persona en cuestión, incluso si es temporal. Todo esto afecta a la productividad del equipo y es muy posible que afecte negativamente a la capacidad de volver a la programación establecida.

Equilibrar la carga de trabajo en lugar de las personas permite que un equipo que ya está establecido pueda avanzar y ayudar. Se convierte en una cuestión de prioridades, en lugar de una cuestión de las personas.

Permita que los equipos se apropien de las áreas de características, no de las capas de la arquitectura

Haga un esfuerzo por crear equipos verticales que se apropien de las áreas de características. Estos equipos son responsables del trabajo necesario para añadir características a su área, desde la base de datos hasta los cambios de la interfaz de usuario. El equipo está capacitado para ofrecer y una experiencia integral.

Cuando los equipos horizontales se encargan de las capas de la arquitectura, ningún equipo es responsable de la experiencia integral. La incorporación de una característica requiere que varios equipos se coordinen y requiere un mayor nivel de gestió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 al tiempo que los equipos determinan que no es su error y lo asignan a otro equipo.

Los equipos de características no tienen estos problemas. La propiedad y la responsabilidad están claras. Es posible que haya algunos equipos basados en la arquitectura. Sin embargo, los equipos con enfoque vertical son más eficientes.

Pasos siguientes

A medida que los equipos inicien su propia transformación Agile, tenga en cuenta estos principios fundamentales. Recuerde que no existe una receta única que funcione para todas las organizaciones. Las transformaciones Agile son un proceso. Realice cambios y aprenda de ellos. Con el tiempo, la organización desarrollará la cultura Agile necesaria.

Microsoft es una de las empresas Agile más grandes del mundo. Descubra más acerca de cómo Microsoft adoptó una cultura Agile para el planeamiento de DevOps.

Descubra cómo Azure DevOps permite a los equipos adoptar y escalar una cultura Agile.