Armies don’t fight as individuals, they fight as teams. In the U.S. Army, squads are grouped into platoons, then into companies, and then into battalions, regiments, divisions. If these multi-person squads are the basic building blocks in the military, then why is the basic unit of resource on most IT and software development projects the individual person?
There are five individuals in an infantry squad. Three squads, plus a headquarters contingent make up an infantry platoon. As the size of the group increases, specialized groups are added, for example, a division could have a hospital, military police, signal, logistical support, and even a band.
XP proponents advocate programming in pairs and agile methodologies in general advocate close communications and collaboration within a team. But trust, communications, and relationships aren’t built overnight and once a team completes a project, the individual members are often reassigned to other projects, breaking the relationships. In maintenance work we often find individuals working alone. But what if we considered the fundamental resource unit a tiger team, say three-five people — each with some mix of skills (both specialist and generalist level) — a lead developer, a junior developer, a tester, and a product analyst (Tiger Team roles would be tailored to the situation).
Over time these individuals would form a powerful team, drawing on each others skills, experience, and abilities. “This team merges into a single ‘virtual super designer’ able to understand and solve emerging changes to features very quickly — most often due to their ability to merge into one iteration a series of conversations and meetings that would normally be conducted in series with wait states (down time) between them,” says Paul Young who implemented this approach in his IT organization. Tiger teams enhance cohesion, problem solving, team spirit, and more.
For large projects, tiger teams would be combined into project teams — at the tiger team level, not the individual. Tiger teams might move from project to project, but as a group, not as individuals. As the project size increases, specialists (an senior architect for example) could be assigned at the project level, while for really large projects there might be specialist tiger teams, like the band in an army division.
Tiger teams tend to be very fast, and very productive. Since there are adequate resources, even for small projects, feature development, testing, and documentation, get done in parallel. Because the team understands the project from several perspectives and how it all integrates, they tends to focus on the most critical items. Because the team works together, they get jazzed about delivering rapidly and self-police — they keep the pressure on each other.
This type of resource allocation is also in line with the findings of Eliyahu Goldratt, Critical Chain Project Management, The Goal, who recommends focusing on throughput rather than productivity. Having 4 maintenance projects, each adequately resourced with 4 people, enables the teams to get them done quickly and effectively. Having 16 maintenance projects, each resourced with 1 person, leads to delays and ineffectiveness.
So try an experiment, create your own Tiger Teams and see what happens!