XPlorations
| XP123 → XPlorations → Managing XP (July 2000) |
| July, 2000 |
There are three prominent roles in managing XP:
- (Project) Manager
- Tracker
- Coach
The Tracker helps the team know if they're on track for what they've promised to deliver; this 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 they go "into
the weeds".
The Manager
The Manager has several key jobs: they face outside parties, form the team, obtain resources, manage the team, and manage its 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 them, there will be no team.You will deal with Customers as well. 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 it's an XP team, the Programmers need to know that going in. 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 obtain a team workspace. XP values face-to-face communication as the highest-bandwidth way to share knowledge. To reinforce this, it has the practice of an open workspace. 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 (including Chrysler's C3 project) 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, they want the expert to teach the team to do the job itself.
You'll need miscellaneous office supplies: paper, pens, markers, and of course file cards.
Manage the Team
As a Manager, you have several responsibilities centered around the team:- Report progress
- Host meetings
- Send people home
- Host celebrations
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".
Send People Home. XP believes in a 40-hour week. Just as you ensure people go to the daily stand-up meeting at the start of the day, make sure they go home at the end of the day.
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 needs.
Manage Problems
As a Manager, you'll face problems as well.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 an troublesome outside team, or with purchasing software, or solving an environment problem. If 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. An example might be production support - you might sacrifice someone to an iteration of "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 managing and 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 where I've been 95% Tracker and 5% Programmer. It amazes me how much having one task on the tracking list (negatively) affects my perception of the priority and status of things.
There are three basic things the Tracker will track: the release plan, the iteration plan, and acceptance tests. See the spreadsheets plans.xls and tests.xls (Excel 7.0) for an idea of how you might capture this information. (Don't feel obliged to use these spreadsheets; they're just there to give you the idea.)
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 the chart once it's served its purpose.
Track the Release Plan
In release planning, the Customer decided 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" - in order - and those "out"). Or, you may want a chart as a more permanent record:| Release Plan
Stories Planned (in order)
Stories Deferred
|
The release plan probably won't change radically more often than every few iteration, so it's not a big burden to track this information.
Track the Iteration Plan
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 the team completed, and how many task points each programmer
completed, in the previous iteration. (You supply that information.) Again,
you might maintain this information on cards, on a whiteboard, or in a
chart:
| Iteration Plan
Iteration: N Start date End date Stories
Tasks
|
(One task may support many stories.)
During the iteration, perhaps once or twice a week, you'll talk to each
Programmer and find out how many task points they've spent on a task, and
how many remain until completion. 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 2-week iteration, and half the tasks aren't done, raise a
flag. With luck, the team can adjust internally. If not, the Customer may
have to adjust the plan.
Acceptance Tests
The Tracker will maintain a chart for the acceptance tests. (Normally, the Customer or a Tester will actually run the tests.) You might make a table like this:| Acceptance Tests
Date | # Passed | # Failed
|
but this information is even more compelling as a poster in graph form:
As the days go by, you'd like to see more tests in total, and fewer
failed tests. If that's not the case, people will notice.
The Coach
The Coach role evolved as someone "on the ground" to help the team maintain its process. Alistair Cockburn 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 of a Coach, the activities they do, and some problems they might face.Attributes
The Coach is a mature person. "Calm" is too passive a word; it would be more accurate to say they are "centered" or 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. They're willing to talk, but also willing to listen. They'll let the team explore, but provide a guard-rail 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 present to mentor, monitor, and help.
Activities
The Coach's activites 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 2-hour affairs, or people are skipping unit tests, or acceptance tests are not being written, 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, 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 fallable, 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.
ExtremeProgramming (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. Ron Jeffries - http://c2.com/cgi/wiki?EnforcingMethods |
Change the Process. One of XP's rules is "They're just rules": sometimes, the best thing to do is change the 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? etc.
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 "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. 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 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 how it needs to, but you should ensure that each of these areas is addressed.
Resources and Related Articles
- Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 9.
- Extreme Programming Explained: Embrace Change, Kent Beck.
[Written 6-15-00]