Escalamiento ágil: mejores prácticas de SAFe para Scrum Masters

Este artículo es la segunda parte de la serie de escalamiento Agile de Toptal, diseñada para guiar a los gerentes de proyecto en los esfuerzos de expansión de su equipo. Lea la primera entrega, “5 marcos de escalamiento ágil comparados: ¿cuál debería usar?” para obtener una descripción detallada de las opciones más populares.

A medida que los productos crecen y se vuelven más complejos, también lo hacen los equipos que los producen. Cuando llega el momento de escalar, muchas empresas hacen la transición de Scrum a Scaled Agile Framework (SAFe), un sistema que se implementa a nivel empresarial y permite a las empresas administrar múltiples productos complejos que requieren equipos de equipos para desarrollarse.

Un maestro de Scrum que se mueve hacia un marco SAFe entrará en un entorno que es a la vez familiar y nuevo. Los artefactos, roles y ceremonias se basan en Scrum. Pero operar a una escala más alta conlleva algunas responsabilidades adicionales, especialmente para los maestros Scrum que optan por pasar al rol de ingeniero de tren de lanzamiento (RTE), una trayectoria común. El RTE actúa como el maestro Scrum de todo el tren de lanzamiento. En lugar de liderar un equipo Scrum de nueve a 11 personas, los RTE se convierten en líderes servidores de equipos que abarcan varios departamentos y organizan eventos de mayor tamaño y alcance.

Lo básico: Scrum a SAFe

SAFe permite a una empresa aplicar enfoques, valores y principios ágiles en varios equipos. El "equipo de equipos" resultante se conoce como el tren de lanzamiento ágil (ART). Los equipos individuales continúan empleando un maestro Scrum para hacer negocios como de costumbre, mientras que el rol similar al maestro Scrum en un ART lo realiza un RTE. El RTE aplica los mecanismos generales y la gobernanza de Scrum, pero a nivel organizacional, más que de equipo. Otros roles y artefactos tradicionales de Scrum a nivel de equipo también cambian en consecuencia. Por ejemplo, el “propietario del producto” de ART se convierte en gerente de producto; un “backlog del producto” se convierte en el backlog del programa; un "retraso de sprint" es un retraso de iteración; y el “incremento del producto” es ahora el incremento del programa (PI).

Hay cuatro configuraciones de SAFe: Essential, Large Solution, Portfolio y Full, y la que use depende de la medida en que su empresa adopte el marco. Las configuraciones permiten la implementación en múltiples niveles, que van desde varios equipos que trabajan juntos hasta la integración completa de la cartera y la agilidad empresarial en toda la empresa. Pero en todos los niveles, el objetivo sigue siendo escalar las prácticas Agile y Scrum, no reemplazarlas.

Scrum Masters en SAFe

Los maestros de Scrum que trabajan en un marco SAFe a nivel de equipo encontrarán que sus trabajos no son significativamente diferentes. Seguirán siendo un líder de servicio para un equipo Agile, responsable del entrenamiento y la educación, eliminando impedimentos y fomentando un entorno en el que los miembros del equipo se sientan seguros para rendir al máximo y mejorar continuamente.

Sin embargo, habrá algunas responsabilidades nuevas. Un maestro SAFe Scrum apoya al RTE en el evento de planificación de PI y en la ejecución del programa, y ​​representa a su equipo en las reuniones de sincronización de ART. Cuando hay impedimentos que están más allá de la capacidad del equipo para eliminarlos, el maestro Scrum los eleva al RTE.

Un maestro de Scrum que decida convertirse en un RTE descubrirá que su función implica decididamente más consideraciones. El ART puede incluir equipos nuevos para usted o nuevos para Agile, como análisis de negocios, hardware o cumplimiento. Y debido a que las configuraciones más altas de SAFe incluyen operaciones de programas o carteras, la gerencia estará directa y regularmente involucrada de maneras que no estarían en Scrum, asegurándose de que todo esté alineado con los objetivos a nivel de empresa y/o cartera.

El RTE es responsable de eliminar los impedimentos que están más allá de la capacidad de un solo equipo. Se comunican con las partes interesadas e impulsan la mejora continua a nivel de ART. El RTE entrena no solo a los equipos sino también a los líderes de esos equipos, ayudando a todos los niveles del ART a avanzar hacia la autoorganización y la autogestión.

Eventos SAFe

Así como un maestro Scrum facilita los eventos a nivel de equipo, un RTE facilita los eventos a nivel de ART: la planificación de PI, la sincronización de ART, la demostración del sistema y la inspección y adaptación. Como RTE, interactuará con una variedad más amplia de partes interesadas que como maestro Scrum y manejará varios equipos con intereses contrapuestos. Hay más asistentes, y más variados, en cada evento, y debe alinear las prioridades y obtener la aceptación de las iniciativas con mucha anticipación.

Planificación IP

El evento de planificación de PI es una ceremonia esencial para SAFe, una gigantesca sesión de dos días para alinear los objetivos de todos los equipos dentro de ART para las próximas ocho a 12 semanas mediante la creación del plan de PI. Es como un evento de planificación de sprint, pero abarca varios sprints en varios equipos.

Entradas

• visión de negocio
• Lista de las 10 a 15 funciones principales que se implementarán
• Detalles sobre la capacidad de cada equipo

Salidas

• Plan PI (un plan de entrega para los próximos cinco o seis sprints)
• objetivos IP
• Lista de riesgos potenciales

Consejos generales para el evento de planificación de PI

• Obtener la aceptación de las partes interesadas. Antes de la reunión, los RTE deben establecer quiénes son las partes interesadas clave y compartir sus aportes con el grupo.
• Alinear prioridades. Antes de la sesión, programe una reunión de un día de duración con el equipo de gestión de productos para acordar una visión de alto nivel de las funciones que deben ofrecerse, así como las prioridades futuras. Habrá mucho que trabajar en el evento, como riesgos y dependencias, y es bueno tener un acuerdo direccional básico en su lugar.
• ¡Ensayar! La planificación de PI es un gran evento. Puede que no sea útil pasar dos días completos ensayando, pero una sesión de dos a cuatro horas con los líderes del equipo de ART que crea una experiencia lo más cercana posible será de gran ayuda. Cree una versión simplificada de la agenda del evento y compártala antes del ensayo para que la práctica pueda comenzar desde un lugar bien informado.
• Esté preparado para el avance de la misión. El objetivo de la planificación de PI es entregar un plan a largo plazo en un período de tiempo comparativamente corto. A veces, las personas querrán entrar en detalles extensos sobre todo, que no es para lo que es el evento. Explique esto a los líderes de equipo en el ensayo y en la sesión; recuerde a los equipos que el objetivo es entregar planes de alto nivel y crear alineación, no planificar cada minuto de los próximos tres meses.
• Preparar información sobre la capacidad del equipo. Pida a sus maestros de Scrum que proporcionen cálculos de capacidad para las próximas ocho a 12 semanas. Espere alguna respuesta negativa o preguntas; por ejemplo, es posible que un maestro Scrum no sepa con precisión cuántas ausencias tendrá su equipo en los próximos dos meses. En tales casos, solicite presupuestos y sea flexible al responder a los límites de capacidad durante el propio PI.
• Comparta la agenda de planificación de PI. Distribuya el cronograma al menos dos semanas antes del evento y prepárese para responder muchas preguntas. Habrá muchos asistentes, y si SAFe es nuevo para usted y su empresa, probablemente también lo sea para muchos otros miembros del equipo. Según mi experiencia, para el segundo o tercer evento de planificación de IP, la presión sobre los facilitadores se vuelve mucho menos intensa a medida que los equipos se familiarizan con el evento y saben qué esperar.
• Gestión segura de asistencia. A menudo es difícil para los gerentes o gerentes senior asistir a un evento de dos días, pero la asistencia de la gerencia es imprescindible para garantizar una alineación de alto nivel. Confirme su asistencia al menos dos semanas antes de la planificación del PI y organice cualquier apoyo que necesiten. Lo mismo se aplica a los dueños de negocios, que necesitan aprobar los objetivos de PI.

Sincronización ART

El evento de sincronización de ART es una reunión semanal en la que el RTE puede obtener información sobre el progreso de los equipos e identificar los riesgos y obstáculos del programa. Si bien de ninguna manera es la única ocasión para que un RTE evalúe los impedimentos y determine si requieren una escalada, es un evento importante que proporciona un lugar regular para que se planteen estos asuntos.

Entradas

• progreso de los equipos
• Registro de impedimentos
• El plan de PI (para identificar cualquier desviación importante entre el plan y el progreso real)

Salidas

• Escalaciones (si es necesario)
• Decisiones sobre cualquier cambio en el plan de PI

Consejos generales para el evento ART Sync

• Fomentar la comunicación regular. Debido a que ART Sync es semanal, en lugar de diario como Scrum stand-ups, el RTE debe dejar en claro que los equipos pueden plantear problemas urgentes de inmediato y no deben esperar a la próxima sincronización de ART.
• Esté preparado con datos. Solicite a los maestros de Scrum y a los propietarios de productos que traigan métricas de progreso cuantificables, como el trabajo pendiente o el flujo acumulativo, para tener una conversación informada sobre el progreso.
• Vaya más allá de una revisión de estado semanal. La sincronización de ART está destinada a ser un evento en el que se alinean las prioridades y se resuelven los problemas, no un simple registro.

Demostración del sistema

La demostración del sistema pretende mostrar el alcance completo del trabajo creado durante una iteración anterior. En este evento, el gerente de producto y su equipo muestran a los dueños de negocios y otras partes interesadas el progreso integrado de ART en su forma actual.

Aporte

• El estado actual del trabajo basado en el resultado de todos los miembros del equipo Agile en el transcurso de la iteración anterior

Salidas

• Comentarios sobre la idoneidad del sistema para su propósito
• Cambios en la cartera de pedidos (si es necesario)

Consejos generales para el evento de demostración del sistema

• ¡Ensayar! Dedique de 30 a 45 minutos cada dos semanas a trabajar con los presentadores para concretar sus segmentos.
• Deshazte de los toboganes. Presentar el trabajo integrado real. Si está trabajando en un producto de software, haga que los presentadores muestren a las partes interesadas un incremento de producto en funcionamiento en lugar de una plataforma de diapositivas. Si es posible, demuestre su producto en un entorno de ensayo. Desea que la demostración se asemeje con precisión a la experiencia del usuario final. Si no puede presentar un sistema integrado cada dos semanas, analice su canal de entrega e intercambie ideas con los equipos sobre cómo puede adoptar la cultura CI/CD y DevOps.
• Centrarse en el valor comercial. Su presentación es para dueños de negocios y partes interesadas; compartir lo que es más importante para ellos.
• Mantenga la retroalimentación enfocada. Los comentarios de las partes interesadas que reciba serán importantes, pero este evento no es el momento para cambios drásticos en la visión o la hoja de ruta del producto. Esté preparado para llevar la conversación de vuelta a la retroalimentación de alto nivel que los equipos pueden convertir en elementos de acción en un momento posterior.
• Que sea breve. Las partes interesadas son personas ocupadas; una reunión de 45 a 60 minutos resultará en una asistencia más frecuente y comprometida.
• Permita tiempo para preguntas y respuestas. Sea transparente en sus respuestas. Recuerde que a veces “No lo sé, pero podemos averiguarlo” es la mejor respuesta.

Inspeccionar y adaptar

Inspeccionar y adaptar es una mega sesión retrospectiva que tiene lugar al final de un PI. La sesión se divide en tres partes,

• La demostración del sistema PI: un escaparate de toda la salida integrada de PI. Es similar a la demostración del sistema principal, pero en lugar de una iteración, este evento muestra el trabajo integrado en todo el PI.
• Mediciones cuantitativas y cualitativas: una oportunidad para que el RTE presente las métricas recopiladas a lo largo del PI. Estas métricas incluyen (pero no se limitan a) la velocidad del equipo, las historias de usuarios aceptadas, la cobertura de pruebas unitarias o defectos abiertos.
• Taller retrospectivo y de resolución de problemas: una oportunidad para que los participantes revisen el PI, reflexionen sobre lo que funcionó y lo que no, identifiquen problemas sistemáticos y propongan formas de resolverlos.

Entradas

• progreso de los equipos
• El estado actual del trabajo integrado de la ART, incluidos todos los resultados del incremento del programa.

Producción

• Lista de mejoras potenciales

Sugerencias generales para el evento Inspeccionar y adaptar

• Avise con anticipación a los dueños de negocios. Proporcionar al menos dos semanas de antelación antes del evento. Reúnase con los gerentes de productos y propietarios de negocios asistentes antes de la sesión para alinearse con la presentación de resultados cualitativos.
• Asegurar la asistencia de los principales interesados. Su presencia es más importante en la demostración del sistema PI cuando muestra el trabajo del equipo y el producto en evolución. Muchos de los consejos para la demostración regular del sistema se aplican aquí: ensaya de antemano, evita las diapositivas de la presentación y muestra los entregables reales.
• Evite la culpa. A lo largo de la sesión, asegúrese de que nadie se sienta amenazado por los datos presentados o los problemas identificados en la retrospectiva. Algunos equipos pueden sentirse celosos o a la defensiva si los números de otro equipo son más altos, o sentirse señalados si un problema se originó en su equipo. Adopte una cultura de equipo completo para adelantarse a tales problemas.
• Centrarse en cuestiones sistemáticas. Trate de no prestar demasiada atención a los problemas esporádicos, brinde a su equipo el espacio que necesitan para generar ideas y deje volar la imaginación para las soluciones propuestas.
• Crear propuestas accionables. Al final del evento, debe tener elementos pendientes para que los equipos los implementen. Identificar los problemas no ayuda si no se toman medidas para resolverlos.

La siguiente tabla compara los eventos SAFe con sus equivalentes de Scrum y describe la frecuencia y ejecución de las ceremonias a nivel empresarial:

Intensificación y ampliación

La transición de Scrum a SAFe puede ser intimidante. Operar a mayor escala siempre presentará nuevos desafíos y nuevas formas de pensar incluso en las prácticas más familiares. Si elige convertirse en un RTE, encontrará que el trabajo depende más de las habilidades que ya tiene. Un RTE es un agente de cambio y un líder servidor, al igual que un maestro Scrum, y el trabajo le brinda la oportunidad de desempeñar este rol a nivel empresarial, elevando sus habilidades junto con sus productos.