Implementar equipos Scrum funcionales en una organización es un reto por sí mismo, y muchos fracasan constantemente en este paso. Sin embargo, una vez que se tienen múltiples equipos altamente dependientes operando dentro del mismo producto o flujo de valor, se necesita algo más fuerte.
Es necesario utilizar un marco de escalado que abarque a los equipos Scrum. Dándoles procesos y reglas a seguir para que se sincronicen entre sí, se alineen y no se pierdan por el camino.
A menudo se acaba con equipos Silo, lo que básicamente significa equipos Scrum independientes que trabajan en pos de su objetivo local pero que apenas tienen ni idea del objetivo común final de todo el programa. Aquí es donde entra en juego el Scaled Agile Framework (SAFe).
¿Qué es SAFe?
SAFe es un enfoque que aplica un marco y unos procesos ágiles a las organizaciones jerárquicas del pasado. Abarca los niveles de estructura y los procesos, pero en lugar de recrearlos, reintroduce un segundo sistema de forma orgánica que resulta familiar a la mayoría de las partes interesadas del sistema original.
SAFe se construye en torno a varios valores fundamentales.
Alineación
- Todos los equipos de scrum deben comprender la visión y la estrategia y cuál es el objetivo final hacia el que marchan.
- Conecte la estrategia entre los equipos y condúzcalos a una ejecución conjunta.
- Comuníquese con los equipos con un lenguaje común unificado que puedan entender fácilmente.
- Compruebe constantemente si los equipos entienden los objetivos y la visión.
- Los equipos deben estar centrados en el cliente y deben comprender quiénes son los clientes y qué necesitan. Actualice la estrategia para reflejarlo.
Transparencia
- Cree un entorno en el que todos puedan trabajar al máximo y sin falta de confianza.
- Comunique abiertamente sus argumentos y hechos. Sea directo y honesto, y no oculte hechos importantes delante de los equipos.
- Fracase rápidamente y convierta los errores en momentos de aprendizaje. Si algo resulta no tener éxito, dese cuenta pronto y aprenda de ello. Entonces, cambie de estrategia.
- Visualice el trabajo que está construyendo para que todos puedan comprenderlo mejor.
- Facilite el acceso a la información necesaria.
Respeto por las personas
- Haga hincapié en lo que significa ser humano. No trate a las personas como recursos.
- Valore la diversidad de las personas y sus opiniones. Apoye los comentarios sinceros.
- Haga crecer y eduque a las personas mediante el coaching y la tutoría.
- Acepte que su cliente es quien consume su trabajo.
- Construya asociaciones duraderas dentro y fuera de los equipos.
Mejora implacable
- Construya un entorno en el que resolver los problemas motive a los equipos.
- Reflexione sobre cómo lo hizo la semana pasada e identifique qué se puede hacer mejor la próxima vez.
- Tome los hechos como el argumento más importante para mejorar las cosas.
- Proporcione tiempo y espacio para las innovaciones. Dé a los equipos la oportunidad de experimentar y probar distintas vías, aunque no sean las más seguras.
SAFe aporta una capa de colaboración y comunicación a los sistemas ágiles a escala. No sustituye a las actividades individuales de los sprints del equipo Scrum que usted realiza hoy en día.
Una parte clave de todo SAFe es el Tren de Lanzamiento Ágil (ART). Se trata de un equipo estable y duradero de equipos Scrum (normalmente hasta 12 equipos separados) que aporta regularmente nuevas funcionalidades incrementales después de cada liberación de sprint. Desarrollan, entregan y dan soporte a una o más soluciones en un flujo de trabajo.
Funciones de SAFe
SAFe se basa en personas con diferentes conjuntos de responsabilidades. Ceñirse a las expectativas de los roles es el factor crucial que determinará el éxito de la implantación del marco. Por lo tanto, también es importante entender cuáles son esos roles y cuál es su propósito.
#1. Equipo ágil
Los equipos ágiles son interfuncionales, lo que significa que pueden abarcar toda el área que están implementando dentro del propio equipo. También son entidades autoorganizadas que definen, construyen, prueban, despliegan y liberan incrementos de valor.
Cada equipo ágil tiene el conjunto de habilidades para ejecutar su alcance acordado y comprometido. El equipo ejecuta ese alcance por incrementos cada sprint de forma predecible. La previsibilidad es crucial porque sólo así el equipo puede comprometerse a entregar objetivos concretos en un tiempo concreto. La comunicación y la entrega son los valores cruciales que el equipo debe mejorar constantemente.
El equipo ágil es parte fundamental de las sesiones de planificación del incremento de programa (PI) para crear historias dentro de los sprints y planificarlas. Por último, se comprometen con sus propios Objetivos PI.
El Scrum Master entrena al equipo ágil y facilita las reuniones del equipo. Eliminan los impedimentos y protegen al equipo de influencias externas. Participan en las reuniones Scrum como parte del ART.
El Propietario del Producto (PO) es otro miembro especial del equipo. El PO es la voz del cliente e influye directamente en las historias y en su priorización. El PO se comunica con otros PO para definir y priorizar las historias en el backlog del equipo.
#2. Gestión del producto
La gestión del producto se sitúa por encima de los equipos scrum y se encarga de la alineación entre los equipos. Deben cubrir las siguientes responsabilidades
- Cumplir los objetivos empresariales asegurándose de que los equipos de desarrollo crean productos y soluciones viables y sostenibles.
- Comprender las necesidades del cliente y asegurarse de que los productos se completan con una perspectiva de cliente definida.
- Garantizar que haya suficientes características listas en el backlog en todo momento.
- Apoye el flujo de trabajo a través de los tableros del programa y hacia la cartera de pedidos del programa.
- Determinar el alcance del siguiente incremento del programa dando prioridad a las características que han creado los equipos. La gestión del producto es la responsable última de la definición del siguiente IP.
#3. Arquitecto de sistemas / Ingeniería
El equipo de ingeniería analiza y desarrolla el contenido acordado de las historias del backlog. Son la parte experta del equipo y cubren las siguientes responsabilidades:
- Crear y mantener la Pasarela Arquitectónica para que las nuevas características puedan utilizar los habilitadores tecnológicos.
- Participar activamente en la planificación del incremento del programa. Estar presente durante las demostraciones del sistema al final de cada incremento del programa.
- Trabaje con equipos ágiles para implementar nuevos habilitadores de arquitectura. Sólo así los equipos podrán construir nuevas características.
- Ayude a los equipos ágiles a definir soluciones y decisiones de diseño de alto nivel. Sugiera soluciones alternativas y el mejor enfoque para las actividades de prueba de concepto dentro de los equipos ágiles.
- Crean una pasarela arquitectónica. Se trata de una definición de habilitadores tecnológicos listos para ser consumidos por las características que definan los equipos respectivos.
#4. Propietarios de negocios / Partes interesadas
Son los equipos externos a los equipos Scrum, pero siguen desempeñando un papel importante en el marco SAFe en cada etapa de la ejecución.
Antes de la planificación de PI:
- Aportan información a las actividades de refinamiento del backlog.
- Participar en la Planificación Pre-PI según sea necesario.
- Asegurarse de que los objetivos empresariales son comprendidos y acordados por las partes interesadas clave del tren, incluido el Ingeniero del Tren de Lanzamiento (RTE), la Gestión de Productos y los Arquitectos de Sistemas.
Durante la Planificación PI:
- Proporcionar el contexto empresarial y la visión para el próximo PI.
- Participe en la Revisión del Borrador del Plan y asigne valor de negocio a los objetivos del PI del equipo.
- Participe en la Revisión por la Dirección y ayude a resolver los problemas que conducirán a la aceptación del Plan Final.
Después de la Planificación de la IP:
- Participe activamente en el mantenimiento de la alineación del negocio y el desarrollo a medida que las prioridades y el alcance cambien inevitablemente.
- Ayude a validar la definición de los Productos Mínimos Viables (PMV) para los Épicos del Programa y guíe la decisión de pivotar o perseverar en función de la entrega del PMV.
- Asista a la Demostración del Sistema para ver los progresos y aportar sus comentarios.
- Asistir a los eventos de Planificación de Sprint y Retrospectiva de Sprint del equipo ágil, según sea necesario.
- Participe en la Gestión de Lanzamientos, centrándose en el alcance, la calidad, las opciones de despliegue, el lanzamiento y las consideraciones de mercado.
#5. Ingeniero de Tren de Lanzamiento (RTE)
El RTE organiza las actividades de las personas y los equipos dentro del ART. Es el papel de un Scrum Master para todo el programa. Las principales responsabilidades son las siguientes
- Gestionar y optimizar el flujo de valor a través del ART.
- Establecer y comunicar los calendarios anuales para Sprints e Incrementos de Programa (PIs).
- Ser el moderador de las reuniones de planificación de los PI.
- Organice los equipos y ayúdeles a crear un resumen de sus objetivos identificados para los PI. Transfiera los objetivos de los equipos a los objetivos generales del Plan PI.
- Reúna a los equipos para comunicar y resolver los riesgos y las dependencias entre ellos.
- Conecte a la gestión de productos, a los propietarios de productos y a otras partes interesadas externas para alinear a las partes en su estrategia común.
- Orquestar los talleres Inspeccionar y Adaptar con el objetivo de mejorar continuamente los procesos y actividades ya existentes.
- Evalúe el nivel de madurez actual de la adopción de la metodología ágil en todos los equipos y defina los elementos de acción de seguimiento para mejorar los equipos en el futuro.
#6. Liderazgo
El liderazgo define la estrategia del programa y proporciona a los equipos todas las herramientas y el apoyo necesarios para permitir su trabajo. En última instancia, definen el sistema en el que trabajan todos los demás. Por eso es crucial contar con un equipo directivo que dé al equipo la definición correcta de objetivos y valores. Sus principales responsabilidades son las siguientes
- Liderar con el ejemplo.
- Adoptar una mentalidad de crecimiento.
- Destacar los valores y principios de SAFe.
- Desarrollar a las personas.
- Liderar el cambio.
- Fomente la seguridad psicológica.
Planificación del incremento de programa (PI)
La planificación del PI es un evento de dos o tres días con el objetivo de comprender y comprometerse con el trabajo para el siguiente incremento del programa. Puede tratarse del periodo del próximo trimestre, por ejemplo.
La gestión del producto es la propietaria de la priorización de las características identificadas durante la planificación del PI. Los equipos ágiles son los dueños de la planificación de la capacidad, la creación de historias, la estimación y el compromiso con los objetivos del PI.
La planificación del PI es esencial para SAFe. Si no está haciendo la planificación de PI, eso significa básicamente que no está haciendo SAFe.
Proceso PI
La planificación de PI comienza con algunas aportaciones sobre la mesa. Cada corriente de trabajo recogerá sus necesidades e ideas sobre lo que les gustaría construir a continuación para sus productos. Luego lo llevan al PI como aportación:
- Las 10 principales características a implementar a continuación,
- Backlog ART de epopeyas o características listas para formular,
- Visión del Propietario del Producto.
Comienza el debate entre las distintas corrientes de trabajo. Cada uno de ellos presenta sus visiones y características. Destacan lo que es importante implementar a continuación y lo que necesitan para tener éxito al hacerlo. Esto puede significar varias cosas diferentes:
- Habilitación por parte de otras corrientes de trabajo para que puedan seguir adelante con las características.
- Dependencia de otras corrientes de trabajo y necesidad de dar prioridad a los pedidos.
- Problemas actuales presentes en el sistema y que deben solucionarse primero para poder continuar.
- Retos de personal para el equipo. Es posible que aún falten varias funciones clave dentro del equipo para la implementación de contenidos que requieren las funciones.
- Las limitaciones presupuestarias impiden que su flujo de trabajo ejecute la visión en el plazo previsto.
- Cualquier otro riesgo, problema, suposición o dependencia que el equipo pueda reconocer y que sea necesaria una discusión más amplia con el resto de los equipos SAFe para alinearse en el objetivo común.
Recorrido de PI
La planificación de la IP propiamente dicha suele dividirse en varios días, normalmente de dos a tres, en los que la agenda puede ser la siguiente:
Día 1
- Discuta la declaración de la empresa y los próximos objetivos clave que conforman la visión y la estrategia generales del programa. La dirección es la dueña de esta parte y la comunica claramente al equipo.
- Ponga sobre la mesa todas las características de las corrientes de trabajo y priorícelas en consonancia con la visión común.
- Adéntrese en la visión de la arquitectura y defina los objetivos principales de los requisitos de desarrollo. Destaque los retos técnicos y acuerde la resolución de los impedimentos entre los equipos.
Día 2
- Explique detalladamente el proceso de planificación a los equipos. Describa los resultados esperados una vez cerrada la IP.
- Realice por primera vez los Breakouts de equipo durante la planificación. El objetivo del equipo es crear borradores de planes e identificar impedimentos y riesgos.
- Una vez finalizado el breakout, los equipos presentarán y revisarán los borradores de los planes que hayan creado delante de los demás equipos.
- El siguiente paso es para la dirección, donde revisan los planes y dan instrucciones a las iniciativas de resolución de problemas que siguen a continuación. Se realizan ajustes en los planes en función de los retos, los riesgos y los impedimentos.
Día 3
- Comience el día con los ajustes de los planes que ahora están en consonancia con la reunión de la dirección del día anterior.
- Los equipos desarrollarán los planes definitivos y perfeccionarán los riesgos e impedimentos. Los propietarios de las empresas asignarán valor empresarial a los objetivos de los equipos.
- A continuación, los equipos presentarán los planes finales ante toda la audiencia.
- Se discutirán los riesgos restantes a nivel de programa y se aplicará la información sobre riesgos ROAM (resueltos, propios, aceptados, mitigados).
- Los equipos votan su confianza en los resultados de la planificación del incremento del programa.
- Si los votos son demasiado bajos o la confianza general sigue siendo baja, se lleva a cabo una planificación adicional.
- Tras el compromiso del IP, la ETR planifica una retrospectiva para que los equipos discutan cómo ha ido la planificación y qué mejorar para la siguiente ronda. El liderazgo declara lo que va a suceder en adelante junto con las instrucciones finales.
Resultado de la IP
El resultado final de la planificación de PI es la lista de características previstas para su finalización por sprints dentro del siguiente periodo de PI. Todas las dependencias conocidas tienen un plan exacto sobre cómo resolver y desbloquear el progreso de las características.
Los equipos se comprometerán con sus objetivos y alcances. Si hay objetivos adicionales que no forman parte necesariamente de la lista, trátelos como objetivos no comprometidos. Ésos aún pueden resolverse potencialmente si el tiempo y los recursos lo permiten.
Los equipos documentarán y realizarán un seguimiento de todos los riesgos del programa y tendrán un plan exacto sobre cómo afrontarlos.
Los equipos también capturarán todas las ideas retrospectivas que se les ocurran en su reunión retrospectiva y las marcarán como lecciones de aprendizaje para la próxima sesión de planificación del IP.
En cuanto a los equipos en concreto, hay algunas expectativas concretas, como:
- Los equipos se comprometen con objetivos con valores empresariales.
- Los equipos calcularán su capacidad por sprint para poder estimar mejor la viabilidad del contenido de la hoja de ruta.
- También tienen en cuenta la carga real por cada sprint.
- Las historias se llevan a los sprints concretos de cada flujo de trabajo en función de la capacidad aportada.
- Los equipos votan por la confianza en el plan de IP y el contenido a entregar.
Conclusión
Esto no tiene por qué parecer obvio, incluso después de leer todo lo anterior, pero puedo decirle que transformar una gran organización en SAFe es una tarea extremadamente difícil. Sí, en algunos casos, puede parecer una misión imposible. Aunque se apliquen algunos de esos principios básicos, normalmente se necesitan muchas iteraciones para llegar a un estado en el que se pueda decir con seguridad que ahora es SAFe :).
Muy a menudo, el progreso está arruinando algunos principios y reglas jerárquicos de la vieja escuela, que no van a morir por mucho que se intente. Puede tener una amplia planificación de PI y resultados de algún tipo, que incluso puede nombrar con confianza. Pero, ¿qué significa realmente que los equipos de trabajo no vayan a funcionar con una metodología ágil adecuada?
Sólo puedo decir que aquí no hay lugar para los híbridos. O se está dentro, con todos los procesos, las personas y la mentalidad adecuados, o se está fuera si al menos uno de los aspectos de la metodología no se cumple realmente.
Naturalmente, antes de plantearse la implantación de SAFe, tenga claro que ya domina los principios y la forma de trabajar del equipo ágil. No sólo desde la perspectiva del liderazgo, sino dejando que los equipos voten y expresen su sincera opinión. Puede que le sorprendan los resultados.
A continuación, busque buenos recursos de aprendizaje para la certificación ágil.