Ha dado sus primeros pasos en el desarrollo ágil.
Tal vez ha realizado un piloto con un solo equipo y quiere aprovechar las ventajas para más equipos.
Tal vez ya tenga varios equipos trabajando según los principios ágiles y se haya topado con algunas barreras que le impiden obtener todos los beneficios.
O tal vez ha estado trabajando de manera ágil con su(s) equipo(s) durante varios años y ahora quiere adoptar prácticas ágiles en toda su empresa.
Sea cual sea su situación, ha oído hablar de los marcos ágiles escalados y se pregunta si merece la pena invertir en uno de ellos para pasar al siguiente nivel.
¿Pero cuál?
Ahí es donde entra este artículo.
Le ofrece una breve introducción a la escalada ágil y a los principales enfoques de escalada para que pueda centrar su atención en el que parezca más adecuado.
Empecemos por lo que significa escalar de forma ágil.
¿Qué significa adoptar Agile a escala?
La idea de la agilidad de la escala es permitirle adaptarse y seguir siendo competitivo respondiendo rápida y adecuadamente a las necesidades de los clientes y añadiendo toques encantadores para que los clientes vuelvan a por más.
En última instancia, y en términos prácticos, significa extender el trabajo ágil a todos los equipos, a todos los niveles y en todos los departamentos, incluida la alta dirección, y reducir la coordinación y el control al mínimo.
Las principales herramientas para ello son los equipos autónomos, la alineación de valores y objetivos, y la responsabilidad y transparencia en todos los niveles, tanto hacia arriba como hacia abajo de lo que queda de una estructura jerárquica original.
Evidentemente, te enfrentarás a problemas diferentes al extender la agilidad a uno o varios equipos dentro del mismo departamento, que al dar el salto a departamentos más allá de la ingeniería de software o la informática (donde se originó la agilidad).
La variedad de marcos ágiles a escala, la estructura y las prácticas que defienden, y los problemas específicos que abordan, varían.
El más adecuado para ti depende de la fase en la que te encuentres en tu viaje ágil y de si lo que un marco está diseñado para lograr se ajusta a tus aspiraciones de escalar ágilmente y, finalmente, convertirte en una empresa ágil.
Ahora, esto es importante, hay mucho más que hacer que adoptar un marco.
¿Cuáles son los verdaderos retos de la ampliación de Agile?
Un marco de trabajo te ayuda a evitar reinventar la rueda en lo que respecta a la estructura, los procesos y los principios que debes seguir para ser ágil.
Pero los verdaderos retos de una transición ágil están en un nivel completamente diferente.
Tienen que ver con la mentalidad y la cultura que necesitas para ser verdaderamente ágil: soltar (gran parte de tu) control y confiar en que todo el mundo quiere rendir al máximo.
Eso significa que:
- descentralizar las decisiones.
- crear transparencia y alineación en torno a los objetivos estratégicos y la forma de organizar el trabajo.
- encontrar un equilibrio entre los equipos autónomos y las dependencias entre equipos.
Cambiar prácticamente todo en la forma de organizar el trabajo.
- entregar antes y perfeccionar los productos » en la naturaleza».
- colaborar en toda su empresa y con sus clientes.
- Actualizar, sustituir e integrar sus sistemas de información para permitir un flujo de información transparente en toda la empresa.
Probablemente suene desalentador y no voy a restarle importancia a la tarea.
Sin embargo, diré que es totalmente posible.
Con formación, práctica, voluntad de fracasar hacia adelante (centrándose en aprender de los resultados que no se prefieren) y un poco de paciencia, puede hacer que funcione y disfrutar de la alegría de una empresa ágil orientada a las personas y a los clientes y de la ventaja competitiva que conlleva.
Así pues, vamos a aclarar las características más importantes de seis marcos de trabajo para escalar su adopción ágil.
1. Marco Ágil Escalado (SAFe)
SAFe® combina las prácticas Lean, Agile y DevOps para la agilidad del negocio.
Proporciona orientación sobre tres niveles para la entrega de productos en un entorno ágil a escala y añade orientación sobre la ampliación de la agilidad en toda la empresa con su cuarto nivel, el de la cartera.
La última versión de SAFe amplió ese nivel superior con mucho de Lean Portfolio Management.
Muchos profesionales ágiles consideran que SAFe es demasiado prescriptivo y complejo.
En efecto, prescribe muchos roles, eventos y prácticas. Añaden bastante complejidad y requieren una inversión y un compromiso significativos para su adopción. Además, restan flexibilidad a lo que se considera ágil.
Sin embargo, para las empresas muy grandes esto puede ser una bendición disfrazada.
La naturaleza prescriptiva de SAFe proporciona una orientación concreta sin obligar a revisar inmediatamente la estructura organizativa de la empresa o la arquitectura del producto para ayudar a minimizar las dependencias del equipo.
Una de las herramientas que utiliza para ello es su evento de planificación trimestral: el Programa de Planificación del Incremento (PI planning).
Se trata de un evento de colaboración descendente y un ciclo de planificación que se superpone al ciclo de sprints estándar de Scrum o a la cadencia de Kanban.
La planificación PI permite alinear a todos (en su nivel de adopción) en los objetivos estratégicos para los próximos tres meses. Ayuda a sacar a la luz las dependencias entre los equipos y los departamentos implicados, y a establecer un orden de prioridades que permita avanzar eficazmente hacia el objetivo de PI.
La siguiente tabla muestra cómo se relacionan los cuatro niveles de Marco Ágil Escalado con sus cuatro configuraciones de adopción.
Algunas notas sobre los niveles SAFe:
- A nivel de equipo, SAFe es esencialmente Scrum más varias prácticas de XP (eXtreme Programming). Los equipos pueden optar por utilizar algunas prácticas de Kanban para gestionar su flujo de trabajo, véase más adelante.
- El nivel de programa coordina los esfuerzos de los equipos con la planificación trimestral del incremento del programa (PI Planning) y un equipo de equipos llamado Agile Release Train (ART), Ingeniero de Release Train, como líder servidor y entrenador que facilita los eventos ART.
- Si tiene un producto grande en el que trabajan más de 150 personas, SAFe añade un tren de soluciones para coordinar los distintos ART y un ingeniero de trenes de soluciones cuya función es similar a la del RTE pero a un nivel más integrado.
- El nivel de cartera gestiona los flujos de desarrollo y se coordina con los otros niveles para garantizar que los trenes de liberación ágil y los trenes de soluciones se alineen con los objetivos estratégicos.
SAFe y Kanban
Dentro de SAFe, los equipos pueden elegir seguir Scrum o Kanban. Dicho esto, como la mayoría de los otros marcos, el equipo Kanban descrito por SAFe sólo habla de las prácticas de visualización del trabajo, limitación del trabajo en curso y gestión del flujo. Y les pone restricciones porque «estos equipos están en el tren, y algunas reglas adicionales deben aplicar».
Más importante aún, SAFe pone restricciones a los equipos Kanban porque «estos equipos están en el tren, y algunas reglas adicionales deben aplicarse». – cita del artículo de Team Kanban.
Las reglas son que los equipos planifican juntos, hacen demostraciones juntos y aprenden juntos.
En otras palabras, tienen que participar en los eventos de Scrum de otros equipos – no es necesariamente algo malo.
Pero hay más. Del mismo artículo:
«Los equipos Kanban no invierten tanto tiempo en la estimación como lo hacen los equipos ScrumXP. En su lugar, echan un vistazo al trabajo necesario, dividen los elementos más grandes cuando es necesario, y tiran de las historias resultantes a través del sistema Kanban hasta su finalización, en su mayoría sin mucha preocupación por su tamaño. Sin embargo, durante la planificación de PI, los equipos de SAFe deben ser capaces de estimar la demanda de trabajo frente a su capacidad, y también ayudar a contribuir a las estimaciones de los elementos de backlog más grandes entre equipos (Características). Además, la previsión requiere una comprensión de la velocidad del equipo de una manera que sea coherente con los otros equipos en el tren y la velocidad general de ART».
En otras palabras, SAFe espera que los equipos Kanban hagan mucha más planificación y estimación – ¡incluso para otros!
Aunque es comprensible desde una perspectiva de planificación general, esto va casi totalmente en contra de lo que es Kanban, y reduce la flexibilidad y agilidad que es inherente a Kanban.
2. Scrum@Scale (SaS)
Publicado en 2017, Scrum@Scale es el nuevo niño de la cuadra en los marcos de escalamiento ágil y lo guía en el escalamiento ágil para la entrega de productos.
Img Src: ScrumAtScale
Busca hacer a escala lo que Scrum hace para un solo equipo: mantener separados el qué (producto) y el cómo (proceso). Para ello, define dos ciclos distintos pero superpuestos: el ciclo del Scrum Master para la entrega del producto y el ciclo del Product Owner para el descubrimiento y la definición del producto alineado con la visión y los objetivos estratégicos de su empresa.
Cada ciclo tiene un grupo de liderazgo para apoyar el funcionamiento eficaz: un MetaScrum Ejecutivo (EMS) que cumple la función de propietario del producto a nivel de la organización y un Equipo de Acción Ejecutivo centrado en las mejoras de los procesos de toda la organización en el ciclo de scrum master.
Dos nuevos roles facilitan las versiones escaladas de los eventos de Scrum: el Scrum of Scrums Master y el Chief Product Owner.
SaS define componentes con un propósito específico tanto en el ciclo del propietario del producto como en el del scrum master. Permiten personalizar su transformación con tácticas más allá del diseño y las ideas centrales de cada uno.
Nota sobre Scrum of Scrums vs Scrum@Scale
Scrum of Scrums (SoS) y Scrum@Scale (SaS) se confunden a menudo.
Scrum of Scrums es una técnica para la coordinación entre equipos. No se trata de escalar ágilmente para la entrega de productos o la empresa.
Todavía vale la pena discutirlo brevemente porque es ampliamente adoptado, es una parte explícita de Scrum@Scale, y muchos otros marcos utilizan la idea básica para estructurar la coordinación a través de múltiples equipos.
Scrum de Scrums (SoS)
Scrum de Scrums introduce un equipo de equipos con su propio backlog para todo lo necesario para coordinar el trabajo de los equipos y resolver los impedimentos que un solo equipo no puede abordar por sí mismo.
En SoS, los representantes de los equipos se reúnen en un scrum de scrums diario para discutir el trabajo realizado y los siguientes pasos necesarios para abordar las dependencias.
El SoS funciona para un máximo de 3 a 9 equipos de 3 a 9 miembros cada uno. Para organizaciones más grandes, una adaptación que se ve con frecuencia es un Scrum de Scrum de Scrums.
3. Scrum a gran escala (LeSS)
LeSS es un marco para escalar la entrega de productos ágiles. La idea que impulsa todo Large Scale Scrum es para (permitirle)
- hacer más con menos.
- evitar la sobrecarga y evitar las optimizaciones locales.
- adoptar un enfoque de producto completo organizando sus equipos en torno a las diversas formas en que su producto aporta valor a sus clientes. Por ejemplo, un equipo centrado en las funciones de voz y otro en los mensajes de texto.
Img Src: less.works
Al igual que otros marcos basados en Scrum, LeSS es Scrum para un solo equipo con algunas adaptaciones.
Realmente las mantiene al mínimo. Sólo añade una retrospectiva general y una parte preliminar a la planificación del sprint, y sustituye las revisiones del sprint por equipo por una de todos los equipos.
Para el resto de la coordinación, LeSS sugiere: «Sólo habla, comunícate en código, viajeros, espacio abierto y comunidades».
En otras palabras: hablar cuando sea necesario y sólo sobre lo que importa en ese momento (Espacio Abierto) y, por otra parte, promover las interacciones entre equipos sentándose con otro equipo (Viajeros) y formando comunidades en torno a intereses compartidos.
Es un ejemplo de cómo LeSS es uno de los marcos menos prescriptivos que existen.
El hecho de que las normas de LeSS quepan en sólo dos caras de una hoja de papel, es otro.
Es capaz de ser tan conciso gracias a sus 10 principios de base que impregnan el marco y a los tres principios de su orientación sobre la adopción. Así que, en caso de duda, siga las orientaciones de los principios.
Para las organizaciones con más de ocho equipos, existe LeSS Huge.
LeSS Huge divide el producto en áreas de requisitos y añade un solo rol.
Ese es el Propietario General del Producto. Esta función es responsable de la priorización de todo el producto y de decidir qué equipos trabajan en cada área de requisitos.
Todas las áreas siguen el mismo sprint y producen un único incremento de producto integrado.
4. Nexus
Nexus es un marco para la entrega ágil de productos a escala.
Se esfuerza por reducir la complejidad y las dependencias entre equipos con oportunidades para cambiar el proceso, la estructura del producto y la estructura de comunicación.
El marco Nexus define un Nexus como un grupo de 3 a 9 equipos scrum con un único propietario del producto y un único backlog del producto, similar a Scrum@Scale.
Introduce un Equipo de Integración Nexus y un Refinamiento entre Equipos para coordinar el trabajo y las dependencias entre equipos.
El Equipo de Integración del Nexo se ocupa de los problemas de integración que impedirían al Nexo entregar un incremento de producto integrado. Está formado por el propietario del producto, además de un scrum master y miembros de los equipos de desarrollo.
El perfeccionamiento entre equipos es una actividad continua para identificar las dependencias entre equipos y para determinar con antelación qué equipo trabajará probablemente en un elemento. Los asistentes pueden variar en función de los elementos que se vayan a perfeccionar.
Otras adaptaciones a los eventos de Scrum de un solo equipo, son:
- Planificación de sprint de Nexus para coordinar el trabajo de todos los equipos de Nexus.
- Nexus Daily Scrum, además del scrum diario de cada equipo, para mantener el control de las dependencias (recién descubiertas) y los problemas de integración.
- Nexus Sprint Review que sustituye a las revisiones del sprint de cada equipo.
- Retrospectiva del Sprint de Nexus para revisar cómo han funcionado los equipos y sus procesos y herramientas compartidas. Cierra el sprint, por lo que sigue a las retrospectivas de los equipos individuales
5. Agilidad disciplinada (DA)
Agilidad Disciplinada started as Disciplined Agile Delivery (DAD), with a focus on product delivery.
Img Src: pmi.org
A partir de ahí, evolucionó y pasó a llamarse Disciplined Agile para reflejar su creciente alcance. A partir de 2017, DA muestra cómo las funciones empresariales trabajan juntas y qué deben abordar para la agilidad a escala en lo que llama una Empresa Ágil Disciplinada.
DA es ligero. Ilumina el «qué» y las herramientas que se necesitan para hacerlo realidad, pero deja el «cómo» en sus manos.
Agilidad Disciplinada ofrece orientación en cuatro niveles:
- Fundación le da los principios, las promesas y las directrices de la «mentalidad DA», los principios lean y ágiles, los enfoques más tradicionales, los roles y las estructuras de equipo que puedes adoptar, y lo que necesitas para elegir tu forma de trabajar (WoW).
- La disciplina DevOps amplía el DevOps estándar – agilizando el desarrollo y las operaciones – integrando la seguridad y la gestión de datos.
- Los Valores Streams le ayudan a unir sus estrategias y a mejorar cada parte de su negocio en el contexto del conjunto.
- Agilidad Disciplinada Empresarial le ayuda a crear una cultura y una estructura propicias para el cambio, el aprendizaje y la innovación.
El conjunto de herramientas de DA es tan amplio que es como un superconjunto de todas las herramientas utilizadas en otros enfoques. Lean, Scrum, Kanban, y todas las técnicas y métodos que vienen con ellos. Aun así, es ligero porque no te obliga a tomar ninguna dirección en particular, puedes mezclar y combinar y construir tu propio marco de trabajo sin tener que empezar desde cero.
6. Kanban de empresa, también conocido como Portfolio Kanban
Al escuchar «Kanban», la mayoría de la gente piensa en tableros con columnas llenas de etiquetas adhesivas.
Img Src: kanban.university
Pero el método Kanban es mucho más que las tres prácticas de visualización del trabajo, limitación del trabajo en curso y gestión del flujo que suelen utilizarse en otros marcos ágiles.
El método Kanban es una forma de vida, perdón, de trabajo.
Es uno de los 13 pilares del Sistema de Producción de Toyota que hizo que Toyota pasara de ser un pequeño fabricante de coches japonés a un fabricante de coches con una fiabilidad inigualable que domina el mundo.
A Kanban no le preocupa cómo se estructura la organización.
Sus cuatro principios y seis prácticas le guían en la optimización del flujo de trabajo, centrándose en las necesidades y expectativas de los clientes, fomentando el liderazgo en todos los niveles, y aprendiendo y mejorando continuamente.
¿Suena ágil? Sí, Kanban hizo ágil a Toyota mucho antes de que se escribiera el Manifiesto Ágil.
La belleza es que se puede aplicar Kanban a cualquier flujo de trabajo o flujo de valor, en cualquier nivel de una organización o proceso de trabajo. Y eso hace que Kanban sea intrínsecamente escalable.
El kanban empresarial o Portfolio Kanban se produce por:
- difundir los principios y prácticas de Kanban y entrenar a todos en ellos
- agrupar y vincular el trabajo para reflejar sus objetivos estratégicos y la cartera y los programas y visualizar las dependencias entre ellos..
Nota en Spotify
Img Src:crisp.se
No he incluido Spotify como marco ágil a escala por varias razones.
- El documento técnico que describe el «modelo Spotify» fue el primero de una serie, pero los demás nunca se publicaron. En otras palabras, ¡no estaba completo!
- El «modelo de Spotify» no era un modelo, sino una aspiración. No tardaron en tener problemas con él, aunque en ese momento todavía no eran tan grandes.
- El «modelo Spotify» utiliza nombres extravagantes para una estructura matricial ordinaria aunque se diferencia de la estructura matricial «tradicional» en que no asigna personas a proyectos, sino que las asigna a equipos estables centrados en la entrega de su parte del producto.
- El «modelo Spotify» se centra en la autonomía y no habla de alineación y responsabilidad.
Fuente: Spotify’s Failed #SquadGoals, la lista de referencias y recursos de esta fuente contiene enlaces al documento técnico original y a dos vídeos que explican la aspiración de Spotify para su cultura.
Picking the Right One for You
Eso es todo. Seis marcos ágiles a escala. O más exactamente, cuatro marcos, un conjunto de herramientas y una forma de trabajar.
¿Cuál será?
Algunas indicaciones generales para elegir los mejores candidatos:
- No se obsesione con elegir la combinación perfecta. Aparte de las claras diferencias entre Scrum y Kanban, la mayoría de los marcos tienen el mismo objetivo y difieren principalmente en los aspectos de agilidad a escala a los que prestan más atención.
- Si ya está usando Scrum y está contento con él, el camino obvio es preseleccionar los marcos basados en Scrum.
- Si quiere la menor sobrecarga posible, LeSS y Enterprise Kanban vienen a la mente.
- Si quiere ampliar su viaje ágil desde la entrega del producto a toda la empresa, entonces SAFe y Ágil Disciplinado son las opciones naturales.
- Si aprecia escoger los mejores enfoques y herramientas para cada aspecto, Ágil Disciplinado puede ser su ganador.
Vaya por delante y elija lo que le convenga
Sí, escalar la agilidad puede ser una perspectiva intimidante, pero cada uno de estos marcos y enfoques de Agilidad Escalada está diseñado para ayudarle en su viaje.
Si no le atrae ninguno de los marcos y enfoques aquí mencionados, abundan otros marcos y enfoques, y aproximadamente 1 de cada 6 empresas desarrolla el suyo propio.
Así que, adelante, cree esa lista de preseleccionados y comience su selección, o decántese por lo hecho a medida.