Domain-Driven Design: Tackling Complexity in the Heart of Software

1.
Some stability in database schema (or at least reliable notification of change) or an export
utility
2.
Fortunately, the project manager of the Booking application development team is motivated to
help the yield analysis team. This could have been a problem, because the operations department
that actually does day-to-day booking reports to a different vice president than the people who
actually do yield analysis. But the upper management cares deeply about yield management and,
having seen past cooperation problems between the two departments, structured the software
development project so that the project managers of both teams report to the same person.
Therefore, all the requirements are in place to apply 
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS.
I've seen this scenario evolve in multiple places, where analysis software developers and
operations software developers had a customer/supplier relationship. When the upstream team
members thought of their role as serving a customer, things worked out pretty well. It was almost
always organized informally, and in each case it worked out about as well as the personal
relationship of the two project managers.
On one XP project, I saw this relationship formalized in the sense that, for each iteration,
representatives of the downstream team played the "planning game" in the role of customers,
huddling with the more conventional customer representatives (of application functionality) to
negotiate which tasks made it into the iteration plan. This project was at a small company, and so
the nearest shared boss was not far up the chain. It worked very well.

---

C
USTOMER/SUPPLIER TEAMS
are more likely to succeed if the two teams work under the same
management, so that ultimately they do share goals, or where they are in different companies
that actually have those roles. When there is nothing to motivate the upstream team, the situation
is very different. . . .
[ Team LiB ]

---

[ Team LiB ]
Conformist
When two teams with an upstream/downstream relationship are not effectively being directed
from the same source, a cooperative pattern such as 
CUSTOMER/SUPPLIER TEAMS
is not going to
work. Naively trying to apply it will get the downstream team into trouble. This can be the case in
a large company in which the two teams are far apart in the management hierarchy or where the
shared supervisor is indifferent to the relationship of the two teams. It also arises between teams
in different companies when the customer's business is not individually important to the supplier.
Perhaps the supplier has many small customers, or perhaps the supplier is changing market
direction and no longer values the old customers. The supplier may just be poorly run. It may
have gone out of business. Whatever the reason, the reality is that the downstream is on its own.