Hey Brad I just migrated to a different project and as such am joining a new team. This new project has already been started before I joined and I’ve noticed that this team does things differently then my old team; Which is causing some loop backs because I’m not aware of what this team does differently until I do something the way my old team did it and someone on this team tells me I have to do it again the right way. I brought this up with my manager and he suggested I tell the team about something called a Team Charter.

What the heck is a Team Charter?

Well a Team Charter is just a document, don’t let the term “charter” fool you into thinking its anything more formal then that. It describes what the team has agreed to be the process and rules of conduct that the team will use to govern itself. It also spells out the nature of the work the team has been commissioned to do and the expectations for the results at the end of the project.

There isn’t any real format needed, it could be a pretty document or a simple bullet point list; It could be digital or analog. Whatever form the charter takes it should be clear, concise, and accessible to all members of the team (pigs and chickens). It should also be dynamic, it should grow with the team; changing as the team becomes more mature.

What is the Purpose of the Charter?

The purpose of the Team Charter is to have all the agreed upon rules and processes in one spot so that team members can refer to it as needed. It also serves the purpose of helping new team members get up to speed by giving them a guide to how the team functions without relaying on a brain dump during their welcome to the team meeting which is prone to forgetting to pass on critical info, not asking the right questions, and information overload. It also helps to remind the team why they exist in the first place since it defines the goal of the project and what the team is expected to produce.

In short its purpose is to be a record so team members new and old can refer to what has been agreed upon and what the companies exception for the team is.

Who is the Team Charter For?

The key word in the name of the charter is Team. The Team Charter is made by the team for the team.

When I first started telling people about Team Charters I was a little worried that some one would take that idea and turn it into a group wide doctrine; Thou shall do this because it says so in the group charter regardless if it applies to your project/team. I mean I’m all for cross project consistencies but different teams have different dynamics and goals. How the team operates should be allowed to adapt to the team vs. having the team adapt to a rigid process.

So to that a Team Charter should be created by the team for the team. When the project is over and the team disbanded the charter is thrown out as its no longer needed. When a new project comes along and a new team formed a new Team Charter should be drafted.

When is the Team Charter written and who creates it?

The Team Charter should be created at the start of a project during the project kick off meeting. It should be one of the first things the newly formed team collaborates on. Not only is it good to have all the rules and expectations set right off the bat but it allows the team members to get to know each other by having them sit down together and collectively define rules, processes, and goals before the official start of the project. The team leader or a selected scribe would physical write down the charter but it should be created by the entire team (pigs and chickens). A Team Charter should be enforced by the team but not imposed on the team. That is the rules and processes should come from the self-organized team and not from the Team Manager or Team Sponsor.

When is the Team Charter updated?

The Team Charter should not be carved in stone, teams grow during the course of a project and as such what once worked at the start of the project might no longer work mid way through. What the fledgling team choose as goals and processes might no longer suite the project and need to be amended. The Team Charter should be allowed to be amended as needed at any point during the project. To allow for this ensure your charter can support change, if analog (ink and paper) make sure to leave room for amendments and if digital make sure not to lock it down (I’ve used a Wiki page before since Wiki’s are easy to update and some support revision control so amendments can be reviewed later on).

If your using an iterative process like SCRUM the sprint retrospective is an excellent place to open up the Team Charter and make amendments as needed (again why a Wiki page is a good format as you can quickly update it while in the meeting).

What goes into a Team Charter?

The type of information that can go into the team’s charter are but not limited to:

• How the team members roles and responsibilities are defined.
• How the teams work relates to the organizations goals.
• When the work is expected to be finished.
• What it is the team will deliver.
• How the team will measure success.
• How the project will benefit the company.
• Which resources will be available to the team.
• What kind of decisions the team will have the authority to make (RACI).
• What are the major milestones.
• What are the risks and how they will be addressed.
• Definition of common terms.
• A description of the different meetings the team will use during the project. Here you would explain how the stand up meetings will work or specify who will attend and how often bug scrub meetings are held.
• Explain things like how the team will do code reviews if at all and detail out the bring donuts for breaking a build rule if your team is so incline.
• Most importantly the team should list out their own goals for the project. The team can have their own goals that they can rally behind other then just meeting the dead line. These could be things like achieving X% code coverage, deliver a working prototype in time for a given trade show, or getting all the legacy code under test.

Example

Here is an example of a team charter:

Avengers's Team Charter

1.PURPOSE STATEMENT
This team has been formed to redesign the control software used in our Helicarrier product line.

The current design of the software does not lean itself to automated testing and is to heavily coupled making it difficult to fix issues and/or add new features. Because of this our release cycles are long, our ability to quickly respond to field issues require internal negotiation for approval and our ability to diagnose field issues requires Engineering resources appose to support technicians. Because of this our ability to react quickly to changes in the market is hindered resulting in our product not having the features to remain competitive or the quality to boost our brand image as an organization.

The mission of this team is to redesign the control software to overcome the above mention shortcomings so that we as an organization can offer a quality product so we can remain a leader in the air supremacy markets.

2.TEAM OBJECTIVES
A team is formed to achieve a given purpose; in order to know when the team has successfully satisfied that purpose a team must understand what the goals/milestones are. In the above purpose statement we are defining what the purpose of this team is, here we are defining the goals the team must achieve in order for it to satisfy that purpose.

* TODO - List team goals here
* TODO - List team goals here

3.FUNTIONAL ROLES
Below lists the functional roles that exists within the team. See RACI documents for more details on role responsibilities.

Product Owner (Product Manager): Nick Furry
Primary stakeholder and owner of the product family. Responsible for defining the scope of the project, identifying what features are and are not needed, and has final say to accept or reject the output of the team. Is ultimately accountable for the team’s success or failure.

Team Manager (Program Manager): Natalia Romanova
The liaison between the team and other stakeholders. Responsible in ensuring the team have the resources they required to complete their goals. Able to act as the Product Owner in the Product Owners absence.

Sprint Master: Steve Rogers
A member of the team who also holds the responsibility to ensure that the team charter is abides by, conducting the team meetings and generating reports to measure the team’s progress for the benefit of the Team and the Team Manager.

Team Leader: Dr. Bruce Banner
A member of the team who also holds the responsibility for keep the team on track and working productively as a whole. The Team Leader is responsible to ensuring that the team’s goals are clearly defined in the charter and understood by every member of the team.

Hardware/Software Developer: Tony Stark, Steven Rogers, Dr. Bruce Banner, Dr. Henry Pym, Janet Pym
A member of the team who is responsible for achieving the goals set forth in the current sprint.

4.TEAM PROCESSES
4.1 TEAM MEETINGS
4.1.1 Team Stand-Up Meeting
The team will meet at 0800hrs every morning, except for Sundays, for 15min at the main WAR room for a daily stand up meeting. All members of the team are welcome to attend; Development, QA and the Team Manager are expected to attend on a regular basis.

Each member of the team in attendance will give a brief statement of what they worked on the day before and what their plans for the day will be. Each team member will have 10 seconds to give their update, members exceeding this time limit will be time boxed by the Sprint Master to ensure the stand up meetings don’t run longer then 15min.

The meeting will start promptly at 0800hrs, no sooner and no later to ensure (a) all team members have time to arrive at the meeting location and (b) the meeting is not delayed by late arrivals. 

The status updates will go around the room in a counter-clockwise fashion starting at a randomly selected team member chosen by the Sprint Master; late attendees standing before the currently presenting team member, and therefore have missed their turn, will present at the end.

The meeting will be adjourned by a team celebratory "Go Team".

4.1.2 Bug Scrub Meeting
Bugs discovered during a sprint will be logged by QA but left un-prioritized.

Once a week the Team Manager acting as the Product Owner's proxy will meet with the QA Lead to prioritize the new bugs; bug prioritization is no different then task prioritization and therefore does not indicate which sprint the bug will be corrected in. 

No changes to the current sprint will occur unless a newly discovered bug is found to be severe enough to warrant the change in the sprint contract. If such a bug is found the Team Manager will negotiated with the Sprint Master which item(s) in the current sprint need to be removed in order to not effect the amount of work allocated in the current sprint.

Bugs not found critical enough to warrant a change to the current sprint contract will be added to the product backlog.

4.1.3 Team Planning Poker Meeting
The team will generate estimations on how long any work item will take to complete through a process called Planning Poker. The idea is to generate "Team" estimations; an estimate of how long it will take any member of the team to complete the work. This negates the need to know which member of the team will do the work on day one allowing any member of the team to be able to action the item.

The team will meet as required to conduct a Planning Poker session in order to estimate the work items in the current projects back log.

At least one meeting needs to be conducted prior to the first Sprint Planing Meeting in order to get a better understanding of the realistic time table for the project as a whole. The farther away a task is to actually being worked on the more uncertain the estimate will be; estimates can be refined over time. An estimate given to a work item at the beginning of the project will not be as accurate as the refined estimate given to the item when it is assigned to a sprint.

Planning Poker meetings will be held by the Sprint Master.

A maximum of three Estimation Poker rounds are to be done per work item before the median is used as the estimation value by default if no consensus is found.

Attendees can choose to draw the “Bio Break” card as needed but excessive use of the card will be frowned upon.

All estimates will include the time needed to write unit test.

Any work items that have an estimation value of 10 needs to be broken down into smaller sub tasks. 

The Product Owner or their proxy (the Team Manager) are expected to attend to provide clarification. All items are expected to have some form of estimate; leaving an item with a question mark is undesirable. If clarification can not be achieved a reasonable compromise (median or highest estimate) will be used understanding that the estimate will need to be refined closer to when work will begin on it.

4.1.4 Sprint Planning Meeting
At the start of each sprint a planning meeting will be held to:

* Define the goal(s) for the given sprint
* Define what items the team will commit to completing within the sprint.


In this meeting items will be selected from the product backlog; clarification, re-estimations, and breaking down the tasks into sub tasks can occur at this point if needed. Items added to the sprint backlog constitutes a contract stating that these items will be completed by the end of the sprint.

Assignment of tasks will not be done during the Planning meeting; once the sprint begins team members will self-assign items out of the sprint backlog until all items have been completed.

All members of the Development team are expected to attend, QA team members are welcome to attend as this is where we'll be disusing the expected behaviour.

This meeting will be held by the Sprint Master.

4.1.5 Sprint Demo Meeting
At the end of each sprint a demo will be held to:

* Celebrate and acknowledge the teams success over the last sprint (in this context success limited to the completion of tasks; the "What was done")
* Present the working features to the Product Owner for acceptance.


The Product Owner will either accept the feature (marking the item as Done) or reject the feature returning it to the product backlog.

It is imperative that the Product Owner be able to attend the demo.

The Sprint Master is accountable for making sure the demo is ready although the task of setting up the demo can be delegated to another member of the team.

Time will be allocated at the end of the sprint for preparing the demo, items done during this setup time will not be included in the demo.

4.1.6 Sprint Retrospective Meeting
At the end of each sprint after the demo a Sprint Retrospective meeting will be held by the Sprint Master. The Sprint Retrospective meeting focuses on the process not the product. To reiterate if the team completes the sprint but the Product Owner rejects every item due to changes in the market since the start of the sprint, that fact will have no baring on the relative success of the sprint process. The process can be successful even if the product is not.

The purpose of the retrospective meeting is to allow the team to reflect on the process and as a team come up with ways to improve any part of the process that isn't working. Corrective measures can be long term or short term, once a part of the process is no longer serving a purpose it can be discarded. Project work discussions are unwelcome except as contextual examples to facilitate process discussion.

The prescribed processes followed by the team including this charter will be updated as a result of this meeting.

4.1.7 Project Retrospective Meeting
At the conclusion of the project the team will meet to go over the process followed by the team and the team’s performance throughout the project.

This meeting is not to discuss the general success or failure of the project itself but rather the process followed by the team and the teams own performance as a whole.

The Team Project Retrospective meeting will be held no later than 2 weeks from the official conclusion of the project. The Team Project Retrospective meeting will be held by the Sprint Master.

The goal of this meeting is to celebrate the team’s successes and analyses the team’s failures in an effort to improve on them for the next project. 

4.2 TEAM MEETING CODE OF CONDUCT
The following code of conduct applies to all forms of meetings held or attended to by the team.

* Team members are expected to arrive on time so that the meeting can begin promptly, late attendees can enter the room making all effort not to disrupt the flow of the meeting. The meeting organizer is not expected to recap for the sake of the late attendee.
* The meeting organizer is expected to begin the meeting with a statement to clearly define the purpose of the meeting and the desired outcome. These should also be included in the meeting invention.
* The meeting organizer will present in some form a meeting agenda. Attendees are expected to stick to the meetings given agenda and to limit tangent conversations to after the meeting agenda has been completed.
* The meeting organizer will pay attention to only invite those members of the team that need to attend the meeting. Non-critical members can still be invited but marked at optional to allow them to choose to attend.
* The meeting organizer or a delegated scribe will take down meeting minutes including the action items. The meeting minutes are to be uploaded to the S.H.E.I.L.D. intranet.
* During the meeting only one person will speak at a time; team members will not attempt to speak over others nor will two different conversations be had at the same time.
* Meetings running longer then 1hr will at minimum include a 10min break for each hour of duration over 1hr. Team members are expected to be back from break promptly at the end of the 10min to ensure the meeting can re-start without delay. The meeting organizer is not expected to wait for tarty attendees nor recap for the sake of the late attendee.


4.3 TEAM COMMUNICATION
We as a team will communicate with each other through various means including but not limited to:

* Face to face
* E-mail
* Instance Message
* Phone Calls
* Meetings

Regardless of the form, prompt responses to the messages/inquiries from one another are expected. If a member is unable to complete their tasks as promised, they should advise the group in advance as soon as appropriate so that alternative arrangements can be made.

4.4 TEAM STRUCTURE
Although different members of the team will chair different roles with different responsibilities all team members are able to communicate with any other member of the team regardless of position within the organization. We have a non-hierarchical team structure.

4.5 TEAM DECISION MAKING PROCEDURE
Regardless of the type of decision to be made collaboration will be favored approach. That is that consensus is the goal; however, since 100% consensus can be a difficult goal to achieve the definition of consensus is as follows: Consensus will be considered achieved when 60% of the group is in agreement and the remaining 40% although may not agree will support the decision. This definition is about efficiency and trust; not about exclusion.

A decision once made is final only until the end of the sprint. All decisions are allowed to be readdressed and re-evaluated; a decision must be allowed to die when it has outlived its usefulness. This is at the heart of an organic and agile process; the ability to reassess truths.

4.6 TEAM WORK ASSIGNMENTS
4.6.1 Sprints
The team will organize their work load into sprints; each sprint will consist of 2 working weeks (10 working days) where the start and end dates are denoted by a Sprint Planning, Demo, and Sprint Retrospective meeting.

A working day as defined by this team is considered to have 6 hours, this accounts for time lost for meetings, correspondence (emails, phone calls, etc.) and other unavoidable administrative actives that happen on a day to day other than dedicated work towards a task. The number of working hours in a day may change once the teams actual velocity is better understood.

4.6.2 Sprint Task Assignment
Each member of the team will self-assign work tasks, the Product Owner, Team Manager, Team Leader or Sprint Master will not assign work tasks to team members.

At the end of each Sprint Planning Meeting each member of the team is expected to self-assign one work item to start with. When each member completes their work task they will self-assign another unclaimed work item from the Sprint Backlog.

It is the responsibility of the team as a whole to complete all work items assigned to a sprint. The Sprint Master is responsible for generating and updating reports that describe the team’s current process within a sprint. The Team Leader is responsible for ensuring that the team is able to complete their tasks without impediments.

4.7 TEAM EXPECTATIONS
4.7.1 Attendance at Meetings
Team members are expected to arrive at meetings promptly and attend every meeting where they are noted as a required attendee. If a team member is absent another member is to be selected as a delegate to speak for the absent team member.

4.7.2 Participation
Full participation is expected of all team members. If someone feels that others are not giving it their all, the concerned member will discuss it one-on-one with the other member of the team, offline. If that does not work or the team member is uncomfortable confronting the other team member directly they can bring it up with the Team Leader or Team Manager.

4.7.3 General Courtesy and Respect
All members of the team will respect the different functional areas and roles of each member designated to that function. Team members will address each other with a level of respect and truthfulness.

As a team we agree that all topics even uncomfortable ones are open for conversation in an effort to be open, honest and truthful with each other

4.7.4 Code Review
As a team all development members are expected to submit any code changes to at a minimum two other development members for review. The chosen tool for this is ReviewMyCode. Code changes will not be committed to the source repository until it has achieved sign off by two other development members of the team.

Members of the team requested to give a review of another’s code changes are expected to be fair yet truthful and are expected to turn around a code review no later than 24hrs from the time the review request was given.

4.7.5 Coding Standards
As a team all development members are expected to abide by the Coding Standard defined by S.H.I.E.L.D.

4.7.6 Unit Testing
As a team all development members are expected to include unit tests with all new features, re-factored code or other applicable coding changes. The unit testing framework to use has been chosen to be S.H.I.E.L.D Test for C++ and Asgard-Your-Self for C#. A 100% code coverage is not expected but the team is encouraged to strive for a relatively high code coverage.

4.7.7 Broken Builds
As a team it is expected that any code changes committed to the source repository will not break the CI builds. To facilitate this all build actives will be able to be run locally by the team members prior to committing to ensure that their changes will not negatively affect the build system.

When a build is broken it is the offending team member who is responsible to rectify the broken build promptly. A prolonged broken build hides errors and hinders QA.

The builds will employ continuous integration and attempt to provide prompt feed back to the development team to allow broken builds to be identified and corrected quickly.

So that’s what the heck a Team Charter is; a written document that the team can use as reference to what the purpose of the team is, what the team sponsor is expecting at the end of the project, and what the team agreed on in regards to conduct and process.

Until next time think imaginatively and design creatively