Building the Extended Team

Building the Extended Team2017-10-12T22:05:27+00:00

Buildin the Extended Team

Context

Summary

Provide a summary of this practice.

Building the Extended Team gives the Core Team access to the information, expertise, authority and resources  needed for successful delivery, but which the team does not already contain.

Purpose

What is the overall goal or intention of this practice?

Building the Extended Team is used:

  1. to identify any gaps or limitations on their ability to successfully deliver all the Core Team’s commitments.
  2. to identify the external functions and groups that could fill those gaps and overcome those limitations.
  3. to create the necessary relationships with these functions and groups.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

Although Building the Extended Team should be performed at the start of the release, it is also a continuing activity that needs to be reviewed and repeated from time to time as the Release or Iteration proceeds.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

The Extended Team must always be defined well enough for the Core Team to be confident that it can successfully deliver all commitments for the foreseeable future.

At the very least, this should include all work in the current Release.

Entry conditions

What pre-conditions must be met before this practice is used?

Building the Extended Team cannot realistically begin until the Core Team has a defined Release backlog.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Create Context Diagram.
  1. Create a map of the organisation ,Showing all functions, SMEs, authorities, etc., that may affect the Core Team’s work.
  2. These are potential members of the Extended Team.
2Identify Core Team’s stakeholders
  1. Review the Context Diagram to identify which of these can affect how – or how well – the Core Team deliver.
  2. Identify the stakeholders the Core Team need to implement each planned Release.
    • These should form the Core Team’s actual Extended Team.
  3. Create a contact list.
3Define specific dependency
  1. Define why each member of the Extended Team is needed.
    • I.e., the Core Team’s specific dependency on each one.
    • Specific deliverables, expertise, decisions/authorisations, etc.
  2. Draft a preliminary dependency log defining the requirements for each relationship
4Build relationship
  1. Review & align the Core Team’s plans.
  2. Identify areas where the Core Team need their support.
  3. Agree the Core Team’s detailed requirements.
    • Scope, deliverables, responsibilities, quality, etc.
  4. Confirm their capacity & ability to meet the Core Team’s requirements.
  5. Agree how to engage with each other.
    • Contacts, meetings, escalation, etc.
    • Scheduled dependencies – events, alignment, roles, etc.
5 Set up mechanisms
  1. Set up the Core Team’s mechanisms for managing this relationship.
    • Responsibilities, schedule, etc.

Detailed process

#StepByOutputInstructionsNotes
1Create Context Diagram.Iteration Lead.

Product owner.

Team.

Context Diagram
  1. Create a map of the organisation, showing all functions, SMEs, authorities, etc., that may affect the Core Team’s work.
  2. These are potential members of the Extended Team.
2Identify Core Team’s stakeholdersIteration Lead.

Product owner.

Team.

Contact list
  1. Review the Context Diagram to identify which of these can affect how – or how well – the Core Team deliver.
  2. Identify the stakeholders the Core Team need to implement each planned Release.
    • These should form the Core Team’s actual Extended Team.
  3. Create a contact list.
3Define specific dependencyIteration Lead.

Product owner.

Team.

Draft dependency log
  1. Define why each member of the Extended Team is needed.
    • I.e., the Core Team’s specific dependency on each one.
    • Specific deliverables, expertise, decisions/authorisations, etc.
  2. Draft a preliminary dependency log defining the requirements for each relationship.
4Build relationshipProduct Lead.

Iteration Lead.

Team.

Relationship agreements
  1. Review & align the Core Team’s plans.
  2. Identify areas where the Core Team need their support.
  3. Agree the Core Team’s detailed requirements.
    • Scope, deliverables, responsibilities, quality, etc.
  4. Confirm their capacity & ability to meet the Core Team’s requirements.
  5. Agree how to engage with each other.
    • Contacts, meetings, escalation, etc.
    • Scheduled dependencies – events, alignment, roles, etc.
It is important that all relationships should be based on explicit agreements. It is likely that, when either side comes under pressure, their respective commitment is likely to be reinterpreted unpredictably.

Agreements do not need to be formal, but they do need to include:

  • Agreed responsibilities for verifying any information or materials that pass between the two sides. This should include:
    • Who will verify what.
    • What are the relevant quality requirements.
  • If necessary, a schedule of events:
    • Milestones.
    • Final delivery.
  • Liaison meetings:
    • To track progress.
    • To identify changes.
    • To adapt the relationship as needed.
5Set up mechansismsIteration Lead.

Team.

Management mechanisms
  1. Set up the Core Team’s mechanisms for managing this relationship.
    • Responsibilities, schedule, etc.
Typical mechanisms:

  • Dependency log.
  •  Calendar:
    • Liaison with Extended Team members.
    • Dependency events (review, delivery, etc.).

Issues & risks

What are the key concerns in making a success of this practice?

  • Members of the Extended Team will have their own goals, priorities, processes, timescales, authorities…
    • The Core Team needs to understand and respect these.
  • Simply because it lies outside the Core team, the Extended Team represents a permanent risk to delivery.
    • This may case delays, conflicting priorities, etc.
    • If at all possible, skills or experience the team finds it needs regularly should be brought into the Agile team.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?