AGILE Teams

Most agile teams are less than 10 people and collocated. Although this sounds naive, Jim High smith has estimated that close to three quarters of all software development teams, be they agile or not, are less than 10 people in size. In this relatively simple situation, you can adopt a simple team organization structure, as in Figure 1. Agile team members, particularly on small teams, tend to be generalizing specialists (www.agilemodeling.com/essays/generalizingSpecialists.htm) who have one or more specialties such as Java programming or testing, at least a general knowledge of the software process and of the domain that they're working in, and the willingness to collaborate closely with and learn from others.
What you typically read about in the agile literature is how a team of developers, lead by a team coach or "Scrum Master", works closely with a product owner who represents the stakeholder community to build a high-quality working system on an incremental basis. What you don't hear about as often is what I call the "supporting cast"—the technical experts, domain experts, and optional independent tester who help the team to succeed. Sometimes the team needs the help of technical experts, such as build masters to set up their build scripts or a database expert to help tune their database. Similarly, sometimes the product owner will bring in domain experts to work with the team, perhaps a tax expert to explain the nuances of a requirement or the sponsoring executive to explain the vision for the system. Effective agile teams often have an independent test team working in parallel that validates their work throughout the lifecycle (see "Scaling Test Driven Development, www.ddj.com/architect/205207998). Domain and technical experts are typically brought into the team for a short period of time, perhaps only a few hours or days, to help with a specific task. Independent testers and agile DBAs work with the team on an ongoing basis.

Medium-Sized Agile
As the size of your team grows, starting at 15 and perhaps up to 50, you'll see a team structure similar to Figure 2. You may also start to see some of the coordination groups of Figure 3, particularly if you organize your team into a collection of subteams. As the team size grows, the independent tester(s) move from being optional to mandatory due to the complexities of the domain problem being addressed. If you're working with relational database technology, you'll want an agile database administrator (DBA) who is skilled in techniques such as database refactoring, continuous database integration, database regression testing, and agile data modeling. Small teams will generally spread this work amongst themselves, but as the team grows it makes sense to have someone in the role to focus on data issues. Agile DBAs work closely with developers, ideally pairing with them, to do database-related work.

Size Matters
If you don't see your traditional job role on the diagrams, there's a good reason—the work is likely being done, but in a different manner. For example, product owners and developers do business analysis, yet the role of business analyst doesn't appear in any of the diagrams. I often work in organizations that have traditional roles such as business analyst, quality assurance analyst, architect, designer, and so on in their organization/process charts. Invariably these organizations are still transitioning to agile and are still in the process of evolving their culture to reflect agile philosophies. It takes time, often several years, to shift to the agile paradigm.
Perhaps the spam is right after all—size does in fact matter because it is one of the determinants of your team organization. The agile community is in the process of rediscovering the divide-and-conquer techniques of yesteryear, applying them in more collaborative and lean ways, but inevitably in a manner that experienced IT professionals will quickly recognize.