I believe that to become an agile software developer that you need to move away from being a narrowly focused specialist to become more along the lines of what I like to call a generalizing specialist (a concept I first discussed in Agile Modeling although I introduced the term in Agile Database Techniques).  Generalizing specialists are often referred to as craftspeople, multi-disciplinary developers, cross-functional developers, polymaths, versatilists, or even "renaissance developers".  A generalizing specialist is someone who: Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...). Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.

A generalizing specialist is more than just a generalist.  A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few.  Big difference.  A team of generalists can easily flounder because none of them have the skills to get things done.  Similarly, a generalizing specialist is more than just a specialist.  A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others.  Specialists will often be blind to the issues which other specialists focus on, and as a result will struggle to work with those other specialists effectively. As Figure 1 indicates, people who are generalizing specialists are in the "sweet spot" between the two extremes of being either just a specialist or just a generalist, enjoying the benefits of both but not suffering from their drawbacks.

Figure 1. Comparing Specialists, Generalists, and Specializing Generalists.

Becoming a Generalizing Specialist

When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA.  You will initially focus on becoming good at that role, and if you’re lucky your organization will send you on training courses to pick up advanced skills in your specialty.  Once you’re adept at that specialty, or even when you’ve just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain.  When you do this you evolve from being a specialist to being a generalizing specialist. 

Figure 2 depicts a fictional skills assessment of an IT professional, showing how it evolves over time.  In this example, the person has solid skills in Java development, and some initial skills in modeling, testing, and database administration (DBA).  Then, two years later, they've improved all of their skills, including their Java programming skills.  They may have achieved this through training & education, mentoring, or collaborative techniques such as modeling with others or pair programming.  Then, three years later their skills have improved further, although it's interesting to note that focus on a new skillset (.Net programming) may have motivated the person to let their Java programming skills go stale.

Figure 2. How a generalizing specialist's skills may evolve over time.

As an individual it's an incredibly good strategy to become a generalizing specialist.  The greater your skillset, the more likely that you'll be in demand and the easier it will be for your to gain employment.  Furthermore, you'll likely get better jobs than you would have because of your greater productivity and versatility.  Just like you wouldn't have a stock portfolio with a single stock in it (that's an incredibly risky investment strategy) you shouldn't have a skills portfolio with only one specialty.

Why Generalizing Specialists?

There are several reasons why you should prefer to build teams from generalizing specialists:

1. Improved communication and collaboration.  A generalizing specialist is someone with a good grasp of how everything fits together.  As a result they will typically have a greater understanding and appreciation of what their teammates are working on.  They are willing to listen to and work with their teammates because they know that they’ll likely learn something new.  Specialists, on the other hand, often don’t have the background to appreciate what other specialists are doing, often look down on that other work, and often aren’t as willing to cooperate.  Specialists, by their very nature, can become a barrier to communication within your team. Another challenge with specialists is that they have difficulty working together effectively with others because they don’t have the background to understand the issues that the others are trying to deal with. 

2. Less documentation.  Specialists are often motivated to create far more documentation than is required, when all you can do is write use cases then those use cases will end up including information that could be better recorded elsewhere, and very likely require reviews of said documentation when they provide it to other specialists.  The implication is that the same piece of information will often be captured by several specialists because they’re afraid that they’ll lose that information.  It’s quite common on projects dominated by specialists to see a business rule captured in a user interface specification, in a business rule specification, in a logical data model (LDM), in a UML class diagram, in acceptance tests, and in source code.  Clearly there’s a chance that the business rule will be described inconsistently (thereby motivating more bureaucracy in the form of traceability) let alone the obvious overhead involved with reviewing and maintaining each version of it.  A generalizing specialist will write less documentation than a specialist because they have a greater range of options available to them.  Instead of having a user interface specialist capture the rule in a screen specification, the data specialist capture it in an LDM and so on the generalizing specialist will instead capture it in the most appropriate place(s).  In this case that could be in the form of one or more acceptance tests as well as in the source code.  In short, a generalizing specialist can choose the best artifact to to capture the information in one and one only place.  The implication is that a team composed of generalizing specialists will be more effective than one composed of specialists.

3. Improved flexibility. In his discussion of integrating usability specialists onto an agile team, Paul Hodgetts discusses several practices which result in productivity loss which are motivated by having specialists on your team.  Specializations forces the team to pre-assign tasks to individuals, thereby hindering the team's ability to dynamically allocate tasks as new circumstances emerge. 
4. Less risk. Specialization drives teams to break down their iteration tasks to accommodate each person's specialty, resulting in finer-grained tasks and more points of hand-off between people.  This can be seen in the diagram of Figure 3 where each specialist does their work, handing it off to the next specialist.  The problem is that every time there is a hand-off between people there is information loss, documentation is the worst option for communicating information between people (see discussion about the CRUFT calculation), thereby increasing overall project risk.  Figure 4 shows how an agile team would be organized -- instead of throwing artifacts "over the wall" to one another agile team members instead share the artifacts between them, working together to evolve the artifacts as needed and when needed, learning from each other as they do so.  This lowers overall risk because there is less information, greater knowledge of the system amongst individual team members, and growing skills amongst team members. 

Figure 3. A traditional software development team.

Figure 4. An agile software development team.

Generalizing Specialists and the Whole Team Practice

The Whole Team practice, popularized by Extreme Programming (XP), recommends that you include everyone on the team with the skills and perspectives required for the team to succeed. Furthermore, it recommends that everyone on an agile team contributes in any way that they can.  If people are generalizing specialists then it becomes much easier to form whole teams because it will be easier to find someone with the skills that you need.  If people are specialists then you'll find it much more difficult, and you'll often be forced to have a single person work on multiple teams because those teams need someone with their specialty.

Conclusion

In many ways a generalizing specialist is simply a software craftsperson.  The reason why I don’t use the term “software craftsperson” is that it is a loaded one that is likely to turn off a large number of traditional developers that prefer something along the lines of "software engineer".  I believe that “generalizing specialist” is more palatable.

In short, my experience is that generalizing specialists are much more effective than either specialists or generalists.  The best developers are generalizing specialists, or at least actively are trying to become so.  There is still room for specialists within your IT department, they can often act as internal consultants to your development teams, but as IT departments become more agile I suspect that we will see fewer specialists surviving over time. 

Recommended Resources

Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes  (Paul Hodgetts) The Longevity of IT Skills Rethinking Business Analysts Roles on Agile Teams: From Small to Large Strategies for Effective Training and Education (T&E) in I.T. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.