Org Structure, Software Architecture, and Cross-functional Teams

Some 46 years ago, Melvin Conway wrote, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

This idea is known as “Conway’s Law,” and the converse is known as “Reverse Conway’s Law.” It’s as true today as it was a half century ago.

The basic idea is this: Your organizational structure drives a particular software architecture. And your software architecture drives a particular organizational structure. People who work closely together and communicate frequently will create software that reflects this and vice versa.

The Reinforcing Loop of Org Structure and Software Architecture

This dynamic leads to one of the major points of friction for established organizations trying to become agile:

When your organization and architecture have settled into a highly-specialized, component-oriented structure, it can be very difficult to form cross-functional teams who can work on deep vertical slices of your system. There may be no combination of 9 people to make a Scrum team who can work on the whole stack. And without such teams, it can be very difficult to achieve many of the agile values and principles (e.g. frequent delivery and feedback, responding to change, customer collaboration).

Addressing this requires short- and long-term action.

In the long term, you want to get cross-functional teams, but you probably don’t have the skills and knowledge in your team members to pull it off. This means cross-training to grow people’s skills to cover more of your system. Cross-training requires slack. You’ll need to over-staff teams—or allow teams to pull less work than their full delivery capacity—so people have time to learn new areas rather than trying to maximize efficiency in delivering what they already know.

In the short term, you want to get as cross-functional as you can.

Suppose you have a group of 25 people working on the same product. Different people have become experts in different areas of the system. Now, you’re adopting Scrum, so you need to find 3–4 cross-functional teams who can deliver high-value features all the way to done. Ideally, any of the teams should be able to pull any item from the backlog. It looks like this:

One Product Backlog, Multiple Scrum Teams

So, what do you do?

First, you need to define what “high-value features” and “all the way to done” mean in your context. The Product Owner should be able to to present a product vision and the top several sprints of a Product Backlog. The Product Owner and team should be able to build a Definition of Done.

The backlog and Definition of Done describe the work mostly from the PO or customer perspective. You need to translate this to skills required on teams. Work with team members to make a list of the kinds of tasks required to complete the features on your backlog to the Definition of Done. Many of these tasks will refer to a part of system rather than just a technology. This gives the group a sense of the work any team (ideally) should be able to do.

Next, you need to know who can do what. Chris Matts, in his excellent post on staff liquidity, recommends having each person rate themself on each skill using this scale:

0 – “I know nothing!”
1 – “I can run it”
2 – “I can tweak it or bug fix it”
3 – “I can redesign or refactor it” / “I OWN it!”

Matts suggests building a matrix of skills and people and using that matrix to identify skills to develop. Likewise, you could use the matrix to identify your most cross-functional teams.

An alternative approach if you’re all in one place is to print the list of skills and give it to each person. They fill in their scores, highlighting 2s and 3s. Then, wearing their skills like signs, they move around the room trying to form the most cross-functional teams they can.

I like this approach for several reasons:

  1. Teams can usually self-organize faster than a manager could find the optimal combination of skills from a matrix.
  2. The self-organizing approach accommodates things like, “I’m a 1 in that area today, but I’m really interested in learning more, so I plan to be a 2 or 3 in the next few months. We can go a little weak on that skill for now.”
  3. Self-organizing teams accommodates factors not covered by the skills matrix, such as who works well together (or not).
  4. Teams leave with more ownership over their composition, which makes team members willing to work outside their preferred skills to make the teams effectively cross-functional. (“We said we could do anything from the backlog, so let’s figure out how to do it,” rather than, “Management didn’t give us this key skill we need.”)

After a few sprints, revisit the team structure, asking: What skills are you missing on your team? How have your skills affected what you pull from the backlog (i.e. are you avoiding certain kinds of backlog items)? What steps are you taking to fill skill gaps on your team?

It may become apparent that some people need to change teams. One team might have excess capacity in a key skill while another lacks the skill. Or it may simply become clear where team members need to pair, cross train, or undertake formal learning to build new skills.

Bottom line: There’s great value in having fully cross-functional feature teams. But because of Reverse Conway’s Law, you might not be able to do that on day 1 with Scrum. Start where you are and take intentional steps to get to where you want to be. Don’t let your history keep you from starting to become agile, but equally, don’t let it limit how agile you can become.

Last updated