In 1967 Melvin Conway submitted a paper called "How Do Committees Invent?" to the Harvard Business Review. HBR rejected it on the grounds that he had not proved his thesis:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
He got the paper published a year later in Datamotion magazine and it you’d like to read the original it’s available on his website here -- Fred Brooks subsequently coined the name "Conway's Law" when he wrote about this idea classic book "The Mythical Man-Month".
In his article, Melvin asks "Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs? The answer is: Yes, the relationship is so simple that in some cases it is an identity." and he concludes "a design effort should be organized according to the need for communication." The basic point he makes is that the shape of software reflects the communication patterns of the people making it.
When I've heard conference speakers, such as Michael Feathers and Kevlin Henney, invite the audience to consider Conway's Law, their focus is usually spotting problem areas resulting in the code layer rather than the people layer. The division of an organisation into teams and departments can create barriers and interfaces in the software. The effects are usually even worse when multiple organisations are involved and those organisations are in different countries around the world with time-delays introducing inevitable delays into communications. Many traditional software development organisations use “teams” that are a bunch of people reporting to the same line manager but each person taking responsibility for adding specific functionality. These software developers usually have different coding styles and rationale for design decisions. The resulting code can be like a patchwork quilt and hard to maintain due to inconsistent coding conventions.
Agile approaches to software development can be seen as a way of "refactoring" communication between people and improve the software they create. When we adopt XP practices of Collective Code Ownership and Pair Programming, we improve knowledge sharing and code consistency. On an XP team, any developer can work on any part of the code, code is created and reviewed in pairs, this helps the team to produce code that can be understood by any team member. XP seems to be a set of organisational design patterns that works for a small team. Sharing knowledge between teams working on the same code is a challenge so maybe we need to exchange people between these teams in the same way as an XP team does pairing swaps.
As an agile coach, I work more with individuals and teams than on the code. I spent many years as a software developer and enjoy “debugging” people and communication problems. In working with people to simplify and untangle process, I find myself applying concepts learned in software design, such as decoupling interactions and clarifying responsibilities. Information and work flows through a software, information and work also flows through a software development organisation. Are there any design principles that we regularly apply in software that could benefit how we design our organisations?
I thought it might be fun to revisit the SOLID design principles to see if any apply to the people domain. SOLID is a set of Object-Oriented design principles crafted by Robert Martin and the Object Mentor team in the early 00's to help teach OO design to C++ programmers who might be struggling to make the shift. Michael Feathers gets the credit for coming up with the acronym!
The SOLID principles are:
- Single Responsibility Principle (SRP)
- Open/Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
Let's look at each of these in turn to see whether they might apply in anyway in the people sphere, at the both the level of individuals and teams.
Single Responsibility Principle, an object should have only one reason to change. A class has a single responsibility; it does it all, does it well, and does it only. The purpose of this principle is to make it easy to understand the class and have a single place to make changes to this behaviour.
If we try to extend SRP to the people layer, this implies each person does a specialised job which is pretty much at odds with Agile software development concepts such as collective code ownership. We know that if we have a single specialist then they can become a knowledge bottleneck and we're in trouble if they get sick or go on holiday. This brings to the surface some constraints that we have to work with in the people layer - we have a limited number of people and they are not always available. In software we're used to a world with virtually no limit on the number of entities we can create with separate responsibilities.
However, we can go down the route of applying SRP for flow of information into the team by establishing a Product Owner to be the gatekeeper for new story requests and set priorities for the team. There is also sense in which SRP might apply at a team level, making one team responsible for all changes to a specific product. This is a core idea in Scrum, one team per product. We understand which team needs to make the changes and they have all the knowledge to make those changes.
On larger software systems, we end up with multiple teams and because of the various technologies involved component teams often proliferate. This may work where there's an even stream of work to keep all these component teams busy. But large agile projects often find that feature teams work better than component teams. So again in the P-layer we're concerned about levelling the workload and avoiding knowledge bottlenecks.
Open/Closed Principle, a class should be open for extension and closed for modification. Again this is all about isolating changes. We can’t really extend or modify people so I’m not sure that there’s a way to apply this in the people domain. At the team level we can add, remove or consolidate teams and having some consistent process across teams makes this easier.
Liskov Substitution Principle, instances of an interface should be wholly substitutable regardless of implementation. Implementations of an interface should behave the same way from the point of view of the caller. They should not require callers to have any knowledge of implementation variances to do the same work. Perhaps this applies to the the communication interface to teams. For instance, those processes used when we send the team new support requests and introduce new requirements. If there is a team that handles support requests, we use the same process irrespective of the individual who is picking up the requests, this is in some sense applying LSP. The team can rotate who is on support duty but the interface is the same.
Interface Segregation Principle, several interfaces with specific purposes are better than one larger interface. It’s better to have many small interfaces than fewer big ones as this allows them to change independently. I think that ISP does apply for software teams, we need to identify the parts of the organisation that interact with the team and agree a pattern for these interactions. I’d say that this applies to cadence of meetings, such as demos, and having a clear agenda for specific regular meetings with different groups. This can be a big improvement on general management meetings that aim to cover several different things and involve one or two of participants in turn during one long meeting.
Dependency Inversion Principle, collaborators should depend upon abstract interfaces, not concrete implementations. Objects should be minimally coupled and know little to nothing about how their collaborators are implemented. I’m running out of steam here but perhaps DIP can be seen to apply to how Scrum handles the separation of the stakeholders and the development team. The team decide how they do the work and owns the Sprint Backlog, commitments with stakeholders are made on the Product Backlog only.
I’ve written this article for XPDay magazine as a recent topic I’ve been pondering and hope to discuss this topic at the Open Space there. I’m also posting this article on my blog because I’m interested to hear your comments. I've written this in rather a hurry and I'm sure that there are other ways that SOLID principles might be seen to apply to software development organisations.
