A central tenet of the Agile methods is collaboration -- all participants in the project being actively involved with each other in all of the project work. While this sounds great in theory, it can be problematic in practice because all team members are not equal.
Most of the Agile methods describe team members as generalists. Some (for example, Extreme Programming) explicitly describe a team of generalists, with no team member owning code or any other thing, and all team members having the authority to do anything that is necessary to achieve the goals of the User Story at hand.
But can we achieve the Agile ideal of full and open collaboration when our team members are not generalists? Is there a place for specialists on Agile teams
Yes. And Yes! Let's take a look at how Agile teams reconcile these different perspectives.
In most organizations, development team members are specialists. Each has an area of expertise, and for some, the term "expert" is fully applicable. They have developed a depth of knowledge and experience in a specific topic that others on the team cannot duplicate. In many cases, we hired them specifically for their expertise. And those who are not yet fully expert are experts-in-training. They are members of specific technical groups and are learning more about their technical specialty every day. We provide them with training and work opportunities and encourage them to become experts in their specific areas.
Specialization is a natural and appropriate approach in IT. There is so much to learn, so much to know, and so much change all the time that no individual can know everything. Our technical team members must be constantly learning just to keep up. They need to specialize if they are ever to reach a level of mastery, but specialization means that mastery will be narrowly focused.
So we end up with requirements specialists who tell the team what is needed, architects who determine how the software should be structured, coders (who specialize in C, Java, whatever) who lay down the code, testers who validate the software, DBAs who build the data structures, and on and on.
Specialization is a good thing, and we should embrace it even if we choose to use an Agile development approach.
Agile methods push us toward generalizing. The Agile values and principles push us away from the idea of specialist individuals and toward a collective view of the team. Indeed, it is the team that is responsible for planning and doing the work, and the individual team members are first and foremost members of that collective.
Many of the efficiencies that are gained from an Agile approach come from breaking down the specialist silos that are reinforced by the waterfall view of development. These efficiencies start with the decoupling of the specialties from project phases: Agile projects no longer have a Requirements phase, Design phase, Coding phase and Testing phase.
The Agile project flow starts us down the road toward eliminating throw-it-over-the-wall behavior. The real benefits of an Agile approach come when there are no longer any walls for things to be heaved over, and that requires the team members to actively work together in all of the project work -- the definition of Generalizing.
On an Agile team, we want to embrace generalization in order to achieve much of the Agile promise. But we need to do it in a way that makes excellent use of the special knowledge and abilities of our specialist team members, hence the idea of "Generalizing Specialists" -- professionals who are indeed specialists, but who step outside of their specialty when needed.
Specialists can almost always generalize because their skill sets are usually T-shaped. In this analogy, the vertical leg of the "T" represents the person's area of expertise -- narrow and deep. The crossbar at the top of the "T" represents all of the other technical areas in which the person is merely competent -- broad, but with varying amounts of depth.
Generalization is valuable to specialists for several reasons. First, experts who fail to venture outside of their specialties can suffer from a type of myopia that limits their ability to apply their specialty in various contexts. With little knowledge of or interest in other technical areas, the expert can apply his or her expertise in a way that is inefficient, counterproductive or even downright wrong in the larger scheme of things.
Second, failure to venture outside of one's area of expertise also means that the person's level of "mere competence" in other areas will degrade over time, both because of a fading memory of knowledge that is not used, and because of technical advances that may invalidate what was known, rendering that knowledge obsolete.
While it may seem obvious that a technical specialist should be devoted to the specialty for which they were hired, the opposite is actually true. The most effective specialists are the ones who maintain their competence across a broad range of related technical topics.
Generalizing Specialists on Agile Teams
To make the best use of specialists, an Agile team must distinguish between the tasks that require deep expertise and the more abundant tasks that require mere competence. The specialists on the team should claim the tasks that require their expertise, but not necessarily every task that is related to their specialty. They must be ready and willing to claim any task outside of their specialty that they are capable of doing if that will be the best way for them to help the team achieve the Sprint goals.
For example, the database specialist should be the primary actor in any database design activities. (Of course, the work should be done in collaboration with the other team members so the database design accounts for all data needs, and so the team members are conversant with the database design and the reasons for it.) Once the design has taken shape, any team member who knows SQL can create a table or add a column where it is needed. When database questions come up, these team members should discuss them with the database specialist, and decide if that task requires the specialist's attention, or if (with their questions answered), the other team members can compete the tasks.
While all specialists might potentially share work related to their specialty with other team members, Requirements Elicitation and Testing are two specialties for which the specialists should not just do the work, but should lead the entire team and mentor the other team members as they build and mature their competence.
Requirements Elicitation: An important keystone of an Agile approach is the active participation of every team member in understanding and responding to the customer's requirements. Adding a Business Analyst (BA) or other requirements expert to the team does not change this.
The best use of a BA on an Agile team is as a facilitator of discussions about user stories. It is best if the BA avoids standing in for the Product Owner, because the Product Owner should be a participant in those discussions. And the BA shouldn't just become the team's requirements documenter, because the requirements details can be captured by any team member in the form of notes, Acceptance Criteria, test cases or diagrams, and because traditional requirements documentation is not useful on Agile projects. When the BA's time isn't consumed with facilitating discussions, they can help with other work (e.g., reviews, critiques, testing).
Testing: The Agile Principle about "Continuous Attention to Technical Excellence ..." is a tall order. It means that every member of the Agile team must be assuring the quality of everything they do. This begins with good design and use of appropriate techniques, but it also includes verification and validation of all kinds, including testing. Adding a Tester to the Agile team does not change this.
As with the database expert, the testing expert should be a central player in designing the test strategy for the project as a whole and for each Sprint -- in collaboration with the rest of the team of course. With a good test strategy in place, every member of the team should be creating Test Cases, writing automated test scripts, and running tests. The testing expert's time is best spent overseeing the team's testing work, helping team members improve their techniques, pair-testing with them, and doing additional testing beyond the more basic testing that the others are doing. When the tester's time is not consumed with testing-related activities, they can help with other work (e.g. reviews and critiques of designs, code and other things).
T-shaped specialists fit very well into the Agile generalist model. They add value by providing oversight and expertise in demanding or critical tasks. They also benefit from the generalist approach demanded of a truly self-managing team. They avoid becoming a bottleneck by off-loading tasks related to their specialty that others can accomplish, while they build their competence in related areas making their specialized knowledge more valuable.
Specialists win (becoming more capable and valuable), other team members win (also becoming more capable and valuable), the team wins (becoming more efficient in their work), the customer wins (getting better software more quickly), and the organization wins (as their resource pool becomes deeper and more valuable). Ergo, all kinds of awesome.
Yes, even specialists can thrive in a generalized environment.
I presented a webinar on this topic in March 2016.
Listen to the recording in the Learning Library at on the Web Seminar Archives.