A well managed team with solid development practices can get a lot of quality work done in a short period of time. What does a team like this look like? Small, at least that’s what the 2012 TSS Java Trends survey indicates. When asked the question “What is the size of the typical development team you work with?” fully 40% of respondents said their team size was 4-9 with 24% saying 10-20. 

With Agile development practices being all the rage these days, the survey results seem to fit well with this practice. Agile philosophers evangelize a team of 4-9 as being the optimal size and balance of getting things done quickly and too much overhead. This doesn’t mean you can’t have a bigger team. 24% said their team sizes range from 10-20 members, which may have included non-developer positions such as project managers, business analysts and management.

So what does the optimal Agile development team look like? In a nine person team, the individual skillsets might break down like this:

1 skilled in Architecture

1 skilled as a Systems Analyst

1 or 2 skilled Senior Developers

2 or 3 skilled Junior Developers

1 skilled Build Person

1 skilled in QA/Testing

Of course, the team size is highly dependent on several other factors such as project size, project complexity, timeline, available skill sets and budget. But any size project can benefit from an agile approach. In fact, 11% of respondents represented teams of more than 50. That is a big team, probably representing multiple technology layers and a mix of distributed and dedicated onsite developers all working on a multi-year project.

But let’s not forget the really small teams. 16% of respondents said they worked with team sizes of less than three. These are most likely developers that wear many hats or are in a break-fix mode where patches and maintenance are more the priority. 

Interestingly in contrast to the 2010 TSS Java Trends survey, 2011 saw a contraction of team sizes of 4-9, down from 57% of respondents. Growth seems to be trending upward in the 10-20 team size over last year, from 14% to 24%. That is a big jump. This could mean either there are bigger projects with more need for developers or the Agile evangelists need to get out there and well, evangelize, more. In any case, Java developers and Agile philosophies are alive and well, joined at the hip and ready to roll. 

In a nine person team, the individual titles might break down like this

You are very wrong!! i am sorry , you have a totally wrong idea about Agile and Scrum teams.

In a true SCRUM environment , there are no Architects , Senior Developers or "senior" analysts. SCRUM is very clear on Roles and Responsibilities. All members on the development team are responsible for "coding", there are no leads or architects, no one sits on a pedistle. Design is done by teh team as a group on a white board.

There is no "senior" analyst either!. There are Product Owners , who have been authorized by the Mgt to drive priorities and requirements. 

Please do your home work do not share your bookish knowledge !!

I don't see how can you build a team where you have n developers of similar skill level. You'll be very lucky , if you can do that. Yes, you do need architect or very senior developer in each team. Reality is that you'll have people in your team from skill level 3 to 9. You still need someone to guide junior people. You still need someone to review everything. System analyst...yeah I agree. All team members work with product owner and there is no specific system analyst in scrum team.

Scrum assumes many things w.r.t team composition, co-location and many other things.

I agree with your point about Agile having clear roles and I understand why it is so popular with developers and sales people but it feels like a total cop-out to me.

Developers are terrible at creating schedules so Agile tells them not to bother (any idiot an schedule a week or two at a time, that's not real scheduling). Salespeople always want inject new features in the middle of a project and Agile tells them they can do so.

So round and round we go, everyone getting their way, but in the end you end up delivering some very poorly thought-out software (design goes out the window) much later than you could have done with proper planning.

Agile is great for building small things but I fail to see how you can build anything meaningful with it. Have fun...

Some people here reads a lot and practice a little on successful agile projects.

It's true that in agile teams driven by a framework like Scrum o Kanban (but anyway the framework is not important for our subject because the framework is from an organizational perspective) everyone shall code, but that does not mean that every "developer" will have the same skills as the others: some developers will have deepr knowledge in how to architect a full system, others how to architect an application, others will be skilled in persistence, others will have soft skills and better leadership abilities.

they will all CODE, that's a must, no one will just draw diagrams or energize the team, but a successful team will always encourage a generalist that will continue to shape some particular skills: for instance do you think everyone in your team will be skilled in the same degree to provide guarantees that his code does not suffer from any web security problems or that his persistence follows all the patterns and scalability rules ? definitely not.

same for leadership skills and ability to energize the others, it's just wrong theory (but m not even theory, just misunderstanding) that in Agile we are all the same.

I would agree to the comment above. With agile focus on cross-functionality and T-people, typical team of nine would more likely be

1. Team member

2. Team member

...

9. Team member

Naturally, some have stronger expertise in one area, but they are by no means eligible for special title or seniority qualifier. 

Well, in my experience one of the biggest source of problems in large teams is the partioning/separation of knowledge, where each developer specializes in a small part of the application and doesn't know (or doesn't want to know) about the rest.

Smaller teams typically encourage and reward redunfancy of knowledge and skills within the team. This in turn reduces a lot of overhead when integrating components together, or when people leave (as happens in any project) or just go in vacation.

-Laurent

it depends..mayit be small or big as long as it is a cohesive and work well together what to buy a graphic designer

As long as the team works well size does not matter

stork club newsreel