Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book


There are three prominent roles in managing XP:

  • (Project) Manager
  • Tracker
  • Coach

The manager owns the team and its problems. The manager presents a face to the world, forms the team, obtains resources, and manages people and problems.

The tracker helps the team know if it's on track for what it's promised to deliver. This typically is not a full-time role.

The coach helps the team use and understand the XP approach, mentors the team, and helps the team get back on track if it goes "into the weeds." Depending on the size of the team, all three roles might be embodied in one person or in several. A team of moderate size will want separate people, because it can be emotionally hard to be both manager and coach.

What Doesn't an XP Manager Do?

If you're a manager of an XP team, there are several things you won't do, that a typical project manager might under some other discipline.

  • You don't set priorities; the customer does that.

  • You don't assign tasks; programmers do that.

  • You don't estimate how long stories or tasks will take; programmers do that.

  • You don't dictate schedules; the customer and programmers negotiate them.

What's left? That's what we'll explore.

What Does an XP Manager Do?

The manager has several key jobs: face outside parties, form the team, obtain resources, manage the team, and manage the team's problems.

Face Outside Parties

As a manager, you will deal with several parties. The first is "funders": a manager needs resources (including money) to manage. The manager provides the funders with insight into the results of their spending. If a manager can't convince someone to support the team, there will be no team.

You will deal with customers. The customer is the person (or group) willing to claim responsibility for setting priorities and choosing functionality. This may be a user or user surrogate; it could be (but often isn't) the funder. XP requires an on-site customer who will make critical decisions. An XP manager needs to set the customer's expectations appropriately: the team needs a knowledgeable and committed customer.

You will interact with other people as well. This will include people internal to the company (e.g., database administrators) or external groups (e.g., salespeople or specialists).

Form the Team

The manager assembles the team of programmers (through hiring, transferring, or contracting). If you're forming an XP team, the programmers need to know that at the beginning. The manager will help the team bond and help to establish its process. Ideally, especially for a larger team, the team will include a coach.

Obtain Resources

The manager must obtain resources for the team.

You need to create a team workspace. XP values face-to-face communication as the highest-bandwidth way to share knowledge. An open workspace reinforces communication. This space needs to be set up to allow people to pair-program. (This doesn't fit the usual corporate model of cubes.) Most teams will want at least some "personal space" as well.

The team needs hardware and software with which to program. Some teams dedicate a machine to integration and release. Other teams simulate this with a physical token (although it's a lot easier to forget to grab the stuffed animal than to forget to move to the standard machine).

Your team won't be experts at everything: at some point, they may ask you to obtain specialist consulting. XP teams regard specialists as a resource for their learning. Rather than expecting an expert to do a job, it wants the expert to teach the team to do the job.

You'll need miscellaneous office supplies: paper, pens, markers, and of course file cards. (Like anything, you can delegate this job, but the ultimate responsibility is yours.)

Manage the Team

The manager has several responsibilities centered around the team:

Report Progress. The funder, and possibly many other groups, care about the progress and status of your team. Track risks and issues so those people have the information they need.

Host Meetings. You'll handle the logistics for meetings: making sure there's a place to meet, that everyone knows about it, that supplies are available, and so on. The key meetings are the release planning meeting, the iteration planning meetings, and the daily stand-up meetings. You may find you need other meetings as well, but don't let "meetings" get in the way of "work."

Host Celebrations. You have many opportunities to celebrate what the team does: release plan complete, iteration complete, system released, or other important days. Handle the logistics: make sure the right people are invited and that the team gets the celebration it deserves.

Manage Problems

As a manager, you'll face problems. (XP doesn't change everything.) A project may hit a crisis of some sort. The manager needs to be in the loop, ready to deal with the customer or even the funder. The attitude is not "Woe is me," but rather "This is something you need to know," hopefully followed by "Here are some offers we can make to help it get better." A team will hit roadblocks that don't quite reach the crisis level. There may be places where your authority can get something done in minutes that would take the programmers days or weeks. Perhaps

it's in dealing with a troublesome outside team, purchasing software, or solving an environment problem. If even you can't make headway, you may need to get the customer involved.

Sometimes the problem will be a troublesome member of the team: you may have to get rid of a team member who refuses to follow the team's rules.

If there are outside distractions, the team should minimize these where it can and find a way to deal with them where it must. Production support is an example; you might sacrifice someone to an iteration if he volunteers for pager duty.

If there is outside pressure, remember that the customer is in the hot seat for setting priorities; deflect such pressure away from the programmers.


The tracker handles the mechanics of measuring the team's progress. (Some teams combine the tracker with the manager.) The tracker can act as a disinterested party, with little "skin" in the game. This is a strength. I've been in positions in which I've been 95 percent tracker and 5 percent programmer. It amazes me how much having one task on the tracking list interferes with my perception of the priority and status of the others.

There are three basic things the tracker will track: the release plan, the iteration plan, and acceptance tests. You can easily make simple spreadsheets for the tracking you need to do.

You may find other things to track as well. If you can measure a problematic but controllable behavior, the very act of putting up a chart will tend to improve it. Don't overburden yourself though: remove such a chart once it has served its purpose.

Track the Release Plan (Stories)

In release planning, the customer decides the order of stories and which ones are planned for the release. In its simplest form, this information can be maintained in two stacks of cards, those "in" (planned for the current release) and those "out." Or you may want a chart as a more permanent record (FIGURE 9.2).

FIGURE 9.2 Release Plan Chart

The release plan probably won't change radically more often than every few iterations, so it's not a big burden to track this information.

Track the Iteration Plan (Tasks)

The iteration plan covers a shorter time period, but requires more active tracking. Recall that iteration planning will identify the stories and tasks to be completed in an iteration.

Creating the iteration plan requires some critical information: how many story points did the team complete, and how many task points did each programmer complete, in the previous iteration. (It's your job to track and supply that information.) Again, you might maintain this information on cards, on a whiteboard, or in a chart (FIGURE 9.3). (Note that one task may support many stories.) During the iteration, at least a couple of times a week, you'll talk to the programmers individually and find out how many task points they've spent on a task and how many remain until completion. You might get this information during the daily stand-up meeting. You can use this information to decide if a team is on track for the iteration. If you're on the middle Monday morning of a two-week iteration, but fewer than half the tasks are done, raise a flag. With luck, the team can adjust internally. If not, the team may have to ask the customer to adjust the plan by deferring or splitting stories.

FIGURE 9.3 Iteration Plan Chart

Acceptance Tests

The tracker will maintain a chart for the acceptance tests (the tests defined by the customer). Normally, the customer or a tester will actually run the tests. You might make a table, but the information is far more compelling as a poster in graph form (FIGURE 9.4).

FIGURE 9.4 Acceptance Tests Graph

As the days go by, you want to see more tests in total and fewer failed tests. If that's not the case, people will notice.


The coach role evolved as someone "on the ground" to help the team maintain its process. Alistair Cockburn (2001) describes XP as a "high-discipline" process, and the coach is one of the tools XP uses to maintain that discipline. We'll look at the attributes and activities of a coach and some problems a coach might face.


The coach should be a mature person. "Calm" is too passive a description; it would be more accurate to say a coach should be "centered," unflappable, not easily fazed. The ones I've known (XP or not) have all been good, even expert, programmers. (And the team seems to sense that if they really need it, the coach can go deep into the well for something to help.) A coach is respected, but also respectful. He or she is willing to talk, but also willing to listen. The coach lets the team explore, but provides a guardrail in case of danger.

Finally, the coach is on-site. Just like the customer must be there to answer questions, run tests, and set priorities, the coach is there to mentor, monitor, and help.


The coach's activities focus on the process and the team. The coach will tend to own few or no development tasks.

Monitor the Process. The coach's key job is to monitor the process. If stand-up meetings become two-hour affairs, people are skipping unit tests, acceptance tests are not being written, or people are consistently leaving late, the coach needs to blow the whistle. Usually, just calling attention to a problem is enough to wake people up to solving it.

Enforce the Process. On occasion, you get someone who purposefully does not follow the team's rules. This can't be allowed to continue; it can destroy the team's productivity and morale.

Ron Jeffries (Jeffries, 2001), the coach on Chrysler's C3 project, describes his approach:

What I do (as opposed to how I talk) is that when someone is transgressing rules in some way, I'll have a talk with them. Usually something bad will have happened, which lets us begin by agreeing that something bad shouldn't happen again. I relate the rules to the bad effect in an impersonal way: The UnitTests weren't run before the code was released. The UnitTests would have shown the problem. That's why we insist on running them every time. We're fallible, the computer isn't.

Usually the problem won't occur again. Also I watch the person and nag them a few times in a friendly way.

Perhaps most importantly, I'd coach the other team members to watch out for the bad behavior when partnering. In other words, gang up on him.

If it does happen again, I'll have a still friendly but serious chat that says "Everyone in the group really does have to follow the rules." Since they're programmers, they can do the math on people who don't follow the rules.

If it happens a third time, I would politely but gently remove them from the group. If removing them isn't possible, I'd make it turn out that they didn't get to work on anything important. [...] Extreme Programming (and leadership in general) is a work of love. If you don't respect others, you're not doing it right. I try always to let my great respect show through for people who try hard to do the right thing. And sure enough, they do try, in almost every case. The others, who are perhaps trying in some way I don't understand... I respect them too... and wish them success elsewhere.

Change the Process. One of XP's rules is "They're just rules": sometimes, the best thing to do is change a process. The coach can help the team spot these areas and work through to a new approach.

Mentor. The coach is available for mentoring. This may be to work as a design partner or programming pair, or to help someone find their way on a subject new to them.

Supply Toys. The coach may see that the team needs a reminder about something, and a toy may be just what's needed. Or a toy may be needed to give the team permission to relax a little.


In addition to keeping the process in line, the coach will be sensitive to problems that might arise. Here's a sampling:

Velocity Slowing Down. The tracker may report that the team is completing fewer task points or story points than planned. If there are no obvious reasons (a hurricane shut down the building, lots of family emergencies, etc.), the team needs to do some soul-searching: are they refactoring? producing all the tests? pairing? and so on.

Messy or Duplicate Code. This is a sign that refactoring is not being done well or often enough. The team needs to be reminded that the "simplest" code requires work to keep it that way. In a bad case, the team may have to take some time just for refactoring.

Quality Going Down (as measured by the tests or difficulty integrating). The team needs to focus more on testing "everything that could possibly break." See if you can identify a particular type of error that seems to be slipping through and devise a test approach for it.


We've looked at three roles in managing XP:

  1. Manager: Face outside parties, form the team, obtain resources, manage the team, and manage problems.

  2. Tracker: Track the release plan, track the iteration plans, track acceptance tests.

  3. Coach: Monitor, enforce, and change the process; mentor; supply toys; handle problems.

A team may organize these roles as needed, but you should ensure that each of these areas is addressed.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020