Pages

Sunday, February 07, 2010

Building Generalized Specialists

Generalist Vs Specialist 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,

 


A Specialist is some one who knows a “bit more” about something.

In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc


A Generalist is some one who knows a bit about many things


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 ?


image 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

 



Module Name

Skills/technology      Primary         Backups

Billing

JSP, Java, Hibernate      Rashmi     Rohit, Chandru

Dynamic IP Generation

Java, C++, Tcp/Ip      Jim     Chandru, Rashmi
CMTS configuration WAS, TCP/IP, REST, XML       Chandru      Jim, Rohit


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.  

3 comments:

Anonymous said...

Nice. We had an interesting discussion on this topic at the Mumbai Agile User Group last Oct.

Another option is the contractor model, where the team is generalists, but you bring in specialists for a short while at certain points in the project as "contractors." Could be external contractors, or people from another project who are "rented" for a week or so.

Venkatesh Krishnamurthy said...

Thanks Siddhi for sharing this info.

Katie said...

Really like this post! Our team seems to have a good mix of Generalists and Specialists but I really like your idea of having a "backup pattern." Could be clutch in certain situations. Your blog is now featured on Agileshout.com.