This page is shown in English as no translation to ไทย is available.


What is a team?

Teams are the core building block for large product development—and team structure has a huge impact on productivity and cycle time.

Team has:

  • a shared work product
  • interdependent work
  • a shared responsibility
  • a set of working agreements
  • responsibility for managing the outside-the-team relationships [SJS03]
  • distributed leadership [Katzenbach98]

Self-managing teams

Self-managing teams are the basis of Scrum and a widespread modern management practice. The team has the authority to design, plan, and execute their task and to monitor and manage their work process and progress [Hackman02]. The team rather than a (project) manager—has the responsibility of deciding how to work.

Self-managing teams do not just happen, they need the right environment. The organization is responsible for supporting the team development by creating the conditions needed for teams to succeed. Switching to self-managing teams means the job of the traditional manager changes from directing the team to creating these conditions.

Cross-Functional Teams

Self-managing teams are cross-functional (or multifunctional). A cross-functional team is a “group of people with a clear purpose representing a variety of functions or disciplines in the organization whose combined efforts are necessary for achieving the team’s purpose[Parker02].

By definition, a Scrum team is cross-functional. Its members include at least product marketing (Product Owner), software development, and testing. A cross-functional team implies breaking the organizational barriers between development and testing by putting them in the same team

Cross-functional means that team membership includes all the key functions involved in the project, usually Engineering, Marketing, and manufacturing, at a minimum [Smith07].

Team based organization

Team-based—LeSS—organization has the following structure:

  • Dedicated teams—Each team member is dedicated for 100% of his time to one and only one Team. This might feel inflexible, but team members require dedication if you want them to (1) take a shared responsibility for the Team’s goal, and (2) take ownership of how a team works—own their processes.
  • Cross-functional teams—Each team contains all functional skills needed to produce a shippable product. Traditional functional specialization might feel the most ‘efficient’ from that function’s perspective, but most effortand problems in product development is “between the functions” and thus teams require to be cross-functional if you want them to focus on the whole working product.
  • Co-located teams—Each team is co-located in the same room. This might sound unreasonable. Wouldn’t you, in today’s globalized world, want to use the best skilled people in the place where they are? No. We want the best teams that can take a shared responsibility for the outcome of the Team, and learns from each other. Shared responsibility requires trust. Humans build up trust quickest by close cooperation and face-to-face communication. Co-location also promotes team learning—the essense of continuous improvement.
  • Long-lived teams—A Team stays together ‘forever.’ This might feel idealistic, but Teams need to have stability if you want the team to care about how they work as a Team. Anyone who has ever been on a real long-lived team knows that teams get better as the team members get to know each other and learn how to do and improve work together.

Team manages external dependencies

What are the implication for large product development? They are profound! First, each team needs a clear goal so that they know their boundaries. Establishing customer-focused feature teams helps. It results in code-focused, cross-team communication. Second, the organization needs to make it crystal clear that the teams themselves are responsible for coordinating their work with other teams. A team’s success must be measured by the whole product’s success to prevent local optimization. Removing official coordination roles such as project managers makes it clear to the team that coordination is their responsibility. Third, establish a whole product-wide continuous integration system. This creates the visibility teams need so that they can coordinate their work. The health of the product must always be visible to everybody.

Multi-skilled Workers

Learning is the major activity in product development. In the long run, reducing learning reduces efficiency—not increases it. Sherman, in Fortune Magazine:
Workers will be rewarded for knowledge and adaptability. Specialization is out, a new-style generalism is in. The most employable people will be flexible folk who can move easily from one function to another, integrating diverse disciplines and perspectives… people will need the ability not only to learn fundamentally new skills but also to unlearn outdated ways.

Team makes decisions

Self-managing teams make their own decisions. However, many people grew up in a command-and-control environment where management made decisions for them. A Scrum Master can help the team learn how to make decisions. A team agreement on how to make decisions is more important than the specific decision-making method.

The Decider protocol [MM02], is a quick and easy way of making consensus decisions.

Have conflict in the team

People working together creates conflict. That is not a bad thing. But conflict needs to be resolved. Unresolved conflict has a negative impact on team performance and creates a dysfunctional team atmosphere [Lencioni02]. Resolved conflict, on the other hand, creates learning and trust, both of which have a positive impact on performance. Conflict is an opportunity for the team to improve their performance, and hence a good thing.

Don’t have phase-based “resource allocation”

Scrum is not the waterfall. There are no phases. With its self-managing, cross-functional, long-lived feature teams, it balances the “resource need” over the release. The same people stay on the release from the beginning until the end.


These different—but proven—team concepts cause major change in organizations.

  • Self-managing teams require a change from command-and-control management to manager-teacher. Instead of focusing on what people do, management should focus on how to create the environment for the teams to succeed.
  • Cross-functional teams require breaking functional boundaries and working together across the whole organization to optimize delivering customer value. Instead of boxing people in functional groups, management should focus on cross-functional learning.
  • Long-lived dedicated teams require giving work to existing teams and letting them decide how to do it. Instead of considering individuals to be the unit of performance, the focus needs to be on complete teams.

When switching to cross-functional teams, changing management style is difficult. Luckily, a lot of excellent material has been written on this subject.

Cross-functional teams are described mainly in product development literature. Some good texts:

Some texts related to software development teams: