Contents
Overview- Introductions
- Team Description
- Stakeholders
- Mission
- Code of Conduct
- Roles
- Team Processes
- Work Processes
Overview
At this point you are ready to begin creating the Team Charter. Tell members as often as needed that the team is not creating a book, just a “team constitution” of a few pages, much of it bullet and numbered lists. Also remind them the charter can and will change over time, so there is no need to get too hung up on specific decisions or wordings. Everything can be revisited. The goal now is to deliver the first iteration. Again, the sections below explain their linked steps, meant to be done within the Self-Directed agile team meetings.
Introductions
In most groups people can work together for many years and still occasionally find out interesting facts they did not know about others’ backgrounds and interests. Knowing each other well as people reduces team member conflicts, both by building personal bonds and providing explanations for behaviors.
For example, if you know someone has a child with special needs, that person’s desire for more worktime flexibility than the average parent makes sense. Also, if you do not know everyone’s background, you may not be aware of “hidden” skills on the team, or may resent it when someone speaks as if they are an expert on an issue (because you don’t know they are!). And different understandings of the same job title can cause misunderstandings.
It will help the teaming effort immensely for each of you to fully understand the history of the others. So even though some or all of you may know each other well, start with detailed introductions.
⇒ Steps: Make Introductions
Team Description
What is this team? In one or two sentences, what job types make up this team, and what do or will you do? You are not looking for a mission statement, but a factual description of the team. This is the first step to making sure everyone is working toward the same ends. Your discussion may turn up some differences in how you view the team.
Example: “The ER Publications Team is a self-directed work team comprised of technical editorial, design, and production staff supporting the Environmental Restoration Project.”
⇒ Steps: Write Team Description
Stakeholders
The term “stakeholders” is business jargon for everyone affected by a team’s efforts. It points out that the people you provide deliverables to are not the only ones with an interest in how well you function—in other words, you may have more “customers” than you realize! Communicating with everyone affected by your team the way they want you to, and especially getting input from them when making decisions that will affect them, will reduce external conflicts. This also improves your decision-making and customer satisfaction by getting multiple perspectives, and thus raises the team’s reputation in the company.
Create a list of stakeholders for the Team Charter, specifying the groups or titles that fit at least these five categories:
- Direct customers—The first people to receive the output of your work, whether in or outside of the company.
- Indirect customers—People who receive the output of your direct customers, if you don’t connect directly with an external one. Keep working down the chain, and you should be able to connect any team to the end user: “paying customers” for businesses, “affected citizens” for government agencies, “members” for clubs and professional organizations, and “clients” for nonprofits.
- Management—Managers who will be affected if you do not do your jobs well. When naming these, use titles, not names. Start with the team’s manager, and go all the way up the hierarchy to the head of the company.
- Owners—Those “considered to have rights or obligations of an owner regardless of legal title.”[1] Even if yours is not a private company, it has owners. For a corporation, the owners are the stockholders. For a government, they are the taxpayers. For a charity, you might consider the owners to be the volunteers or the donors or both.
- Peers—Organizations in the company that are not “customers” as defined above, but still depend on your organization to do well. For example, if a team is the first line of support for customers calling for help, a smaller second-line group would be overwhelmed if the first team could not solve most customer problems.
⇒ Steps: List Stakeholders
Mission
Overview
A lot of people are cynical about mission statements. That may be because a lot of companies come up with lofty statements that are not very specific, or the companies never do anything to back those statements up. A survey of 1,300 workers across the United States found that 48% only “sometimes” or “rarely” used mission statements to guide their actions. Reflecting this cynicism, the president of a multibillion-dollar construction company said: “When I was told we needed a mission statement, I thought it was just a lot of MBA jargon.
“But,” he went on to say, “it’s been a powerful tool to get our people working and moving in the same direction.”[2] One major study found in 1996 that companies adhering to mission statements over the years “outperformed the general stock market by a factor of 12 since 1925.”[3] And the employee survey mentioned above found that 60% of employees who wanted to stay with their employers used mission statements to guide their actions, versus only 30% of those thinking of leaving their employers.
There are very practical reasons for a team to have its own mission statement. A statement can:
- Prevent overlaps of effort between your team and others in the company.
- Ensure that your work is in line with the company’s goals.
- Remind you why your team exists, building a stronger sense of purpose.
- Make your job feel more worthwhile and purposeful.
The mission is the only item that should appear on both the Team Charter and the Continuous Improvement Plan, thus tying them together.
There are different kinds of mission statements. One kind is a grand statement of your core reason for existence, something always there regardless of what your goals are, such as these old examples:
- International Minerals and Chemical Corporation—“To increase agricultural productivity to feed the world’s hungry.”
- Wal-Mart—“To give ordinary folk the chance to buy the same things as rich people.”
- Walt Disney—“To make people happy.”
- Nike—“To experience the emotion of competition, winning, and crushing competitors.”
Or, a mission can be a statement of what you want to become—a single major goal for ten or more years down the road. Here are some even older examples:
- Boeing in 1950—“Become the dominant player in commercial aircraft and bring the world into the jet age.”
- Stanford University in the 1940s—“Become the Harvard of the West.”
- Nike in the 1960s—“Crush Adidas!”
Some people would call the first kind of statement a mission and this second type a “vision.” It does not really matter which type you choose, and in time you may want to have both. Whichever type you choose, the keys to these statements are that they are relatively specific, and most importantly, they are interesting. The Nike examples added the fun of sport competition to working for a sporting goods company. So as you work on a mission statement, go for something big—what a couple of researchers[4] called a “Big, Hairy, Audacious Goal.”
Guidelines
- Stay aligned—Keep the missions of your company and division(s) in mind as you create the team’s mission. If they do not fit, the company may not be as likely to provide the resources you need from it over time.
- Balance the bar—Most teams make one of two big mistakes when setting their mission and related goals: They set them too high, guaranteeing failure; or they set them too low, guaranteeing success. The latter does not sound too bad, but the problem is, low goals are boring. If you know you can jump over a six-inch bar, and that is all you need to jump to win, how excited will you get about winning? What you want is a mission you can achieve, but might not.
- Boundaries—Another reason teams fail to achieve missions and their supporting goals is the failure to account for barriers they cannot change. Keep in mind:
- Guidance from your manager.
- Responsibilities that cannot be taken on or passed off by the team, at least in the short term.
- Resource limitations that may require time to overcome, such as skills the team lacks or equipment it needs. Setting a mission that would require added resources over time is fine, but it should be one you can make progress on until you get them.
- Simplicity—Keep your mission statement as short as possible, and definitely to a single sentence. Every time you add an “and,” you double the chance of failure. Maybe you can “Change the way people think about toilets,” and maybe you can “Eliminate tile scum forever,” but the odds of doing both may send your mission down the drain.
⇒ Steps: Choose a Mission
Code of Conduct
Like missions, lists of values or team rules are viewed with a lot of skepticism, for many of the same reasons. But, again, the fact that they have been misused or ignored by others is no reason to dismiss their importance. Every formal grouping of humans develops a set of rules for dealing with each other, some written, some not. Governments have laws and regulations; civic and religious groups have bylaws; and kids regularly declare to their playmates, “You can’t do that!”—referring to some rule that may or may not have been spoken out loud. Phil Jackson, who coached two National Basketball Association teams to national championships in the U.S., had a startling quote on the role of a value to one of them: “More than anything else, what allowed the Bulls to sustain a high level of excellence,” he wrote, “was the players’ compassion for each other.”[5]
Values or behavior rules, like the mission statement, should be specific and practical. As two teamwork researchers[6] put it, the values must clarify what members “expect and want from one another, what they prefer” in how they work with each other.
Of course, this list can and should be changed as the team develops. If at some point any one of you feels a value and/or its behaviors are not working, bring it up. If you want to add one, bring it up. If a new member joins the team, ask him or her if there is a behavior important to that member, and find a way to incorporate it into the list. Obviously, you do not want to turn the list into a 200-page legal document, but make sure the values are working for you, not the other way around. The one overriding rule is this: If you do not agree with a value, do not simply violate it. Raise the issue with the team.
Later you will create a team procedure for using these values to address team member disagreements.
⇒ Steps: Create Code of Conduct
Roles
Overview
Sometimes team conflicts erupt over, “Who is supposed to do what?” Often that question is really, “Who is supposed to tell whom to do what?” Despite what the official organization charts say, lines of authority become blurred based on factors like seniority and technical expertise. Clarifying the official job roles of each team member pays major dividends by eliminating time losses caused by people duplicating effort; confusion over who is responsible for a function; and the conflicts that arise from both. Also, becoming self-directed requires figuring out how to adapt each function to spread out administrative duties so they best serve your collective needs. Part of that process is defining the administrative roles and how you wish to handle them as a group.
In the next two sections, you will create a Role List describing job-related and team-related functions.
Work Roles
To clarify “who does what,” include your work roles and a few primary tasks for each in your charter. For an example, see the “Sample Team Charter.” In it, the team defined the two job roles of its members: Editor and Compositor (page designer). In the course of creating this charter, the editors learned they were causing extra work for the compositors by placing graphics in the documents in incorrect ways. The compositors had to remove the graphics, fix related formatting issues, and re-insert the graphics. To eliminate the inefficiency, the team agreed to add this line under the Compositor role: “Inserts figures, photographs, and tables.” The related problems ceased immediately.
As you can see, their charter also made clear that members shared the duty, “Manages document files and version control.” This meant no one could rightly claim during a crisis, “That’s your job!”
For the charter you do not need the level of detail used in formal job descriptions. But discussing your work roles can expose the root causes of problems the team may be having. To spur the discussion, create a list describing the critical tasks and decisions of each job role represented on the team, focusing on possible overlaps or gaps between roles.
On most teams there will be fewer job roles than members, since more than one person will fill the same role. If every member has a unique job role, your team may be at risk for serious work delays due to the one expert on a topic being out, or worse, leaving the team (the “Won the Lottery Syndrome”).
⇒ Steps: Define Work Roles
Team Roles
Overview
Before continuing, the team should review the Administrative Tasks Checklist from the manager if a list was provided, to see which of the roles the manager wants to turn over to the team and when. If not, I recommend assuming the team will handle all of them until told otherwise—that is the essence of self-direction! The team will fill the Facilitator and Scribe roles regardless.
Facilitator
As detailed on the “Meeting Facilitation” page, the facilitator:
- Creates the meeting agenda, which includes making sure all action items and objectives that came due since the last meeting are covered.
- Ensures the team gets all the information and handouts it needs before the meeting.
- Runs the meeting according to the agenda and rules that ensure time is not wasted.
- Leads problem-solving efforts and builds consensus behind decisions.
- Creates new action items.
In a self-directed team, this position must rotate among members. If one person holds it, there is a tendency for people outside the team—and sometimes inside of it—to start treating that person as “the boss.” Plus, well-documented changes in the brain occur when someone gains a position of social power over others, changes like reduced empathy and less ability to listen, which would hurt team performance.
Ideally, all members will take on the role. People tend to cooperate with the facilitator more when they know they will need the same cooperation themselves some day! FuSca recommends you rotate every one to four meetings, but not more often than weekly. That way no one feels overwhelmed by the extra duties.
Please note that I have seen introverted or shy people handle these duties just fine—speaking as an introvert myself. Though at first they were often hesitant, all adapted well, and some actually preferred being in the role, because it defined easy ways to add value during meetings. Some extraverts have struggled just as much, because they had to rein in their urges to dominate the conversation.
Obviously, no one who really resists should be forced to do the role. When I have trained SDWTs I push reluctant members to “just try it” once, saying they can recuse themselves from future rounds if they really hate it. None have.
⇒ Steps: Define Facilitator Role
Scribe
The scribe makes sure there is a written record of the meeting. You do not need detailed “minutes,” just a quick summary and the resulting decisions. Notes are critical to ensure the team keeps moving forward efficiently. Research shows our memory is less reliable than we realize. Without meeting notes, conflicts often arise over what was decided, and discussions of postponed topics may re-cover old ground.
If you adopt (or are already using) Scrum or Kanban, all of this information can be recorded on the user story cards. In that case, the Facilitator will record it, and the Scribe role is not needed.
The notes only include:
- Topics covered.
- Agreements reached.
- Action items, listing for each the specific task, report date, and responsible person, as described on the “Meeting Facilitation” page.
Note: If you are using FuSca Light, the spreadsheet provides a useful format. - Parking Lot issues not yet addressed.
After the team gets going, you can decide what level of detail you want.
Consider rotating this role, too, because it takes time and prevents the scribe from participating fully in the discussions. If some of you are really uncomfortable with writing, you can solicit a group of volunteers and rotate the job among them. But if you do that, the rest of you should expect to do more of something else, such as taking on more action items.
If everyone takes on the scribe role, the rotation schedule should follow the facilitation schedule. In other words, if you rotate the facilitator role weekly, have next week’s facilitator serve as this week’s scribe. That way they are fully up to speed on what the team is doing, so it is a little easier to put an agenda together and gather needed materials.
⇒ Steps: Define Scribe Role
Other Roles
Teams have defined many other roles, such as Liaison, Quality Manager, or Point of Contact. In reviewing the Administrative Task Checklist from your manager, some that you need may become obvious. Now or as your team thinks of roles that would be helpful, add them to the Team Charter.
⇒ Steps: Define Other Team Roles
Team Processes
Overview
Your team may not need to define all of the team (or “administrative”) processes in the rest of this section. You need a Work Management procedure, and I strongly recommend the “Member Conflicts” procedure. But the immediate need for the other procedures below is open to discussion based on team type, customer needs, the Administrative Tasks Checklist, company policies, and so forth.
Work Management
Any systematic approach to planning your team’s work is better than no system. The “Agile for Entrepreneurs” chapter explains the value of a work management system. If anyone on your team objects, go over the first section in a team meeting.
That chapter presents a light, simple approach to planning and tracking your work. You may choose to adopt that for now, and then evolve it to your needs. If you are using a method like that, Kanban, or Scrum, you can simply include a link to existing information from your charter and note whatever changes you are making. (As explained in “Trying the System,” if you have never used that method before, follow it exactly as described at first. Learn how to ride the bike before you take off the training wheels!)
But the core idea behind Self-Directed agile is that you can create your own method for identifying and tracking your work. The Project Management Institute has spent many years detailing all of the outputs customers or stakeholders could possibly require, and the intermediate steps required to get there, in the Project Management Body of Knowledge. Fortunately, these can be boiled down to this set specific to agile teams:
- Identifying—Determining what work needs to be done in the near future (see “Gather Requirements”).
- Prioritizing—Ordering it based on the value it provides your customer (see “Organize the Work”).
- Clarifying—Getting specific about the high-priority items (see “Groom Stories”).
- Assigning—Deciding who will work on the items you are ready to start.
- Tracking—Monitoring progress to predict and prevent problems.
- Communicating—Providing information to stakeholders on status and progress.
- Delivering—Handing the work off to whomever needs it, whether customers or another group in your organization.
In established enterprises, most or all of these questions may already be answered. That is, you might have a Project Management Office with a set of required steps and “artifacts.” In that case, you probably have a project manager assigned and only have to work out how to provide what that person needs from you with as much agility as possible. Depending on how rigid those policies are, your team may not be allowed to become agile, but at least it can gain the benefits of empowerment for other aspects of team performance and member satisfaction.
⇒ Steps: Create Work Management Procedure
Member Conflicts
Come up with a “safe” method of raising concerns about another team member. People must feel comfortable making mistakes with each other—that is how we grow, by learning from our mistakes. Direct communication about mistakes is best, but takes courage and sometimes does not work. In any case, it is important to have a method within the team for helping members talk things out.
One way to do so is through a third party in the role of mediator. You could assign a mediator within the team; have a mediation role that people volunteer for and/or rotate through; or allow the parties to agree on a mediator. Perhaps, too, you would like the issue to come to the team as a whole if mediation fails, rather than going directly to the boss. See the “Mediation Procedure” on the Radical Agilist site for an example of how mediation works, and the “Sample Team Charter” to learn how one team approached this issue.
Keep in mind that anything the company could get sued for—sexual or religious harassment, racial comments, potential violence, and such—must be raised with your Human Resources Department immediately. Otherwise you also risk team members landing in a courtroom.
⇒ Steps: Create Member Conflicts Procedure
Reporting Progress
The team manager and other stakeholders need to be informed what you are doing as a team. Create a procedure that incorporates both manager and team desires regarding the who, what and how of these communications.
If you are already using Scrum, simply invite them to the Demonstration Ceremony and provide “View” access to your Agile tracking tool, if online. Otherwise, as mentioned before, a standard method is to send a “Manager’s Report” on a regular basis that indicates topics discussed, decisions made, and questions for the manager.
⇒ Steps: Create Progress Reporting Procedure
New Member Orientation
When you bring a new member onto the team, remember what it is like to start a new job. Even if the person was already an employee of the company, they might have to adjust not only to the job, and possibly to working on a self-directed team, but to working on this team. The team and the individual are best served by striking a balance between helping the new hire fit into the existing culture of the team and giving the team the benefits of a fresh perspective.
Create a procedure for easing the transition by giving him or her a chance to review and request changes to the Team Charter and Continuous Improvement Plan.
⇒ Steps: Create New Member Orientation Procedure
Other Procedures
The steps for this chapter include a set at this point for considering what other procedures you want to create.
⇒ Steps: Create Other Procedures
Work Processes
If your company requires you to document your work processes in what commonly are called “standard operating procedures” (SOPs), review those documents for changes required by your new empowerment and agility. You may need to replace the manager as the approver, for example, and to reflect the decisions you made earlier under “Work Management.”
Even if not required, you may want to consider some light procedures covering these situations to save you time in the long run:
- All major deliverables the team provides routinely, to use in process improvement;
- Complex jobs done only on occasion, so you do not lose time recalling how to do them; and
- Likely emergency situations, because you do not want to be figuring out what to do while in a crisis.
Example: How would your team meet its obligations if the power went out for more than a day?
However, bear in mind my “80/80 Rule.” Except as required by law, certification bodies, etc., only do routine procedures covering 80% of the team’s labor time, and only make any of them detailed enough to cover 80% of the times the process is used (allowing people to flex when circumstances warrant it).
⇒ Steps: Define Work Processes
↑ Self-Directed agile | ← Kick Off Process | → Do a Little Planning
Full references are in the Teamwork Bibliography.
[1] The definition of an “equitable owner” per Dictionary.com.
[2] Quoted in Martin 1993.
[3] Collins & Porras 1996.
[4] Ibid.
[5] Jackson 1995.
[6] Robbins & Finley 1995.