Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Agile Developers: Generalists or Specialists?


December 2002; Agile Modeling

What type of skills do you need to be effective at agile development processes such as Extreme Programming (XP), Feature Driven Development (FDD), Agile Modeling (AM) or SCRUM? From a personal point of view, should you specialize and become expert at a single activity or become a jack-of-all-trades generalist who knows a little about a lot? From a management point of view, if you're forming a team, what type of people should you strive to include?

To address the complexity of software development, the first reaction of many organizations is to build a team of specialists, assuming that because specialists are proficient at a specific task, they are therefore more efficient; therefore, the optimal organization involves a team of specialists who hand off their work to other specialists. This "assembly-line" school of thought may be appropriate for prescriptive software processes, but it's clearly not appropriate for agile processes. Furthermore, a specialist-focused approach is geared toward larger teams—if there are X distinct tasks required to develop software, you need at least X specialists following this approach. How big is X? Twenty? Fifty? One hundred? Depends on how finely you define the specialties, doesn't it? Considering that most agile development methodologies are aimed at small teams of developers, the specialist approach isn't likely to work well.

Specialists often have difficulties working with others: Either they lack the humility to recognize that other people have something of value to offer, or they are so narrowly focused that they may not realize that their work may cause someone else to do significant rework later on.

Despite their name, specialists' skills may not be up to snuff, even in their own specialty. The high rate of technical change within the IT industry provides an environment in which developers can work with a new technology for several months, become reasonably familiar with it and claim to be experts because of the lack of competition. All these factors contribute to the hazards of building a team of people who are only specialists.

So how about a team of only generalists? Everyone would have a fairly good understanding of how to develop software, but unfortunately may not possess the detailed knowledge required to get the job done. Your project will need people intimately familiar with the techniques and technology you're using. If you're working with Enterprise JavaBeans (EJB), you want developers with expertise in Java programming as well as in EJB development. A team working with Oracle on the back end will also want someone with Oracle database administration experience, and a team developing software for a brokerage will want people who understand the nuances of stock and bond trading.

Clearly, neither extreme works well—instead, what you want is something in the middle. One approach is to build a combined team of generalists and specialists. The generalists provide the glue, focusing on the bigger picture, while the specialists deal with the project's detailed complexities. This works well because the generalists' strengths balance the specialists' weaknesses—and vice versa.

An even better approach is to build a team comprised of people who are generalists with one or two specialties. For example, I'd claim that I'm a generalist. I have a pretty good handle on how the software process fits together, yet I have specialties in business application software modeling, object persistence and Java programming. One of my current coworkers is a generalist with specialties in modeling, EJB development and testing, whereas another is a generalist with specialties in telecommunications networking and Java programming. The advantage of building teams from generalists who have one or more specialties is that they quickly find common ground with their coworkers—after all, they're generalists, with the necessary background to appreciate the importance of other specialties. The main disadvantage is that these people are often very senior, and thus are difficult to find—it can easily take ten to 20 years to gain sufficient experience to become a generalist.

There's never a perfect solution. I advise developers to continue learning new skills, particularly a wide range. Have some technical as well as "soft" people skills. Take on diverse roles on projects, and try to work on different types of projects in various domains. The more you know, the more valuable you become, and being valuable is always a good career strategy.

Recently on the Agile Modeling Mailing List:

  1. Misconceptions regarding Agile Modeling (AM). This was a conversation that I began when I became concerned with the misconceptions regarding Extreme Programming (XP) that came up on newsgroups such as comp.object and comp.software-eng. These misconceptions include the idea that you can't use CASE tools with AM, that you can't review agile models and that positions such as "business analyst" are disallowed.
  2. The notion of primary keys. We had several discussions regarding key strategies within physical data models, an important modeling consideration that affects both your data schema as well as your source code. The relative merits of surrogate keys and natural keys were discussed in detail, each strategy having its own backers.
  3. Use case modeling issues. A conversation that began on the Rational Unified Process users group spilled over onto the AM mailing list when someone needed help trying to understand the appropriate use of the <<include>> and <<extend>> stereotypes. My rule of thumb is that when you know the exact step where another use case needs to be invoked, then <<include>> is likely what you want, whereas if a use case may be invoked any time during a range of steps, then <<extend>> is your better option. I like to think of <<include>> as a function call and <<extend>> as a hardware interrupt.

Recommended Online Resources

Agile Modeling Mailing List.
http://www.agilemodeling.com/feedback.htm

Essential XP: Emergent Design. Ron Jeffries.
http://www.xprogramming.com/xpmag/expEmergentDesign.htm

Misconceptions Regarding Agile Modeling.
http://www.agilemodeling.com/essays/misconceptions.htm

Pixid's Whiteboard Photo software for cleaning up digital photos of whiteboard sketches.
http://www.pixid.com

Reuse in Use-Case Models: <<extend>>, <<include>>, and Inheritance.
http://www.agilemodeling.com/essays/useCaseReuse.htm

Specifying Requirements With a Wall of Wonder. Ellen Gottesdiener.
http://www.therationaledge.com/content/nov_01/t_wallOfWonder_eg.html


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Agile Modeling

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Recent Articles

Upcoming Events



Most Recent Premium Content