Generalists vs. Specialists Revisited

In a recent post I referenced two opposing views on generalist and specialists development team members, both derived empirically. I will continue to blog my experience on this issue because the question goes to core issues like the composition of teams, etc.

Summary argument for generalists: generalist team members decrease the communication barrier by having overlapping experiences and skills. Also, involving more people in more tasks contributes to a better understanding of the “big picture” by individual developers and to increased “ownership” by the team. My last post on this largely discussed the arguments for specialists.

Here are some observations from my work with cross-functional teams at Danube:

  1. Not everyone can do everything well. Some developers (in the generic sense of the word) are very astute, for example, at QA and finding obscure bugs while others are not so inclined.
  2. Not everyone wants to do everything. In general, people like to do what they do well.
  3. It is obvious that inexperienced developers should not be making critical design decisions on their own.
  4. The more team members that are involved with requirements analysis work the better the results.
  5. Conceptual Integrity starts to fade and development slow down when the team lacks a “guide (PDF)“.
  6. However, if the entire team is not engaged in the design process they will lack the big picture and ownership required for individual responsibility.

What do I take away from these observations? I like the “Recommended Actions” in the HolisticDiversity pattern. Let teams create specialist roles of their own volition to depending on the conditions at hand. Rather than mandate everyone do everything, or vice versa bestow individuals with specialized roles, let the team decide what they need to do to get the work done and get out of the way.

Hey wait a minute… isn’t that what Scrum calls “team self-organization”?

Now my question is: can any team self-organize to overcome the problems they face? Are there minimum requirements for team self-organization? Stay tuned…

Victor Szalvay

Victor Szalvay currently leads product development for CollabNet’s ScrumWorks® product suite. In that capacity, he works closely with customers, stakeholders, and the development teams to deliver high business value each release cycle. With more than 150,000 active users worldwide, ScrumWorks is used by more than half of the Fortune 100 and boasts the largest market share of any Agile management tool.

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
sign up for emails
conversations

CollabNet: #CollabNet taps #app #dev industry pro @jliband: as VP of marketing, #Agile, #DevOps, #ALM, #Cloud http://t.co/f7e5Za5TbT
Date: 16 April 2014 | 9:16 pm

CollabNet: 2014 #FutureOSS Results Are In! Finds OSS Powering New Technologies, Reaching New People, & Creating New Economics http://t.co/ECtIkdjG9R
Date: 14 April 2014 | 5:05 pm

CollabNet: Certified #Scrum Product Owner (CSPO) Training Course at #CollabNet HQ in South San Francisco April 16-17 http://t.co/ETLXBrxtTr
Date: 10 April 2014 | 10:25 pm