Clearing the backlog

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

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 is 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 transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy 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.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating 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". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

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.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!