How to convince management on the importance of teamwork?

Question

I've worked for a state agency for over 1.5 years (arguably far longer than I should have, but that's another matter). Most of what we do is create & maintain ASP.NET web applications for other agencies. In the time that I've been here, I haven't seen any team projects. It's always 1 project per developer (although projects do tend to migrate from developer to developer). If the developers were highly skilled, maybe this wouldn't be a problem, but it seems we still have a lot to learn (myself included - I'm no expert and have done my fair share of wtf's). I've seen databases that were badly normalized (all columns nullable, even those that seemed to be used as primary keys), cascading style sheet-based security (making certain controls invisible until people login), and lots of code duplication.

Furthermore, we're usually expected to start coding even while major requirements issues are still being decided upon, and only the developer, the client, and sometimes a non-technical business analyst is responsible for testing. It's easy for buggy code to go into production.

Rather than give up/quit, I want to see if I can improve working conditions. At the next "team" meeting, I want to suggest that they assign 2-3 developers per project rather than one, so that we can finally learn from each other. I want to be able to discuss architectural decisions and best practices with someone who is as responsible for the project as I.

My question is: can our department be more productive with multiple developers per project (realize, this would mean we'd work on fewer projects concurrently), or should I be arguing for something else instead (e.g., code reviews or agile practices - although none of us know how to do agile)? What resources could I provide to convince management?

EDIT:

Some responses thus far ignore an important matter: many of the developers I've worked with have been laid off recently due to a budget crunch. There are only two developers left that I've worked with before (and one only telecommutes now). There are other developers in the department though, but I've never met them before (yes, after 1.5 years, most of the people there are still strangers to me. There really isn't much opportunity to socialize). I honestly have no idea whether other devs would support my idea, and I don't know how to introduce it to them.

Answer 1

Do you have a colleague who feels the same way? You could spend half your day at their desk, "helping" with their project, and then they could reciprocate. If (both) your productivity improves, then you'll have a convincing argument to present to your management.

Answer 2

Cybis - I would definitely not recommend the giving up or quitting. I'm not so sure that the private vs. public sector are all that different at times when it comes to this. I know exactly what you are talking about, in fact my team is going through this right now.

First, if management does not see a value in this, it will never be an accepted practice. It may not be your direct management, and it could be 2 or 3 levels up the chain that actually have to buy off on it. But rather than start with your management, I would reccomend drumming up support from the other developers.

Second, sometimes it is easier to ask for forgiveness than permission. If the changes are being rejected and the team really wants them. Maybe the team can work together, taking the initiative on their own to begin demonstrating the value of multiple developers per project.

This is what I feel about it right now... Spreading the developers out to one developer per project makes it look like you are working on more. If that is the goal, then goal accomplished. If you can combine two or even three developers on a project and shorten the release cycle, chances are that all subsequent releases of all systems will be benefited if you've learned from eachother. I've recently been paired with another developer, about 20% of the time, and at first it felt slower. But today we are flat out flying. Projects started in January and due by the end of March are nearly complete...

If all else fails, make your own company ;)

Answer 3

can our department be more productive with multiple developers per project

I think you might have to argue on the basis of improved quality, not improved "productivity".

The fastest (most 'productive') method is probably to have 1 developer per project, and to finish each project in 10 minutes maximum; and you can do this, if you don't care about quality at all: http://www.cs.cmu.edu/~jasonh/personal/humor/efficiency.html

There's some (perhaps undefined) level of correctness, which your programs are or are not meeting. The top of your question, describing the problem, was all about correctness. If you want to talk about productivity, you need to talk about improving the rate at which you produce, not just software, but "sufficiently correct" software, i.e. about improving your defect avoidance and defect removal efficiencies ... and not, I think, talk about improving your raw (ignoring quality) "productivity".

If your managers don't see poor quality as a problem, and don't see long defect-removal-times as a problem, then I don't know what you can do to convince them.

or should I be arguing for something else instead, e.g. code reviews

I like code reviews; but many people don't.

This line sounded dangerous to me: "I want to be able to discuss architectural decisions and best practices with someone who is as responsible for the project as I." It makes me wonder why you're unable to discuss decisions, and whether it really is important to discuss them with someone who's as responsible for the project as you. Instead of having several co-equals on each project, might it be enough for each project to have one full-time Chief but give each Chief access to part-time Advisors?

Answer 4

I'm not sure bringing this up for the first time at a team meeting is the right approach. It's too scary/unknown which means people may reject it without thinking. It's better to socialize this quietly until there is support among several people. Toward that end, I would:

• Talk to my boss about the idea. See what he thinks about it. Do so in private though.
• Try to get my teammates to do this. Ask around. Maybe some of them feel the same way. Even if not, try doing joint code and design reviews. Start going to them with questions and expect the same in return.

Working as a team definitely brings benefits. I would suggest checking out the book Tribal Leadership for justification why this is true and for steps to work toward achieving it. I've been on teams that acted in silos and teams that worked as a team and the latter are definitely more productive.

Answer 5

It sounds like your biggest reason for wanting multiple developers per project is to try to improve the quality of the code produced, and secondly to increase productivity.

If that is the case I think you would get much more benefit from trying pair programming. This way instead of 2 programmers working on the same project, on different tasks, you get the benefit of 2 brains working on the same task, with all the associated knowledge sharing and positive peer pressure.

However it does sound as if this company have been rolling along like this for years and is just happy that projects "get done", regardless of the process.

So perhaps pair programming would be too much of an initial change, ie in appearance you have 2 people semmingly doing the job of the one before. Therefore your suggestion of at least having more than 1 developer on a project might be a first step on the way to pair programming.

Unfortunately in the eyes of some managers, code quality and productivity are mutually exclusive, you can't be great at both. I think helping managers to get over this view is going to be your major battle.

Probably the best way to do this is to convince them to at least let you try it out on a few real projects (with safeguards to fall back on). Then if successful, you can present actual evidence that it works to management, in the interest of making changes company wide.

Of course as ususal this (too clever) statement applies "You can either change your company, or you change your company."