I wrote a thread a while back about UI vs Front End code and how we'd tried to separate into separate teams. Some of the advice you guys gave was not to be separated into teams. Unfortunately, to me this seems to be a difficult problem- it gets really, really hard to coordinate agile development across a large team. In fact, it's painful. We kept the separate teams, but not really. That is, we had separate stand ups, but since we were sharing a backlog, buglist, QA, and ended up working in the same areas of code, what it really became was a big mess of having to add a LOT of process in order to control things.

Now, I realize Agile does not mean "no process"- however, it seems we are going unnecessarily slow right now, and it all has to due with making sure such a large number of people is coordinated. I'm comparing our current team (2 Technical Architects, 6 programmers, 5 QA, 1 BA, 1 Project Manager) to the team I worked on at my previous company (3 programmers, 2 QA, 1 Project Manager), and the difference in efficiency is staggering.

At my previous company (working on the same product- but back end only), we didn't even have a bug list, believe it or not. All bug reporting was done verbally because QA and devs sat in the same area, and our level of defects was low enough that that was good enough to get it done. Now I realize that is not necessarily a good way to do things or that it should be my expectation in general, but I bring it up to illustrated just how informal things were (and the quality was VERY high- we released a lot of code very fast and never once had to release a hot fix to production outside of our normal release period, which was once every couple of sprints depending on functionality). We had very little in terms of documentation- most requirements gathering was done on the fly as we progressed through stories. Our users sat with us in planning meetings before the sprint, and whatever we didn't glean from that we found out with direct access during the sprint. Coordination between developers was simple- we always talked with one another, used similar techniques, and asked a lot of questions of each other any time we were trying something new. Our only design documentation was very high level- one or two pages describing the overall structure of the application and what its purpose was.

I contrast that with the current process- we have a massive bug list that does not get cleared each sprint (in the previous situation, we never carried bugs between sprints). Even though we are split into "teams", at the end of a sprint everyone is responsible for working all of the bugs in the bug list (so your big reward for getting done faster is to fix the other teams mistakes). We spend a lot more time coordinating all of the moving parts: a lot more documentation is created so that everyone understands what they are supposed to do- Additional meetings are had before and during the sprint to ensure everyone is on the same page for a story, and the TAs are responsible for creating design documentation that each team will follow for the sprint- they are kept so busy they don't get to write code (one of them actually does now- he splits his time 50/50 between writing code and his TA duties). The code itself is quite a mess, with different programmers using different approaches to solve the same problems and different values being pushed (for instance- I value small, simple methods that contain only a few logical statements, where another programmer values having all the logic easily accessible to his eye in big 200 line methods).

It's really frustrating, because at the end of a year we are much, MUCH less productive than I feel we should have been. In fact, I believe given our old team with half the developers, we could have accomplished about the same amount of functionality with a cleaner code base. Our product owner had only budgeted one year for the augmented team (the original team from the first company along with one of the TAs are the only permanent fixtures- the rest are contractors we only had for one year), so we have been counting the days until we get to the end of the road and can strip back to the smaller team. The current process is just so painful- so much time spend coordinating and having to wade through code written by people with different ideas about what good code looks like. It is SO frustrating to go into an area of code with no unit tests and have to fix bugs, which fixing bugs in the areas where there are unit tests is a cinch- of course, we spend more time fixing bugs in the areas without unit tests . . . go figure.

But I'm finding out now that the PO is looking to rehire the contractors for another year, and I'm about ready to scream. I am tired of working overtime on this project, investing blood sweat and tears while other people cannot be bothered to write unit tests and have coding practices I don't agree with. But it's not just that- even if we all were in agreement on how to write good code, coordinating this number of people is painful, without a large gain to show for it.

My manager (one of the TAs, and a good friend) is trying to figure out how to fix things for the next year. He wants to do it by getting stricter on standards- enforcing unit testing and function length, and anything else we can measure. I suppose we may have to do this, but I'm not convinced it's going to be that effective. It seems when you have to start taking draconian measures on people's code, its going to be hard to really motivate people to do better. Ultimately, you'd like for people to adopt common coding practices of their own volition through a good team spirit and a desire to work together, but when that doesn't happen I suppose you have to do what you have to do.

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.

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? 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? Will draconian measures for enforcing code quality work, or will the just lead to bitterness and frustration?

I know I had it good before, and maybe trying to get back to that is a mistake or just unrealistic. I'm just embarrassed by how little we've produced in the time-frame we've had, especially given the number of hours I've put in on this project. I'm not going to keep putting in overtime, and I'm certainly not inspired to to it in an environment that feels like I'm swimming in molasses. I took this job because I was excited to keep working with a great team on a great product using Agile methodologies. But I feel like my team has been swallowed up in this monster of a team, every day we are throwing out more Agile and adding more process to make sure everything is coordinated. I don't think I'm ready to quit or anything, but it's painful enough that it's hard to get excited about the work. No way am I personally going to work as well when I feel that way.

Anyway, sorry for the long-winded post (typical for me, I know). I guess it really just boils down to what can we do to mitigate the pain of a bigger team? Any thoughts would be very appreciated.