Several articles have been written comparing the heavyweight and the lightweight methods. 

However, I found this document to be very comprehensive in comparison.

The document compares the Heavy Weight methods like
Waterfall, UP and Spiral Model  with the Light weight methods like

  XP, Scrum, FDD, DFDM,etc. 

The topic of  Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions.  I too have my personal opinion about this topic. 


Let me start this discussion with a few definitions.

Put it in a simple way,

The question arises, should we have specialists in the team or generalists in the team.   Each of these techniques has its own pros and cons as explained in this article.

My opinion is that, every individual is passionate about something. Some times they get to express it and get opportunity to pursue the same, and many won?t get this chance. People pursuing their passion end up becoming true specialists. However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.

Is there a problem being a specialist ?

Many Agile evangelists say specialists are not good. However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.

Let me give you an example, most of the software companies (that I have seen so far)  have limited number of  Architects and Database administrators and mostly these roles are shared among various projects. Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements. At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper.  This is a challenging situation right ?  How can we make use of the DB admin in handing this situation as he is the only one available.

Let us review couple of options on hand

 Option 1:

Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed.  But doing so might make the current client unhappy

 Option 2:After completing the current assignment, go back to earlier project, understand the defect and fix it.  This may not be possible as the defect is critical and needs immediate attention
 Option 3:Split time between the current requirement gathering work and fixing the defect.  It has been proven that  multi tasking reduces efficiency and productivity.      

Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders to encourage generalized specialists.

How to build Generalized Specialists ?

While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.In such instances,  I apply what is called ?Backup Pattern?. This pattern name is my own invention. While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other.  This provides an opportunity to have backups(in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks.  However the same backup personnel  would continue to have their own specialization. The team members could volunteer to be backups.

Here is an example of a table showing my backup pattern technique

Above technique has helped me in tackling the issues of specialization. This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.

Conclusion

Having an extreme form of  all Specialists or Generalists is not healthy for any project.  There should be balance between these two types  and decision to have generalists or specialists should be based on specific context.  

Jeff Patton kept talking about usage of the word Requirements considered harmful during recently concluded Agile Bengaluru conference. When you listen to Jeff from his context and examples, you tend to nod your head in agreement.

Jeff has written a very nice article about the subject and I don?t want to copy/paste the article, and go ahead and read it here.