“Traditional” project management had a lot of focus on managing dependencies. The better approach is to eliminate or at least minimize them.
Jonathan Smart referenced this and also mentions “high cohesion” and “low coupling.” Those are software engineering terms that became mainstream in the 1970s. Coupling and cohesion are also reflected in “object oriented” design.
“Cohesion” is how well elements in a single component or module work together and to what degree there is a common goal or purpose. Low cohesion means there are multiple purposes/directions being served and looser relationships. You can see how cohesion has parallels with teams and workgroups in organizations.
“Coupling” is the degree of interdependence between modules or components. Low coupling means there is less chance that changes in one component will affect other components. Low coupling is also related to the “black box” concept where one doesn’t need to know the internal workings of a component to use it effectively as part of a larger design. Here, too, you can see parallels to organizational interactions.
The aim is for high cohesion and low coupling.
This discussion is a parallel I have talked about before. There is a link between software engineering and organizational engineering. We are even rediscovering some good organizational principles through good software engineering and agility principles.
In one sense, we are reversing Conway’s Law that an organization will recreate its structure/communication patterns in the systems it designs. We are now applying better technical systems designs the other way, in a sense, into better organizational designs/communications 😉
While we’re at it, there’s another software concept that correlates to organizational design and coupling. APIs – application programming interfaces – govern how a software unit interacts with other units. The principle behind APIs is that one should only need to know how a unit’s API functions to interact effectively with that unit. One need not know how the other unit functions internally. An API can help lower coupling and increase independence. This also means less need to change one unit’s internal workings when another unit changes *if* the API remains the same.
The same concept can apply organizationally. One organizational unit can run experiments (e.g., improving workflow) without causing problems in other units if there is low coupling and how interactions occur stay the same. The other units can choose to change via leveraging the learning from the experiment. However, they are not required to do so for the overall project or organizational “system” to keep functioning.
The same goes with a unit’s backlog of work. Lower coupling/higher independence means a unit can change the backlog sequence without outside coordination. A change in one unit backlog doesn’t automatically require change in other unit backlogs.
Note that this doesn’t mean contractual relationships between units. It just means that there are understood and followed protocols and ceremonies for interacting. And as lightweight as practical.
The above is another reason why software folks and non-software folks should talk 🙂