Team

Definition

Team

a relatively small-scale indirect producer with the following characteristics:

• Endeavor. A team is a major component of a program or project.
• Parent Producer. A team is a major component of an organization.
• Structure. A team consists of a cohesive collection of one or more related roles and/or subordinate teams that collaborate to perform a cohesive set of tasks (i.e., typically an activity, although the tasks may comprise a major subset of an activity or a set of related activities).
• Management. A team is managed as a unit.

Classification

As illustrated in the preceding figure, organizations are part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Producer
• Subclasses:
  • Endeavor Teams, which are aggregate teams that staff an endeavor:
    • Enterprise Team
    • Program Team
    • Project Team
  • Management Teams, which provide administrative management to an endeavor:
    • Customer Management Team
    • Endeavor Management Teams:
      • Enterprise Management Team
      • Program Management Team
      • Project Management Team
    • Center Management Teams:
      • Contact Center Management Team
      • Data Center Management Team
      • Reuse Center Management Team
    • Change Control Board
    • Configuration Management Team
    • Disaster Recovery Team
    • Emergency Response Team
  • Strategy Teams, which develop the overriding strategies for an enterprise during business engineering endeavors:
    • Digital Branding Team
    • Business Strategy Team
    • Technology Strategy Team
  • Engineering Teams, which perform engineering tasks during application development endeavors:
    • Architecture Team
    • Computer Security Incident Response Team (CSIRT)
    • Database Team
    • Deployment Team
    • Endeavor Debrief Team
    • Environments Team
    • Hardware Development Team
    • Independent Test Team
    • Integration Team
    • Metrics Team
    • Pair Programming Team
    • Process Team
    • Quality Team
    • Requirements Team
    • Reuse Team
    • Review Team
    • Safety Team
    • Security Team
    • Software Development Team
    • Training Team
    • User Interface Team
  • Post-Development Teams, which perform tasks after the deployment of the application:
    • Content Management Team
    • Maintenance Team
    • Operations Team
    • Product Standards Committee
    • Retirement Team
    • User Support Team (e.g., contact center, help desk)
  • Evaluation Teams, which perform technical evaluations of cohesive collections of work products:
    • Architecture Evaluation Team
    • Center Evaluation Team
    • Configuration Management Evaluation Team
    • Content Management Evaluation Team
    • Database Evaluation Team
    • Deployment Evaluation Team
    • Environments Evaluation Team
    • Hardware Evaluation Team
    • Integration Evaluation Team
    • Management Evaluation Team
    • Requirements Evaluation Team
    • Retirement Evaluation Team
    • Software Evaluation Team
    • Strategy Evaluation Team
    • Test Evaluation Team
    • Training Evaluation Team
    • User Experience Evaluation Team
    • User Support Evaluation Team

Responsibilities

All teams typically have the following common responsibilities:

• Produce a related set of work products.
• Provide a related set of services.
• Request changes to, and report defects in, work products.
• Collaborate professionally with other teams, organizations, and roles.
• Provide other producers with consulting and domain (subject matter) experts on its work products, work units, and component producers.
• Provide status reports including any important unresolved issues.
• Provide the management teams with effort and schedule estimates.

Tasks

All teams typically perform the following common tasks in an iterative, incremental, parallel, and time-boxed manner:

• Change Requesting
• Collaboration
• Defect Reporting
• Effort And Schedule Estimation
• Expertise Improvement
• Resource Requesting
• Status Reporting

Documentation

The OPEN Process Framework (OPF) documents the following information about each reusable team:

• Definition of the team
• Responsibilities of the team
• Roles (or subordinate teams) that collaborate to form the team
• Tasks performed by the team
• Work products produced by the team
• Guidelines

Guidelines

General Guidelines

• Most teams should be “joint” (a.k.a., cross-functional) teams made up of individuals representing different roles and potentially even different organizations. Joint teams are useful for reaching consensus decisions and increasing quality by increasing the amount of iteration and viewpoints represented.
• Typically (and especially on small endeavors), the same person may simultaneously or at different times play:
  • Multiple roles within a single team
    (if the person has the necessary training, expertise, and personal characteristics).
  • Different roles on different teams
    (if needed for the success of the endeavor).
• A team may be geographically distributed, with members collaborating via the Web and the telephone.
• Major signs of risks associated with teams include:
  • Not Representative.
    The team does not include members that represent all major types of stakeholders.
  • Not Knowledgeable.
    The team does not include members knowledgeable and experienced in the performance of all relevant tasks to be performed.
  • Not Authorized.
    The team has not be properly authorized to perform the assigned tasks.
  • Not Collaborative.
    The team members do not work well together, resulting in discord, frustration, and a loss of morale.
  • Not Committed.
    The team members are not committed to the goals of the team and the work they are assigned to perform.

Usage Guidelines

Usage guidelines for using the OPEN Process Framework (OPF) to produce a process containing endeavor-specific teams include:

• Construction Guidelines for constructing an endeavor-specific process containing teams:
  • Relevancy.
    Only select relevant teams during process construction.
    • Because every endeavor does not require every kind of team, only select those teams in the reuse repository that are appropriate for the endeavor.
    • Make your selections based on the types of work products to be produced, the types of services to be provided, the team’s responsibilities and associated tasks to be performed, and the management team’s ability to manage large numbers of fluid, overlapping teams.
  • Team Size.
    Construct teams that have appropriate sizes:
    • Large projects requiring numerous people to complete are usually organized into numerous, relatively small teams (e.g., 2-5 persons who perform 3-7 roles).
    • Small projects often contain some teams with only a single member who performs multiple roles.
    • The optimum size of atomic teams is from 2 to 5 persons with a maximum size of around 10.
  • Number of Teams.
    Construct the appropriate number of teams:
    • Team cohesion increases the number of teams.
    • Small team size increases the number of teams.
    • Because OPF is a general (and therefore relatively complete) framework, its class repository contains a very large number of teams that can be somewhat daunting to managers and process engineers on small projects. Although one might be tempted to merge several teams into one overall team on small projects, such teams lose their cohesiveness and require large amounts of redocumentation. On such projects, it is typically better to have numerous small teams that have the same membership performing different team-specific roles.
  • Empowerment.
    Ensure that teams are empowered:
    • Give teams the mandate to make and act on decisions within their scope of responsibilities (although they naturally collaborate with other producers that may be impacted and use formal change request forms when changing baselined configuration items).
    • Encourage teams to take a proactive stance regarding identifying and solving problems.
    • Give teams the necessary resources (e.g., time, tools, equipment) to meet their responsibilities.
    • Give team members the necessary training to perform their tasks.
    • Enable teams to set and sign up for their own schedules.
  • Different Teams.
    Different endeavors require different processes, which in turn will require different teams.
  • Documentation.
    Properly document the teams used in the process:
    • Document the selection of teams in the process description document.
    • The project organizational chart will be a living evolving document because:
      • Many teams will be created as needed at various times during the project to fulfill specific responsibilities and will be disbanded when the associated tasks are completed.
      • Teams can be very fluid with new members continually joining and leaving.
• Extension and Tailoring Guidelines for extending the repository with a new class of teams:
  • Approach.
    The same basic approach is used for extending the class library with a new type of team and tailoring an existing team: specialization (i.e., inheritance). Select the most specialized appropriate existing team in the repository and create a new specialization with the appropriate characteristics.
  • Scope.
    Extension and tailoring can theoretically involve all aspects of a team. As appropriate, you can:
    • Modify the team’s name and definition.
    • Add, modify, or delete team responsibilities.
    • Add, modify, or delete team roles (or component teams)
    • Add, modify, or delete team tasks.
    • Add, modify, or delete team work products.
    • Add, modify, or delete team guidelines.
  • Emphasis on Deletion.
    Because OPF is a relatively complete framework, its method components often contains elements that are not needed on every endeavor. Thus, extending the class library with a new team or tailoring an existing team more often involves the deletion of unnecessary elements (e.g., responsibilities, roles, tasks, and work products) than additions or modifications.
  • Proper Characteristics.
    A team should be complete, cohesive, and internally and externally consistent:
    • Name.
      • Every team should have an endeavor-unique name.
      • The team’s name should intuitively imply a single concept.
      • The team’s name should intuitively imply its responsibilities.
    • Definition.
      • Every team should have an unambigouous definition.
      • The team’s definition should be a single sentence that properly defines the team.
      • The team’s definition should be consistent with its responsibilities.
    • Responsibilities.
      
      • Every team should be assigned a complete set of responsibilities that justifies its existance.
      • The team’s responsibilities should be cohesive.
      • The team’s responsibilities should be consistent with its name and definition.
    • Roles.
      
      • Every team should be composed of a complete collection of roles and/or subteams in the sense that these roles provide all of the required expertise and knowledge (e.g., one person’s weaknesses will be counter-balanced by other people’s strengths).
      • The team’s membership should be cohesive in the sense that its roles collaborate more with each other than they collaborate with the roles of other teams (i.e., the roles have high-internal coupling)
      • The roles played by the team’s members should be consistent in the sense that the team’s:
        • Responsibilities should be a subset of the responsibilities of its constituent roles.
        • Tasks that it performs should be a subset of the tasks performed by its constituent roles
        • Work products that it produces should be a subset of the work products produced by its constituent roles.
    • Tasks.
      
      • Every team should be assigned a complete set of tasks.
      • The tasks that the team performs should be cohesive in the sense that they share a set of common similar input and output work products.
      • The tasks performed by a team are delegated to its constituent roles and subteams. These tasks should be consistent in the sense that the task that the team performs:
        • Imply its responsibilities.
        • Should be a subset of the tasks performed by its constituent roles.
        • Produces the work products that it is responsible for producing.
    • Work Products.
      
      • Every team should be responsible for producing a complete set of related work products.
      • The team’s work products should be cohesive (e.g., they are associated with a single activity or work product).
      • The team’s work products should be consistent in the sense that:
        • They are implied by the team’s responsibilities.
        • They are created or updated by the team’s roles.
        • They are created or updated by the team’s tasks.
    • Well-Defined Interfaces.
      A team’s interfaces to other producers should be well-defined in terms of the tasks it performs and the work products it needs and imputs and produces as outputs. This makes it easier to change the team membership and the techniques that it uses to perform its tasks without adversely affecting other dependent producers.
    • Consistent Terminology.
      The terminology for method components used in the description of a new or tailored team should be the same as that used in the rest of the class library of method components.
  • Timing.
    Extension and tailoring to produce new or modified teams can happen at any time during the endeavor:
    • At the beginning of the endeavor when the endeavor-specific method is produced.
    • During the actual performance of the resulting process as situations change and lessons are learned.
  • Documentation.
    Ensure that each new type of team is adequately documented in the:
    • Process Description Document and that all standard topics are included.
    • Endeavor Organization Chart