Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
alphabetically, or by height –  Steven A. Lowe May 25 '11 at 14:16
1  
You'd likely get better answers on pm.stackexchange.com. –  Macke May 25 '11 at 14:27
    
I'd be happy to have this question migrated to pm.stackexchange.com. How does that happen? –  Nick Hodges May 25 '11 at 14:54
    
Why should you 'maximize development time and minimize admin time' while you should optimize for progression and speedy development? –  Barfieldmv Jan 10 '12 at 12:34

3 Answers 3

up vote 4 down vote accepted

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.

share|improve this answer
1  
"Additionally the development team doesn't feel the pain of their mistakes (which is critical to getting better!) " -- great point. –  Nick Hodges May 25 '11 at 15:44

Almost impossible to answer this without being the project manager.

Self-organizing teams could work, with proper communication.

Or you could group 3 developers and 1 QA person together to make 7 "commando" teams.

If you don't have enough senior devs to lead 7 teams, organize teams around the senior devs.

Unless the senior devs don't want to lead teams.

Etc.

Almost any organization of the teams could work, depending on the size and scope of the projects that occur.

My advice: talk to your people instead of us. We don't know jack about your project, they do.

share|improve this answer
7  
Last line is the best part of this answer. –  jzd May 25 '11 at 14:22

•What are the thoughts on "Specific support team" vs. "Module teams fix all their bugs"

I am a big proponent of Support Team for a number of reasons. You will find going forward that customer emergencies, patch releases, urgent bugs, and other production issues can take up a large chunk of time on the modular teams and make estimation of project work much harder for them. Having the support team made up of highly experienced and very well paid developers with that being their prime focus will increase productivity across the board for all module teams.

•How do you maximize development time and minimize admin time (code reviews, other "lead developer stuff")

I am not so sure that code reviews should be considered "administrative". I consider them intrinsic to the development process and should be accounted for when estimating user stories. Meetings, dealing with project managers and the like should be handled by the lead on a team and the lead should shelter his team from that garbage.

•How do you integrate/organize the QA people to ensure proper testing and regression suites?

Give them a manager with experience in QA, and make sure that they have detailed business requirements or user stories so that they can write complete and comprehensive test cases and automated tests. Keep QA involved in status meetings that involve discussion of features and also make sure that they have a chance to review the features before the sprint is complete.

•What non-technical positions (QA Manager, Dev Manager, etc.) might be good for maximizing developer productivity?

Project managers are important and business analysts that deal directly with customers can be a valuable asset to a team.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.