Escalado de la cultura ágil a equipos grandes
Las palabras grande y Agile no suelen usarse en la misma frase. Las grandes organizaciones se han ganado la fama de ser lentas. Sin embargo, la situación está cambiando. Muchas grandes empresas de software están llevando a cabo con éxito la implantación de Agile. Están aprendiendo a escalar los principios de Agile con o sin marcos populares como SAFe, LeSS o Nexus.
En Microsoft, una organización utiliza Agile para crear productos y servicios que se distribuyen bajo la marca Azure DevOps. Este grupo tiene 35 equipos de características que pasan a producción cada tres semanas.
Todos los equipos de Azure DevOps son propietarios de las características desde su creación hasta su finalización y más allá. Son dueños de las relaciones con los clientes. Gestionan su propia cartera de productos. Escriben y comprueban el código en la rama de producción. Cada tres semanas se despliega la rama de producción y la actualización se hace pública. A continuación, los equipos supervisan el estado del sistema y solucionan los problemas en directo.
Según los principios ágiles, los equipos autónomos son más productivos. Una organización Agile quiere que sus equipos tengan control sobre su ejecución diaria. Pero la autonomía sin alineación llevaría al caos. Docenas de equipos que trabajan de forma independiente no producirían un producto unificado y de alta calidad. La alineación otorga a los equipos su propósito y garantiza que cumplan los objetivos de la organización. Sin alineación, incluso los equipos con mejor rendimiento fracasarían.
Para escalar Agile, hay que permitir la autonomía del equipo al tiempo que se garantiza la alineación con la organización.
Para administrar el delicado equilibrio entre alineación y autonomía, los líderes de DevOps necesitan definir una taxonomía, definir un proceso de planeamiento y utilizar charlas de características.
Definición de una taxonomía
Un equipo de Agile, y la organización más grande de la que forma parte, requieren una cartera de pedidos claramente definida para tener éxito. Los equipos tendrán dificultades para tener éxito si los objetivos de la organización no están claros.
Para fijar objetivos claros y establecer cómo cada equipo puede colaborar en su consecución, la organización debe definir una taxonomía. Una taxonomía claramente establecida crea la nomenclatura de una organización.
Una taxonomía habitual es epopeyas, características, casos y tareas.
Epopeyas
Las epopeyas describen iniciativas importantes para el éxito de la organización. Las epopeyas pueden llevar varios equipos y varios sprints, pero no carecen de fin. Las epopeyas tienen un objetivo claramente definido. Una vez que se alcanza el objetivo, 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 las nuevas funcionalidades necesarias para hacer realidad el objetivo de una epopeya. Las características son la unidad de distribución; representan lo que se entrega al cliente. Las notas de distribución pueden elaborarse a partir de la lista de características que se han completado recientemente. Las características pueden llevar varios sprints para completarse, pero deben dimensionarse para garantizar un flujo constante de valor para el cliente. Las características se dividen en casos.
Casos
Los casos definen el valor añadido que el equipo debe aportar para crear una característica. El equipo divide la característica en partes graduales. Es posible que un único caso no aporte un valor significativo al cliente. Sin embargo, un caso representa un software de calidad de producción. Los casos son la unidad de trabajo del equipo. El equipo establece los casos necesarios para completar una característica. Los casos se desglosan opcionalmente en tareas.
Tareas
Las tareas establecen el trabajo necesario para completar un caso.
Iniciativas
Esta taxonomía no es un sistema universal. Muchas organizaciones incorporan un nivel superior a las epopeyas que llaman iniciativas.
Los nombres de cada nivel pueden adecuarse a las necesidades de la organización. Sin embargo, los conceptos definidos anteriormente (epopeyas, características, casos) se usan ampliamente en el sector.
Línea de autonomía
Una vez que se fija una taxonomía, la organización debe trazar una línea de autonomía. La línea de autonomía es el punto en el que la propiedad del nivel se traslada de la administración al equipo. La administración no interviene en los niveles que son propiedad del equipo.
El ejemplo a continuación muestra la línea de autonomía trazada debajo de las características. La administración es propietaria de las epopeyas y las características, lo que genera alineación. Los equipos son propietarios de los casos y las tareas, y tienen autonomía sobre cómo se ejecutan.
En este ejemplo, la administración no indica al equipo cómo dividir los casos, planear los sprints o ejecutar el trabajo.
El equipo, sin embargo, debe garantizar que la ejecución se ajuste a los objetivos de la administración. Aunque un equipo sea propietario de su cartera de historias, debe alinearla con las características que se le hayan asignado.
Planificación
Para escalar el planeamiento de Agile, un equipo debe contar con un plan para cada nivel de la taxonomía. Sin embargo, es importante repetir y actualizar el plan. Este proceso se denomina planeamiento por oleadas.
El plan ofrece orientación durante un periodo fijo de tiempo con una estimación de ajuste a intervalos regulares. Por ejemplo, un plan de 18 meses podría ajustarse cada seis meses.
Este es un ejemplo de métodos de planeamiento para cada nivel de una taxonomía: epopeyas, características, casos, tareas.
Visión
La visión se expresa a través de las epopeyas y establece la orientación de la organización en el largo plazo. Las epopeyas establecen aquello que la organización desea completar en los próximos 18 meses. La administración es propietaria del plan y lo ajusta cada seis meses.
La visión se presenta en una reunión general. Como la visión pretende ser ambiciosa y muchas cosas pueden cambiar en ese lapso de tiempo, se espera conseguir alrededor del 60 % de la misma.
Temporada
Una temporada se describe a través de las características y establece la estrategia para los próximos seis meses. Las características definen lo que la organización quiere transmitir a sus clientes. La administración es propietaria del plan estacional y presenta la visión y los planes estacionales en una reunión general. Todos los planes del equipo deben alinearse con el plan estacional de la administración. Prevea cumplir en torno al 80 % del plan estacional.
Plan de 3 sprints
El plan de 3 sprints establece los casos y características que el equipo completará en los próximos tres sprints. El equipo es propietario del plan y lo ajusta en cada sprint. Cada equipo presenta su plan a la administración a través de la charla de características (consulte a continuación). El plan detalla cómo se alinea la ejecución del equipo con el plan estacional de 6 meses. Prevea lograr en torno al 90 % del plan de 3 sprints.
Plan de sprint
El plan de sprint establece los casos y características que completará el equipo en el siguiente sprint. El equipo es propietario del 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. Prevea lograr en torno al 95 % del plan de sprint.
Línea de autonomía
En este ejemplo, la línea de autonomía se traza para mostrar el punto en el que los equipos tienen autonomía en el planeamiento.
Como se indicó antes, la propiedad de la administración no se extiende más allá de la línea de autonomía. La administración ofrece orientación a través de la visión y los planes de temporada y luego da autonomía a los equipos para crear planes de 1 y 3 sprints.
Charlas de características: donde la autonomía se une a la alineación
Una charla de características es una reunión informal en la que cada equipo presenta su plan de 3 sprints a la administración. Esta reunión garantiza que los planes del equipo se alineen con los objetivos de la organización. También ayuda a la administración a mantenerse al corriente de las actividades del equipo. Aunque el plan de 3 sprints se ajusta en cada sprint, las charlas de características se realizan según sea necesario, normalmente cada uno o tres sprints.
En una charla de características se conceden 15 minutos a cada equipo. Con 12 equipos, estas reuniones pueden durar unas tres horas. Cada equipo prepara una presentación de 3 diapositivas, que incluyen lo siguiente:
Características
La primera diapositiva esboza las características que el equipo abordará en los próximos tres sprints.
Deuda
La siguiente diapositiva explica cómo gestiona el equipo la deuda técnica. Deuda se refiere a todo aquello que no cumpla los criterios de calidad de la administración. El director de ingeniería fija los criterios de calidad, que son los mismos para todos los equipos (alineación). Algunos ejemplos de criterios de calidad son 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 que se recogen en la última diapositiva incluyen cualquier factor que afecte al progreso del equipo, como problemas que el equipo no pueda resolver o dependencias de otros equipos que deban escalarse.
Cada equipo presenta las diapositivas directamente a la administración. El equipo presenta de qué manera su plan de 3 sprints se alinea con el plan estacional de 6 meses. La dirección formula preguntas aclaratorias y sugiere cambios de rumbo. Asimismo, puede 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, esta podrá solicitar un nuevo plan. En este caso poco frecuente, el equipo volverá a planear y programará una nueva charla de características para revisarla.
Confianza: el pegamento que una alineación y autonomía
Cuando se practica Agile a gran escala, la confianza es bidireccional:
La administración debe confiar en que los equipos harán lo correcto. Si la administración no confía en los equipos, no les concederá autonomía.
Un equipo se gana la confianza al entregar sistemáticamente códigos de alta calidad. Si los equipos no son de confianza, la administración no les concederá autonomía.
La administración debe ofrecer planes claros para que los equipos se alineen con ellos y luego confiar en que sus equipos los ejecuten. Los equipos deben alinear sus planes con la organización y llevarlos a cabo de forma confiable.
A medida que las organizaciones buscan escalar Agile a escenarios más grandes, la clave es dar autonomía a los equipos al tiempo que se garantiza que se alineen con los objetivos de la organización. Los pilares fundamentales son la propiedad claramente definida y la cultura de confianza. Una vez que una organización disponga de esta base, descubrirá que Agile puede escalar muy bien.
Pasos siguientes
Existen muchas formas de que un equipo de cualquier tamaño empiece a obtener beneficios hoy mismo. Eche un vistazo a algunas de estas prácticas que se escalan.
Descubra las características de Azure DevOps para la administración de carteras y la visibilidad entre equipos.
Microsoft es una de las empresas Agile más grandes del mundo. Descubra cómo Microsoft escala el planeamiento de DevOps.