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.
- 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 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.
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.
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 ScrumMaster 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.
- Leading Teams, by Richard Hackman.
Harvard professor Richard Hackman is a long-time team researcher. His book is currently our favorite team-related book. It has a strong focus on helping management in their change to team-based work.
- Leading Self-Directed Work Teams, by Kimball Fisher.
This book has a strong focus on the change in role when one becomes a team leader of a self-directed team.
- The Wisdom of Teams, by Jon Katzenbach and Douglas Smith.
This is probably the most popular team reference and certainly worth reading.
- The Five Dysfunctions of a Team, by Patrick Lencioni.
Written like a novel, it covers well the need for conflict in teams.
Cross-functional teams are described mainly in product development literature. Some good texts:
- Fast Cycle Time, by Chris Meyer.
This is a true classic on product development and talks about cross-functional (multifunctional) teams in detail.
- Revolutionizing Product Development, by Steven Wheelwright and Kim Clark.
Another classic in product development literature; has one chapter on cross-functional integration.
Some texts related to software development teams:
- Software for Your Head, by Jim and Michele McCarthy.
Jim and Michele spent years in ‘boot camps’ to find the most efficient ways for teams to work. They documented this as a set of protocols in this book.
- Peopleware, by Tom DeMarco and Tim Lister.
This classic on the importance of people in software development also has a couple of chapters focusing on teams.