En este capítulo, el número 9 de “Agile Latam”, Ettiane Salamanca y Deiby Ordoñez conversan acerca de uno de los temas más comunes en agilidad: El Escalamiento Ágil.
Parten hablando de ¿qué es es escalamiento en agilidad? Y hacen un recorrido por algunos de los marcos de escalamiento más conocidos en el mundo, compartiendo algunas de sus experiencia y cerrando con algunas consideraciones importantes a la hora de decidir escalar.
Podríamos decir que escalar es (o debería ser) expandir o ampliar algo que ya me funciona de manera local, pequeña o acotada, que en este caso sería la agilidad.
A menudo las iniciativas ágiles empiezan a necesitar incluir más ámbitos o elementos de la cadena de valor o Value Stream que impactan.
Dos grandes focos
Alineamiento, integración y coordinación de trabajo entre múltiples equipos |
Llevar los principios ágiles a otros niveles de la organización |
“La tercera ola de la agilidad”
Charlie Rudd analiza agile como un movimiento social con algunos hitos históricos y los divide en tres olas. La primera es la ola de los Equipos Ágiles (2001-2015), la segunda es la de Agilidad a Escala o Escalamiento Ágil (2007 a la fecha) y la tercera es la de Business Agility (2009 a la fecha).
En el capítulo conversamos acerca de:
- ¿El escalamiento va en declive?,
- ¿Los años y características coinciden en latinoamérica?
- ¿Quién no ha pasado las primeras dos olas va tarde?
¿Cuál ha sido tu experiencia escalando? ¡Déjanos tu comentario!
Marcos de Escalamiento Ágil
Algunos Marcos de Escalamiento Ágil (Elaboración Inspirit)
Scrum de Scrums (SoS)
- Escalar scrum cuando hay grupos grandes (+12 personas), dividiéndolos en equipos ágiles de 5-10 personas.
- Sincronización tipo Daily Scrum que incluye un miembro designado como “embajador” de cada equipo: Scrum of Scrums.
- 15 minutos (referencia) para el Scrum de Scrums.
Preguntas de referencia:
- ¿Qué ha hecho mi equipo hasta ahora desde la última vez que nos vimos que podría afectar a otros equipos?
- ¿Qué hará mi equipo antes de que nos volvamos a ver que pueda afectar a otros equipos?
- ¿A qué problema se enfrenta mi equipo que podría obtener ayuda de otro equipo para resolverlo?
Scrum de Scrums se describe por primera vez (resumiendo experiencias en IDX) en un artículo de Jeff Sutherland. (Link)
Spotify
Fuente: Henrik Kniberg. Spotify Engineering Culture.
|
 Parte 1. Link a imagen. Link a video. |
 Parte 2. Link a imagen. Link a video. |
“No inventamos este modelo. Spotify está (como cualquier buena compañía ágil) evolucionando rápidamente. Este artículo es solo una instantánea de nuestra forma actual de trabajar: un viaje en progreso, no un viaje completado. Para cuando leas esto, las cosas ya han cambiado.”
Henrik Kniberg & Anders Ivarsson. Link
En el capítulo conversamos acerca de:
- Visiones e interpretaciones.
- ¿Es un Modelo?
- Contextos de aplicación.
Nexus Framework
Nexus es consistente con Scrum. La diferencia principal es que se presta más atención a las dependencias y la interoperación.
- Nexus (m): una relación o conexión entre personas o cosas.
- Nexus es un marco de trabajo para desarrollar y mantener iniciativas a escala de desarrollo de productos y software.
- Nexus usa Scrum como su componente básico.
- Comprende los roles, eventos y artefactos de Nexus y de las reglas que los vinculan entre sí.
- Entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que trabajan en un solo Product Backlog para construir un Incremento Integrado que cumpla un objetivo.
Está compuesto por:
- El Product Owner.
- El Scrum Master.
- Nexus Integration Team Members.
* Los equipos Scrum, a su vez, son responsables de generar un incremento de producto potencialmente liberable, y todo lo demás prescrito en la guía de Scrum.
Los eventos en Nexus son bloques de tiempo (Timebox) que se basan en los bloques de tiempo de los eventos de Scrum, que se mantienen, reemplazan o se añaden.
Los artefactos, al igual que en Scrum, proporcionan transparencia y oportunidades de inspección y adaptación.
Adaptación visual de artefactos Nexus basado en gráfica original de Scrum.org
“Ken Schwaber y Scrum.org desarrollaron Nexus. La Guía de Nexus fue escrita y suministrada por ellos.”
Nexus Guide Link
En el capítulo conversamos acerca de:
- Experiencias y consideraciones.
- Complejidad/facilidad de transición si usas scrum.
- Dificultades aplicandolo.
Large Scale Scrum: LeSS
“Desde 2005, hemos trabajado con clientes para aplicar el marco LeSS para escalar Scrum, desarrollo lean y ágil a grandes grupos de productos. Compartimos esa experiencia y conocimiento a través de LeSS para que usted también pueda tener éxito al escalar.”
Craig Larman & Bas Vodde (Link).
Scrum @ Scale Versión 1.05 – 29 abril 2019
Es un framework dentro del cual redes de equipos Scrum que operan consistentemente con la Guía de Scrum pueden abordar problemas adaptativos complejos, mientras entregan de manera creativa productos del mayor valor posible. Es un modelo de referencia.
Scrum@Scale es:
- Ligero – la mínima burocracia viable
- Fácil de entender – consiste solo en equipos Scrum.
- Difícil de dominar – requiere implementar un nuevo modelo operacional.
Scrum@Scale es un framework para escalar Scrum. Simplifica radicalmente la escalabilidad usando Scrum para escalar Scrum.
Roles
- SoS,SoSoS
- Product Owner, Chief Product Owner,EMS
- SM, SoSM, EAT
Eventos
- Scrum de Scrums
- Refinamiento
- Retrospectiva
Disciplined Agile Delivery (DAD)
Disciplined Agile Delivery (DAD) (que podríamos traducirlo como Entrega Ágil Disciplinada) se autodefine como un enfoque ágil híbrido, orientado-al-aprendizaje y a poner a las personas-primero para la entrega de soluciones de TI, orientado-a-objetivos, consciente de la empresa (“pragmatismo sobre idealismo”) y escalable, ya que DAD es un aspecto, y posiblemente la base, del kit de herramientas (toolkit) Disciplined Agile (DA).
Declara roles primarios y roles potenciales de soporte (especialistas).
También tienen una adaptación, que ellos llaman extensión o ampliación, del Manifiesto Ágil, y lo consideran la base de su enfoque:
The Disciplined Agile Manifesto: https://www.pmi.org/disciplined-agile/disciplined-agile-manifesto
Una de las consideraciones que lo ha hecho sujeto de muchas críticas es que hace parte oficialmente de PMI.
Libro que describe DAD, “la referencia principal”: Scott Ambler and Mark Lines. Ligados RUP, a UML y otros conceptos relacionados. Link
Scale Agile Framework: SAFe 5.0
Scaled Agile Framework 5.0 – Full SAFe – https://www.scaledagile.com/
“SAFe ® para Lean Enterprises es una base de conocimiento de principios, prácticas y competencias integradas y comprobadas para lograr la agilidad empresarial utilizando Lean, Agile y DevOps.”
La última versión, SAFe 5.0, se basa en las siete competencias básicas:
- Liderazgo Lean-Agile
- Agilidad técnica y de equipo
- Entrega ágil de productos
- Entrega de soluciones empresariales
- Lean Portfolio Management
- Agilidad organizacional
- Cultura de aprendizaje continuo
SAFe se basa en tres cuerpos principales de conocimiento: Agile Development, Lean Product Development, and Systems Thinking.
“El WhitePaper SAFe 5.0 proporciona una visión general de cómo SAFe puede ayudar a las empresas a mejorar los resultados comerciales al acelerar la productividad, el tiempo de comercialización, la calidad, la participación de los empleados y más.”
En el capítulo conversamos acerca de:
- Nuestra relación con SAFe.
- Conceptualización de SAFe.
- Algunas piezas interesantes o diferenciadoras de SAFe.
- Variaciones de SAFe de marcos o métodos originales.
- Opiniones y experiencias con SAFe
Alcance (aproximado) de cada marco de escalamiento ágil
| Marcos de Escalamiento Ágil | Equipo | Programa | Portafolio | Organización |
| Scrum de Scrums: SoS | X | X | ||
| Large Scale Scrum: LeSS | X | X | ||
| Spotify “Model” | X | X | ||
| Scrum at Scale (Scrum@Scale) | X | X | ||
| Nexus Framework | X | X | ||
| Disciplined Agile Delivery: DAD | X | X | X | |
| Scale Agile Framework: SAFe | X | X | X | X |
Otras comparaciones
ASK: AGILE SCALING KNOWLEDGE – THE MATRIX: Link.
SAFe, LeSS, Nexus. Por Jerónimo Palacios: Link.
Consideraciones al escalar
Muchas gracias por escucharnos
Con esto cerramos este capítulo de Agile Latam, muchas gracias por escucharnos, y si nos escuchaste hasta el final ¡Coméntalo! Nos gustaría saber de tí, sabemos que fue un capítulo extenso y aún así, introductorio.
Esperamos que nos dejen sus comentarios, opiniones e ideas para capítulos. Pueden dejarlos en nuestras redes sociales: en Instagram, en LinkedIn, usando el hashtag #AgileLatam en cualquier red social, o acá abajo en la opción de comentarios.
