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.
Very interesting report, thanks for the recommendation!
I was a bit disappointed that the report only considers WIP per team member. In my current team, we don’t have any problem with that. Every team member works on one task at a certain time (ok, sometimes two). But the whole team is working on several stories simultaniously. So a team member might work on a task of story 1, then take one from story 3 then work on a task from story 2, then go back to story 1, and so on. I don’t like this situation, but the rest of the team does not want to change that. I was hoping that the report would provide me with some arguments against this practice.
But I will use the report to argue for a change anyway…
Hi Dave, I wanted to thank you for this post. The Red Pill team at Rally and myself have been working very hard to bring quantitative insight into the conversation to complement the qualitative insight that practitioners have been spreading. I wanted to let you know that the 6 “decisions” or behaviors that we analyzed for this first paper is just the start. For this first round, we restricted ourselves to behaviors we could extract from ALM data but we are soon going out with a survey to extract another 40 practices, contexts, and behaviors (what I call “decisions” in the paper). Things like TDD, continuous integration, and other engineering practices, as well as additional context, team makeup, and process decisions (age of the code base, skill of team members, dedicated scrum masters and/or POs, etc.).
We expect that these 45 variables should give us a predictive model for performance.
BTW, this work is done as part of my role at Rally, Director of Analytics, but it also feeds into my PhD pursuits at Carnegie Mellon. If you follow my twitter @LMaccherone, I sometimes post early drafts of the findings there to get reaction before we publish them in a paper. I couldn’t find your twitter handle on this page in a quick glance but if you tweet about your post and mention my twitter handle, I’ll be sure to retweet it.
Hi Larry,
Thanks for the comment, and for your work in collecting this very useful information. I posted a tweet with your twitter id, so you should be able to get my twitter id from that.
Cheers,
Dave
[…] tip to Dave Nicolette who first pointed this paper out to […]