The first thing to notice is that the customer (on the left hand side of the drawing) has no direct line to the development team. The vice-versa is true as well. Customer has to go through Product or Support to get to development. Development teams themselves have to go through either Product, PMO, Operations or Support to get feedback from customers. Conway’s Law, when applied to this setup would mean that since developers are a one or two layers removed from the customers, the features and products they produced are likely to be one or two steps removed from the real needs of the user.

Each group has multiple masters. Product is directly responsible for satisfying feature and enhancement requests from Customers, Sales and Support. Product is also responsible for providing structured requirements and priority updates to the Development teams as well as PMO. This forces the Product department to create a mixed set of priorities which most likely is not directly representative of the priorities of the customers. Development teams, already one step removed, receive this mixed list of priorities. For the dev teams though, this is just one “customer”. They also have to satisfy directly received tickets from Support, provide timelines to PMO, deployment requirements to Operations all while satisfying the overriding directives from Architecture.

Each group also has its own objectives and incentives. Sales wants flashy items to sell, Customer Support wants low time to resolution on calls, Product wants maximum number of complete features, Development wants new technology and maintainable code and Operations wants easily deployable, portable and stable products. Everyone is pulling in slightly different directions, with customer satisfaction, delivery of customer value and fulfillment of customer outcomes lost somewhere in the middle of the tug-of-war. All this is happening, while each member of each department is doing their best and working hard to achieve the department’s objectives.

The lack of alignment sets Conway’s Law into motion. The result of this is usually a confused (or an increasingly confusing) product. The separate departments push their separate agendas onto the end product. The product, as a consequence, has lots of features, but most of them are incongruent and rarely used. With the teams developing the product being a couple of layers removed from the customers, this feedback rarely makes it back to them. Even if it does they are already on to the next thing on some other department’s priority list. The competing and misaligned priorities for each department leads to the actual customer priority being lost in the shuffle. Each department firmly believes they are doing the best thing for the customer and the misaligned priorities result in customer’s best interests being only half-fulfilled at best.

Conway’s Effect on Process

It is not just the priorities that are mismatched, the departments have different capacities and speed of production as well. This would mean finished work sitting between departments in queues waiting to be picked up. It could also mean departments being starved for work as they are waiting for deliverables from other parts of the system. Instead of the process enabling a lean flow of value to the customer, the value generated sits in queues despite everyone doing there best to achieve their department’s goals. The structure and mismatched capabilities make flow very hard to attain. If we restate Conway’s Law in terms of process, it would fit perfectly — Any organization that follows a process will inevitably produce a process whose structure is a copy of the organization’s communication structure.

Even within, what is supposed to be a cohesive team, the separation of concerns persists. This is usually because the departments themselves are not in alignment on objectives, priorities or incentives.

We can try to solve this be moving folks from the product and operations teams onto the development teams. This can at times work, but as long as the individuals serve separate masters and have varied incentives, bad, inefficient processes will emerge. If BAs and PMs are made a part of the development team, but still serve a separate product department, they are receiving mixed signals. Many times, not always, they tend to act as teams within the larger team. Due to this, there is a “not my job” and “over the wall” mentality that develops on the team. High level requirements are the PM’s job, writing stories is the BA’s job, writing and testing code is the developer’s job and deploying the code to production is the OPS person’s job. Even within, what is supposed to be a cohesive team, the separation of concerns persists. This is usually because the departments themselves are not in alignment on objectives, priorities or incentives.

One quick note on DevOps. If you put a person from the operations team onto the dev team and all that person does is OPS work with no interaction with the devs, it does not mean that you are “doing” DevOps. For DevOps, developers take on operations responsibilities and operations folks help out with development.

With separate objectives and incentives, the queues will still exist. Value will still sit in these queues and becomes stale. Stories and features would be coded and tested weeks or months after they are written. The same will happen for deployment activities. Finished work will not make it to customers months after it was done. This would cause disappointment for any customers of this process as their wait times keep increasing. An increase in inter-department wait times leads to increased mistrust among already segregated departments. Departments do not believe that their partners are moving fast enough and push more and more work downstream. Sales does it to Product, Product to Development and Development to Operations. The overriding belief becomes — “in order to get more done, we need to push more work onto them”. This is where Little starts helping Conway.

Little’s Law

In 1961, John Little provided mathematical proof of the queuing formula that has come to be known as Little’s Law. In the development world, it is commonly expressed as follows —

Here Lead Time(or Cycle Time) is the amount of time it takes for a work item (task, story feature, initiative etc.) to get done. Work In Progress (WIP) is the total number of items in progress. Throughput is the number of items getting done per unit of time (per day, per week, per month etc.). Little’s Law is a truth of nature. It is mathematical fact and is inescapable.

The simple conclusion from Little’s Law is that if we have a consistent speed of getting things done, the amount of time it takes to do each thing, is directly proportional to the number of things we are working on. In other words, if we want to get things done faster, we need to work on fewer things. One important thing to remember is that this applies at every level of granularity. It applies at the story level, the feature level and the initiative level.

Conway and Little — Putting the WAR in softWARe since 1960s.

As we have already discussed, one of the consequences of an organization splintered along specialization departments is sibling departments pushing more and more work onto each other. Unfortunately, according to Little’s Law this only makes things worse. The more things we take on , the longer each individual thing takes. As opposed to delivering individual bits of value to the customer, we work on everything and deliver nothing. Since everything takes a long time, we try to subvert the process by having “fire lanes” and high priority expedites. Unfortunately, these are not exempt from Little’s Law. They only increase the WIP. Also, because we have done nothing to increase our throughput, all this does is increases our cycle times for each deliverable. Increased cycle times, fuel more frustration, greater mistrust and increased friction between departments. Once again, the customer and, as a consequence, the company comes out as the loser in the struggle.

Conway And Little Are Your Friends

So far we have only explored the negative effects of Conway’s Law and Little’s Law. The fact is that these two are our friends. They can help us design our organizations for success and then execute on the design. First let us define what success means, then design the organization around that definition of success and finally establish flow to become successful. Conway will help us design the organization and Little will help us establish flow.

What if we took a very simple definition of success — Achieve positive outcomes for the customers. This would require creating alignment between all the moving parts of the organization. The sketch below is how I would propose we create an organization to achieve success.