Cuando se nos encomendó la misión de rehabilitar el centro comercial ícono de la ciudad de Piura en el tiempo récord de 30 días no dudamos en aplicar Scrum.
Sabíamos que el mall con todos sus establecimientos había sido gravemente afectado por el desborde del río durante el fenómeno El Niño Costero 2017.
Se contaban entre los daños tabiquerías humedecidas, instalaciones colapsadas, acabados y enchapes desprendidos, etc.
El objetivo era lograr la pronta reapertura a través de la intervención de zonas de servicio, áreas comunes, extensas fachadas exteriores y cerca de 60 locales internos del primer nivel que se encontraban arrendados a reconocidas marcas comerciales (locatarios).
Hasta ese momento no había reportes ni precedentes en nuestro país de la aplicación de Scrum en algún tipo de proyectos de construcción pero estaba convencido de su potencia por ser un marco de trabajo ágil con el cual los equipos pueden abordar problemas complejos, adaptativos y a la vez entregar resultados de máximo valor productiva y creativamente (1).
Se trataba de romper el paradigma de que Scrum es sólo para Tecnologías de la Información (TI) y así aterrizarlo al sector construcción para lograr la mayor cantidad de sus beneficios.
¿Porqué Scrum?
La decisión se tomó considerando que debíamos realizar entregas de ambientes en ciclos cortos y concentrados ya que los locatarios necesitaban realizar sus implementaciones internas.
Inicialmente se observó que una programación típica en cascada no sería la más apropiada.
Si bien se manejaban plazos, se conocían desde ya restricciones e incertidumbres que podrían afectar el cumplir con la entrega final (liberación de ambientes a intervenir, especificaciones y logística de los materiales a usar, disponibilidad de andamios, etc.).
Debido a la urgencia del proyecto y las restricciones antes mencionadas se optó por imprimir agilidad, flexibilidad y a la vez un orden mediante el trabajo en Sprints con la posibilidad de ajustarnos a entregas de productos completos (locales) tal como se observa en el gráfico siguiente.
Procesos y Herramientas utilizados Entre los procesos y herramientas inmediatas que se identificaron como aplicables al proyecto fueron:
Identificación de los roles: Scrum Master, dueño del producto (Product Owner) y los socios.
Formación del equipo Scrum.
Creación de la Lista de pendientes del Producto (Product Backlog). Listado dinámico y públicamente visible para todos los involucrados en el proyecto.
Creación de la Lista de pendientes del Sprint (Sprint Backlog)
Ejecución de Sprints. Iteraciones o ciclos de trabajo cortos y recurrentes.
Llevar a cabo reuniones diarias (Daily Sprints) y el mantenimiento de la lista de pendientes del Sprint.
Llevar a cabo la reunión de retrospectiva del Sprint.
Implementar un tablero tipo Kanban (2) (cuya palabra de origen japonés se compone de dos términos: Kan que puede traducirse como "visual" y ban, como "insignia", siendo una traducción aproximada: "insignia visual").
Aprender Scrum haciendo Scrum
Como piloto de aplicación tuvimos algunas barreras que vencer y la primera fue el hecho de que parte del equipo desconocía del framework. De inmediato se preparó un taller de inducción y capacitación en el cual se pudo ir predimensionando la magnitud de nuestro Product Backlog y posterior primer Sprint.
Los miembros del equipo pudieron visualizar, explicar y discutir entre ellos los objetivos así como las restricciones que debíamos superar.
Identificando Roles
Existen tres roles centrales en Scrum que en última instancia llevan la responsabilidad de cumplir con los objetivos del proyecto. Dichos roles son: el propietario del producto (Product Owner), el Scrum Master y el equipo Scrum. En conjunto se les conoce como el equipo principal de Scrum (3). En nuestro proyecto, estos roles se asignaron a medida que se identificaba la participación de las personas desde su puesto original.
El Jefe de Operaciones del centro comercial fue identificado en el rol de dueño del producto (Product Owner) por ser quien conocía las necesidades específicas de avance en cada semana y por lo tanto brindaba las pautas que nos permitían elaborar y actualizar la Lista de Producto y del Sprint.
Para las ocasiones en que el Jefe de Operaciones del centro comercial (Product Owner) no se encontraba se coordinaban las acciones con el representante de la empresa de Supervisión quien asumía esa posición para continuar con los trabajos.
El cambio de paradigma en la organización convencional de obra también significó que el Jefe de Proyectos de la empresa constructora pase a desempeñar internamente el rol de Scrum Master, a partir de lo cual se convertiría en un facilitador para el trabajo del equipo. Aunque no fue fácil, trataba de no tener ningún tipo de injerencia, hacerle saber a los miembros cuáles eran las mayores prioridades y darles cierta libertad para la autorregulación en la ejecución. Fue labor indispensable encargarse en gran medida de mantener el ambiente ágil y liberar restricciones que podían surgir.
De ésta manera, el equipo de desarrollo planificaba y se comprometía a velar por el cumplimiento de las tareas asignadas en cada Sprint. En éste proyecto el equipo Scrum estuvo determinado en primera persona por el ingeniero Residente, dos ingenieros de campo y dos asistentes. Sin embargo, un equipo de apoyo se desenvolvía desde Oficina Técnica.
El proceso Scrum
El proyecto a desarrollar en el centro comercial se dividió en 12 paquetes de trabajo con estimaciones de esfuerzo de realización similar. Estos paquetes de trabajo se convirtieron en nuestras “Historias de Usuario” a desplegar durante todo el periodo de ejecución de obra:
1.Locatarios sector 1
2.Locatarios sector 2
3.Locatarios sector 3
4.Locatarios sector 4
5.Locatarios sector 5
6.Servicios Higiénicos
7.Fachada 1
8.Fachada 2
9.Fachada 3
10.Fachada 4
11.Cambio de Pisos
12.Obras Complementarias
Los sprints fueron diseñados para 1 semana tomando en cuenta que nos habían dado sólo un plazo total de 4 semanas y el avance en la entrega de locales por sectores era decisiva.
El producto mínimo viable era aquel que permitiera la reapertura del centro comercial. En proyectos de construcción se trata de elementos tangibles y por lo tanto, en éste caso, se refería a la entrega de locales terminados para la implementación posterior.
La idea siempre era trabajar en algo que aportaba valor para el cliente y con los recursos disponibles, evitando correr el riesgo de intervenir zonas que no eran urgentes.
La agilidad que imprime Scrum permitió asimilar el cambio desde un enfoque flexible. Se manejaba la variable de la disponibilidad de ingreso a cada local para poder realizar los trabajos y ésto cambiaba día a día cualquier programación tradicional que se pudiera tener.
Desde el primer día de la implementación del Product Backlog y el Sprint Backlog los llamativos colores en la pizarra atrajeron la mirada y la curiosidad de los integrantes, lo cual facilitó su ingreso al entorno. Luego éste artefacto se popularizó tanto que se creó un lugar especial dentro de la oficina técnica de obra al que denominaron “Sala Scrum”.
Trabajo dentro del Sprint
La labor estuvo enfocada en el seguimiento a la ejecución del trabajo de campo según la lista especificada para cada Sprint.
PLANIFICACIÓN DEL SPRINT
La definición y priorización de la Lista de Producto proporcionada por el Product Owner (Jefe de Operaciones del mall) sirvió de guía inicial al Scrum Team para determinar las entradas de cada Sprint. Fue necesario detallar las tareas considerando los recursos de mano de obra y materiales con los que se contarían al momento de la ejecución.
Asimismo, se definió desde un inicio el criterio de aceptación para cada paquete de trabajo:
"Completamente liberado, con protocolo de obra y listo para el inicio de la implementación del local por los arrendatarios".REUNIONES DIARIAS
Se trató de mantener reuniones diarias aunque no fue fácil habituarse a un mismo horario debido al intenso seguimiento que demandaba el trabajo de campo. Aun así el Daily Scrum actualizaba al equipo técnico sobre los avances y los pendientes previstos con el correspondiente listado de restricciones.
REUNIÓN DE REVISIÓN DEL SPRINT El cliente revisó semanalmente el avance (lo planificado para cada sprint). Se buscó la retroalimentación de los interesados (incluidos subcontratistas) y su opinión sobre el producto entregado de modo de encontrar la manera de hacerlo cada vez mejor. RETROSPECTIVA Los sábados, antes de finalizar la jornada se realizaba la última reunión del sprint para analizar el desempeño del equipo durante el presente ciclo y aumentar la madurez del mismo con el aprendizaje obtenido. En algunas sesiones se tuvieron que evaluar las razones por las que no se cumplió lo planeado para tomar acciones en el siguiente Sprint. El equipo Scrum se mantenía motivado a pesar de que las circunstancias eran adversas. También se escucharon voces incrédulas acerca del método pero finalmente se consiguió el objetivo planteado.
Artefactos utilizados
EL KANBAN DE TRABAJO Kanban es una adaptación del sistema de producción de Toyota mediante tarjetas de trabajo que se introducen al sistema sólo cuando hay capacidad para procesarlo. A nivel mundial se le reconoce ser una de las metodologías adaptativas que menos resistencia al cambio presenta (4). El tablero Kanban se dividió de tal manera que represente el flujo del proceso: Product Backlog | Sprint Backlog | Planificado | En Proceso | Terminado
Asimismo, se vio la necesidad de dividir la sección “Planificado” en otro estado del proceso llamado “Liberado” debido a que la intervención en varios ambientes sólo se podía realizar tras el retiro de las pertenencias del usuario.
De la misma manera, para mejor control, la sección “En proceso” fue subdividida en tres: Desmontaje, montaje y acabado. Adicionalmente se agregaron los contenedores para: Seguimiento a procuras / Contrataciones / Planos clave / Restricciones.
Lecciones aprendidas A la luz de los beneficios obtenidos, queda claro que la organización necesita capacitar a sus ingenieros en metodologías y marcos de trabajo ágiles para la dirección de proyectos. Aquello redundará en niveles altos de madurez en su gestión al momento de ejecutar los proyectos de construcción. Algunas lecciones que podemos rescatar son:
En proyectos de construcción la ejecución de los paquetes de trabajo no dependen únicamente de los miembros del equipo Scrum. Por lo tanto, se verifica que para obtener una alta velocidad de entregas se debe mantener en paralelo un alto nivel de control sobre todos los recursos de la obra (incluida la parte técnica). Aquí son aplicables otras filosofías como Lean Construction que, lejos de ser excluyentes, deben tratarse en conjunto con la gestión global del proyecto de construcción. Tal como lo expresan Schwaber y Sutherland (1991-2016), Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas.
Al inicio no será fácil dejar de llevar las prácticas de la gestión tradicional al contexto ágil. Ser un agente de cambio para el equipo y la organización sólo es posible estando convencido de los beneficios de las prácticas ágiles.
Los proyectos de construcción (y más aún en retail) demandan un sobre esfuerzo que se da generalmente en la recta final. En Scrum, cuando se percibe la presión por el cumplimiento de lo comprometido, es posible que de Sprint a Sprint se pueda generar desgaste permanente en el equipo lo cual supone mantener una alta motivación.
Es importante que en la implementación efectiva de Scrum se considere la participación de un Coach ágil para respaldar el mapa de ruta a seguir, se asegure la adopción del marco y de ésta forma no termine desviándose o abandonándose el proceso.
Conclusiones y beneficios obtenidos
Concluimos que ha sido viable aplicar el marco de referencia Scrum en la dirección del presente proyecto de construcción siendo su principal beneficio el haber otorgado flexibilidad y a la vez un orden dentro de un entorno de trabajo acelerado e incierto.
Creemos perfectamente aplicable a otras áreas de apoyo en obras como Logística, Seguridad y Calidad que podrían generar su propio equipo Scrum en coherencia con el de Gestión del Proyecto.
El Scrum en obras de construcción es un mundo distinto al de TI. Encontrar la mejor dinámica dependerá en gran medida de la experiencia acumulada, la buena disposición de los miembros del equipo, el aval de la alta dirección y hasta la comprensión del cliente y supervisor que brinden su apoyo total en beneficio de la obra.
Será común encontrar en el camino de implementación escépticos o detractores que luego terminan adhiriéndose. El lanzamiento de éste piloto ha permitido ganar adeptos en la empresa que se encuentran interesados en certificarse.
En la construcción el producto mínimo viable es un elemento tangible que requiere de insumos para su elaboración, por lo tanto se requiere incorporar a la metodología la gestión de los mismos.
La visibilidad de los tableros, la transparencia y simpleza en la información de avance es un gran aporte. Se sugiere controlar las adquisiciones y subcontratos paralelamente y de la misma manera.
Es evidente que Scrum expandirá su espectro de influencia sobre más sectores productivos. En la construcción ya es un inicio y en los años venideros contaremos con mayor experiencia que permitirá incrementar sus beneficios.
FUENTES. https://www.oficinadegestiondeproyectos.com/2017/05/scrum-en-proyectos-de-construccion.html
ACERCA DEL AUTOR.
Ingeniero Civil, certificado PMP, SFC, con más de 15 años de experiencia dirigiendo proyectos de edificación, retail e infraestructura. Consultor y conferencista director de PMO Perú
"Cuando pierdas, no pierdas la lección" -Dalai Lama
Agradecimientos 😊 Al valioso grupo humano que formó parte del Equipo Scrum en la ciudad de Piura poniendo toda su disposición y talento para que los objetivos se hagan realidad, convencidos de que siempre hay formas innovadoras para hacer mejor las cosas. A mi amigo Cristhian Arias por sus importantes consejos para mantener la dirección del proyecto enfocada en Scrum. A todos ellos, mi especial agradecimiento sabiendo que la mejor recompensa es y será vuestra satisfacción personal y profesional!
BIBLIOGRAFÍA. (1) "La Guía Definitiva de Scrum: las Reglas del Juego" Ken Schwaber y Jeff Sutherland - 1991-2016 (2) "Desarrollo Ágil con Kanban" Eugenia Bahit 2011 (3) "Cuerpo de Conocimiento de Scrum (Guía SBOK)" SCRUMstudy. Edición 2016 (4) "AGILE Roadmap: diagnóstico y evaluación de prácticas ágiles para ser implementadas en equipos de trabajo" Fausto I. Nelson Amancio 2013 - Universidad Politécnica de Valencia
TRANSCRIPCIÓN: Areli Álvarez Lean Construction México®
Comments