Playbook de Scrum a Escala
Una guía para los líderes de la organización sobre las dinámicas del equipo de equipos
Para que necesitamos agilidad a nivel organizacional?
La mitad de los equipos "ágiles" son ágiles solo en nombre (no tienen un producto funcional al final del Sprint)
La capacidad de entregar valor (innovación) a los clientes se ve limitada por factores organizacionales (capacidad de coordinar el trabajo
entre los diferentes equipos e interesados)
Líderes con una visión sistémica, pueden optimizar el flujo de valor desde la idea hasta la entrega y retroalimentación del cliente, para
esto tienen que trabajar juntos, destruir el pensamiento en silos y la optimización local en favor de la optimización del sistema completo.
Los líderes ágiles entienden que el bienestar de los colaboradores es un factor determinante para la generación de valor.
Principales impedimentos para la agilidad a escala
Gerencia con pensamiento "Waterfall" desestabiliza a los equipos, irrumpe en el backlog y desmotiva a los equipo.
Incapacidad de la empresa para definir prioridades y crear un Backlog priorizado de cosas valiosas y trabajar con equipos estables y
enfocados en una cosa a la vez.
Dependencias de arquitectura, deuda técnica, exceso de vistos buenos, incapacidad por cambiar los procesos
Practicas anticuadas de ingeniería, falta de integración continua, pruebas automatizadas y ambientes/datos de prueba.
Pensamiento en silos, no colaboración entre desarrollo, operaciones, seguridad etc.
Trabajo con contratistas waterfall.
Managers se convierten en líderes
Objetivos claros y retadores Líderes alineados demuestran que comparten una visión y valores
Destruyen la deuda organizacional Proveen los recursos que los equipos necesitan, eliminan el desperdicio y los procesos absurdos,
crean un ambiente en el que la gente quiere trabajar (Líderes de servicio)
Eliminan la deuda técnica Invierten en mejorar la arquitectura, prácticas de ingeniería, implementan DevOps, eliminan el "Teatro de la
administración de riesgos en TI" y hacen que entregar valor a los clientes sea rápido y seguro.
Hacen a los Product Owners responsables por el valor generado por punto
Planes de entrega realistas basados en información real de velocidad y no un Gantt Chart imaginario.
Priorización del backlog liderada por el cliente (salir a la calle, empatizar con el cliente, definir la propuesta de valor)
Retorno de la inversión del producto
Hacen a los Scrum Masters responsables por la Mejora de procesos y Felicidad de los equipos
Curva positiva de productividad
Mejora medible de procesos (tiempo de ciclo, lead time a producción)
Felicidad del equipos: modelo de bienestar, métrica de felicidad, eNPS
Siempre saber que cosas funcionan y que cosas no funcionan.
Hacen a los equipos de desarrollo responsables por la calidad
Tasa de defectos en producción
Remediación de la deuda técnica.
Los líderes ágiles entienden que:
El backlog de la organización fluye a equipos estables - no la gente a los proyectos.
A los clientes no les interesan los proyectos, ágil se enfoca en crear equipos de alto rendimiento que pueden enfrentar los retos
más grandes de la organización, pero para esto tienen que estar enfocados, 100% dedicados al equipo incluyendo al PO y el
SM
Medir la productividad por Sprint
No el tiempo para producir un producto que no sabemos si va a funcionar
El plan se actualiza constantemente basado en información real
No con un gantt imaginario
Tener un problema es lo más importante
El Kaizen es el trabajo más importante (Kaizen es el plan de mejora para el factor más importante que limita la velocidad o
felicidad del equipo)
Managers conforman en equipo de acción ejecutiva para destruir los impedimentos a la
agilidad.
Estructuran a la organización para máxima velocidad y adaptabilidad
Definen y ejecutan una estrategia de transformación
Mantienen un baclog actualizado de acciones
Intervienen y toman medidas para destruir el desperdicio y mejorar el rendimiento.
Destruyen los impedimentos para que los equipo se autoorganicen, se autoadministren, tengan el camino directo a producción y mejoren
su bienestar.
El Equipo ágil
La fundación de la organización ágil es el equipo ágil. No se puede escalar ágil si no se cuentan con equipos de alto rendimiento
El equipo tiene un objetivo trascendente
Trabajan juntos (físicamente en un espacio del equipo)
3 a 9 miembros 100% dedicados (4 o 5 tamaño idea sin contar al SM y PO )
Scrum Master: Remueve impedimentos & asegura el buen Scrum
Product Owner:
Es un líder de servicio (No es el jefe)
Traduce la visión en un Backlog.
Es una sola persona
Dedica 100% del tiempo al equipo (50% del tiempo con los clientes y stakeholders entendiendo las necesidades y el otro 50%
con el equipo clarificando y verificando la entrega
Multidisciplinario > Camino independiente a producción
Son responsables de su proceso y de la calidad de sus entregables
Auto organizado: deciden como hacer el trabajo, no necesitan a un jefe que asigne tareas y controle
Auto administrado: deciden cuanto trabajo hacer en el Sprint basado en las prioridades
Backlog fluye a equipos estables: El equipo es estable, no se remueven personas para iniciar otros proyectos, no es interrumpido desde
afuera.
Product Owner responsable por el resultado Retorno de la inversión del equipo
La organización ágil El equipo de equipos
Una red conectada de equipos de alto rendimiento reemplaza la estructura tradicional de comando y control.
Se abandona el enfoque tradicional de inicios del siglo 20 basado en la optimización del uso de los recursos y el seguimiento de cronogramas
Jefes controlan individuos a-travez de burocracia, reglas planes y reportes
Se resalta la eficiencia y se implementan recortes de costos
Las ordenes siempre vienen de arriba (poca flexibilidad para la creatividad y pensamiento estratégico del individuo) = No espacio para la
innovación.
Se adopta un enfoque en la velocidad y adaptabilidad a escala
Deleitar al cliente es la mayor prioridad (entrega rápida de valor)
Líderes como facilitadores se enfocan en remover impedimentos
Una red plana de equipos conectada de forma dinámica.
Transparencia radical y mejora continua.
Las mismas dinámicas del equipo ágil se aplican a la organización
Los equipos están cada vez más cerca del mercado, necesitan menos intermediarios para tomar desiciones por lo tanto pueden ir más rápido.
Los líderes proveen la visión y procuran el alineamiento de los objetivos.
Ver video: Transformando la piramide hacia una organización ágil.
Referencias
Transforming the pyramid to an agile organization - This is agile
Libro: A Leaders Guide to Radical Management - Stephen Denning
Libro: The Team of Teams - General Stanley McChrystal
Multiples equipos trabajando juntos: Scrum of Scrums y El Meta Scrum
Scrum of scrums es un mecanismo para escalar ágil a nivel organizacional. Se utiliza para transmitir la información relevante para el éxito de la
organización limitando los canales de comunicación, de manera de que los equipos y los líderes se enfoquen en las prioridades del día. El Scrum
of Scrums es una reunión similar a la reunión diaria del equipo Scrum, la diferencia es que el Scrum of Scrums lo atiende un equipo virtual de
miembros de otros equipos Scrum que colaboran para construir y entregar un producto o servicio.
El MetaScrum es un proceso constante de priorización y refinamiento de las necesidades de los clientes que asegura que cada equipo está
atendiendo la prioridad más importante. El Meta Scrum hace que la empresa se enfoque en el 20% de las cosas que generan el 80% del valor.
Alineamiento y priorización con El MetaScrum
El MetaScrum es un proceso constante de alineamiento de prioridades, descomposición del backlog y planificación de las entregas entre
multiples equipos.
MetaScrum de Nivel 1 y 2
Meta Scrum de Nivel 1
Meta Scrum de Nivel 2
Establece las prioridades para múltiples equipos
Espejo del refinamiento y planificación
Un solo backlog usado por POs de la línea.
Features
Epics
Alineamiento y coordinación entre equipos
Pensamiento Sistémico - responsabilidad del sistema
PO Nivel 3 = CPO = Chief Product Owner
MetaScrum de nivel ejecutivo
Resumen de actividades del MetaScrum
Proceso y objetivo
Entrada
Proceso
Salidas
Responsable
Visión estratégica Ali
near a la organización
hacia un objetivo
común y define un
propósito claro
Inteligencia sobre los
consumidores y la posición
competitiva
Feedback de los productos
Feedback del proceso de
entrega
Reunión de interesados
Visión anual
Revisión trimestral
Hipotesis sobre las
necesidades del mercado y
motor de crecimiento a ser
probado
Objetivos claros y reglas
claras para la priorización y
ordenamiento del backlog
Contexto adicional sobre la
visión, cultura, objetivos y
normas.
MetaScrum Ejecutivo (C
EO/Directores/Gerentes,
CCPO, CPO)
Priorización de
iniciativas
Visión estratégica
Iniciativas, temas estratégicos
Preferencias de los
stakeholders
Reglas de priorización
Reunión mensual de
interesados (puede ser
más frecuente)
Priorización con criterio
económico (WSJF)
Backlog alineado para cada
equipo a nivel de Features y
Epics
Actualización del Kanban de
Portafolio
Chief Product Owner
Backlog priorizado a nivel de
Features y Epics
Product backlog del equipo
Requerimientos emergentes
Plan de entrega
Definición de propuesta
de valor
Análisis de las 7
dimensiones de
producto
Mapa de historias
Reunión de
refinamiento con el
equipo
Backlog consolidado y a
nivel de equipos
Backlog listo (READY) para
2 sprints en cada equipo
Chief Product Owner y
Product Owners
Permite el progreso
eficiente hacia una
misma visión
Descomposición y
refinamiento
Descompone
proyectos complejos
en elementos
funcionales que un
equipo puede producir
en un sprint
Planificación del
release Pronosticos
de entrega para
Features clave y
manejo de
expectativas con
stakeholders
Backlog priorizado
Velocidad de todos los
equipos
Datos historicos de
requerimientos emergentes
Feedback de los stakeholders
sobre la trayectoria actual
Reunión trimestral de
planificación del release
a nivel de la tribu (CPO)
Actualización semanal
del Burndown Chart y
plan de entrega (PO)
Roadmap y pronostico de
disponibilidad de las
funcionalidades clave
Burndown Chart de la
entrega
Solicitudes de cambio del
plan
CPO (Plan trimestral)
PO (Plan de entrega del
equipo)
Mejorar el retorno economico del sistema con con la administración ágil del portafolio
CPO= Chief Product Owner, lidera las prioridades para un equipo de equipos (tribu), al igual que un Product Owner, sus principales
caracteristicas son la pasión y la comunicación constante con los clientes, stakeholders, gerentes etc, para definir con su equipo cuales son las
prioridades.
El CPO administra el Kanban de Features de la Tribu (en equipo con el MetaScrum), asegurando un balance entre la oferta y la demanda,
descartando iniciativas de bajo valor y favoreciendo aquellas con más retorno vs esfuerzo.
Por que usar Kanban para administrar el portafolio?
1. El Kanban hace el trabajo visible para toda la organización, se conocen las prioridades y en que está trabajando cada equipo
2. Limitando el trabajo en progreso, se logra el enfoque de los equipos en las funcionalidades más importantes, se evita el multitasking y se
aumenta la velocidad del sistema.
3. Administrando el flujo de funcinoalidades por el sistema se pueden detectar y eliminar cuellos de botella: focos de desperdicio por colas,
esperas, exceso de documentación, etc.
Priorizar con criterio economico
Hacer primero los trabajos que retornen más valor con menos esfuerzo.
Usando el WSJF (El trabajo ponderado más corto primero)
Alternativamente podemos usar la técnica de WSJF si no tenemos un VAN calculado.
El WSJF es utilizado para obtener el máximo beneficio económico de un sistema secuenciando los trabajos con criterio económico: cual es la
relación del valor del trabajo con el esfuerzo de producirlo.
Costo del retraso: para poder comparar trabajos a travez de diferentes dimensiones o lentes de análisis, podemos preguntarnos: cual es el
costo de retrasar este trabajo?
Una forma de calcular el Costo del retraso es sumar el Valor de Negocio + La criticidad en el tiempo + La generación de oportunidad o
reducción de riesgo asociada al Feature.
Utilizando una técnica de estimación relativa (como la estimación relativa con tallas de camiseta) podemos obtener el costo del retraso.
Feature
Valor de negocio
Criticidad en el
tiempo
Reduce riesgo,
genera
Oportunidad
Costo del
retraso
Tamaño
WJSF
Costo del retraso / Tamaño
A
XS =13
M = 35
L= 54
102
M = 35
2.91
B
M = 35
XS = 13
XS = 21
69
S = 21
3.28
C
L = 54
XS = 13
XS = 13
90
L = 54
1.66
Ver la herramienta de priorización en Excel.
Agilizar- Herramienta de priorizacion (1).xlsx
Referencias
Agilizar - Presentación de Release Planning
Velocidad y ejecución con el Scrum of Scrums
El Scrum of Scrums es una inspección y adaptación entre los equipos Scrum para la colaboración, coordinación efectiva y remoción de
impedimentos para el plan del día.
Scrum of Scrums nivel 1 y 2
Hace visibles y Remueve impedimentos para el plan del día
Espejo de la reunión diaria Que logramos ayer, que es lo más importante para hoy, cuales son los principales impedimentos.
Limita los canales de comunicación A travez de esta reunión coordinamos entre los diferentes equipos sin necesidad de reuniones o
comunicados adicionales.
Obtiene saturación de la información Sabemos en que están enfocados los otros equipos, obtenemos una consciencia colectiva del plan
del día a nivel organizacional.
Coordinación entre equipos
Actua como equipo de release
Entrega de software funcional en cada Sprint: El Scrum of Scrums asegura que el objetivo colectivo de entregar valor se cumpla
Uno o más representantes del equipo Scrum participan en la reunión.
Fortalece la relación de confianza entre los equipos y los Scrum Masters ayudando al rendimiento de la tribu.
El Scrum of Scrums puede ser diario para equipos que trabajan sobre un mismo producto o menos frecuente (ie 2 veces por semana) para
equipos que tienen pocas dependencias. En estos casos se puede utilizar para revisar impedimentos comunes.
El equipo de acción ejecutiva destruye los impedimentos del día.
Ej Scrum of Scrums
8:30 Reunión diaria de los equipos Scrums
9:00 Scrum of Scrums nivel 1
9:30 Scrum of Scrums del Scrum of Scrums (nivel 2)
10:00 Reunión del Equipo de acción ejecutiva La gerencia puede resolver los impedimentos más importantes del día.
El Scrum of Scrums no es:
Una reunión de estatus de los equipos hacia una estructura burocratica fuera de la tribu.
No debe convertirse en una carga administrativa para los equipos
No se usa para desarrollar el backlog (ver MetaScrum y proceso de refinamiento)
No debe convertirse en una reunión de quejas en donde cada día recitamos los mismos impedimentos sin que nada pase: en lugar de
esto, los scrum masters toman los impedimentos y los resuelven con ayuda de los líderes.
Quien participa
Miembros del equipo que necesiten coordinar dependencias (ej Desarrolladores que requieran resolver problemas de integración)
El Scrum Master o Product Owner cuando sea necesario.
Chief Product Owners, Jefes y/o gerentes dependiendo del nivel (Scrum of Scrums, Scrum of Scrum of Scrum of Scrums)
Los participantes se auto gestionan, clarifican el plan y hacen visibles los impedimentos
Si se requiere un MetaScrum Master puede coordinar el proceso y gestionar el backlog de impedimentos de la tribu.
Referencias
infoQ Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate https://www.infoq.com/news/2014/03/scrum-of-scrums
ScrumInc (Jeff Sutherland) Scrum of Scrums https://www.scruminc.com/scrum-of-scrums/
Scrum.org Resurrecting the Much-Maligned Scrum of Scrums https://www.scrum.org/resources/blog/resurrecting-much-maligned-scrum-scrums