SCRUM en Proyectos de Construcción

SCRUM EN PROYECTOS DE CONSTRUCCIÓN Por: Ing. Ysmael Ormeño Zender, PMP®, SFCTM (*) Junio, 2017

SCRUM EN PROYECTOS DE CONSTRUCCIÓN

Y SMAEL ORMEÑO Z ENDER

CONTENIDO RESUMEN INTRODUCCIÓN ¿POR QUÉ SCRUM? PROCESOS Y HERRAMIENTAS UTILIZADOS APRENDER SCRUM HACIENDO SCRUM IDENTIFICANDO ROLES EL PROCESO SCRUM EN CONSTRUCCIÓN TRABAJO DENTRO DEL SPRINT ARTEFACTOS UTILIZADOS LECCIONES APRENDIDAS CONCLUSIONES Y BENEFICIOS OBTENIDOS BIBLIOGRAFÍA

Página 2 de 13



A GRADECIMIENTOS :

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 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.

Página 3 de 13



SCRUM EN PROYECTOS DE CONSTRUCCIÓN Por: Ing. Ysmael Ormeño Zender, PMP®, SFC

RESUMEN El presente caso busca romper el paradigma de que Scrum, como marco de trabajo ágil, es sólo para Tecnologías de la Información (TI) y confirmar la viabilidad de su aplicación al sector construcción. En ese sentido se describe cómo se logró la rehabilitación de la infraestructura del más importante centro comercial en la ciudad de Piura a pocos días del desborde del río y en un reducido plazo de 30 días. La obra fue ejecutada en medio del desabastecimiento de materiales, restricciones de ingreso a las áreas dañadas y con el apremio de los arrendatarios de locales para iniciar su implementación. Estas variables requirieron de un proceso con alta capacidad de adaptación al cambio conducida con el enfoque Scrum a través de la implementación de roles, participación activa del cliente, entregas incrementales con valor para los usuarios finales, eventos en Sprints, artefactos visuales y sobre todo un comprometido equipo Scrum.

INTRODUCCIÓ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. Se contaban entre los daños tabiquerías humedecidas, instalaciones colapsadas, acabados y enchapes desprendidos, etc.

Patio de Comidas Open Plaza el 27 de Marzo de 2017 Fuente: Perú 21. Foto: @verdesrosas

Página 4 de 13



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.

¿POR QUÉ 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.

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

1

"La Guía Definitiva de Scrum: las Reglas del Juego" Ken Schwaber y Jeff Sutherland - 1991-2016 Página 5 de 13



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 y taller de afianzamiento del equipo Scrum

2

"Desarrollo Ágil con Kanban" Eugenia Bahit 2011 Página 6 de 13



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 Scr um3. En nuestro proyecto, estos roles se asignaron a medida que se identificaba la participación de las personas desde su puesto original.

Figura 2. 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

3

"Cuerpo de Conocimiento de Scrum (Guía SBOK)" SCRUMstudy. Edición 2016 Página 7 de 13



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 EN CONSTRUCCIÓN 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.

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

Página 8 de 13



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 éste artefacto se popularizó tanto que se creó un lugar especial dentro de la oficina técnica de obra al que denom inaron “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".

Página 9 de 13



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 presenta4.

Tablero Kanban y contenedores de apoyo como planos clave y cuadro de adquisiciones 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 Página 10 de 13



El tablero Kanban se dividió de tal manera que represente el flujo del proceso: Product Backlog | Sprint Backlog | Planificado | En Proceso | Terminado

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

Página 11 de 13









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

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

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. Página 12 de 13


Y SMAEL ORMEÑO Z ENDER 



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.

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

(*) ACERCA DEL AUTOR ING. YSMAEL ORMEÑO ZENDER, PMP®, SFC

[email protected] oficinadegestiondeproyectos.blogspot.com

Ingeniero Civil, certificado como Project Management Professional PMP® y SFC TM. Egresado de la Maestría en Gestión y Administración de la Construcción - UNI. Diplomado en Evaluación y Administración de Proyectos – PUCP. Más de 15 años de trayectoria profesional con experiencia en Gerencia de Proyectos de edificación, retail e infraestructura como la Carretera Interoceánica Sur. Experiencias en la aplicación del Marco Lógico del BID. Actualmente conferencista, consultor y Director Ejecutivo en PMO Perú. Página 13 de 13

SCRUM en Proyectos de Construcción

Recommend Documents