Create a Context Diagram

Create a Context Diagram2017-10-12T22:05:27+00:00

Create Context Diagram

Context

Summary

Provide a summary of this practice.

Creating a Context Diagram provides a map of the parts of the organisation as a whole that may affect how (and how well) the Agile team delivers.

Purpose

What is the overall goal or intention of this practice?

Creating a Context Diagram is used:

  1. to support Building an Extended Team.

SLA

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

  • Context Diagrams should be created or revised at the beginning of each Release.
  • The Context Diagram should be actively verified and maintained throughout the Release.

Exit conditions

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

Creating a Context Diagram is complete when it provides enough information needed to create and manage the Extended Team.

Entry conditions

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

N/a.

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
1Review generic Context Diagram.
  1. Review the generic Context Diagram.
  2. Update it to reflect your own organisation.
2Identify interfaces.
  1. Starting from your location on that diagram, identify your interfaces.
3Identify specific groups.For each group, confirm:

  1. Is there a single group or are there many (e.g., for different types of policy, or perhaps you work for multiple business units)?
  2. What is their official name (a surprisingly important fact in large, complex corporations)?
  3. Who is their manager or lead?
  4. What is their official role or function (independently of what you want from them)?
  5. What (if anything) needs to pass between you (information, expertise, decisions, etc.)?
  6. What, if any, is your current relationship with them?
    • What is the actual interface?
    • Will it meet your future needs?
  7. Who is your Single Point of Contact with them?
    • What are their contact details?
  8. If you feel you need a regular relationship with them, are there regular newsletters you need to receive or events you need to be involved in?
4Contact groups.
  1. Contact each group.
  2. Verify their interface.
5Communicate Context Diagram to team.
  1. Make sure that your team know how this relationship works – it will, after all, directly impact their work.
  2. Display the finalised Context Diagram somewhere highly visible to the whole team.

Detailed process

#StepByOutputInstructionsNotes
1Review generic Context Diagram.Iteration Lead.

Product Owner.

Team.

Draft Context Diagram
  1. Review the generic Context Diagram.
  2. Update it to reflect your own organisation.
2Identify interfacesIteration Lead.

Product Owner.

Team.

  1. Starting from your location on that diagram, identify your interfaces.
3Identify specific groupsIteration Lead.

Product Owner.

Team.

For each group, confirm:

  1. Is there a single group or are there many (e.g., for different types of policy, or perhaps you work for multiple business units)?
  2. What is their official name (a surprisingly important fact in large, complex corporations)?
  3. Who is their manager or lead?
  4. What is their official role or function (independently of what you want from them)?
  5. What (if anything) needs to pass between you (information, expertise, decisions, etc.)?
  6. What, if any, is your current relationship with them?
    • What is the actual interface?
    • Will it meet your future needs?
  7. Who is your Single Point of Contact with them?
    • What are their contact details?
  8. If you feel you need a regular relationship with them, are there regular newsletters you need to receive or events you need to be involved in?
This step is necessary only because in many organisations the structure and functions are far from clear and often poorly documented.
4Contact groupsIteration Lead.

Product Owner.

Team.

  1. Contact each group.
  2. Verify their interface.
 Who should contact each group generally depends on:

  • The specific purpose of creating this relationship.
  • The relative status of the individuals whose cooperation is needed.
  • The nature of the cooperation.
    • If authorisations or resources or other special effort will be needed, a senior contact (typically the Product Owner) may need to make the case for collaboration.
    • If only routine actions and contributions are required, a more ‘horizontal’ contact may be appropriate.
5Communicate Context Diagram to teamIteration Lead.

Team.

  1. Make sure that your team know how this relationship works – it will, after all, directly impact their work.
  2. Display the finalised Context Diagram somewhere highly visible to the whole team.
  • The Context Diagram should be displayed in the team’s normal working area.
  • This will both allow them to become familiar with the details and cause them to raise issues where unexpected relationships or responsibilities occur.

Issues & risks

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

  • Many organisations fail to maintain organisation charts, responsibilities, etc. As a result, it is important that the team should verify that they are dealing with the right groups and functions:
    • Directly with those groups and functions.
    • Explicitly, and in terms of what they need them to do for the 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?