Today we have the first "guest blogger" posting on this blog. My colleague Antti Tevanlinna developed a description for a pattern that his team has been implementing for some time. The pattern is called "Teams within a team" and deals with scaling up agile projects.Let us know what you think through the comments.Problem And ContributionThe goal of an organization is never to create just one part of a system. Only the whole system will have value. In a medium-sized team, how do you create efficient sub teams for the parts while optimizing for the whole system?The contribution of this pattern is the counter balance for freedom of teams. We discuss dividing people into feature teams that can concentrate on a specific part of the system. In conjunction with freedom, it is of importance to discuss how the independent teams are aligned to work so that the whole system gets done.ContextThis pattern is an organizational pattern that addresses how to divide work among a medium-sized group. This pattern is suitable in iterative work such as when using the Scrum process model. We assume that there exists a project with a goal. This goal has been elaborated into a subgoal list. This may be a list of user stories, a product backlog, or whatever similar list. This list is used to agree what needs to be done and to track the progress.ForcesMost non-trivial projects require more than ten people involved. There are two classical alternatives to grow an organization: you can either make one team bigger or you can create multiple teams:Ten people are too many to form a coherent team. You can try it, but you will soon find that the common purpose is diluted. People will find themselves specializing and not working together. Soon, it is hard to tell why is this group of people a team. As the team grows, the communication inside the team becomes difficult likewise.The other option is split the whole group of people into teams. The teams have a purpose. This purpose can be found based on development process phase, e.g. requirements, or by architecture, e.g. user interface and database. Communication across the teams will pose a challenge and the teams will create their own view of the overall goal.Ending up using these to patterns seems often like a force of nature. Neither of them optimizes for the overall goal: delivering as many subgoals as possible from the subgoal list.SolutionSplit the whole into semi-independent sub teams. Aim for the optimal team size in your context so that the team can accomplish any work item from the subgoal list. A team is a group of people with all the competencies needed for completing a task. The teams are cross-functional in other words. The team size has an impact, but this discussion is omitted here. There may be multiple skills that one person has. Other skills are specialties. These considerations are not a part of this pattern.(We will later (maybe) discuss selecting teams based on value to be delivered and self-selection of the teams. This discussion goes into analyzing emergent teams as opposed to assigned teams.)In the beginning of an iteration let sub teams choose what they will work on and deliver. Thereafter, the authority over the items to be produced is given to the team. The team has the autonomy of work practices, communication, and in general "how to get it done". In the end of the iteration the team is expected to have finished the item. A simple way to see that is to use iteration end demonstrations. This means the teams are given the scope of delivery and one iteration as time to deliver the scope. The team themselves are the resources. In a sense, the sub teams complete a mini-project in a iteration. We have now described a simple pattern to form teams that are often referred to as feature teams. Next we will describe what is the counter balance for the given freedom. While teams are allowed to be as autonomous in the work practices, the integrity of the system is preserved by measurement and project management. The primary measure of progress in iterative work is the fulfillment of stories or requirements in the work list (e.g. the product backlog). Tracking of completed work binds the teams together in the following ways:The teams are not measured based on their own contribution, but the organization is measured only for the combined throughput. This prevents sub-optimization for the sub team. This shares the responsibility for the scope and the schedule between the sub teams.All work is considered finished only when the changes any item requires exists in the whole system. No team owns a part of the system. A change is considered complete when the whole system has been considered. This prevents passing responsibility for the whole to somebody else, and the responsibility finishing what has been started is shared.It is the whole organization that agrees that the item has been completed. The teams suggest propose that it has been done, but the organization has the final say. The responsibility of the quality is shared.RationaleThis pattern focuses on lifting some essential project management practices to a level above a team. Firstly, preserve the whole system as the primary measure of progress. Secondly, the whole must be present as the basis of the work - You work with the whole all the time even if you are a part of a team. That means, all work contributes all the time to a common object and not something that the team owns. This arrangement separates the smaller tasks that the teams perform from the whole of project. The independence of teams and the interest whole of the organization is balanced. The teams can self-organize, while the whole sets the targets for the self organization.This pattern provides an alternative to dividing teams based on architecture or development process phase. When we want to optimize our work based on value to be delivered, it makes sense not to divide the teams based on history or the used process. These two divisions often sub optimize. They have bias toward dividing principle, which is not generally what items we want to produce.When the teams are divided neutrally in the aforementioned sense, they are not inclined to turn inwards. On the contrary the teams need to look outwards more actively, because the goal to be delivered is on the higher level.This pattern is surprisingly scalable in the number of management people required. In a team of 20 people, the whole can be preserved with an appointed architect, quality engineer, and a project manager. This is less than having those roles defined for all the sub teams.ConsiderationsThe following variables have been identified to affect the resulting context of applying the pattern:Lifetime of a teamThe level of independenceThe frequency of synchronizing the teamsThe team building activities sub teams and the larger teamThe role of architecture and qualityThe role management, projects, and programsRelated PatternsThis pattern is closely related to Jim Coplien's Holistic Diversity, which addresses the same kind of dilemma. He's pattern shares the solution for splitting the teams. We have extended the pattern by considering the team of teams. We have also described the forces and practical methods for keeping the whole system intact. Many descriptions of feature teams can be found. We find that those descriptions also lack the discussion on what structures exists above the feature teams. Posted by

Today we have the first "guest blogger" posting on this blog. My colleague Antti Tevanlinna developed a description for a pattern that his team has been implementing for some time. The pattern is called "Teams within a team" and deals with scaling up agile projects.

Let us know what you think through the comments.

Problem And Contribution

The goal of an organization is never to create just one part of a system. Only the whole system will have value. In a medium-sized team, how do you create efficient sub teams for the parts while optimizing for the whole system?

The contribution of this pattern is the counter balance for freedom of teams. We discuss dividing people into feature teams that can concentrate on a specific part of the system. In conjunction with freedom, it is of importance to discuss how the independent teams are aligned to work so that the whole system gets done.

Context

This pattern is an organizational pattern that addresses how to divide work among a medium-sized group. This pattern is suitable in iterative work such as when using the Scrum process model. We assume that there exists a project with a goal. This goal has been elaborated into a subgoal list. This may be a list of user stories, a product backlog, or whatever similar list. This list is used to agree what needs to be done and to track the progress.

Forces

Most non-trivial projects require more than ten people involved. There are two classical alternatives to grow an organization: you can either make one team bigger or you can create multiple teams:

• Ten people are too many to form a coherent team. You can try it, but you will soon find that the common purpose is diluted. People will find themselves specializing and not working together. Soon, it is hard to tell why is this group of people a team. As the team grows, the communication inside the team becomes difficult likewise.
  
• The other option is split the whole group of people into teams. The teams have a purpose. This purpose can be found based on development process phase, e.g. requirements, or by architecture, e.g. user interface and database. Communication across the teams will pose a challenge and the teams will create their own view of the overall goal.
  

Ending up using these to patterns seems often like a force of nature. Neither of them optimizes for the overall goal: delivering as many subgoals as possible from the subgoal list.

Solution

Split the whole into semi-independent sub teams. Aim for the optimal team size in your context so that the team can accomplish any work item from the subgoal list. A team is a group of people with all the competencies needed for completing a task. The teams are cross-functional in other words. The team size has an impact, but this discussion is omitted here. There may be multiple skills that one person has. Other skills are specialties. These considerations are not a part of this pattern.

(We will later (maybe) discuss selecting teams based on value to be delivered and self-selection of the teams. This discussion goes into analyzing emergent teams as opposed to assigned teams.)

In the beginning of an iteration let sub teams choose what they will work on and deliver. Thereafter, the authority over the items to be produced is given to the team. The team has the autonomy of work practices, communication, and in general "how to get it done". In the end of the iteration the team is expected to have finished the item. A simple way to see that is to use iteration end demonstrations. This means the teams are given the scope of delivery and one iteration as time to deliver the scope. The team themselves are the resources. In a sense, the sub teams complete a mini-project in a iteration.

We have now described a simple pattern to form teams that are often referred to as feature teams. Next we will describe what is the counter balance for the given freedom.

While teams are allowed to be as autonomous in the work practices, the integrity of the system is preserved by measurement and project management. The primary measure of progress in iterative work is the fulfillment of stories or requirements in the work list (e.g. the product backlog). Tracking of completed work binds the teams together in the following ways:

• The teams are not measured based on their own contribution, but the organization is measured only for the combined throughput. This prevents sub-optimization for the sub team. This shares the responsibility for the scope and the schedule between the sub teams.
  
• All work is considered finished only when the changes any item requires exists in the whole system. No team owns a part of the system. A change is considered complete when the whole system has been considered. This prevents passing responsibility for the whole to somebody else, and the responsibility finishing what has been started is shared.
  
• It is the whole organization that agrees that the item has been completed. The teams suggest propose that it has been done, but the organization has the final say. The responsibility of the quality is shared.
  

Rationale

This pattern focuses on lifting some essential project management practices to a level above a team. Firstly, preserve the whole system as the primary measure of progress. Secondly, the whole must be present as the basis of the work - You work with the whole all the time even if you are a part of a team. That means, all work contributes all the time to a common object and not something that the team owns. This arrangement separates the smaller tasks that the teams perform from the whole of project. The independence of teams and the interest whole of the organization is balanced. The teams can self-organize, while the whole sets the targets for the self organization.

This pattern provides an alternative to dividing teams based on architecture or development process phase. When we want to optimize our work based on value to be delivered, it makes sense not to divide the teams based on history or the used process. These two divisions often sub optimize. They have bias toward dividing principle, which is not generally what items we want to produce.

When the teams are divided neutrally in the aforementioned sense, they are not inclined to turn inwards. On the contrary the teams need to look outwards more actively, because the goal to be delivered is on the higher level.

This pattern is surprisingly scalable in the number of management people required. In a team of 20 people, the whole can be preserved with an appointed architect, quality engineer, and a project manager. This is less than having those roles defined for all the sub teams.
Considerations

The following variables have been identified to affect the resulting context of applying the pattern:

• Lifetime of a team
  
• The level of independence
  
• The frequency of synchronizing the teams
  
• The team building activities sub teams and the larger team
  
• The role of architecture and quality
  
• The role management, projects, and programs
  

Related Patterns

This pattern is closely related to Jim Coplien's Holistic Diversity, which addresses the same kind of dilemma. He's pattern shares the solution for splitting the teams. We have extended the pattern by considering the team of teams. We have also described the forces and practical methods for keeping the whole system intact. Many descriptions of feature teams can be found. We find that those descriptions also lack the discussion on what structures exists above the feature teams.