Escalado de Agile a equipos de gran tamaño

Las palabras grandes y Agile no suelen usarse en la misma frase. Las grandes organizaciones han ganado la reputación de ser lentas. Sin embargo, eso está cambiando. Muchas organizaciones de software de gran tamaño están realizando correctamente la transformación en Agile. Están aprendiendo a escalar principios ágiles con o sin marcos populares, como SAFe, LeSS o Nexus.

En Microsoft, una de estas organizaciones usa Agile para crear productos y servicios enviados bajo la marca DevOps de Azure. Este grupo tiene 35 equipos de desarrollo de funcionalidades que lanzan sus actualizaciones a producción cada tres semanas.

Cada equipo de Azure DevOps posee funcionalidades de principio a fin y más allá. Son propietarios de las relaciones de los clientes. Administran su propio backlog de producto. Escriben y comprueban el código en la rama de producción. Cada tres semanas, se implementa la rama de producción y la versión se convierte en pública. A continuación, los equipos supervisan el estado del sistema y corrigen problemas de sitio activo.

Según los principios ágiles, los equipos autónomos son más productivos. Una organización ágil quiere que sus equipos tengan control sobre su ejecución diaria. Pero la autonomía sin alineación daría lugar al caos. Docenas de equipos que trabajan de forma independiente no producirían un producto unificado y de alta calidad. La alineación proporciona a los equipos su propósito y garantiza que cumplen los objetivos de la organización. Sin alineación, incluso los equipos de mejor rendimiento fracasarían.

Para escalar Agile, debe habilitar la autonomía del equipo al tiempo que garantiza la alineación con la organización.

Para administrar el delicado equilibrio entre la alineación y la autonomía, los líderes de DevOps deben definir una taxonomía, definir un proceso de planificación y usar chats de características.

Definición de una taxonomía

Un equipo de Agile, y la organización agile más grande a la que pertenece, necesitan un trabajo pendiente claramente definido para ser exitoso. Los equipos tendrán dificultades para tener éxito si los objetivos de la organización no están claros.

Para establecer objetivos claros y indicar cómo contribuye cada equipo a ellos, la organización debe definir una taxonomía. Una taxonomía claramente definida crea la nomenclatura de una organización.

Una taxonomía común es epopeyas, características, historias y tareas.

Epopeyas

Las epopeyas describen las iniciativas importantes para el éxito de la organización. Las épicas pueden requerir varios equipos y varios sprints para completarse, pero tienen un final. Las epopeyas tienen un objetivo claramente definido. Una vez alcanzado, la epopeya se cierra. El número de epopeyas en curso debe ser manejable para mantener la organización centrada. Las epopeyas se dividen en características.

Características

Las características definen la nueva funcionalidad necesaria para lograr el objetivo de una epopeya. Las características son la unidad de lanzamiento; representan lo que se lanza al cliente. Las notas de la versión publicadas se pueden elaborar en función de la lista de funcionalidades completadas recientemente. Las características pueden tardar varios sprints en completarse, pero deben tener un tamaño para garantizar un flujo de valor coherente al cliente. Las características se dividen en historias.

Stories

Los casos definen el valor incremental que el equipo debe entregar para crear una característica. El equipo divide la característica en partes incrementales. Es posible que un único artículo completado no proporcione un valor significativo al cliente. Sin embargo, una historia completa representa software de calidad de producción. Las historias son la unidad de trabajo del equipo. El equipo define las historias necesarias para completar una característica. Las historias pueden dividirse opcionalmente en tareas.

Tasks

Las tareas definen el trabajo necesario para completar un artículo.

Iniciativas

Esta taxonomía no es un sistema que se adapte a todas las situaciones. Muchas organizaciones presentan un nivel superior a las epopeyas denominadas iniciativas.

Los nombres de cada nivel se pueden adaptar a su organización. Sin embargo, los nombres definidos anteriormente (épicas, características, historias) se usan ampliamente en el sector.

Línea de autonomía

Una vez establecida una taxonomía, la organización debe dibujar una línea de autonomía. La línea de autonomía es el punto en el que la propiedad del nivel pasa de la administración al equipo. La administración no interfiere con los niveles que pertenecen al equipo.

En el ejemplo siguiente se muestra la línea de autonomía dibujada debajo de las características. La administración posee epopeyas y características, que proporcionan alineación. Los equipos poseen historias y tareas, y tienen autonomía sobre cómo las ejecutan.

En este ejemplo, la administración no indica al equipo cómo descomponer historias, planear sprints ni ejecutar trabajo.

Sin embargo, el equipo debe asegurarse de que su ejecución se alinee con los objetivos de la administración. Aunque un equipo posee su acumulación de historias, debe alinear esta acumulación con las funciones asignadas.

Planning

Para escalar la planificación ágil, un equipo necesita un plan para cada nivel de la taxonomía. Sin embargo, es importante iterar y actualizar el plan. Este proceso se denomina planificación gradual de oleadas.

El plan proporciona dirección para un período fijo de tiempo con calibración esperada a intervalos regulares. Por ejemplo, un plan de 18 meses podría calibrarse cada seis meses.

Este es un ejemplo de métodos de planificación para cada nivel de una taxonomía: epopeyas, características, historias, tareas.

Vision

La visión se expresa a través de epopeyas y establece la dirección a largo plazo de la organización. Las epopeyas definen lo que la organización quiere completar en los próximos 18 meses. La administración posee el plan y la calibra cada seis meses.

La visión se presenta en una reunión general. Dado que la visión está pensada para ser ambiciosa y mucho puede cambiar durante ese período de tiempo, espera lograr unos 60% de la visión.

Temporada

Una temporada se describe a través de características y establece la estrategia para los próximos seis meses. Las características determinan lo que la organización quiere destacar a sus clientes. La administración gestiona el plan estacional y presenta la visión y los planes estacionales en una reunión general. Todos los planes de equipo deben alinearse con el plan estacional de la administración. Espere lograr aproximadamente 80% del plan estacional.

Plan de 3 sprints

El plan de 3 sprints define las historias y características que el equipo completará en los próximos tres sprints. El equipo posee el plan y lo calibra cada sprint. Cada equipo presenta su plan a la dirección a través del chat de características (consulte a continuación). El plan especifica cómo se alinea la ejecución del equipo con el plan estacional de 6 meses. Espere lograr aproximadamente 90% del plan de 3 sprints.

Plan de sprint

El plan de sprint define las historias y características que finalizará el equipo en el siguiente sprint. El equipo posee el plan de sprint y lo envía por correo electrónico a toda la organización para lograr una transparencia completa. El plan incluye lo que el equipo ha logrado en el sprint anterior y su enfoque para el siguiente sprint. Espere lograr aproximadamente 95% del plan de sprint.

Línea de autonomía

En este ejemplo, la línea de autonomía se dibuja para mostrar dónde los equipos tienen autonomía de planificación.

Como se indicó anteriormente, la administración no amplía la propiedad por debajo de la línea de autonomía. La administración proporciona instrucciones sobre el uso de los planes de visión y temporada y, a continuación, proporciona a los equipos autonomía para crear planes de sprint y sprint 3.

Chats de funciones: donde la autonomía se encuentra con la alineación

Un chat de características es una reunión de baja ceremonia en la que cada equipo presenta su plan de 3 sprints a la administración. Esta reunión garantiza que los planes de equipo se alineen con los objetivos de la organización. También ayuda a la administración a mantenerse informado sobre lo que hace el equipo. Aunque el plan de 3 sprints está calibrado cada sprint, las reuniones de funciones se realizan según sea necesario, normalmente cada uno a tres sprints.

Una reunión de chat sobre funciones asigna 15 minutos a cada equipo. Con 12 equipos de funciones, estas reuniones se pueden programar para durar aproximadamente tres horas. Cada equipo prepara una presentación de 3 diapositivas, con las siguientes:

Características

En la primera diapositiva se describen las funcionalidades que el equipo habilitará en los tres próximos sprints.

Deuda

En la siguiente diapositiva se describe cómo el equipo administra la deuda técnica. La deuda es todo lo que no cumple con los estándares de calidad de la dirección. El director de ingeniería establece las barras de calidad, que son las mismas para todos los equipos (alineación). Entre las barras de calidad de ejemplo se incluyen el número de errores por ingeniero, el porcentaje de pruebas unitarias superadas y los objetivos de rendimiento.

Problemas y dependencias

Los problemas y dependencias enumerados en la diapositiva final incluyen todo lo que afecte al progreso del equipo, como los problemas que el equipo no puede resolver o las dependencias de otros equipos que necesitan escalación.

Cada equipo presenta sus diapositivas directamente a la administración. El equipo presenta cómo se alinea su plan de 3 sprints con el plan estacional de 6 meses. El liderazgo formula preguntas aclarantes y sugiere cambios en la dirección. También pueden solicitar reuniones de seguimiento para resolver problemas más profundos.

Si el plan de un equipo no se alinea con las expectativas de la administración, la administración puede solicitar un nuevo plan. En este caso raro, el equipo replanificará y programará una segunda sesión de chat de funcionalidades para revisar.

Confianza: el pegamento que mantiene la alineación y la autonomía unidos

Al practicar Agile a escala, la confianza es un camino de doble sentido:

• La administración debe confiar en los equipos para hacer lo correcto. Si la administración no confía en los equipos, no dará autonomía a los equipos.

• Un equipo obtiene confianza al entregar de forma coherente código de alta calidad. Si los equipos no son de confianza, la administración no les dará autonomía.

La administración debe proporcionar planes claros para que los equipos se alineen y luego confiar en que sus equipos los ejecuten. Los equipos deben alinear sus planes con la organización y ejecutarse de forma confiable.

A medida que las organizaciones buscan escalar Agile a escenarios más grandes, la clave es proporcionar autonomía a los equipos mientras se asegura de que están alineados con los objetivos de la organización. Los bloques de construcción críticos son la propiedad claramente definida y una cultura de confianza. Una vez que una organización tiene esta base en su lugar, encontrará que Agile puede escalar muy bien.

Pasos siguientes

Hay muchas maneras de que un equipo de cualquier tamaño empiece a ver las ventajas hoy en día. Consulte algunas de estas prácticas escalables.

Obtenga información sobre las características de Azure DevOps para la administración y visibilidad de la carteraen todos los equipos.

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