Agile Series Part 1: The "Typical" Agile ProjectPosted By Taylor Putnam on Mon, 2012-11-26 15:41
After spending the past few weeks working with the Agile projects in QSM’s historical database, I’ve become interested in Agile Development Theory, particularly due to its popularity. While spending days at a time examining our database, I’m left with numerous data-driven questions. Therefore, I thought I would take this opportunity to write a series of Agile-related blog posts.
QSM’s database contains over 100 Agile projects from the U.S. and abroad. The projects include a variety of application types and their top three programming languages were JAVA, C++, and VB.NET. Seeing this, I thought it might be interesting to examine the “typical” Agile project according to our data.
So what does the “typical” Agile project look like? For consistency purposes, I limited the sample to IT systems projects completed in the last six years. I measured the Duration, Effort, Average Staff, and MTTD at various project sizes to see how they compare.
Below are two figures that give demographic information about our “typical” Agile projects:
This scatter plot shows the individual Agile projects compared against QSM’s Business Agile trends.
The table above shows the values of previously mentioned metrics at various sizing units. The purpose of this table was to give a benchmark of how Agile projects in our database typically perform. It is a good way to measure your organization against the industry. This can also be done using QSM’s Business Agile benchmark trends. However, the most accurate way of estimating your projects should be from your own historical data. Since the data in this table are merely descriptive, I’m going to leave the interpretation of the results up to the readers.
In upcoming posts I will further examine the effects of these individual metrics on one another and how that relates to Agile Development Theory. In the meantime I hope this table can help give some insight on the “typical” Agile project. How do your Agile projects compare?
- Duration: includes the time measured in months for all activities beginning with Requirements Determination (Phase 2) through the Initial Release (end of Phase 3)
- Effort: includes the number of person hours for all activities completed in Phase 2 and Phase 3
- Average Staff: includes the number of staff, measured in FTE, for Phases 2 and 3
- MTTD: refers to the Mean Time to Defect determined in the first 30 days after delivery
Re: Question on QSM Business Agile TrendlinePosted by Taylor Putnam on Wed, 2012-11-28 16:12
Thank you for your comment. You are correct - the data used in this table includes projects added to the QSM database since the current set of Agile trends were created. We’ve added about 40 new Agile projects since then, so it’s unsurprising that the results are quite different from the previous trend line.
Another thing worth noting is that for this table I used the metric averages. In general, larger projects (such as 100K SLOC) will have greater variation around the mean than smaller projects. I would imagine if I were to use the median values I would have less dramatic results.
Methodologies aside, your observations raise some interesting questions about the changes in Agile trends over time. Maybe I can examine the changes more closely in a future blog post!
Reply | Add Comment
Question on QSM Business Agile TrendlinePosted by on Tue, 2012-11-27 17:35
When I put the above parameters into QSM v8 and use the QSM Business Agile trendline, I get significantly different results (eg, 100KSLOC - Phase 2 & 3 only, Duration 9.3 mths (+1.5), effort 10,267 (less by over 5,000hrs), Ave staff 9.4 (less by 7 people) and MTTD 0.881 (less by 0.319).
Q/ Is the above data new information that will be used for the next update to the QSM Business Agile trendline?
PS - If a run the solution using 50% of duration of 7.8 mths, I still get different results (eg, 21,800hrs)
Reply | Add Comment