Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.
In the event, coupling the culprit
Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.
- Loose coupling: there is some effect transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
- Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.
In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.
The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's Critical Chain method for more about decoupling with buffers
But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).
With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stovepiping.
Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.
There are two approaches:
- Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
- Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.
With all this, you might see the advantages of an architect on the agile team!
