Spend any amount of time in conversation with me and it is impossible not to notice how easily excited I get about Lean Construction and Agile frameworks, especially Scrum. Lean transformation and business coaching are my primary responsibilities at McCarthy Building Companies, Inc. As McCarthy’s Director of Lean Construction, I am fortunate to work with numerous design and construction Scrum teams from around the United States. As a partner with the Lean Construction Institute and Construction Industry Institute, I get to utilize Scrum with teams across the planet. Over my career, I’ve worked with hundreds of Scrum teams, thousands of Scrum practitioners, and helped coach people with a variety of experience.

How could design and construction teams not be using Scrum since it gives them more time to work, improve, and optimize customer value delivery? Design and construction professionals that never heard of the Scrum framework is another topic entirely. I worked half my construction career before becoming aware of Scrum and then using it daily. The question, “Why don’t teams use Scrum for Design and Construction?” is specifically for individuals or teams that are already aware of the Scrum framework and simply don’t start or abandon it.

Scrum is a team framework that allows complex projects to be delivered with adaptation yet supports people to both productively and creatively produce work at the highest possible value for customers. Teams using the framework report results in increased capacity, quality, and customer satisfaction. I highly recommend you to read the 19-page Scrum Guide to gain understanding of the complete framework and its underlying principles. This sketch visually outlines the complete framework and all the elements are explained in the Scrum Guide.

Teams utilizing Scrum most often double their output in the first couple of Sprints. Equally impressive is that the gains are sustained, and they continue improving their teamwork and work product. For example, one construction team of seven used the Scrum framework to manage all their project management tasks on a large healthcare patient bed tower project while simultaneously managing up to six smaller projects ranging in size from half a million to several million dollar value projects. Equally impressive was the positive client feedback about the project’s high quality, beneficial impact to their ongoing patient care operations, and project stakeholder collaboration among the hospital staff, designers, and frontline trade partners. From my perspective, the most impressive part of this Scrum team aside from the client feedback was that they didn’t have to add more staff as more projects were added and also didn’t have to work longer hours to get the work done. The team more than doubled their output without extra effort.

Another recent example is from a team I worked with last year that was geographically spread across the United States organizing a national construction conference. Traditionally, the team (made up of construction professionals) used to take twelve months to organize the event. With Scrum, they were able to organize the event in four months and spend additional meeting time making value-added changes to the proceedings. The improvement of 8 months sooner is 66.7% of the former 12-month duration. The event had record breaking attendance and higher customer satisfaction ratings as compared to past conferences. The same level of output improvement happens for design and construction teams using Scrum. Often, the first big gains are reductions in staff meeting durations and improved communication among internal and external project stakeholders while simultaneously eliminating weekend or catch up work at home.

Although Scrum works and continues to be used by individuals and teams some don’t experience the productivity gains or benefits with Scrum and soon discontinue using it. Some design and construction professionals even discourage Scrum adoption. I’m sharing my experiences so you can decide what is best for your teams. Some teams that discontinue using Scrum shared experiences about how their manager wasn’t on board or how they stopped using it because the sticky notes were taking too much time to fill in and move across the Scrum board. Others told me they stopped using x, y, z Scrum software because it was taking too much time to enter and update the tasks. Further dialogue with these construction professionals revealed the real root causes:

1. Awareness*

2. Awareness**

3. Awareness***

The types of awareness with new or “experienced” design and construction Scrum teams varies. These are my summarized observations with thousands of practitioners.

1. Awareness* - Individual

Individuals with unreliable Scrum results can’t describe the framework and are very often unaware of the existence of the Scrum Guide. Although the Scrum Guide is not a detailed procedure manual, the first section notes that tactics for implementing Scrum are described elsewhere. Individual awareness of the Scrum artifacts is also low or nonexistent. There are three and each represents the work in three distinct phases. The key purpose of each artifact is to provide information for shared understanding of the work and progress towards the goal. If you haven’t fully adopted the Scrum framework, you can take steps to change that.

2. Awareness** - Team

Teams with unreliable Scrum experiences don’t operate as a Scrum team. There are only three roles in Scrum: Product Owner, Scrum Master, and Development Team. Those role labels were born in software development but the Scrum Guide details how they are implemented in a variety of organizations including those with teams developing software, hardware, networks, autonomous vehicles, education, government, marketing, managing the operation of organizations, daily life management, and even for organizational knowledge transfer. Teams of people with varied titles and functions use Scrum for products, services, and organizational management. Regardless of industry, Scrum teams designate people to each of the three Scrum roles. Teams not operating in the framework are unaware of the roles and their unique purposes. If your team hasn’t fully adopted the Scrum framework, you can take steps to change that.

3. Awareness*** - Organization

Organizations with unreliable Scrum experiences are comprised of individuals, teams, or combinations of both that don’t operate using the Scrum framework. Remember, collections of individuals and teams make up an organization. If you are part of an organization that hasn’t fully adopted the Scrum framework, you can take steps to change that.

The first step to fully adopt the Scrum framework is to increase your awareness. Invest in understanding firsthand by reading the Scrum Guide and engaging with an experienced Scrum Master. Scrum is one very powerful and lightweight framework that can make your job easier, better, and faster. The Scrum Alliance is the world’s trusted source for Scrum and professional certifications and provides many free resources online such as the Scrum Guide. If you are new to Lean Construction, I recommend checking out the free resources the Lean Construction Institute (LCI) offers online. Another great Lean resource is the Lean Enterprise Institute (LEI) video called “Getting started with Lean” narrated by Jim Womack, co-founder of LEI.

add one

Felipe Engineer-Manriquez is a best-selling author, international keynote speaker, Project Delivery Services Director for The Boldt Company, The EBFC Show podcast host, and proven construction change-maker from million to billion dollar-sized projects and companies worldwide implementing Lean and Agile practices. Engineer-Manriquez helps people work twice as fast with half the effort - easier, better, and faster. Felipe is a Registered Scrum Trainer™ (RST), Registered Scrum Master™ (RSM), and enables change via blogging, coaching, social media, and his book, Construction Scrum. He is also a Lean Construction Institute Chairman’s Award recipient for his contributions to the industry. Connect with Felipe at https://thefelipe.bio.link/. .