Especificidad del trabajo de un equipo Agile en SAFe respecto a Scrum en la práctica

Después de publicar entre amigos el primer artículo sobre Burn Down Chart, en los comentarios la primera pregunta que se hizo fue: "Sería interesante saber más sobre vuestra experiencia con SAFe". Por eso, en este artículo intentaré revelar la especificidad del trabajo en SAFe respecto a Scrum en nuestra práctica. No pretendo en absoluto tener la verdad absoluta y estaré encantado de recibir cualquier corrección y aclaración por parte de los colegas.

Primero enumeraré de forma esquemática lo más esencial que diferencia el trabajo en SAFe de SCRUM, en mi opinión.

• Increment en Scrum y Program Increment en SAFe
• ART - Agile Release Train
• Cantidad de equipos que interactúan
• PIPE
• SOS
• PO - no es propietario del negocio
• RTE
• Quinto sprint para aprendizaje
• System Demo

Increment en Scrum y Program Increment en SAFe. En realidad son términos distintos, pero es fácil confundirse porque nadie usa entre nosotros el término Program Increment, todos dicen simplemente Increment - y ese ya es otro término que se usa en SCRUM. Pero en general son bastante similares desde el punto de vista del significado, en mi opinión. Increment en SCRUM es en esencia el producto actual + las historias planificadas para el sprint en estado completado (que han pasado el DOD del equipo). Program Increment es el intervalo de tiempo durante el cual el tren (Agile Release Train) entrega valor incremental a producción. En duración, en nuestro caso son 4 sprints de 2 semanas para desarrollo y un sprint para aprendizaje.

Agile Release Train - es un equipo de equipos que trabajan sobre un mismo flujo de creación de valor. Nosotros lo llamamos simplemente tren, pero según el framework lo correcto es llamarlo "Solution". En nuestro caso, esta regla no se cumple del todo y los equipos a menudo trabajan sobre productos diferentes desde el punto de vista técnico, ya que la mayoría de las funcionalidades de negocio se implementan de forma integral y afectan a varios productos. Esto desde el lado técnico. Pero estoy seguro de que alguien considera todos los sistemas de TI como un solo producto de la empresa y, quizás, incluso sea más correcto.

Cantidad de equipos que interactúan en SAFe es sustancialmente mayor en nuestro caso, en total se recomienda hasta 125 personas en un solo tren. Nosotros tenemos 3 trenes y no en todos se cumple esta regla, hay trenes con más de 125 personas. SCRUM no describe cómo interactuar con otros equipos, según tengo entendido, a diferencia de SAFe, donde hay recomendaciones muy claras al respecto. El artefacto más destacado, en mi opinión, para esto es el Program Board.

En él se muestran las interrelaciones entre los equipos del tren y, discutiéndolo, se realizan los eventos semanales Scrum Of Scrums (SOS) en nuestro caso.

Aproximadamente cada 2,5 meses (cada 5 sprints) ocurre el evento PIPE - Programm Increment Planning Event. Es cuando todos los equipos distribuidos se reúnen en una misma sala durante 2 días y planifican su trabajo para los siguientes 2,5 meses. En el proceso de este evento aparecen artefactos como el Program board, por ejemplo, en el que se muestran todas las dependencias de los equipos entre sí para cada uno de los trenes, arriba ya he mostrado cómo se ve. La tarea del Scrum Master de cada equipo en este evento es la facilitación de la identificación del máximo número de dependencias, luego, en lo posible, su eliminación (mediante la transferencia de competencias verbalmente, por ejemplo, de un equipo a otro o mediante la toma de la dependencia de un equipo por otro, para que el equipo pueda implementar de forma autónoma su funcionalidad sin depender de nadie). En la práctica, en nuestro caso así ocurre. Primero se descomponen las funcionalidades en User Story, las User Story se reparten entre los 4 sprints. Las funcionalidades se colocan en el Program Board y se establecen las dependencias de otros equipos que haya. Durante el evento esto se discute y se corrige.

SOS - Scrum Of Scrum. Este evento se realiza una vez por semana para cada tren por separado. Los Scrum Masters de todos los equipos del tren se reúnen en línea, se transmite el Program Board del tren y se discuten los estados de todas las dependencias y funcionalidades de los equipos del tren concreto. En esencia, este evento es necesario para la sincronización centralizada de los equipos dentro del tren. Algo así como un standup, pero una vez por semana y no para el equipo, sino para los Scrum Masters.

PO (Propietario del producto) - no es propietario del negocio. Hay un Product Manager - él trabaja con los Business Owner de las correspondientes áreas de negocio y en esencia reparte las funcionalidades a los Propietarios del producto. El Propietario del producto trabaja ya directamente en el equipo - divide las funcionalidades en User Stories (en nuestro caso junto con el equipo) y no siempre las divide, pero progresamos constantemente en esta dirección.

RTE (Release Train Engineer - maquinista del tren. Scrum Master de Scrum Masters. Realiza los eventos SOS de su tren. Interactúa con el Product Manager a nivel de funcionalidades. Facilita el PIPE.

El quinto sprint para aprendizaje - sí, a diferencia de Scrum, aquí se asigna al equipo un sprint completo al final del incremento para el aprendizaje. Nosotros, por regla general, en la práctica lo usamos en primer lugar para asistir a formaciones internas, entre ellas también sobre SAFe, pero no solo. Los cursos privados y los meetups tratamos de planificarlos para este tiempo en la medida de lo posible. También tenemos desarrolladores que amplían su stack durante el 5.º sprint, para que exista la posibilidad de cubrir la competencia de alguien en el equipo (respaldar si es necesario).

System Demo. Como resultado del PIPE cada equipo tiene una lista de objetivos para el incremento y cada uno de estos objetivos está evaluado por el Business Owner del tren en una escala de 10 puntos. Esto se llama Business Value. Estos objetivos se dividen en principales y extendidos. Los objetivos principales son los objetivos en los que el equipo no ve ningún riesgo en alcanzarlos. Los extendidos son los objetivos con riesgos de consecución. Todos los objetivos son obligatorios y el volumen de trabajo se planifica para todos los objetivos. En el System Demo el Business Owner acepta los resultados del trabajo por el incremento. Supongamos que el equipo tenía 3 objetivos principales con evaluaciones 10, 6, 8 y 2 extendidos con evaluaciones 10, 3. Imaginemos que el Business Owner puso respectivamente las siguientes evaluaciones: 8, 6, 4, 2, 0. Ahora se puede calcular el porcentaje de consecución de los objetivos: para el 100% se toma la suma inicial de puntos por los objetivos principales, en nuestro caso es 10+6+8=24. Los puntos alcanzados se calculan teniendo en cuenta los objetivos extendidos (es decir, 20 de 24 el equipo alcanzó), es decir, como resultado el porcentaje de consecución de los objetivos del equipo será (20*100)/24 = 83,3%. Un resultado normal se considera alcanzar del 80% al 100%.

En todo lo demás trabajamos según SCRUM. Bueno, o casi en todo :) En cuanto a nuestra experiencia: puedo decir que, desde mi punto de vista, la evolución es evidente. En un año de trabajo los equipos crecieron mucho, se volvieron autoorganizados, algunos equipos, es cierto, se desintegraron, pero incluso en esto se vislumbra una cierta evolución. Todavía hay margen para crecer.

Comentarios de colegas de facebook

«¡Zhenya, hola! ¡Qué bien que escribas, bien hecho! Corrijo un poco lo de los trenes: no se forman alrededor del producto, sino alrededor del flujo de creación de valor. Y en el retail, desde el punto de vista de SAFe, no tenemos un tren, sino un Solution. Simplemente, para comodidad de la comunicación y simplificar la comprensión, seguimos llamándolo tren)»

– Konstantin Voronin (representante de la oficina de proyectos de Ingosstrakh)

«Bueno, y quizás alguien note que desde el punto de vista de SAFe la evaluación de los objetivos se realiza en el I&A; (donde el SD entra como parte, pero no está directamente relacionado con la evaluación) y los propios SD deben realizarse cada sprint (después de las demos de los equipos). Pero por ahora estamos lejos de eso, por eso conscientemente llamamos todo como está escrito en tu artículo)»

– Konstantin Voronin (representante de la oficina de proyectos de Ingosstrakh)

«¡Zhenya, continúa, por favor, es muy útil!»

– Alexey Ionov (Entrenador certificado en SAFe)