SCRUM en La Construcción

Oficina de Gestión de Proyectos - Equipo Scrum en la ciudad de Piura
http://oficinadegestiondeproyectos.blogspot.com/2017/05/scrum-en-proyectos-de-
construccion.html
martes, 30 de mayo de 2017
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 é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
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 é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”.
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

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.
Día de la reapertura del CC con la satisfacción del deber cumplido
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

SCRUM en La Construcción

Cargado por

Copyright:

Formatos disponibles

SCRUM en La Construcción

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SCRUM en La Construcción

Cargado por

Copyright:

Formatos disponibles

Oficina de Gestión de Proyectos - Equipo Scrum en la ciudad de Piura

Scrum en Proyectos de Construcción

Patio de Comidas Open Plaza el 27 de Marzo de 2017

Se contaban entre los daños tabiquerías humedecidas, instalaciones

El objetivo era lograr la pronta reapertura a través de la intervención de zonas

Hasta ese momento no había reportes ni precedentes en nuestro país de la

Se trataba de romper el paradigma de que Scrum es sólo para Tecnologías de

Inicialmente se observó que una programación típica en cascada no sería la

Si bien se manejaban plazos, se conocían desde ya restricciones e

Debido a la urgencia del proyecto y las restricciones antes mencionadas se optó

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

 Identificación de los roles: Scrum Master, dueño del producto (Product

 Creación de la Lista de pendientes del Producto (Product Backlog). Listado

 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

 Implementar un tablero tipo Kanban (2) (cuya palabra de origen japonés se

Aprender Scrum haciendo Scrum

En nuestro proyecto, estos roles se asignaron a medida que se identificaba la

Roles en el Proyecto con Scrum

El Jefe de Operaciones del centro comercial fue identificado en el rol de dueño

El cambio de paradigma en la organización convencional de obra también

Diagrama del proceso Scrum seguido en el proyecto de construcción

La agilidad que imprime Scrum permitió asimilar el cambio desde un enfoque

Desde el primer día de la implementación del Product Backlog y el Sprint

PLANIFICACIÓN DEL SPRINT

REUNIÓN DE REVISIÓN DEL SPRINT

Tablero Kanban en proceso

Asimismo, se vio la necesidad de dividir la sección “Planificado” en otro estado

De la misma manera, para mejor control, la sección “En proceso” fue

Adicionalmente se agregaron los contenedores para: Seguimiento a procuras /

 En proyectos de construcción la ejecución de los paquetes de trabajo no

Conclusiones y beneficios obtenidos

 Creemos perfectamente aplicable a otras áreas de apoyo en obras como

Es evidente que Scrum expandirá su espectro de influencia sobre más sectores

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

También podría gustarte