How do I close the gap between developers and production support teams?

Question

To make my question clear, allow me to define the terms of the title--

Production support teams are the resources who maintain software applications which are currently in use. The developers are the coders who write the software apps from requirements.

Often times atleast in my work experience these two teams meet only once or twice at best, to discuss about the next production release. It is assumed that the production support teams are going to understand potential risks without ever looking at requirements or design documents or ever meeting the clients, or stake holder. It is expected that out of just out of one/two meeting with the Dev teams, the Prod support teams are to understand and mitigate and resolve potential risks out of this release.

This being the problem, I am tasked with coming up with guideline to close the gap between the Production Support Teams and the Developers. What are your ideas? What questions need to be asked when the two teams come together?

Answer 1

Have people rotate between the two teams for a short while. That way when they go back to their original team, they have a better understanding of the issues the other team faces.

Answer 2

I've had great success having the developers and support teams sitting together, or at least spending some time together. That way ideas and assumptions are aired early and some issues can get resolved much sooner.

Answer 3

I would take Elie's suggestion a step further and say always rotate people around. I don't know of any developers who are happy solely doing maintenance work on code that other people have written.

On the flip side, developers who only write new code won't ever feel the pain of maintenance and thus won't learn how to write maintainable code.

Edit:
Ideally, I agree with Tim - there really shouldn't be separate teams and it's a terrible practice. I was assuming that you wouldn't have the power to make that radical of a change, but maybe you do :).

Answer 4

Having two teams is a mistake right from the start.

I have seen this (two distinct teams) at other companies and it always amazed me that this was actually done in the real world.

I suggest only one team of developers - and some are tasked with support, and some are doing new development - but there is no clear delineation.

For one, there is no natural feedback loop (positive or negative) for the developers of new code to actually make it maintainable. They just toss it over the wall for the maintainers to deal with.

I have also seen it create division, rather than cohesiveness. I don't see anything positive/good about the scenario, whereas I see a single product team having many benefits.

I can't understand it.

I agree with others - either rotate through, or make ONE team.

EDIT:

So, for those without the ability to rotate through teams, or make one team:

• There must be visibility on both sides into the issues that arise. That is, the feedback from production must get to the development teams.
• As you suggest, involve production team in the initial design and planning and requirements gathering phases.
• Teams must be able to have easy access to each other

EDIT:

I did work at one company that had a small team that was on loan from the rest of the dev team - they called it the "swat" team. They would build specific functionality for some large clients or for a fee and the code would be put on a specific branch. While similar, they really still came out of the pool of all developers.

Answer 5

Some initial ideas:

1. The production team are stakeholders so they should be involved from day 1. Is your system supportable? Does it publish alert events to the support system/dashboard? Are any manual processes (e.g. weekend bounce) required? By talking to support at project start you will have created the beginnings of a working relationship.
2. As far as is possible involve production support as soon as possible by 'productionising' your system. I.e. try to have your Smoke, QA and UAT builds managed as if they were production systems. Not always possible for smoke builds, but should be possible (even required) for QA/UAT.
3. Training and documentation. Educate the production support team and supply them with good documentation.
4. Ensure that you have a 2nd or 3rd line support process in place - i.e. that the production support team can get in touch with a developer when they need to.

Answer 6

Real integration can only come from working together in the same project.

Best thing is the support team to participate in the development, e.g. team of 4 elements, each week one person is doing mostly support while the others do development. That means the support guy can rest 3 weeks before doing support again.

This makes people fell the project as their "own" and avoid going crazy with the silly questions and brainless tasks that sometimes support can consist of.

Remember also that the support team normally knows much better the users and the way in which they use the system. For that reason they are in the best position to improve it.

The production support team should have access to the requirements or design documents and participate in keeping them up to date.

Answer 7

For myself, I try to hang out with the PSG folks as much as possible, both in work and out. Also, if they have a problem, I get up and go help them immediately if I can. The more you get to know them, what their issues and hassles are in life, etc., the better you can set things up for them.

Answer 8

Building on Elie, Tim and 17 of 26:
Cycle 25%-33% of each team in and out on each release. Whomever have been there the longest; and I don't care what your job title is (senior architect northern hemisphere or peon). Support is effectively dogfooding the application, they know all the gotcha's (and will make sure they are fixed - this has been bugging me for 3 cycles #$%#$%#$%), development knows the latest release the best, so they are best for trouble shooting (oh, of course, that problem will be in function XYZ).