«    »

Staffing Software Development Teams

Recently I had a few discussions relating to the staffing of software development teams, and I was dismayed to learn that some managers viewed this as merely getting the right number of FTE (full-time equivalents) placed onto each team. In this flawed traditional command-and-control viewpoint, people are nothing more than interchangeable resources, and teams are simply sets of resources. This management model worked decently in the past centuries for manual labor, but performs poorly in the context of knowledge work.

A more modern perspective is that people are humans (not resources), and teams are social constructs whose purpose is to execute on a shared vision / goal. Team have holistic characteristics like productivity and culture that arise out of the interactions of people within the team. A smaller high performing team can dramatically outperform a larger poor performing team: the number of people on the team is not the sole factor determining performance.

Unfortunately, just knowing this perspective is not enough to know how to staff teams. The flawed traditional model is very simple to act on (just add bodies till you reach your number), and this is one reason managers still use it. In the remainder of this article I present more concrete tools for determining how to staff teams.

Developer Productivity Model

Software engineering research clearly demonstrates a wide variance in productivity between software developers - perhaps as much as 10 times between the best and worst programmers. The problem with taking this into consideration when staffing is that the productivity of individual developers is incredibly difficult to measure or predict accurately.

One proxy measure that is available when staffing is the grade or level of the developer (junior, intermediate, senior). This can be a reasonable approximation for productivity if levels are assigned based on observed capabilities doing software development and are not based on years of experience, politics, or performance doing non-development work (e.g. helpdesk support or testing). As a tool for staffing, each developer's level can be mapped to an equivalent in terms of FTE, normalized to the intermediate developer level.

An important consideration to factor into this model is the level of support (help) less senior developers require from more junior developers. A senior developer with a big enough team of juniors will get none of their own development done as all their time will be spent helping the juniors accomplish their tasks. Each junior and intermediate will essentially consume a certain percentage of a senior developer's time.

The following table provides a numerical model of these above two factors based on my experience.

Developer Level FTE Equivalent FTE Consumption of Senior Developer
Expert 2.0 0.0
Senior 1.5 0.0
Intermediate 1.0 0.1
Junior 0.5 0.2

Here is an example of using this model. Management wants to double the output of a team of two senior developers, so two more developers are assigned: one intermediate, one junior. The original output of the two seniors is modeled as 1.5 * 2 = 3.0 FTE, while the output with the two new developers is modeled as 3.0 + 1.0 + 0.5 - 0.1 - 0.2 = 4.2 FTE, which is only a 40% increase in output. Two more intermediates would have to be added to the team to achieve double the productivity: (1.0 - 0.1) * 2 = 1.8 + 4.2 = 6.0 FTE.

Team Roles Model

The prior model focused on developers, but successful software development teams require additional skills in a variety of areas, especially in understanding the business domain and expertise in testing. This model is based on a lean product development flow perspective: the developers are the core builders of the product (software) but are provided support to have a smooth flow of business ideas / needs translated into working, fully tested software ready for production. The model determines the amount of business and testing expertise needed on a team based on ratios with the number of developers (or FTE equivalent, if using the above Developer Productivity Model).

The actual ratios required depends rather heavily on the context. The following table provides some guidance when developing enterprise business software.

Area of Expertise Ratio Corresponding Context
Business 1 : 5 Simple business domain.
Business 1 : 3 Complex business domain.
Tester 1 : 4 Simple software.
Tester 1 : 2 High quality desired, complex software, or requires lots of types of testing that developers are not strong at.

While it can be difficult to get the right balance of skills up front, it becomes much easier during development when using tools like a Kanban board to visualize the flow of work. If developers are running out of requirements / refined user stories to work on, then more business expertise is likely needed (or reduce the number of developers). If the development team releases software with lots of defects or there is a backlog of functionality that is written but not tested, then more testing expertise would help. (Ensure first that the developers are properly reviewing and testing their work.)

Team Leadership Model

This model is based on Alistair Cockburn's writings in Crystal Clear: A Human-Powered Methodology for Small Teams in which he states that a critical success factor in software development projects is having strong leadership within the team for three key areas:

  1. Business / product
  2. Technical
  3. Process

The roles of product owner, architect, and agile coach / Scrum master correspond to these three areas, but you don't necessarily have to have explicit roles defined on the team for each of these areas. The key is to having people on the team who will naturally provide leadership and guidance to the rest of the team.

If you find this article helpful, please make a donation.

«    »