miércoles, 5 de julio de 2017

Scrum in Construction Projects

This case seeks to break the paradigm that Scrum, as an agile framework, can only be applied on Information Technologies (IT) and to confirm the feasibility of its application on the construction sector. In this direction, we will describe how the infrastructure of the most important mall of Piura was restored just a few days after a river overflow and in 30 days.

The work was executed among shortage of materials, restrictions of entry to damaged areas and the urge of the tenants of shops to start their implementation . These variables required a process with a high capacity of adaptation to change led by the Scrum approach through the implementation of roles, active participation of the client, incremental deliveries with value for the final users, events in Sprints, visual artifacts and overall, a committed Scrum team.

When we were given the mission of restoring the  most iconic mall of Piura in a record time of 30 days, we did not hesitate to apply Scrum.

We knew beforehand that the mall and its shops had been greatly affected by the river overflow that occurred during El NIño Costero in Peru in 2017.

Open Plaza Food Court on March 27, 2017
Source: Perú 21. Photo: @verdesrosas

The damages included moistened partition walls, collapsed installations, detached finishes and veneers, among others.

The objective was to achieve a quick reopening through the intervention in service areas, common areas, wide external facades and nearly 60 internal shops on the first floor that were rented to well known brands (tenants).

Until that time, there were no reports or precedents in Peru about the application of Scrum to any kind of construction projects but we were convinced of its potential to be an agile framework within which teams can address complex adaptive problems while productively and creatively delivering results of the highest possible value (1).

It was about breaking the paradigm that Scrum is only for Information Technology (IT) and thus apply it to the construction sector to achieve a higher number of benefits.

¿Why Scrum?
We took this decision considering that we needed to deliver areas in short and focused cycles since tenants needed to carry out their internal implementations.

Initially, we observed that a typical waterfall programming would not be appropriate.

While deadlines could be managed, there were restriction and uncertainties beforehand that could affect the final delivery (liberation of areas to intervene, specifications and logistics of materials to use, availability of scaffolds, etc.).

Due to the urgency of the project and the above mentioned restrictions, we decided to put agility, flexibility and order by work in Sprints with the possibility of adapting to delivery of complete products (shops) as seen in the chart below.

Figure 1. Traditional waterfall planning vs. Sprint planning

Used Processes and Tools
The process and tools identified as applicable to the project include:
  • Identification of roles: Scrum Master, Product Owner and partners.
  • Creation of the Scrum team.
  • Creation of the Product Backlog. Dynamic and publicly visible list for all the stakeholders of the project. 
  • Creation of the Sprint Backlog.
  • Sprint Execution. Short and recurrent iterations or work cycles.
  • Hold Daily Sprint meetings and maintenance of the Sprint Backlog.
  • Hold the Sprint feedback meeting.
  • Use a kanban board(2) (a Japanese word made up of two words: Kan meaning "visual" and ban, "board", with an approximate translation meaning: "visual board").

Learning Scrum Doing Scrum
As an application pilot, we had some obstacles to overcome and the first  was that a part of the team did not know about the framework. An induction and training workshop was immediately prepared, in which we could evaluate the magnitude of our Product Backlog and later First Sprint.

Scrum framework training  
The members of the team were able to see, explain and discuss the objectives as well as the restrictions that we needed to overcome.

Scrum team consolidation workshop  
Identifying Roles
There are three main roles in Scrum which ultimately carry the responsibility of meeting the objectives of the project. Those roles are: Product Owner, Scrum Master and Scrum team. Together, they are known as the Scrum core team (3).

In our project, these roles were assigned as the participation of people from their original position was identified.

Figure 2. Roles in the Project with Scrum

The Head of Operations was identified as the Product Owner, for being who knew the specific needs of progress each week and therefore provided guidelines that allowed us to make and update the Product and the Sprint List.

In the occasions in which the  Head of Operations of the mall (Product Owner) was not present, the actions were coordinated with the representative of the Supervision company, who took that position in order to continue with the work.

The paradigm shift in the conventional organization of work also implied that the Head of Projects of the construction company internally assumed the role of Scrum Master, and would become a facilitator for the team work. Even though it was not easy, he tried not to interfere, and he let the members know which were the top priorities and gave them some freedom for self-regulation in the execution. It was essential to keep the environment agile and free from restrictions that may have arisen.

Thus, the development team planned and was committed to achieving the tasks assigned in each Sprint. In this project, the Scrum team was determined in first person by the Resident engineer, two field engineers and two assistants. However, a support team acted from Technical Office.

The Scrum Process in Construction
The project to develop in the mall was divided in 12 work packages with similar effort estimations.  These work packages became our "User Stories" to display throughout the execution period of work:

1. Tenants sector 1
2. Tenants sector 2
3. Tenants sector 3
4. Tenants sector 4
5. Tenants sector 5
6. Toilet facilities
7. Facade 1
8. Facade 2
9. Facade 3
10. Facade 4
11. Change of floors
12. Complementary works

The sprints were designed for 1 week considering that we were only given a total period of 4 weeks and the progress in the delivery of shops by sectors was crucial.

Figure 3. Diagram of the Scrum process used in the construction project

The minimum viable product was that which allowed the reopening of the mall. In construction projects, these are tangible elements and therefore, in this case, it meant the delivery of finished shops for their later implementation.

The idea was always to work on something that provided value to the client and with the available resources, avoiding the risk of intervening areas that were not urgent.

The agility that Scrum brings allowed to assimilate the change from a flexible approach. The variable used was availability of entry to each shop in order to conduct the works and this changed everyday with any traditional programming that we could have had.

From the first day of implementation of the Product Backlog and the Sprint Backlog, the colorful tones of the board attracted the look and curiosity of the members, which made their entry to the environment easy. This artifact became so popular that a special area in the work technical office was created, the "Scrum Room".

Daily meeting facilitated by the Scrum Master, with the participation of the Resident Engineer,
field engineers and subcontractors

Work Within the Sprint
The labor was focused on monitoring the execution of field work according to the list specified for each Sprint.

The definition and prioritization of the Product List provided by the Product Owner (Head of Operations of the Mall) was an initial guide for the Scrum Team to determine the entries of each Sprint. It was necessary to detail the tasks considering the labor and material resources available during the execution.

Also, the acceptance criteria for each work package was defined from the start:
"Completely liberated, with work protocol and ready for the implementation of the shop by the tenants"
We tried to hold daily meetings despite the difficulty of agreeing on a same schedule due to the intense monitoring that the field work demanded. Despite that, the Daily Scrum updated the technical team with the progress and expected pending items with the corresponding list of restrictions.

The client reviewed the progress weekly (what was planned for each sprint). We sought the feedback of the stakeholders (including subcontractors) and their opinion about the delivered product in order to find the way to make it increasingly better.

On Saturdays, the last sprint meeting was held before finishing the day in order to analyze the performance of the team during the cycle and to increase their maturity with the learned lessons.
In some sessions, the reasons why something that was planned was not accomplished were analyzed in order to consider actions for the following Sprint.

The Scrum Team kept their motivation despite the adverse circumstances. There were some people that did not believe in this method but ultimately, the planned objective was achieved.

Used Artifacts
Kanban is an adaptation of the Toyota production system by work cards that are introduced into the system only when there is capacity to process it.
It is known worldwide as one of the adaptive methods that features less resistance to change (4)

The Kanban board was divided to represent the process flow:
Product Backlog | Sprint Backlog | Planned | In Process | Finished

Kanban boards and support material like key plans
and procurement chart

Kanban board in process

In addition, we considered it necessary to divide the "Planned" section in another state of the process called "Liberated" due to the intervention in several areas that could only be carried out after the withdrawal of belongings of the user.

In the same direction, for a better control, the "In process" section was subdivided in three: Disassembly, assembly and finish.

Additionally, support was added for: Monitoring to procurement / Hirings / Key plans / Restrictions.

Learned Lessons
Considering the obtained results, it is clear that the organization needs to train their engineers in agile methods and frameworks for the management of projects. That will result in high levels of maturity in their work when executing constructions projects.

Some learned lessons include:
  • In construction projects, the execution of work packages do not depend only on the members of the Scrum team. Therefore, it is verified that in order to obtain a high velocity of deliveries, there must be a high level of control of all the work resources (including the technical aspect) in parallel. Other philosophies such as Lean Construction can be applied here. These, far from being exclusive, must be treated together with the global management of the construction project. As expressed by Schwaber and Sutherland (1991-2016), Scrum is not a process or a technique to build products; but rather a framework in which several processes and techniques can be used.
  • It will not be easy to stop taking the practices of traditional management to the agile context. Being an agent of change for the team and the organization is only possible when convinced of the benefits of agile practices.
  • Construction projects -and especially in retail- demand a higher effort that usually takes place in the final part. In Scrum, when the pressure to accomplish the promised is perceived, it is possible that permanent burnout occurs within the team from Sprint to Sprint, which is why a high motivation must be kept.
  • It is important that in the effective implementation of Scrum, the participation of an agile Coach is considered. The Coach will support the route map to follow, ensure the adoption of the framework and thus, we will not abandon or divert from the process.
Conclusions and Obtained Benefits
We conclude that it was feasible to apply the Scrum framework in the management of this construction project, with its main benefit being flexibility and order within an accelerated and uncertain work environment.
  • We believe it is perfectly applicate to other work support areas such as Logistics, Safety and Quality which could create their own Scrum team coherently with the Project Management team.
  • Scrum in construction works is a completely different world from IT. Finding the best dynamics will greatly depend on the gained experience, the readiness of the team members, the endorsement of the high management and even the understanding of the client and supervisor to provide their total support to benefit the work. 
  • It will be common to find skeptical people or critics during the implementation, but they will eventually join the team.  The release of this pilot has attracted people in the company who are interested in getting certified on Scrum.
  • In construction, the minimum viable is a tangible element that requires inputs for their generation, therefore, the management of these inputs needs to be added to the method.
  • The visibility of the boards, the transparency and simplicity in the information about progress is a significant contribution. We suggest to control the acquisitions and subcontracts in the same way and in parallel.
It is evident that Scrum will expand its sphere of influence over more productive sectors. It has started in the construction sector and in the years to come we will have more experience, which will increase its benefits.

Reopening day of the mall with the satisfaction of achieving this duty

To the valuable human group that was part of the Scrum team in the city of Piura who put all their will and talent to achieve the objectives, with the conviction that there are always innovative ways to make things better.
To my friend Christian Arias for his important advice on keeping the management of the project focused on Scrum.
Special thanks to all of them, knowing that the best reward is and will be your personal and professional satisfaction.

Translated by: Giuseppe Azañero Guillén.

Download full article in: Scrum in Construction Projects

(1) "The Definitive Guide to Scrum: The Rules of the Game" Ken Schwaber and Jeff Sutherland - 1991-2016
(2) "Desarrollo Ágil con Kanban" Eugenia Bahit 2011
(3) "Scrum Body of Knowledge (SBOK Guide)" SCRUMstudy. 2016 edition
(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

3 comentarios: