Empirically (or "anecdotally," if you’re academically-inclined), practitioners know that high work-in-process (WIP) levels tend to lead to a variety of problems. Thanks to Rally Software, we have some hard data to help us make that case with clients.
Rally’s project management tool was among the first of its kind to become widely used in the market. For several years, the company has offered the tool as a web-based service. As a result of this long history, the company has collected quite a lot of data about real projects. They sanitized the data to eliminate references to customers and ran some statistical studies against the data from 9,629 teams. They found a number of very interesting correlations, and I highly recommend you download the free report from Rally’s site: The Impact of Agile Quantified. I don’t usually recommend submitting your contact information to a company, and that alone should indicate that I see value in the report.
The report contains a wealth of useful information. One point that stands out for me was the observed correlation between high levels of WIP and released defects. As I mentioned already, this comes as no surprise to practitioners. Yet, it seems to be very difficult for many managers (and teams) to let go of the idea that they can get a lot of work done by starting many tasks at the same time. The mantra attributed to David Anderson, "Stop starting and start finishing!" rings true.
They report several other interesting findings about effective software delivery. For example, stable teams provided 60% higher productivity, 60% higher responsiveness, and 40% higher predictability than traditional "matrixed" teams. They also found "almost a 2:1 difference in throughput between teams that are 95% or more dedicated compared with teams that are 50% or less dedicated." The "agile" focus on stable and dedicated teams seems to be very practical. The information may help us discuss with clients the idea of moving away from traditional practices like shifting individuals around from team to team on a per-project basis and assigning individuals to multiple projects at the same time.
The report is well worth a read. I’m keeping my copy handy to use as a reference and conversation-starter.