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).  This article is organized into the following sections: Generalizing specialist: A definition Becoming a generalizing specialist Why generalizing specialists? Generalizing specialists and the whole team practice What about specializing generalists? Generalists vs. generalizing specialists Is there still room for some specialists?

Generalizing Specialist: A Definition

1. Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...).
2. Has at least a general knowledge of software development.
3. Has at least a general knowledge of the business domain in which they work.
4. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.

Generalizing specialists are often referred to as craftspeople, multi-disciplinary developers, cross-functional developers, deep generalists, polymaths, versatilists, or even "renaissance developers". 

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.

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 2 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 3 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. 
5. Fewer bottlenecks.  Specialists become bottlenecks, reducing overall team efficiency, when work queues up for them.  For example, a single database administrator (DBA) is assigned to support four development teams due to lack of database expertise amongst other people.  This would be perfectly fine if the four teams generated less than one person's worth of data work in total, but in most organizations as soon as it was recognized that the DBA had slack time available to them they'd likely be assigned to one or more other teams until they finally had no more slack time available to them. So, because work load isn't consistent work will queue up for them sometimes, which means that the teams which they're supporting need to wait for them to get the work done, reducing overall team efficiency as a result.  The specialist in effect becomes a bottleneck.  Sadly, assigning experts to multiple teams is perceived by traditionalists as efficient because they look at it from the point of view of resource allocation instead of the point of view of overall team effectiveness.

Figure 2. A traditional software development team.

Figure 3. 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.

What About Specializing Generalists?

Sure, why not?  In this case someone starts as a generalist and then picks up one or more specialties. This would be just another path, albeit a rare one, to the same strategy.

Generalists vs. Generalizing Specialists

Is There Still Room For Some Specialists?

The quick answer is yes, depending on the context.  There are two categories of situation where your team may find the need for specialists:

1. Short-term unique activities.  For example, your team may find that it needs to setup and configure a database server.  Although you could figure it out yourselves, it’s probably easier, faster, and less expensive if you could have someone with deep experience help your team for a few days to work with you to do so.  This person could be a specialist in database administration.  These one-off situations often occur at the beginning of a project or at the end of the project, what Disciplined Agile Delivery (DAD) would refer to as the Inception or Transition "phases" of your project.

2. In scaling situations.  At scale you may find that the complexities you're dealing with may require specialists focused on addressing those complexities in an ongoing manner throughout your project.  The scaling factors called out in the Agile Scaling Model (ASM) can help to make this a bit clearer.  For example, your team may find itself in a situation with high technical complexity, which in turn makes your build so complex that you need someone(s) specifically focused on being "buildmeisters".  In situations of domain complexity or organizational complexity you may bring one or more business analyst specialists onto the team to help you explore the problem space you’re working in.  

Bottom line is that it it isn’t a black and white world and you will need specialists from time to time.

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

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 Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.