Agile Q&A: What is a Self-Organizing, Cross-Functional Team?

The general guidance in the Principals Behind the Agile Manifesto is that you want self-organizing teams consisting of motivated individuals:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

“The best architectures, requirements, and designs emerge from self-organizing teams.”

The term “cross-functional” doesn’t actually appear in the Agile Manifesto or the 12 Principles. It was a key characteristic of teams identified by most, if not all, of the frameworks (i.e. XP, Scrum) that continued to modify their guidance after 2001.

There is a lot of room for interpretation about what self organizing means and what cross-functional means. There are even more possibilities when it comes to creating teams that exhibit both characteristics.

Some of those possibilities result in teams that are more dysfunctional than the groups of people working on the same project that used to pass as a “team”.

Here’s my perspective on what a self-organizing, cross-functional team that can effectively deliver value to their organization’s customer looks like.

Self-Organizing

The term “self-organizing” has been interpreted in a variety of ways:

• A self-organizing team doesn’t need a manager
• A self-organizing team doesn’t need a project manager
• A self-organizing team forms itself without any outside interference
• A self-organizing team doesn’t answer to anyone

And so on…

Each of those interpretations may have a kernel of truth, but when carried to an extreme result in situations that are worse than where the team was before.

A self-organizing team has the ability to establish their own methodology or way of working together. That specific methodology should be built on top of a shared set of values and principles (I’d suggest Agile values and principles are a good start). The team’s methodology may also be based off a specific framework (or multiple frameworks) and relevant organizational constraints.

The key idea here is the team is able to craft their way of working that accounts for their context, their collective skill sets, the nature of work they are trying to do while considering any valid organizational constraints.

It comes down to the fact that the people actually doing knowledge work usually have the best idea of how to do that knowledge work, given they have the proper experience. I’ve experienced the opposite of this when I was on a team that had to use a methodology enforced from a central methodology group. It was evident fairly early on that the folks who created the methodology had never used the methodology they created. It wasn’t pretty.

A self-organizing team sets the limit of how much work they are expected to complete within a certain time frame. This means the team sets the expectations about what they have to complete. They don’t have to live to expectations that someone who is not doing the work set for them.

The people doing the work are in the best position to know how much they might be able to get done within a time frame. That means they will be wrong less often than someone who is not doing the work, but they will still be wrong. It’s important for self-organizing teams to be able to set expectations and put forth a good faith effort to meet those expectations. If (or when) they realize they can’t meet those expectations, a self-organizing team will reset expectations based on what they learned.

A self-organizing team has influence over what they work on. This does not mean that they can go work on whatever they please, rather they have the ability to determine the direction they go about delivering a particular outcome, keeping in mind any relevant constraints.

A key assumption in the above statement is that this self-organizing team is also cross-functional in that the product people – the people who have responsibility for making decisions about what is built to deliver value to customers  – are part of the team.

 

Cross-Functional

A cross-functional team has access to all the skills necessary to effectively deliver value to customers.

A cross-functional team does not have to consist of all generalists.

A cross-functional team also does not have to consist of all specialists.

You will generally find that a cross-functional team consists of a mix of people who have some knowledge about a lot of different areas, and others who are stronger in one area but are willing to help out in other areas where needed and when they can.

You generally want a stable, focused team such that they are working solely on the work of that team, which may cut down on the number of specialists on the team on an ongoing basis. You may instead opt for people that know enough about a certain topic and bring in specialist knowledge only for very specific occasions.

A cross-functional team does not require specific roles.

You don’t have to have a designer on the team as long as there are people who are proficient at design.

You don’t have to have a tester on the team as long as there are people who proficient at testing.

You don’t have to have a development on the team as long as there are people who are proficient at development.

Whenever you hear people say that every team needs a specific role, take a look at that person’s background. Chances are they’re suggesting that because they come from a background in that particular role. Don’t discount that person’s argument, but seek to understand what skills that role typically has that are important to teams. Chances are they are making a valid point that every team needs specific skill sets.

For the record, my background is in product management, business analysis, and project management. I try hard to put any biases from that background aside, but I’m not always successful.

How would you describe self-organizing, cross-functional teams?

If you’ve worked on a team that you would consider self-organizing and cross-functional, what did it look like, what were its characteristics? Where could it be improved? Share your thoughts in the comments.

 

About the Author

---

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.