Keep Development Teams Small




Keep Development Teams Small

Right. Now look here. In the US of A we have a couple Houses. Members of the Senate & and the House of Representatives—not to mention the attendant bureaucrats and lobbyists. All have committees, sub-committees, oversight committees, and advisory teams.

With all those folks you'd think we'd have an efficiently run nation.

It's because of all those multitudes that we do not.

The Perilous Fight

On the bright side our "Team-Fail" government isn't designing our business software.

The downside: These folks (sometimes) agree with each other, or (more often) disagree merely for the sake of disagreement. How many people does it take to determine we shouldn't kill or steal? Why do we need entire libraries filled with overly reiterated documentation that doesn't really get to the heart of any problem?

Teeming with teams isn't an optimal business solution. The cost inevitably ends up at the expense of the client…which is me and you. We The People.

Oh Say Can’t You See?

Our political system is a daily reminder to keep development teams small. That goes for most any industry but particularly software design—which is not terribly different from development and maintenance of a functional political system.

Cracking software development teams have codes and laws that are respected instead of argued over or dodged. They have Agile; a philosophy with its own manifesto that one could compare to the US Constitution which focuses on people and results rather than institutions and processes. Communication is valued instead of avoided.

The Dawn’s Early Light

Clearly it’s in everyone’s best interests to keep software development teams from growing into a bloated dis-organization. Small teams quickly come up with flexible, goal-oriented plans which naturally result in working software.

  • Small teams are more productive and less expensive. (Plus, software developers don’t need 5K hammers or gold-plated commode seats).

  • Everyone (including the client) has a chance to give input and have their say

  • Small teams equal many brief, productive meetings instead of long, Congressional sessions that end in stalemates broken only by head-splitting yawns

While there is no hard-and-fast rule as to what number of folks should be enumerated on a team, Amazon's Jeff Bezo measures optimal team size in pizzas. Bezo's take on the matter is scrappy--like patriots fighting for smaller government and better communication; more people doesn't automatically equate more productivity or even success and is often the very opposite--counterproductive.

On average, Agile methodologists suggest 7 to 9 people make for the target development team. Keeping that in mind, team size is also determined by need and each person's ability. Ultimately, though, the number of team members is decided by the team members themselves: Self organization.

This Agile-based practice of smaller development teams isn't about rigid rules but having a flexible framework and guidance. Change is progressive instead of panic-inducing. People—developers, clients, team members—are given preference. The client is part of the team and has a direct say in the development process.

Keeping teams agile instead of overstaffed is how productive software developers stay productive. Smaller teams offer:

  • Enhanced efficiency

  • Cool collaboration

  • Rapid results

Land of the Free

Perversely, even the government agrees that smaller teams produce bigger effects. Chances are the government will not take its own advice but you can.

If you are looking to partner with a cracking software development team, or simply look for the best IT talent, contactThe Intellection Group. Unfettered by the burdens of waste economics, fat-cat bureaucracy, and overstaffed sub-committees, the Intellection Group can help. Or give a call at 678-283-4283 for assistance with all your software development needs.