I thought of writing this, since it seems many software experts are obsessed with agile and specifically scrum. Anywhere they go, they want to implement scrum, XP,.. .
Aside from the initial hype and the overly enthusiasts, it's time to have a look at statistical data collected.
Like many other cases in software we need to choose the best tool given the constraints and capacities,.. .
Agile was first developed by a number of software development experts who wrote "agile manifesto" having around 12 principals.Agile is in concept around self directed individuals, communication, customer satisfaction, and minimal documentation.
Since then a number of methodologies have come to exist.
In a book by Capers Jones (Software Engineering Best Practices), different software development methodologies, are compared in respect to different project sizes and metrics.
First we need to establish a definition, to be able to intuitively understand the final results :
- Small project : a project that has less than 10 team members, and lasts for a couple of months to complete.*
- Medium project : a project that has a team of less than 10 members, and lasts around a year, or couple of teams over several months.*
- Large project : a project with multiple teams , over multiple years.*
*Capers uses Function points to measure project size.
According to Capers Agile methodologies are in first ranked in small projects.
For medium sized project Agile comes 2nd, however for large projects agile is not in the top 4.
The following table indicates the top rated (most successful) methodologies foreach development metric, for projects of size 1000 function points:
1.
|
Development schedules
|
Extreme programming (XP)
|
2.
|
Development staffing
|
Agile/scrum (tied)
|
3.
|
Development effort
|
CMMI/5 spiral
|
4.
|
Development costs
|
CMMI/5 spiral
|
5.
|
Defect potentials
|
TSP
|
6.
|
Defect removal efficiency (DRE)
|
TSP
|
7.
|
Delivered defects
|
TSP
|
8.
|
High-severity defects
|
TSP
|
9.
|
Total Cost of Ownership (TCO)
|
TSP
|
10.
|
Cost of Quality (COQ)
|
TSP
|
Given this information, seems we have to look into some criteria to choose the best methodology.
According to Barry Boehm, we need to have a look at the following:
- Is the organisation ready for change at any level to accomodate a methodology, not in words only but in action: i.e.: change space and seats,.. .
- The characteristics of the product. i.e.: Are lives involved?
- Is the development culture ready(i.e.: pair programming, interpersonal issues, can they collaborate?)
It seems agile doesn't have a silver bullet, but yet another tool in the toolbox.
I encourage you to have a look at this article for more details.
