This chapter is from the book
This chapter is from the book
This chapter is from the book
Manager
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.
Tracker
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).
){kind=link}
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.
){kind=link}
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).
){kind=link}
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.
Coach
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.
Attributes
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.
Activities
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.
Problems
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.
Summary
We've looked at three roles in managing XP:
Manager: Face outside parties, form the team, obtain resources, manage the team, and manage problems.
Tracker: Track the release plan, track the iteration plans, track acceptance tests.
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.