12

I work in a large company that is in the process of transitioning to Agile. I suspect our ratios for the various roles are way off, especially for the technical writers. What is the ideal head-count ratio for the various non-managerial roles?

  • developers
  • testers
  • tech writers (producing install guides, release notes, data dictionaries, and other technical docs)
  • user-doc writers (producing user guides and training guides)
2
  • 1
    Your question was lightly edited to prevent closure as an opinion poll. Please feel free to edit further if needed. – Todd A. Jacobs Mar 5 '14 at 1:05
  • The ratio is: all team members are team members. – Andrew Clear Oct 21 '15 at 19:54
7

TL;DR

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.

Team Size

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
end

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.

2
  • Thank you for your answer, which suggests that my company is not yet truly agile. I am having a hard time envisioning what an agile team should look like. Considering that different people have widely divergent skills, it seems wrong to expect people to fill in at any task. I’m hoping to hear what percent of each person’s time is spent doing that person’s specialty (developing, testing, etc.) and what percent is spent on doing whatever other tasks the team needs at this moment. – Cheryl B Mar 10 '14 at 18:59
  • 1
    @CherylB A cross-functional team is self-directed. If you're still thinking in terms of siloed responsibilities and percents of utilization per person then you're still missing the point. There is no canonical answer possible once one accepts your underlying premise. Please review the available literature on Scrum, Lean, and Kanban team structures, as well as the Agile Manifesto and its principles. – Todd A. Jacobs Apr 21 '14 at 13:42
6

The ratio depends on the company and how software and project management oriented the management team is.

In my experience, the majority of staff in an agile software team were testers, because the corporation focused on user experience and prior to delivering the final product to the customer, they needed to ensure that the product was "bug free" and that a high quality product was delivered to the clients to ensure receiving additional projects from these clients.

Therefore, each team had a corresponding project manager, two developers, two to four testers, one tech writer, and a project coordinator assigned for each project. We did not have an specialized user-doc writer as the tech writer along with the project coordinator helped with these type of tasks. This ratio worked well in our agile team; customers were happy, and it seemed like an ideal ratio for our team. Keep in mind each developer was working on two to three projects simultaneously.

I also know of a multinational corporation that does not even have specialized roles in their "software development" team, and hire developers to wear all the hats: do development in all layers, do their own testing, write technical documentation, and specs etc..

This approach is not only a bad practice of using resources effectively (specially that each developer has different skill sets and strengths), but also increases the chances of delivering a defective product due to not having a proper development methodology from initiation to closing. As a result of this, projects in this team are delivered with bugs, budget is not properly allocated, projects are not delivered on time nor within budget resulting in dissatisfied customers and instead of developers being utilized to create new features of the product, they spend most of their time fixing existing and new bugs.

0
1

Personally, I like the following statement from the Scrum Guide

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

Unfortunately not all developers are happy with testing or writing user guides so testers, tech writers, user doc writers are needed. I think that development team should be responsible for providing "ideal head-count ratio" for that roles since testers, tech writers, user-doc writers belong to the Development Team.

Testers, tech writers, user-doc writers might not be needed at all if development team can provide acceptance testing, technical and user documentation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.