Desde que comenzamos esta serie de artículos, hemos hecho hincapié en que SCRUM se adapta a cualquier tipo de industria y proyecto, cuya escencia es conformar equipos de trabajo pequeños y autogestionados. Para que esto se mantenga dentro de parámetros manejables, se recomiendan equipos de entre 6 y 10 personas, en caso de tener más miembros, es posible crear un segundo equipo e incluso, tres; un SCRUM Master con experiencia puede llegar a operar en los tres e incluso, pueden compartir un sólo Product Owner, pero, ¿qué pasa si el proyecto es mucho más grande que esto?
La respuesta no es sencilla, ya que tendríamos que comenzar con un proceso de reorganización del trabajo, que implica varios ajustes dentro de la organización y del proceso de SCRUM.
Con esta premisa, revisaremos los cambios y alcances que debemos de manejar dentro de la metodoloigía. en el contexto de los grandes proyectos.
Para visualizarlo de forma rápida, este proceso supone la creación de múltiples equipos SCRUM, que son coordinados por un equipo principal que gestiona de forma integral el avance del proceso, mientras que los otros generan los entregables que conforman el producto final. El equipo principal no incluyen a todos los miembros de los demás, sino que asisten representantes o embajadores que presentan los avances, reportan problemas encontrados y generan la retroalimentación del proceso en general. Este eveto como tal, en que los principales responsables del proyecto se reunen para mantener la oepración, se le conoce como Scrum de Scrums.
Estructura de un Scrum de Scrums.
La definición de un proyecto grande es variable, de acuerdo a la concepción que tenga cada empresa, esto implica el nivel de recursos que debe utilizar para su realización, la repercusión de este producto en la operación y el tamaño de su portafolio de productos. Al margen de esto, debemos de identificar la cantidad de recursos que se invertirán para su ejecución. Algunos de los factores organizacionales a considerar son estos:
Estos no son cambios menores, ya que están considerándose cuestiones como la sincronización de los entregables de varios equipos, la rotación de recursos que son escasos internamente y que pueden estar trabajando con distintos grupos, planes de comunicación y colaboración, asignación de ambientes (se explicarán posteriormente) y la observación de lineamientos y reglamentos, tanto internos como externos, por mencionar los más relevantes; pero vayamos analizando el proceso.
Se debe tener muy presente que es necesario hacer una selección cuidadosa de este tipo de proyectos, ya que por su tamaño e impacto, su ejecución supone una inversión más cuantiosa de todos sus componentes, tanto tiempo, dinero y cantidad de personal involucrado, lo que una mala elección puede tener repercusiones negativas en la operación.
La definición de “grandes proyectos” dependerá de la empresa y de la complejidad del proyecto emprendido.
Todos los procesos que se han abordado con anterioridad continuán siendo válidos, al igual que los principios y roles definidos, pero para atender los requerimientos específicos de proyectos de gran envergadura, se añaden los siguientes procesos.
Cabe mencionar que estos procesos se han definido formalmente hasta la tercera revisión de la SBOK, anteriormente se implementaba de forma más o menos empírica.
Para clarificar estos puntos, explicaremos de forma breve cada uno, con la aclaración que es necesario revisar la documentación respectiva de cada proceso para tener la visión completa de los procesos.
Al inicio de estos proyectos, se debe crear la Visión del Proyecto, misma que se alinea con los objetivos y portafolio de la organización, su visión y misión, y se identifican tres nuevos roles que son requeridos para esta etapa.
Chief Product Owner que será la voz del cliente, en este caso los Product Owners de cada equipo sólo validan los entregables generados y si cumplen con los criterios de aceptación, las decisiones estratégicas corresponden al primero. Chief Scrum Master será una suerte de coordinador de los otros Scrum Masters de cada equipo y apoya en la coordinación y validación de sprints. Stakeholders que son los principales impulsores y que tomarán las decisiones sobre la ejecución del proyecto.
Otra entrada importante es la referente a las recomendaciones del Scrum Guidance Body, que deberá incluir lineamientos y estándares de la organización, de la industria a la que pertenece y regulaciones gubernamentales. En este caso, su observación es de mayor interés, al ser el producto un componente de alto impacto en la organización.
También durante esta etapa se identifican los ambientes, que se conceptualizan como los espacios de trabajo donde laboran los diferentes equipos, áreas de pruebas o desarrollo e incluso recursos necesarios para el proyecto. Una vez identificados, será necesario hacer una reunión para planear la asignación de los mismos a los diferentes equipos y calendarizar su uso.
Igualmente, se deberán definir los planes de comunicación entre los equipos de SCRUM y el equipo principal, para mantener el flujo constante y se puedan hacer las escalaciones necesarias conforme se avance, además de la planificación de recursos de grandes proyectos para distribuir los recursos que sean más escasos entre los equipos y planear la entrega de los components de mayor valor, al tener que considerar que los equipos van a trabajar al mismo tiempo en distintas historias de usuario.
Al final, se deberán tener los siguientes artefactos para el inicio del proyecto.
Flujo de datos de Creación de Componentes. Fuente: SCRUMstudy.
Ya mencionamos que en esta modalidad tenemos un equipo principal, en el que participan el Chief Product Owner, el Chief Scrum Master, los Scrum Masters, Productos Owners y miembros seleccionados de los equipos Scrum, quienes en conjunto definen la lista de componentes y recursos comunes para todos los equipos durante el proyecto, además de coordinar los trabajos de cada sprint en base al Backlog Priorizado del Producto general, que es gestionado por el Chief Product Owner y el Chief Scrum Master se encarga de asegurar un ambiente productivo para todos los equipos. Las sesiones de trabajo que realizan son propiamente lo que conocemos como Scrum de Scrums.
Durante estas reuniones, se responden las siguientes preguntas,
Al igual que en un proyecto pequeño, pertenecer a un proceso de este tamaño no supone que unos miembros están arriba de otros, sino que son compañeros cuyas funciones son diferentes. En contraste a un standup meeting, cuya realización es diaria, es recomendado que estas reuniones se realicen de dos a tres vecs por semana, con una duración promedio de 15 a 20 minutos, ya que el volumen de gente que asiste y los temas vistos puede ser demasiado extensos y al realizarse con mucha regularidad, puede reducir su efectibidad y consumir demasiado tiempo de los participantes.
En este punto, para auxiliar en la asignación de las tareas, se recurre a elementos ya conocidos como los criterios de aceptación de las historias de usuario, los planes de colaboración entre Scrum Masters y Product Owners, pero también se consideran otros particulares de esta etapa, por parte del equipo principal.
Las salidas de este proceso, son principalmente la lista de entrgables del sprint, dependencias resueltas entre los entregables delproyecto, los ambientes y el cronograma de planeación del lanzamiento actializado.
Flujo de datos de Coordinación de Sprints. Fuente: SCRUMstudy.
Para este proceso, las principales entradas las encontramos con el Cronograma de planificación del lanzamiento y el Plan de preparación de lanzamiento, que en su conjunto definen como se realizará la liberación del productofinal y sus etapas para disposición de los usuarios finales.
Una de las actividades que utilizamos para su definición es el Sprint de preparación del lanzamiento (Release Readiness Sprint), que se realiza sólo una vez antes del lanzamiento, no genera entregables para historias de usuario sino que se revisan que las tareas específicas del lanzamiento y los criterios de aceptación específicos se hayan cumplido para poder proceder con este. Este sprint no es obligatorio, pero se recomienda en los proyectos grandes.
Por otro lado, es común que se definan los Métodos de preparación de lanzamiento, estos son por lo general propios de cada oganización o sector, aplicable a los productos o portafolio y se definen generalmente en el Scrum Guidance Body.
Las salidas correspondientes a este proceso incluyen el Producto enviable, que es un entregable que se pone a disposición de los usuarios; las Notas de lanzamiento que son los documentos se anexan al producto que se entrega y Ambiente de lanzamiento necesario para poder lanzarlo al campo.
Flujo de datos de Preparación de Lanzamiento. Fuente: SCRUMstudy.
En caso de requerir la aplicación de estos procesos, se recomienda revisar a detalle los capítulos 13 y 14 de la guía para el CUERPO DE CONOCIMIENTO DE SCRUM (GUÍA SBOK)” Tercera Edición, ya se describen todos los pasos, entradas, herramientas y salidas correspondientes.
Esto se debe considerar como obligatorio, ya que los requerimientos de un proyecto de gran tamaño probablemente requieran de un análisis más profundo, conocimientos más a detalle de su operación y Scrum Masters con eperiencia.
Tu opinión