How do you maintain technical contracts between development teams?

Question

For example team A and team B are working on different applications that need to implement a similar feature. The feature in question relies on a database and the database is under the control of team B. Even though the user interfaces of the two applications are based on different technologies, the functionality is supposed to be roughly the same. Both teams have their own requirements and design documents. The functionality can be changed based on feedback from either team but then both teams have to update their requirement and design documents.

The teams are geographically distributed and members of each team itself are also geographically distributed. Both teams work with the same client entity but different people. Each team has their own business analyst (requirements specialist). I am trying to make the technical communication between the teams more formal than email so that we can avoid misunderstandings.

How do you make sure that if team B changes the database and or the feature functionality, the other team gets properly notified about it? Do you use some formal text based documents such as interface contracts? Can you share any templates for those? Or do you use some other mechanism?

Answer 1

What about having a Team site (both as one team) or a Wiki so that both teams are aware of the change.

Answer 2

Regular stand-up meetings. Via a conference call. Stand-up == brief, highly focused, information centered. Delegate discussion to individual discussion outside meeting, reporting back at next.

There does need to be an overall authority though, to mediate where agreement cannot be reached and to ensure overall solution integrity.

I agree with Wiki or other collaborative site for publishing the current reality.

Answer 3

A couple of things from my own experience (which sounds very similar to yours)

You should try and have a single design document for the database part of the solution which as djna suggests should be posted on a wiki or similar, with a defined public contract for interaction with the data. This is a good step in the right direction, as it will give everybody a kind of 'shared vision' which helps people converge towards doing the right thing. The contracts should try to ensure that the data access is done in a standardised way.

However, from experience, the code does not always follow the spec exactly, so i would also assign a single owner from one of the teams, whose responsibility is the integration of both systems to the database.

i would then implement a continuous nightly build process with tests, and this build should include the database. This will hopefully flag any issues earlier in the process.

From the project i worked on, you may still have occasional disagreements and breakdowns, eventually we merged both teams. This was the best solution of all for us!!

Hope this helps a little