Building Generalized Specialists
>> Sunday, February 07, 2010
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
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
|
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.
I attended 
