Team Charters

When launching any improvement initiative, the first step is typically forming a team that can get down to the work of getting the job done. To get things off on the right step, I cannot emphasize enough the importance of a team charter. This is true for new agile teams, quality teams and any improvement initiatives when more than one person is needed to get results.

Why, because creating a charter makes sure that proper thought is devoted to the define the problem, set goals, scope and approach, and identify the people and other resources that are necessary to be successful. This simple step forces initial action that sets teams up for long term success.

The format for a charter should be quite simple. Typically, they are written with the following headings:scroll_charter

  • Team Name
  • Problem Statement/Business Case (why team created)
  • Scope (what will and will not be addressed by team)
  • Team’s Customers and their needs (how will the team define success)
  • Team Leader (& champion/sponsor if different, & governance if needed)
  • Team Members (with expertise and time commitments for each)
  • Specific Objectives and How Measured (updated monthly or quarterly)
  • How you will work together (methods, meetings, norms, expectations, guiding principles)
  • Plan (initial team duration, activity backlog/tasks, milestones, meeting schedule, stakeholders and communication expectations – updated as needed)
  • Resource needs (other people, budget, tools, etc.)

The charter creation process should start by having sponsors designate an initial team for the initiative. This team builds each of the above bullet points collaboratively and works with the sponsor and others as needed to gain agreement. Having a team charter at the end of this exercise documents and communicates a team’s purpose. More importantly, the process of creating and maintaining the charter builds understanding of and broad commitment to that purpose.

10 comments

  1. Extremely great content. I actually basically became aware of your blog site and desired to tell you that I’ve quite liked looking through your blog and reports. Nonetheless I’ll be following your feed and I hope to browse your blog again.

  2. I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!

  3. Thanks for the comment. I appreciate the insights. I like your addition of specifically how they will work together.

    To your last point, writing it down is sometimes necessary to aid agreement and communication. If you can achieve those objectives without paper – go for it. I fully agree that the process is more important than the output and simplicity is key. On the other hand, a team that works together for a long time may need a way to store their thoughts about why they exist to keep them focused. The last few bullet points are really planning steps and should eventually be integrated into whatever structure you use day-to-day whether it is a card system, spreadsheet or other work management application.

  4. I agree that it is important to have a team gather and talk about these things. They need the product owner/customer to speak about why they were chosen and brought together. They need to understand the intention of their mission and responsibility, but acknowledge it will shift and change over time. They need to get to know each other (team building activities?). They should have an idea of how they will be measured and what resources they have available.

    Do these need to approached in a formal process with a charter written on a document… probably not. (who’s going to update/read the document later?) And, shouldn’t the sponsor be part of that process?

    Also, one thing I would suggest be added to this list (at least more explicitly) is the team’s agreements to each other. How will they handle failed tests or failed builds? Are they committed to pair programming or TDD? Are customer demo’s done at sprint review or throughout the iteration? Do standing meetings start on time or when everyone is present? Without these agreements, the team won’t be in sync with one another.

    Good post… I’m supportive of the concept and need, just not the full formality. I only like writing documents when I know someone will read them later.

Leave a comment