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.
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:
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:
- Teams can usually self-organize faster than a manager could find the optimal combination of skills from a matrix.
- 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.”
- Self-organizing teams accommodates factors not covered by the skills matrix, such as who works well together (or not).
- 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.
Share in the comments: How have you seen this in your organization?
What about when part of the development of the stack is completely in a different company. And they are using their structure of how to build things? Also most of the time, even with cross functional teams, you are working on things which requires a particular specialist to get things right in the first place because it’s hard to do things right because whatever you do there are thing which takes years to master in particular language, system or version thereof. Also there are the stack you are building which never was thought of using any sort of agile methology. This is the biggest problem of actually succeeding with doing “agile” development, and it’s always fascinating to see how projects always break down by this fact. As soon a simple change results in a 1000 man hour monster, agile methodologies breaks down. No matter what methology you are using the system you are working on will set the pace…
Richard, thanks for the nice blog. Transition to cross-functional teams can be a challenge when an organization is entrenched in a silo’d mentality. I particularly like the skill name tag approach mentioned! What fun! I remember back in the late 80’s having an organization self-organize across some 50 people into teams. The management was petrified about the chaos that would result. Instead we got such commitment and high-powered output! Be bold. People really are the best assets a company has WHEN you let them work!