Is the implication that bad fences make for bad neighbors? Not any more than good fences making good neighbors. As a rule, constraints by way of clear boundaries are valuable guidance because they remove variables from consideration. The fewer variables you need to consider, the simpler the problem domain. Where should those fence posts be set? How should they be set? For such guidance, I'll turn away from the usual technical context toward some other, broader alternative context: the law. There's no aspect of your personal and professional life that isn't subject to the law. The law, like other rules you're subject to, self-imposed or not, are constraints.

Perhaps if we understand how those broader constraints are considered, defined, and imposed, we can gain a better understanding of how constraints can be best applied in our shared business and technical context. How can “good fences” make for “good neighbors” and how does that analogy broadly and specifically apply? I'll ponder that and a few other, deeper questions here.

There are many kinds of fences, all serving different purposes based on their physical characteristics. Some are purely decorative. Some are electrified and deadly. Most others fall somewhere in between. But what does it mean to fence-out versus fence-in? Why one or the other? As the names imply, when it comes to fencing, the context may be to keep nuisances out to prevent damage to my property. Or keep nuisances in to prevent damage to others' property. Almost all municipalities have rules and regulations concerning fencing. As an example of how extensive and non-trivial these rules and regulations may be, consider the state of Oregon: Those 16 pages of referenced statutory provisions also contain other referenced statutory provisions! A “fence” may indeed be more complicated than first thought because much of what a fence is and represents is intangible. Therefore, I should rephrase an earlier statement: fences may be physical in this context.

It turns out that what fences physically are versus what they represent in a legal sense are very different things. In other words, what things are as implemented is distinct from what things are as defined. It's no different with Agile. There's how it's defined and then there's how it's implemented. You have to consider both because the latter is the fusion of the former, plus people and process. The question is whether something implemented is compatible with what it's supposed to be, which entails what it means and how it's designed. A practical example is implementing Agile as Waterfall. These are not compatible things. Like diesel fuel in a gas engine, it's not a combination conducive to success. Therefore, understanding what things are, in relation to their intended context, is an immutable success factor. In this case, to have some understanding of what a fence is, you need to have some understanding of the rules that define what the default rule is, whether you're fencing in or fencing out, and, more importantly, why the default rule may be constructed as it is. Often, the rationale for a rule may be quite simple and pragmatic.

A good rule is one that considers fairness “equity,” meaning that obligations are assigned on who or what can best bear the burden. In the United States, as we travel from east to west, the land is more open. Consider Montana and cattle ranching. Perhaps you've watched the popular Kevin Kostner series Yellowstone. Montana, like many western states, is considered “open range,” meaning that adjacent property owners must “fence out.” Imagine if all cattle ranchers had to physically “fence-in” their cattle. Such fencing would need to be robust and very expansive to the point that it would be impracticable to keep cattle fenced-in. Therefore, the burden of fencing is placed on those that would need to keep cattle “out” of their property. Therefore, such property owners must “fence-out.” There are other governing constitutional rules that require uniform application.

Another important context is that these rules were enacted in one form or another well over 150 years ago. Sometimes these rules were more formal early on. In many cases, rules begin as and evolve from customs and norms. It can be a very difficult thing indeed to distill customs to a generic set of adopted rules to be applied uniformly. I emphasize uniformity sarcastically because there is nothing that prevents rule application being “uniformly” arbitrary and discriminatory! In our shared technology context, consider the never-ending posts on LinkedIn concerning another failed Agile/Scrum/DevOps. Those are all cases where something new came to a pre-existing environment, implying that a new neighbor is moving in across the street!

The other implication is that equitable and fairness principles may not result in an outcome to your liking. One simple reason is that in any project involving multiple teams, each team distinct in terms of its lifecycle and personnel, and each must cede something for the good of the order. There must be a cooperative effort toward a common objective. In the case of fencing duties in the open range, one objective is to set proper expectations among prospective members of a community.

Imagine that you live in the eastern U.S and that you decide that it's time to leave the city, get back to nature, and live a simple life. You end up moving west and building your homestead on a small 20-acre semi-wooded parcel in the middle of what appears to be something characterized to you as the open range. As it turns out, you were in too a big hurry to move! That's why you didn't know that the “open range,” for purposes of your new locale, is a noun not an adjective. It also turns out that it isn't just a noun, it's a proper noun, meaning that it's a thing, with a legal definition that has bearing on the citizenry, even the new ones! Your neighbor, as it turns out, is a cattle rancher. If peace and quiet is the objective, your new locale and neighbor situation sounds like just what the doctor ordered! It's a shame when that peace and quiet was disturbed due to some errant cattle causing significant damage to your property. Suddenly, living on the open range becomes living on the “Open Range,” with the fencing-out duties in tow. When we come to the party, as far as property law is concerned, we're on notice. Nobody forced you to move to the country. In a more populated, less agricultural sphere, you would represent the norm, perhaps with an opposite fencing rule. But in your new context, you're the outlier. That may not be a problem. It all depends on understanding what being the outlier really means. Not being a cattle rancher may be fine, so long as your objectives are compatible with your cattle rancher neighbor in the context of the rules you both are subject to. You can be annoyed at your neighbor all you want. But under the circumstances, absent fraud or some other actionable untoward conduct, what did your neighbor do to you that you didn't do to yourself?

Multi-team projects share some of the same issues. For example, there may be new integrations to implement. Some might have third-party services and some might have internal legacy applications that must integrated in ways not foreseen in its design. How this legacy application comes to the party is an important consideration. The app's arrival also means the arrival of a new team. Fences between teams are about clearly defined responsibilities, some shared and some individual. Fences are not about siloed activity. There still needs to be cooperative behavior. No team on a common project can or should work in a vacuum.

This is why the Swimlane Diagram is useful for matching process to the software and processes (with clear boundaries between) tasked with the work. With clear boundaries, we know where they are and when they are encountered. That's a moment for inspection and adaption because an artifact is passed between boundaries that reference entities that are accountable to one another for collective success. So long as there are clear, reasonable, and compatible expectations, necessary accountability doesn't devolve into unproductive, destructive, and avoidable conflict. The less conflict, the more neighborly and enjoyable and successful your project is likely to be.