If you're still thinking in terms of strongly-defined roles rather than cross-functional teams, then you're not making a successful transition to an agile process. Agile teams may need all of the skills you've listed, but each of those roles is actually the responsibility of the whole team rather than of individuals, and it is up to the team to identify who is best-suited to perform the relevant tasks required to produce a feature.
There's no single canonical answer to this question. A lot depends on the organization, the project, and the available resources. The recommendation from most agile practitioners is 4-9 people; I typically recommend teams of around 7, plus or minus two people depending on the size or complexity of the project.
Agility requires a full set of cross-functional skills on the team, but also requires that the number of communication channels be kept at a manageable level. The recommendation for smaller team sizes is primarily because larger teams aren't capable of the high-bandwidth interpersonal collaboration required by agile frameworks.
Given the following equation for finding the number of communications channels within a team (expressed as Ruby code):
# n * (n - 1) / 2
def channels people
people * (people - 1) / 2
you can quickly see that a 7-person team has 21 communications channels, while a 9-person team has 36. A 20-person team has 190 channels, which generally violates the core agile principle that values "[i]ndividuals and interactions over processes and tools." You will find many agile team processes that perform poorly for larger teams; the 15-minute daily stand-up is just one such example.
Cross-Functional and Self-Organizing
Agile teams must be cross-functional, meaning that while certain people may know more about certain knowledge domains than others on the team, the knowledge and responsibility is shared (often through pairing or other high-bandwidth interactions) rather than siloed into vertical skill sets or strongly-defined roles.
In addition, teams succeed or fail as a team. In order to do so, the teams must be empowered to be self-organizing. In practice, that may mean that Bob writes the documentation while Alice codes, and Mallory writes the acceptance tests that Joe runs on the continuous integration server. However, Bob isn't writing the documentation because he's a technical writer; he's writing the documentation because he's pairing with Alice on some feature, and decides he has the bandwidth to write the documentation while Alice is running the developer-level spec tests on the code the two of them have just collaboratively written.
In general, agile frameworks are built on the idea that the whole team swarms over each story, parceling out the tasks to the people who are most adept or have the most bandwidth to get a particular task done. Since the team is small, and the framework encourages constant n-way communication about task and story status, it is easier to simply hold the whole team accountable at the story level than to try to micromanage swim lanes and hand-offs at the project level.
Teams in Transition
For software teams in transition, I generally advocate the following:
- 5 developers who work interactively with everyone else to ensure that TDD/BDD specs are written, code is documented, and features are tested according to the "definition of done."
- 1 code-savvy QA expert who can work alongside the developers to help them write better tests, and who can maintain the continuous integration server.
- 1 code-savvy technical writing expert who can work alongside the developers to ensure that the product is documented as it's being written (not after the fact) and that the developers are writing documentable code and keeping code comments and documentation up to date.
On some technical projects, you might need someone with database or network design skills, or some other specialty. If so, go ahead and add a person or two, but remember that their job is to spread expertise throughout the team, rather than act out a unique role.
All of these people are full members of the development team; developers, testers, writers, architects, and analysts are all equal participants in every single aspect of an iteration. For example, testing is everyone's responsibility, and not relegated to a second-class team member. Testing should be part of your definition of done, and may include unit tests, integration tests, acceptance tests, or anything else your project has defined as part of the "definition of done." Since it's everyone's responsibility, you don't need a unique role for testing.
Ditto for documentation.
Because these teams are in transition, and are rarely adept at self-organization or collaborative development, you will probably need to allocate some project time (and therefore budget) to training, framework education, teaming exercises, and developing an agile mindset within the team. Simply throwing a few people with vertical skill sets into a room and calling them an agile team will not make it so.
Lastly, it's worth noting that this section focuses on software development; that's simply for illustration. However, the underlying principles of collaboration and n-way communication during iterative development is equally relevant in any other domain. Only the skills required to round out the team should change.