My project consists of 5 sub-teams and I think that what most people under-appreciate is subsystem communication.

Do you think that teams using (or even being forced to) contracts between them to specify input data, output data and possibly communication protocols/calls would be a good idea?

  • I think your question may need a little work. The question is a little incomplete and possibly too technical for this forum. Dec 19, 2012 at 14:59
  • I assume this question is a subset of this one: pm.stackexchange.com/questions/8286/…
    – Tiago Cardoso
    Dec 19, 2012 at 16:25
  • Am possibly a lazy reader but so far I have not yet seen any methodology on applying agile approach to ICDs. The problem is of course who is going to mediate N(N-1) ICDs among N teams and how it's going to work... Dec 19, 2012 at 16:39
  • @allnightgrocery: (quite a bit) of details about my project are here: link
    – mrkafk
    Dec 20, 2012 at 17:56
  • @Tiago Cardoso: yes. Should have included the link..
    – mrkafk
    Dec 20, 2012 at 17:58

5 Answers 5


You don't need contracts. You need clearly defined requirements documents for each of the deliverables being produced. These should be written collaboratively by at least three teams:

  • The team that will be using the deliverable
  • The team that will be producing the deliverable
  • The team that will be providing the input going into the deliverable

The end result should be a series of overlapping documents that provide clear accountabilities for delivering necessary requirements and outputs for each deliverable.

This collaborative document should be reviewed by the PM and his team to ensure there isn't any gold-plating going on, the deliverable is within scope, the quality and acceptance criteria are clear, roles are defined, etc etc. A good example is the work package template from PRINCE2. You can get this and other templates [here].1

  • you're a goldmine! I have to say heartfelt thanks! It starts to come together I think (work package, ICD maybe + kanban + responsibility + tailoring and active oversight you mentioned in another thread).
    – mrkafk
    Dec 20, 2012 at 18:38

The answer is an unequivocal yes. If the input came from an outside vendor, you would certainly have an agreement in place in terms of quantity, quality, specs., costs, whatever. Why would it be any different if the input came from a source internally?

Now, by contract, most would assume some type of paper agreement with signatures. Some teams could require such a thing, e.g., if you were crossing organization divisions, while others would require a simple verbal agreement and handshake. Many team charters can also capture rules of engagement, as well, to a certain level.

Either way, if you don't agree to intra-team requirements, you are not managing the work.

  • 1
    A very good answer to a rough question!
    – Tiago Cardoso
    Dec 19, 2012 at 16:26
  • "Either way, if you don't agree to intra-team requirements, you are not managing the work." - you nailed it I think.
    – mrkafk
    Dec 20, 2012 at 18:14

Yes, you certainly should have a written specification of outlining the interface between the sub-systems. This will form the contract between the teams involved. Both (all) should be involved in the writing of the specification. Depending on your documentation style, this could be a wiki page or other online document.

Some of the things I would cover include:

  • Format(s) of the data.
  • Method of transmission (file, SOAP, REST, other).
  • Batch sizes if data will be transmitted in batch.
  • Expected response time (especially for interfaces accessed for OLTP).
  • Availability schedule.

I can envision the problem to which you refer, and I agree that it may be worth proactively solving. (Proactive solutions involve governance/political capital/stakeholder management. In some environments, political capital and governance are extraordinarily expensive, so it may actually be long run cheaper to plan for failure and solve the problem retroactively).

On the face of it, this is either a quality problem or a risk problem. Team A feeds Team B; Team B needs to express the desired quality standards, and team B needs to plan to mitigate the risks if the quality standards are not met. As @David Espina says, if you're not managing (intra team) requirements, you're not managing the work. If we're talking protocols, inputs and outputs, then the common desire for an excellent result compells us to share very detailed information about expectations.

Does that involve a formal SLA for the teams? That depends on the relationships involved. If the teams are close and cooperative, then a formal SLA may actually inhibit innovation and improved quality. I get nervous when you introduce the term "forced to", because I think the cooperation is probably more important than the actual quality of any part. If you don't have the intent to cooperate and to make each other look excellent, then you may have an XY problem, but perhaps I'm reading too deeply there.

  • The reason I'm thinking about forcing the teams to do it is that when I floated my idea calling it "contract" (completely spontaneously without reading any background info), the idea was sent such a barrage of flak I can't even find the pieces.
    – mrkafk
    Dec 20, 2012 at 18:17
  • Flak in the air strongly suggests an XY problem. I suspect that the problem isn't quality, it is leadership. The teams seem to perceive that their interests are in tension. Which suggests to me that "force" will exacerbate the problem, rather than solve it. Best of luck!
    – MCW
    Dec 20, 2012 at 18:38

Jumping off the Agilish tenant of focusing less on the documentation and more on the people, rather looking to a contract to specify what is needed, focus on setting up an environment that encourages open, consistent and accurate communication.

  • There's a problem of "internal perspective" here: even with lots of good will, people tend to take that their [data format|API|problem definition|whatever] is correct and it's the other team or person that should change theirs. Also when teams A and B change their method of communication it has impact on teams C and D and possibly E. Nasty problem we have (lots of cross-cutting concerns among subsystems and problem domains).
    – mrkafk
    Dec 20, 2012 at 18:11
  • Your comment reinforces my answer on your other question. Sounds like you need a cultural change agent. [Here's the question I'm referring to pm.stackexchange.com/questions/8286/… Dec 20, 2012 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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