You don't need to define the roles if everybody knows who should be in the driver's seat.

You don’t need to define the roles if everybody knows who should be in the driver’s seat.

There are four basic topics that Agile charters address. Each category addresses different concepts that are important to help a team or a team-of-teams in a scaled effort to act in coordinated manner.  The four categories are:

  1. Envisioning Success
  2. Behavior
  3. Timing
  4. Constraints

There are any number of ways to address the concepts in each of the categories, and often a few teams and organizations use multiple approaches to address a specific concept. For example, some charters include a release plan and a set of milestones, both sections provide guidance on when things will happen during a project. Summarized below are the most common components used to address the concepts of behavior and timing. Each item includes a quick definition and a recommendation whether the component should be used for either a scaled Agile or team charter. Yes means the component should typically be used and no means don’t.

Defining Behavior

The charter provides a platform to explicitly identify and agree on a set of expectations for how individuals and groups will behave and interact. Defining behavior as a team will reduce the potential for conflict while promoting positive behavior. Components in this category often include:

  1. Values and Norms reduce conflict and promote positive behavior. Norms can include: respecting team members, not talking over others, showing up on time, and living up to commitments. Everyone involved in the effort needs to brainstorm, discuss, record and then commit to living by the norms. Everyone needs to be able to commit to the norms or the team will struggle with institutionalizing the norms.
    1. Scaled Charter Recommendation: Yes – Most scaled teams of teams include a mixture of people or teams that do not work consistently together therefore establishing a baseline of values and norms is useful for guiding “good” behavior.
    2. Team Charter Recommendation: Yes – Establish team norms when a team is formed. Teams should refresh norms during each team planning session; this will capture any evolution in norms and make sure norms are remembered.
  2. Roles define who does what, to whom they do it and potentially when they do it.
    1. Scaled Charter Recommendation: Yes – Scales Agile frameworks often have more roles than a standard team. Examples in SAFe include the release train engineer, product management personnel (different from product owners), system architect and the DevOps team, etc. Document the roles in order to establish a consistent and transparent understanding of the role.
    2. Team Charter Recommendation: No – The size of a normal Agile teams makes verbally sharing roles (even if they change) easy and effective. At a team level documenting roles generally generates shelf ware. If a roles document is needed, the team is probably too big. Break the team up rather than creating a document.

Timing data provide everyone involved with effort with an understanding of when events are anticipated. Timing data can include release schedule and strategy, sprint cadence, common event timing and any outside date constraints.

  1. Release Plans deliver tactical and strategic information to a team, team-of-teams and stakeholders. Tactically, the release plan, which is revisited every sprint, answers the questions of what will be delivered in a release and/or when the release will be delivered. On a strategic level, the release plan provides a product owner with a tool to understand (and communicate) what the project has and is going to deliver to support their organization’s investment plan.
    1. Scaled Charter Recommendation: Yes – The release plan (and by extension release planning) creates alignment, generates agreement and sets expectations. The release plan provides scaled Agile efforts with a tool to help everyone involved in the effort move in the same direction.
    2. Team Charter Recommendation: Yes (Mostly) – A release plan provides the team with a longer-term planning platform. Teams that have plans for more than a single sprint should develop a release plan to help guide the effort.
  2. Milestones are classically used to identify a specific event or point in time during a project or product life cycle. In a classic waterfall flow the completion of an end of phase review would be a typical milestone. Hitting the milestone would provide evidence of progress. A statement of development cadence (how many weeks in a sprint), demonstrations and release plans will suffice for a formal list of milestones in a charter.
    1. Scaled Charter Recommendation: No
    2. Team Charter Recommendation: No

Each component in the behavior and timing categories addresses a different piece of information that someone thinks MIGHT be needed. The problem is that everything that someone thinks might be needed charter will approach telephone book size in a hurry.  As with the envisioning success, there are some components that every effort should address. For example, most every effort should have a release plan and EVERY group should define and commit to a set of norms. In general however, every team or team-of-teams should decide what information they should capture in addition to a release plan and behavioral norms.