There are already few questions here on Programmers about organizing small teams, but we have a bigger (medium-sized?) team, and that's a bit of a different animal.
So, my question is this: How do you organize a medium-sized team with a very large, older codebase?
Or better, let's quantify it a little more clearly:
The team has:
- 20 Developers (good mix of senior and junior)
- 7 QA Folks
The product is large (2 million lines of code) with 10-12 major modules divided over three major areas (Desktop client, backend server, web).
The team needs to do:
- support/maintenance for the existing customer base
- Customize the product to support new sales and existing customers
- Build new features to keep the product moving forward
- provide regression testing for all new features as well as fleshing out regression for technical debt
Specific sub-questions:
- What are the thoughts on "Specific support team" vs. "Module teams fix all their bugs"
- How do you maximize development time and minimize admin time (code reviews, other "lead developer stuff")
- How do you integrate/organize the QA people to ensure proper testing and regression suites?
- What non-technical positions (QA Manager, Dev Manager, etc.) might be good for maximizing developer productivity?
Your thoughts on the matter are greatly appreciated.
EDIT: I should add that I'm not clueless here, I'm just trying to stimulate some ideas. This isn't an easy problem, and so I'm open to the wisdom of you fine people here.
Best Answer
I hate having support teams and development teams.
When this happens the developers start to look down on the support people (it is a less glamorous role). People get tagged as suppport and then can't get back to doing development where the better pay and promotions tend to be.
Additionally the development team doesn't feel the pain of their mistakes (which is critical to getting better!) and tends to do the same things repeatedly that the support team ends up fixing. This ends up with them thinking they are great developers (they never hear otherwise) and the support team thinking they are idiots.
The other disadvantage is that the orginal developer can often find and fix a bug in a complex system faster than a support person who has to get up-to-speed on what was done and why before fixing. Further, I have often seen support people break things more because they didn't understand the why of something in the first place. This is especially true when you have developers who just do what they are asked to do without questioning it or pushing back on a bad requirement. So when the customer asks for something that conflicts with another requirement they don't know about because they didn't work in that part of the system, the change is made and something that used to work doesn't any more. It's true this can happen when the original development staff does support as well but is less likely to becasue they have more of the backgroupnd information internalized.
I don't see the problem as being how to minimize admin time for developers but more how to get them to do the needed admin work at all! I do think that in planning work, you should only plan for 6 hours a day of productive time. You need to account for leave, jury duty, admin work, meetings, etc., and if you think you will get 8 hours a day in determining your deadline, you already have either a deadline that will not be met or will be asking your people to work continous overtime or not allowing them the time off they need to have to recharge. A tired developer is an inefficient developer. Don't plan to force people to work exhausted.
I do suggest that if your application is database centric, you should have several database developers (not DBAs but people who write database centered code and design databases, especially people with performance tuning knowledge). Your application will work better if you have these people from the start in the design phase. You will also want to read about database refactoring and set up a process where database changes can properly be made as needed.
A contract GUI designer is nice to have around as well. This kind of designer is often not needed full-time, but it's handy to have someone you know you can hire when a major redesign of the user interface is being done.
A good business analyst is a must. A bad one can destroy a project and the team. Do not keep a bad analyst for longer than you need to process the paperwork to fire him. This person can do more harm to a project than virtually anyone else. He will add months and years to projects trying to work around the garbage the devs are given to work from and you will find yourself pushing releases that work but don't do what is needed ruining your credibility.