Let me get this straight... you have an Agile team of 15 people? That seems about twice the size it ought to be, in my experience.

Originally Posted By: JeffS
My suggestion was to split the teams more distinctly- put my original team from before back together and let us work on one of the remaining functional areas. The contractors can go work on a completely different functional area and we can deal with the consequences of the code looking different for different areas. At least we will spend a lot less time in coordination and my team can get back to doing what it does really well. Unfortunately, this suggestion has shot down because the PO really wants the next functional area out the door as quickly as possible, and that means putting every able body on it.

I would agree with your suggestion. Has the PO never heard the phrase "too many cooks in the kitchen"? They doesn't seem to understand that "putting every able body on it" doesn't necessarily mean "getting it out the door as quickly as possible." Indeed, it can even be counter-productive, and there's been plenty of research demonstrating this.

Can you show him your pre-merger team velocity, compared to the post-merger team velocity as a way to bolster your argument? What about other metrics? Bug counts? Or, can you demonstrate that smaller teams would have more capacity? That is, in a large team, everyone has roughly 4 hours of "useful work" per day, with the rest going to meetings, and dealing with large-team communication issues. In two small teams, where the effort directed towards the large-team communication issues goes away, everyone has a 5 hour capacity for "useful work". (These are the sort of questions that your sprint retrospective is supposed to look at.)

Quote:
So all that to say- am I wrong about team size? Are there ways we can coordinate this number of people more effectively than we are?

I don't think you're wrong, at all -- I'm willing to bet that big team you're currently on has already fractured into unspoken sub-teams. You might as well recognize it, and just split into smaller teams, and have a scrum of scrums to facilitate the inter-team communication. If, for example, you have 1 TA on each team, they'll talk to each other naturally. Ditto if you split those 5 QA across the two teams.

Quote:
Should we be looking to replace the team members who are not functioning the way we want, or should we be putting more effort into getting everyone on the same page?

Heh. I'd say yes, and yes. If everyone isn't on the same page, how can they know what the expectations are? And if no-one knows what the expectations are, how can they know if they're meeting them? And how can you know if someone (consistently) isn't meeting them, and needs to be replaced?

Quote:
Will draconian measures for enforcing code quality work, or will the just lead to bitterness and frustration?

Yes, and yes. I've been the draconion enforcer, before. It can lead to bitterness and frustration. It also means everyone knows what the standards and expectations are. I found that the people who got bitter and frustrated fell into two camps -- the people who sucked it up, and did it, and the people who left. The people who sucked it up eventually quit complaining, and agreed that the end result was better. The people who left? Good riddance.