Experto en Project Management

ANEXO: Scrum en Proyectos de Construcción

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.

Patio de Comidas Open Plaza el 27 de marzo de 2017

Fuente: Perú 21. Foto: @verdesrosas
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.

Planificación tradicional en cascada vs. Planificación en Sprints

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.

Capacitación acerca del marco de trabajo Scrum

 Taller de afianzamiento del equipo Scrum
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.

Roles en el Proyecto con Scrum

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 esta manera, el equipo de desarrollo planificaba y se comprometía a velar por el
cumplimiento de las tareas asignadas en cada Sprint. En este 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.
 Diagrama del proceso Scrum seguido en el proyecto de construcción

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 esto 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 este artefacto se popularizó tanto que se creó un lugar
especial dentro de la oficina técnica de obra al que denominaron “Sala Scrum”.

Reunión diaria facilitada por el Scrum Master y con la participación del Ing. Residente,
ingenieros de campo y subcontratistas
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

Tablero Kanban y contenedores de apoyo como planos clave

y cuadro de adquisiciones

Tablero Kanban en proceso

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 depende
ú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 esta 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.

Día de la reapertura del CC con la satisfacción del deber cumplido

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.

Fuente: https://www.oficinadegestiondeproyectos.com/2017/05/scrum-en-proyectos-
de-construccion.html?m=1