Leading construction industry to lean-agile (LeAgile) project management

The construction industry is one of the most expensive and most expansive industries, dealing with multimillion-dollar projects worldwide, from building infrastructure to utilities. As a highly structured discipline, many have assumed construction to be governed mainly by Theory X (part of a theory of human motivation developed by Douglas McGregor) since time immemorial. Though a lot of improvements and enhancements to construction methodology and innovations have occurred, dramatically evolving and turning around the concepts of construction in the past few decades, we still observe that the concept of lean construction is accepted with a lot of disdain and has not yet been globally implemented. Although agile approaches are gathering momentum and are being tested for adoption beyond the software industry, the construction industry still does not want to entertain the idea of agility in projects. This paper will not only highlight the need for the adoption of agility in construction but will also attempt to marry the idea of agility with lean construction, thus introducing a new concept: lean-agile (LeAgile) project management for the construction industry.

This article introduces concepts and ideas on the proposed LeAgile setting for construction projects and discusses following main items:

1. Introduction to Lean and agile
2. Lean and Lean construction
3. Possibility of agility in construction
4. Can Lean and agile be used in unison?
5. Proposed application of lean-agile (LeAgile) project management in construction

Introduction to Lean and Agile

Lean and agile are two separate approaches to management, but some of the researchers have identified a relationship between the two. As they both are historically being developed on a parallel path while some of their features are common and they intrude into the territory of other at various points, giving an impression sometimes that they are one and the same. Whereas both of these approaches are distinct and unique in purpose, we can definitely find a way how to best utilize them together. We can find the similarities and differences and try to have the best of the both worlds. Specifically, in terms of the construction projects, we feel at a loss to draw a parallel or clear distinction between the two.

The dilemma is that the construction industry, which is supposed to be most organized and prospers on the assumption that it manages the resources most effectively, still causes a lot of waste. They have already realised the need to be lean, thus the concept of lean construction is fast being circulated and implemented in construction projects. Naturally, we do have clearer objectives and static scope in construction projects, so it is automatically assumed by many that agile is not for construction, as they are still struggling with reducing the waste. It will not be wrong to say that this difference in scope has almost eliminated the need for agile, while theoretically, it might be debated that if lean and agile can work together in software and other industries, then why not construction?

If we look at the numbers, the construction projects may be smaller in number as compared to software projects in any one place but the budgets of construction project are far more than the projects of all their industries put together. It can be hypothesized that construction industry has greatest benefits to reap if agile and lean can work for them together. It will be debated in this paper why a construction project should be agile but at least we are going to debate it and not take the answer at its face value.

It will be observed that many researchers have taken up the relationship of lean and agile and diverse views exist as to which one of them is more akin to a specific industry. Some treat agile, as a way to do things within the overall perspective of lean and some debate they cannot work together at all. We will try to establish, we can reinforce the commonalities of both and smoothen out the jagged edges, to present a fit for construction industry.

This marriage of convenience between Lean and Agile is already called by some as LeAgile and that is the term we will be taking forward for construction industry.

Definitions

“Lean is an approach that identifies the value inherent in specific products, identifies the value stream for each product, supports the flow of value, lets the customer pull value from the producer, and pursues perfection.” (Karkukly, 2013)

“Lean is doing more with less. Use the least amount of effort, energy, equipment, time, facility space, materials, and capital—while giving customers exactly what they want.” (Womack & Jones, 2003)

“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability.” (Highsmith, 2002)

We see Lacher and Bodamer (2009) discussing agility in project management, while they discuss agile in the perspective of lean. Lacher and Varisco (2008) try to prove that agile is the implementation of lean thinking. According to them, lean-agile is a combination of lean thinking and agile approaches. Lean is the “what” and agile is the “how.”

Discussion

In layman's language, to be lean an organization should focus on the most economical usage of resources, where everything is available only when needed or required, which is called Just-In-Time (JIT). Moreover, a lean organization manages and maintains the flow of all its materials and resources in such a calculated manner that only what is needed is done with surgical accuracy, thus reducing rather than eliminating all chances of waste. To reach such a level of precision, the organization has to ensure that only the work required to meet the objectives of the project is taken up and that anything not contributing directly to the organizational objectives is eliminated. Subsequently, this means all efforts that may lead to waste or a product with less than desired acceptability should not be taken up at all. To be lean, we have to be highly proactive and experienced with processes, and we should be able to forecast and plan very soundly each and every move we will have to make during the project.

In agile, the focus is not on accuracy or precision but on speed and flexibility. Agile focuses how quickly team can react to the changing requirements of the stakeholders and still be able to complete the job in less than the expected time. The team distributes the whole work in smaller chunks and concentrates on one piece at a time; the remaining work is open to suggestion and change. Agile provides a cost-effective response to customer demand and is based on flexibility of design, production, and delivery. Projects with constantly changing scopes may be very good candidates for agile project management; this is why software development is where it was born. Agile empowers us to bring the product to the customer faster, reducing the development cycle considerably.

As expressed earlier, agile and lean have many commonalities, though there still are differences. Where lean focuses on reducing waste, agile focuses on being alert to opportunities to make changes in a fast manner. Agile is for projects with constantly changing scope. Lean needs to be very well planned right from the outset, so scope must be as clear and static as possible.

Background

The “lean revolution” started with the just-in-time (JIT) technique introduced by Taiichi Ohno, way back in 1960. Lean as a formal approach did not appear earlier than 1988, when Toyota introduced it by publishing the Toyota Production System. Lean became popular in quality circles and later was taken up by supply chain in 1990s, as they assumed themselves to be its beneficiaries. It was not until as late as 1992 that the construction industry started considering the application of lean for construction projects. Since then, a lot of work has gone into lean construction and physical results have been produced, which have made lean an integral part of construction project management (Exhibit 1).

Exhibit 1. History of lean and agile (Smith, 2011).

There are similar techniques from Japan like Kanban, a scheduling system that helps determine what to produce, when to produce it, and how much to produce. Kanban was utilized mainly in the automotive industry at first but now it is the talk of the town, as is being adopted by other industries as well.

Agile movement was also following lean on a parallel path. In 1995, the first paper on Scrum was published, soon followed by a book on extreme programming (XP). The Agile Manifesto was formally released in 2001.

Russell and Wong were the first to represent effective scheduling for construction in 1993. In 1998, Harris and Ioannou coined the term repetitive scheduling method (RSM) and in 2000, the Last Planner (LP) system was first published. The Last Planner system and Location-Based Management System (LBMS) also have a parallel stream in history; in one way or another, they show characteristics of either lean or agile. Line of Balance (LoB), a visual method of construction planning, was introduced in 1950. Various names were used for these graphical scheduling tools, such as repetitive scheduling method, linear scheduling method, flow-line scheduling, vertical production method, time space scheduling method, time location scheduling, time versus distance diagrams, and so on (Kenley & Seppänen, 2006 and 2009). LBMS is a construction planning and production control system most often visualized as a flow line.

Differences and Similarities

As we have been referring to the differences and similarities between lean and agile, we must understand that lean is a philosophy whereas agile is a conceptual framework governed by the Agile Manifesto (2001). Lean works at reducing waste, giving value to the customer with an integrated and collaborative team. Agile's primary focus is not on value but on customer satisfaction through simple interactions working with a self-organizing team. Where lean would maximize the profitability, agile would maximize sales by keeping the customer satisfied. Lean needs elaborate planning up front, as in the waterfall model. It cannot leave things to chance, while agile plans continuously throughout the life of the project in smaller iterations (Exhibit 2).

Exhibit 2. Comparison of lean and agile (Batchelor, 2001)

Lean and Lean Construction

MacAdam (2009) applies the five lean principles of Womack and Jones (2003) (specify value, identify the value stream, flow, pull, and perfection) to the three types into which every task completed in an organization can be grouped: value-added, enabler, and waste. Basically, all the activities in a project must add value; if any activity is not adding value, it must be eliminated. Such activities produce waste and are not contributing to the organizational objectives. Still, there are some activities that do not add value by themselves but enable activities that do; such activities are called enablers. In construction, if we want to be agile, we must ensure that we only have value-adding activities and enablers in our schedule and that all non-value-adding activities must be eliminated, because they are waste.

Moreci (2014) shows through a case study how the application of the “Lean A3 process” (term A3 derived from A3 paper size) leads to rapid and effective alignment of the sponsor, key stakeholders, and program team around a revised vision, strategy, objectives, and resource requirements. The Lean A3 process clearly represents the possibility of using agile in lean process. As it was successfully applied to fix a trouble program in the case study by Moreci (2014), there seems to be an opportunity for construction projects to use it in a similar combination.

Moujib (2007) also identified five lean principles and highlighted issues and determined how these could be applied to project management, while discussing the various types of waste that exist in projects. The five lean principles are as follows:

• specify value,
• identify the value stream,
• flow,
• pull, and
• perfection.

Value is defined as a capability provided to a customer at the right time at an appropriate price, as defined in each case by the customer (Womack & Jones, 1990 and 1996). Once the value has been identified, we have to find the value stream—those activities that contribute positively to the outcome or the project's product. Value stream is defined as all the actions, both value-added and non-value-added, currently required to bring a product from raw material to the arms of the customer or through the design flow from concept to launch (Morgan, 2002). Once we make the value flow, we differentiate between the value-adding activities, enablers, and non-value-adding activities. By eliminating non-value-adding activities, we eliminate waste. Once value is created, it is not delivered to the customer until and unless the customer needs it and pulls it on JIT principle. The whole process is then perfected by continuous improvement.

The seven types of lean wastes that apply to lean construction can be defined as follows:

1. Over Production Waste: This waste occurs when we produce more than needed, faster than needed, or before it is needed. Excess production is not required and costs money.
2. Waiting Waste: This refers to any non-work time spent waiting for approval, supplies, parts, and so forth. In construction, this waste is very common when a preceding activity is not delivered on time or finished completely. It creates waiting time during which no value-added activity is performed.
3. Transportation or Conveyance Waste: This is wasted effort to transport materials, parts, or finished goods into or out of storage or between processes with no specific purpose as a result of poor planning. Transportation should be minimized and, if done, it must be on the JIT principle.
4. Over Processing Waste: This means doing more work than is necessary. It is a kind of waste common in poorly planned construction projects where there is a lack of coordination and communication. All unnecessary steps in operations, which add no value to the product or service, must be eliminated.
5. Inventory Waste: This refers to maintaining excess inventory of any supply (materials or goods) in excess of what is required to build the project under construction. Inventory includes raw materials, work-in-process, and finished goods. Excess inventory can quickly build up and tie up dollars and resources.
6. Motion Waste: This is any wasted motion to pick up parts or stack parts, as well as wasted walking. No extra steps should be taken to account for inefficient processes and other faults. If you have to move, it must add value.
7. Correction or Defects (Repair or Rework) Waste: These are products, materials, or services that do not meet expectations or conform to specifications. Corrections and defects are anything requiring repair or rework or even scrap.

Possibility of Agility in Construction

Before we explore the possibility of applying agile practices in the construction industry, we need to quickly review the agile values published in The Agile Manifesto or the Manifesto for Agile Software Development (2001):

• Individuals and interactions over processes and tools,
• Working software over comprehensive documentation,
• Customer collaboration over contract negotiation, and
• Responding to change over following a plan.

It is understood that the Agile Manifesto was created for the software industry, but what we are trying to find is the possibility of applying it to the construction industry. I would change the second value to read “Working product over comprehensive documentation.” Now we can debate each one of these values from an applicability point of view for construction.

1. Individuals and interactions over processes and tools: Construction engineers value their processes and tools more than anyone else and would protect them at any cost. This is because they have a deep-rooted understanding that there is no other way that this specific job can be done. Despite all this, we have seen the construction industry evolving over time, adopting new innovations, and adapting to new methods, tools, and processes. What if we decide to consciously promote creativity in engineering and leave it to our team members and stakeholders to suggest how this specific construction work should be done? LBMS is a great example of construction engineers agreeing that a conventional schedule may not be workable for all locations and that they will have to plan separately for each location. Though it is difficult to digest, there is a ray of hope that it is very much possible to start prioritizing individuals and interactions over processes and tools.
2. Working product over comprehensive documentation: I suppose construction engineers want a workable product but they are so much in love with perfection that they start gold-plating their product until it exceeds the basic specifications. If this is not done because of the customer's changing requirements, which we discuss in the next value, then we must realize that we are causing waste and are not even meeting the target of being lean. As suggested in the LP system, the schedule itself is divided into five layers, with the first two layers being mandatory but not detailed or restrictive for further planning. We agree that LP has already taught us to reduce documentation and take it to the last planner level. Again, there is a possibility that this value can be met for construction projects.
3. Customer collaboration over contract negotiation: We understand that the contract is the binding force between the customer and the builder in any construction project. Engineers will never agree to give priority to customer collaboration over the contract. Let us think this over from the customer perspective. We go through a number of contract revisions, after a lot of fuss, but changes do occur. Why can't we remove this barrier and work as partners with our customer, allowing him or her to flexibly and mutually make any changes? For that, we again have to learn some lesson from the LP system, where the last planner improves his or her bottom-level plan due to the feedback of the customer. There is definitely a possibility that must be explored further.
4. Responding to change over following a plan: If the discussion on previous point is understood and agreed upon, then it helps us justify this value. We must be ready to respond to change as and when it is needed. The simple solution is to make our construction phases smaller in size and iterative in nature. We have a similar example in the LP system, where weekly plans are prepared and collaboration with customer is promoted. There is a possibility that we can apply this value in construction.

Can Lean and Agile Be Used in Unison?

Both the Last Planner (LP) system and Location-Based Management System (LBMS) are lean by nature, as they focus on decreasing waste and increasing productivity. The LP system achieves this through an approach very similar to agile. The Last Planner is the person actually doing the work, or the lowest-level supervisor in construction. The planning is not centric and involvement of this Last Planner is essential. This makes planning a collaborative effort, achieving better commitments. LBMS is more of a technical system in which work flow lines are created for different locations while the overall plan may be governed by CPM traditional (critical path method) and PERT (program evaluation and review technique) methods. LBMS makes the buffers of the critical chain explicit and forecasts future performance based on statistical projections.

Koskela, Stratton, and Koskenvesa (2008) compare the Last Planner system (Ballard & Howell, 1998; Ballard, 2000) with critical chain project management (CCPM) (Goldratt, 1997), while Shankar and Varghese (2013) compare the location-Based Management System with CPM and PERT.

It is interesting to note that Last Planner and agile have a lot of structural characteristics in common. Exhibit 3 shows five levels of an LP schedule in construction. Last Planner interacts with the customer similarly to agile. Based on feedback, Last Planner adjusts and improves the plan on the go. The master schedule is just to define the key milestones, and the phase schedules are slightly more detailed, explicitly defining the handoffs from one phase to the other. These two levels are mandatory but the third schedule, the look-ahead schedule, is optional. If you have time to forecast or if anything has to be replanned, you can use this level. The last two levels are similar to Kanban as well as agile. The weekly work plan may be considered a bit like an agile iteration, and progress tracking may represent the feedback loop with the customer, keeping the door open for scope changes at the lowest level. The similarity to Kanban is that weekly work plan is something we intend to do, whereas progress tracking deals with the doing and done of Kanban. Kanban is probably the missing link between lean and agile, as Kanban has the capacity to bind the two together into LeAgile.

Exhibit 3. Scheduling levels in Last Planner (Smith, 2011).

Exhibit 4 reinforces the explanation given above, as to how this applies to construction projects. The project control here resembles the Planning and Monitoring & Controlling Process Groups in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), while in execution progressive elaboration is taking place in the form of weekly work planning iterations. In the whole of this process, we can see a glimpse of agile, while the overall control is lean.

Exhibit 4. Last Planner in construction management (Smith, 2011)

Proposed Application of Lean-Agile (LeAgile) Project Management in Construction

The discussion in preceding paragraphs was intended to stir up the possibility of applying a lean-agile, or LeAgile, method of project management specifically for construction projects. So far, no such formal method exists, though some research and white papers are available that indicate the application of one or both of these approaches to various industries. The construction industry has finally started to embrace lean construction, which gives us hope that LeAgile project management in construction is not a far-fetched idea, especially when the existing modern approaches to construction, such as LP and LBMS, already hold the key to LeAgility. It is obvious that there would be a lot of opposition from the construction industry to this suggestion, but what is the harm in opening the floodgates of new possibilities? If we can reduce waste in construction projects and make them much more efficient and profitable, why can't we be fast and flexile as well? This will take the future of the construction industry up a notch as we will be saving enormously on time and cost, and will be able to satisfy our stakeholders and sell more, thus making even more profits from our construction projects.