Agile, DevOps, and Shipping Your Org Chart

...organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway

The words above are extracted from the first sentence of the conclusion of "How Do Committees Invent?", an article that Melvin Conway wrote for the Havard Business Review in 1967. It has become known as "Conway's Law" and frequently short-handed as "you always ship your org chart".

The basic premise is that each durable team in a software development organization and the means by which it communicates with other such teams will be reflected in how a shipped product is designed, functions, handles errors, allows itself to be observed, can be supported, is documented, etc. The assumptions and patterns of interfaces reflect the culture and philosophy of each team that had a hand in making them. Generative cultures with high levels of sharing and trust utilizing clearly articulated design patterns will produce easy-to-use software that empowers consumers accordingly. Bureaucratic or pathological cultures that are built on protected empires and information gating will produce software with many disconnected and sometimes duplicate components, no common patterns, and disparate or missing documentation.

Despite occasional efforts to use top-down governance or last-step reconciliation to correct for organization dysfunction, it is by now well known that the only sustainable and effective resolution is to embrace Conway's Law as immutable. If your enterprise culture and resulting organizational structure keeps injecting negative customer experiences into what you ship, you must change your organization for the better to fix it. Obviously enough, everyone working at an enterprise that sets itself on a mission to fix broken culture will be happier as a result, but the fact that it organically improves what gets shipped should make it all the more of a no-brainer as a strategy.

Agile and DevOps

Agile and DevOps emerged as aspects of this important observation about the relationship between organizational culture, team structure, and communications styles. Agile is most seminally about recognizing the essential nature of distributed authority, continuous communication, and rapid adaptation to feedback. DevOps is an extension into the software realm of the lessons learned from the Toyota Product System and the Lean movements that were inspired by it. I won't go any deeper into most of the many other splendors of Agile and DevOps. I want to explore a very specific intersection of these best practice movements and enterprise org charts.

Quality Assurance in Agile

The unit of accountability in Agile is the self-organizing team. The team is expected to deliver on everything that is required to deliver the most important customer value outcomes soonest. Each iterative value delivery task needs to be articulated by members of the team, solutions designed by members of the team, user experience defined by members of the team. development performed by members of the team, testing that the value has been delivered securely and without defect by members of the team, demonstrated to internal/external stakeholders by members of the team, and feedback captured by members of the team. Different Agile methodologies assign these responsibilities to different function titles, but the expectation is that the team doesn't outsource any of the tasks required to complete an iterative task.

Within Agile it is stressed that every hand-off between teams or organizational specialists introduces communication bottlenecks, delay, and opportunities for confusion and error. Even within teams, there is a profound desire for "fungibility", the ability for team members to take on as many different types of work as possible to keep handoffs down and to avoid being paralyzed when the only "specialist" (e.g., database expert, front-end developer, test automator, QA engineer) is overloaded or unavailable.

It's certainly possible to have rare or expensive resources pooled for use by multiple teams, but the idea is to maximize the use of efficient internal communications and refined patterns of collaboration within the team. Whenever it's possible to move activities required for value delivery that are currently performed by external groups into the team, it should be attempted. In an ideal end state, external coordination is only with other self-organizing teams and value stakeholders. Of course, DevOps is also required to fully realize this dream.

Expansion of Domains in DevOps

DevOps brings many more previously separate functions into the tent of the self-organizing team. Test automation is certainly encouraged within any software development practice, but with DevOps it becomes an existential requirement. Continuous Integration/Continuous Delivery/Continuous Deployment (CI/CD) and Infrastructure as Code (IaC) depend on test automation. Combined, these three essential elements of DevOps enable infrastructure management and deployment to become development tasks that can be performed by members of the team whose expertise is designing and delivering software artifacts to deliver value outcomes.

The recognition that the definition of "working software" that is Agile's "primary measure of progress" means software that is deployed to production on infrastructure that is able to deliver the needed value at whatever scale is required is an essential revolution of thinking. This definition makes it clear that the self-organizing team must now ensure that their work is deployable, scalable, observable, and supportable, not just that it worked on their local machine. Bringing validation of these features into the definition of done for a team task requires new skills be brought into the team to eliminate inefficient hand-offs.

It is certainly possible to have external organizations handle some of the "operations" tasks that DevOps brings into the fold, but whenever possible these skills should be brought inside the team. Higher-level standards and practices should be enforced through core software services that automate what to do, not through separate human execution. In most cases, this means that separate Infrastructure and Operations organizations should become core platform development organizations collaborating with component and product development teams. Many transitional structures can certainly exist along the path to this ideal, but all eyes should be on the prize of reducing the number of hand-offs across functional boundaries.

Persistent QA, Infrastructure, and Operations Organizations

All of this said, I have found that many enterprises I have joined, collaborated with, and/or interviewed with appear to have institutionalized permanent QA, Infrastructure, and/or Operations organizations side-by-side with espousing their embrace of Agile and DevOps. Beyond the internal dangers I outline above, this choice manifests user-impacting artifacts in how those organization interact with their customers on quality, the ways in which they are able to deploy/support applications, and the ways in which internal and external audiences can monitor what's going on or communicate with the product team.

As I've noted, there can certainly be resource constraints or transitional timing explanations for this, but I've often gotten lots of long silences and blank stares when I ask leaders if they are on a path to the consolidated QA/Infrastructure/Operations org chart that will reflect directly into how their apps deliver value to their users. So, it's not at all clear to me if the disconnect that unnerves me is niggling at their consciousnesses at all.

Help Educate Me

This entire article has basically served as context for collecting valuable feedback from all of you.

Perhaps I'm being too much of the purist and there are essential reasons why maintaining separate orgs that would seem to violate the tenets of Agile and DevOps is widespread. Perhaps there are problem at scale that I'm not appreciating. It's my recollection that some compliance regimes require complete separation of development and quality assurance organizations because they were born in another era.

I need to understand more of the counterarguments to my assertions so I can become a more useful change agent when I engage with other folks trying to deliver awesome software products.

If you are interested in the original article by Melvin E. Conway that birthed "Conway's Law" it can be found here.