My Scrum Infatuation

I'm infatuated with Scrum. I had heard the term before, but never really knew what it meant. This past week, I was lucky enough to attend a lecture on the subject by Dr. Tom Sheives with the University of Texas at Dallas' Project Management program. Keeping in mind that this four-hour lecture/discussion was pretty much my first and only exposure to Scrum, I gotta say I like the concept a lot.

The Scrum Process in a Nutshell

I won't go into the history of Scrum, or how it fits into the Agile Project Management methodology, but you can read all about it here on Wikipedia. I'd rather just focus on one of the visuals that Dr. Sheives used in his presentation (courtesy of Mountain Goat Software):

This gorgeous graphic explains at a high level how Scrum works. Going from left to right on the graphic, here is the Scrum process:

1. Product Backlog is established by a Product Owner
2. Blocks of the Product Backlog are moved into the Sprint Backlog and decomposed into smaller chunks of work
3. The project team processes the smaller chunks of work in 2-4 week intervals called "sprints"
4. There are also 24-hour feedback loops during the 2-4 week sprints that include Daily Scrum Meetings
5. The Scrum process yields an output called a "Potentially Shippable Product Increment"

Interestingly, on projects utilizing Scrum, there is no project manager per se. There is the previously mentioned Product Owner, who decides on the features of the product and prioritizes the Product Backlog. There is also a ScrumMaster, who supports the project team during the sprints and conducts the Daily Scrum Meetings.

The project team is somewhat self-managing, as the team members decide for themselves how to break down the work in the Sprint Backlog and how to execute the work during the sprints. This approach to project management is quite different than the standard approach as defined by PMI's Project Management Body of Knowledge (PMBOK). Not everybody likes this departure from the standard.

Scrum & Lean

To traditional project managers, the Scrum approach seems risky and laissez-faire, but not to us Lean advocates. We understand the power of Scrum because it adheres to many principles of Lean:

• Pull...the project team pulls work from the Sprint Backlog, which is pulled from the Product Backlog
• One-Piece Flow...work is processed in small, rapid intervals with frequent course corrections along the way
• Daily Accountability...during the Daily Scrum Meeting, commitments are made, progress is verified, and problems are communicated
• Customer Value...the Voice of the Customer is provided by the Product Owner
• Servant Leadership...the ScrumMaster supports the project team, Gemba Kaizen-style
• Self-Adaptive Teams...the constant change inherent in a Scrum environment tends to yield flexible team members capable of adapting to the needs of the project
• PDCA...the Daily Scrum Meeting and the 2-4 week Sprints allow for frequent PDCA cycles, as do Sprint Reviews and Sprint Retrospectives, which are pretty much self-explanatory

Anybody who has studied Lean can see elements of lean thinking embedded within the Scrum methodology. For me, one of the best ways to tell if something is "lean" or not is to see how traditional managers react to it. While the audience at Dr. Sheives presentation seemed to be curious about Scrum, I definitely sensed some apprehension about using it in the real world. I've seen this same reaction dozens of times in regards to Lean, so I have a good feeling that Scrum is a lean approach to executing project work. This is obviously a silly way to judge the merit of a management system, but it has been surprisingly accurate in the past.

Scrum & Construction

During Dr. Sheives' presentation, one of the first things I thought of was the Last Planner System, which is an approach to construction management developed by the good folks at the Lean Construction Institute. Similar to Scrum, the LPS focuses on short time increments, rapid feedback, frequent course corrections, and continuous planning.

Whereas Scrum was developed in response to the constantly changing product requirements of the software industry, LPS was developed in response to the overwhelming complexity and lack of control in the construction industry. Scrum and LPS are just two variations of the same concept--lean project management.

Scrum has proven to be a highly effective approach in the software business, just as LPS has in the construction business. However, Scrum seems to be more utilized in software than LPS in construction, which probably points to the cultural and organizational barriers we face in construction. Figuring out how to remove these barriers is key. If we can do this, we can increase the adoption of lean methods in construction and start seeing the same great results that the software folks using Scrum often see.