Continuous Delivery and Conway's Law

The challenges of continuous delivery

Continuous Delivery is more and more becoming a mainstream practice in how to create and deliver software. The reason for this are the numerous benefits this practice will have on the business as a whole. But as with most other things there is no free lunch and these benefits do not come without a price. An example of this is the fact that there are many challenges you may face when trying to implement continuous delivery in an existing organization. My colleague Daniel Deogun and I have spent quite a lot of time working with implementing continuous delivery practices within organizations. And in doing so we started to notice some reoccurring patterns among the challenges that organizations run into when moving towards continuous delivery.

"They are either caused by an organization's structure, the processes within the organization, or the people that make up the organization"

Typically, you can divide these challenges into two main categories, those related to the business and management part of an organization, and those related to the IT and software development part of the business. (Whether there actually is a difference between "IT" and "business" is of course dependent of the type of organization you are observing but making the distinction will simplify things when analyzing the difficulties many organizations have when attempting to implement continuous delivery.) However, regardless of which category the challenges fall into, many of them tend to share the same common root causes. They are either caused by an organization's structure, the processes within the organization, or the people that make up the organization.

In this article we will look at the challenges from an organizational perspective and take a closer look at the impact that an organization's structure can have on the degree of success when implementing continuous delivery. That is, how can an organization become successful in continuously producing business value?

How good are you at creating business value?

Generally, the process of taking a business idea from its inception to being a valuable product in the hands of customers will look something similar to the following.
It will start out with the idea itself being developed and refined. This idea could for example be a new feature or a completely new product. After that, it will typically move on to some sort of design phase, maybe because it has some UI or graphic elements that needs to be designed. Then, the next step is to actually develop the software and, once done, it will be put into production and run so that the customers can use the product.

In some way or the other, these steps needs to be completed for a software product to be developed. And this holds true regardless of whether the steps are being governed by an agile process or a more sequential process. However, if an organization is structured around different departments, business areas, or teams; each having clearly separated functions, then that tends to make the process very sequential. The reason for this is that the activity of moving from one step of the process to another involves a lot of ceremony. This ceremony typically comes in the form of extensive documentation, meetings, and transfer of responsibilities etc. And because of this overhead involved in moving from one step to another the process self-adjusts so that each step is only performed once.

A typical symptom of these types of organizations is when scenarios like the following plays out: a business idea is created by the business developers but because they know that, once they have passed on the idea, they never going to get a second chance to change anything they keep the idea until they have perfected it to be the best product in history before passing it on to the design department. Once the designers get it they know that, once the developers have gotten their hands on it, it will be impossible to even change a single pixel so they end up designing the most beautiful UI ever seen that has every imaginable feature in it. Not until a graphical nirvana has been reached do they pass it on to development. And so the process continues. If any of this feels even remotely familiar then do not be ashamed. It is more common than you might think.

What we just witnessed in our imaginary little story is an organization that will never be capable of performing anything but a non-repeating, sequential business development process. The organizational structure has thus created an inertia in the process that prevents it from rapidly transforming a business idea into working software. In other words, the structure itself is putting a limit on the cycle time of the delivery process. This limit is very much caused by communication barriers within the process, and as long as these barriers exist this organization will never be able to reap the full benefits of continuous delivery.

Conway's Law

In 1968, Melvin E. Conway published a paper How Do Committees Invent?¹ in which he put forward the thesis that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".

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

M. Conway - 1968

This thesis was later dubbed "Conway's Law" by Fred Brooks in his book The Mythical Man-Month² and it is by this name Conway's thesis is generally known as. The essence in what Conway is stating is that the communication structures within an organization will put limits on what types of IT designs and architectures that the organization can create. Now, this is a very interesting observation. It means that, given a certain organization, there are only certain style of architectures that the given organization can produce. Once you realize this, it becomes apparent that if you are striving towards creating a certain type of software design or architecture, then maybe you should adjust your organization to promote that type of architecture. As a matter of fact, this is exactly what the term Inverse Conway Maneuver is all about.

The nature of business value

Once we start to understand the implications of Conway's Law on IT architecture we can start to use the same reasoning when we are analyzing why an organization might struggle to implement continuous delivery.

Even though the technical aspects of continuous delivery tends to get a lot focus, partly because it is a practice often driven by software centric companies, delivering working software is actually only part of what it is all about. What continuous delivery really is about is the ability to continuously deliver business value. And as we saw in the beginning of this article, the structure of an organization can negatively affect the organization's ability to continuously, and rapidly, produce business value. If your organizational structure is forcing your value creating process to be slow and ineffective, rather than fast and iterative, then you will be unable to continuously deliver business value, and thus you will be unable to successfully implement continuous delivery.

"organizations which design IT/Software products are constrained to produce business value at a rate limited by the organizational structure"

Using the same fundamental reasoning as Conway but from the perspective of business value, we can conclude that organizations which design IT/Software products are constrained to produce business value at a rate limited by the organizational structure. The key element here is the word "rate". The rate at which the organization can produce business value at can be measured by metrics such as overall cycle time, from idea to product in the hands of customers, and keeping the cycle time low is a key aspect of continuous delivery. You may be very good at producing value but if your cycle time is too long you will not be able to get the agility and the responsiveness that your organization needs in order to stay competitive in today's software industry.

So if you are in the midst of moving your organization towards continuous delivery, or have already started but are struggling, then be aware that one of the challenges you might run into is that the structure of your current organization does not support continuous delivery. And if continuous delivery is part of your vision then it might be necessary to adjust your organizational structure in order to be successful with continuous delivery.


---------

[1] "How Do Committees Invent?", Melvin E. Conway, 1968, http://www.melconway.com/research/committees.html
[2] "The Mythical Man-Month: Essays on Software Engineering", Fred Brooks, 1975, https://en.wikipedia.org/wiki/The_Mythical_Man-Month