Extreme Roles

Tracker (TrackerRole)

goes around a time or two a week, asks each Programmer how she's doing, listens to the answer, takes action if things seem to be going off track. Actions include suggesting a CRC session, setting up a meeting with Customer, asking Coach or another Programmer to help. (This was discussed at XpImmersionTwo - but not much on that page.)

Customer (TheCustomer)

writes UserStories and specifies FunctionalTests. Sets priorities, explains stories, views CRC sessions. Corresponds to C3's GoalDonor, may or may not also be the GoldOwner. May or may not be an end-user. Has authority to decide questions about the stories. May have job titles like "Planner", "Analyst", "ProjectLead?", "ProductLead?", "ProductManager", or even "Designer".

Programmer (ExtremeProgrammer)

estimates stories, defines EngineeringTasks from stories, estimates how long stories and tasks will take, implements stories and UnitTests.

Coach (TheCoach)

watches everything, sends obscure signals, makes sure the project continues to StayExtreme. Helps with anything. Applies RolledUpNewspaper as required. See TheCoach for some beginning notes on this.

Tester (FunctionalTester?)

implements and runs FunctionalTests. Graphs results, makes sure people know when test results decline. (Note: Programmers do their own UnitTests.)

Doomsayer (TheDoomsayer)

points out when the sky is falling, and when you're in big trouble, guys. (see comments below.)

Manager (XpManager??) (ItManager)

schedules meetings (e.g. IterationPlan, CommitmentSchedule), makes sure the meeting process is followed, records results of meeting for future reporting, passes to Tracker. Possibly responsible to the GoldOwner. Goes to meetings, brings back useful information, pays for pizza, keeps the rain off, fills out personnel actions. Does not tell people what to do (Customer and IterationPlan do that), when to be done (CommitmentSchedule), or check to see how they're doing (Tracker).

Some roles probably should not be combined. Programmer-Tracker, Programmer-Tester, Customer-Programmer, Coach-Tracker are examples. Manager probably shouldn't combine with anything except Tracker. RonJeffries' opinion is that Coach shouldn't combine with Programmer, but maybe it can be done successfully. He's just not good enough.

Ron, on the XpLeiden project I find myself in the role of both Coach and Tracker. Can you explain why that is a bad idea? Also you say Programmer-Tester probably isn't a good combination. Is that true even if the customer writes the functional tests in a special format he can understand and the programmer only implements the code that parses this format and uses the result to test the program? Thanks! -- Martijn

I am not Ron, but I will answer anyway. If you want a tracker to get the most honest answers from the individuals point of view. It is best if this task is designated to a non threatening person. The Coach on occasions applies the RolledUpNewspaper, ergo Contradiction. If I were a tracker I would ask open questions, and attempt to encourage any rumblings of danger early. From my perspective the tracker's role is to be the eyes that see while the coach role is to be the hands that do things. A winning pair of these would fix any project team I have been on.

I think that this is a very good list of roles, but in most projects that I've been involved in (extreme or not), there have been a few ExtremeAntiRoles. See that page for more, but RonJeffries' comment on them is worth repeating:

If these people are on your project, remove them. If you can't, remove yourself or prepare for pain. -- RonJeffries

Is the Tracker or the Coach what others would call a Technical Lead?

Could be, could be not. On our team, Tracker never writes code and doesn't know how. Coach never takes primary responsibility for implementing anything, instead sits with people and helps them, and monitors the process. Coaching well takes a huge amount of time, as you are learning. I'm not smart enough to combine it with much else. There are quiet times, but not that many. -- rj

Is the Doomsayer an essential role?

The word has a negative connotation, but it's not listed as an Anti-Role. Is legitimizing the doomsayer one of the ways that ExtremeProgramming attempts to make it OK to tell the truth? -- JoeBowbeer

Actually I just listed it as a "humorous" observation that most teams have one. However, expressing fear is, in my opinion, a valid thing to do, and teams suppress that expression at their peril. -- RonJeffries

Sometimes on a large project I don't mind having a contrarian around. Of course, when there are only three of you, it can get a little tedious!! But if she is smart and does it without being negative, it can be uncomfortable but productive. -- RobertDiFalco

There's being courageous (as per the ExtremeValues), and then there's being reckless. If you're not looking ahead for the obstacles in the road, you're going to crash. This is what the Doomsayer does, I think. Extending this to Kent's LearningToDrive?? story, the Doomsayer is the person who looks ahead to the horizon, and notes the oncoming truck in the wrong lane. At least, this is how I see it... -- RobertWatkins

As the tester and doomsayer for our team, I feel these roles can be effectively combined. Doomsaying is ugly but someone has to do it. Actually I feel the tester can add value many ways, measuring quality and value produced by XP. Metrics is not my strong suit but some potential customers need hard data to prove the worth of XP. -- LisaCrispin

As a former doomsayer for a truly doomed team, I think the most effective way to use a person in this role is to have the role explicitly defined. I'm not saying it needs to be well-defined (i.e. responsibilities and such), just that everyone needs to recognize that (as noted above) someone has to be looking ahead for obstacles in the road. Otherwise your (usually on-target) warnings will be dismissed as paranoia or whining.

I agree that doomsayers are necessary. Somehow they see things coming around the corner that no-one else expects. However, I wonder if this isn't more of a personality trait than a role, in the same way that being detail-oriented or a big-picture guy represent ways we are comfortable working. Given that roles seem to least loosely correspond to skills, what are the necessary/sufficient PersonalityTypes?? for xp? See also MyersBriggsTypes. -- AnthonyBaker

No mention of a customer's customer anywhere here. -- LarsAronsson

The playing field needs boundaries. It stops at the customer. Part of the Customer role is for the Customer to decide business value and what will serve their customers best.

I initially wanted to ask "Why is Customer-Programmer a prohibited role combination?", but in the process I came up with two more questions:

• Why is the Programmer role not to be combined with anything except Doomsayer? I think I intuitively know the answer, but can't really articulate it.
• What is the minimum XP team size?

• Programmer #1, Doomsayer
• Programmer #2, Doomsayer
• Customer, Tester, Tracker, Doomsayer
• Manager, Tracker, Doomsayer
• Coach, Doomsayer

This suggests a minimum team size of four, and possibly 5 if the Coach is a mere mortal human.

How can XP be adapted to very small teams? If there are fewer than four people, is XP possible?

I'm surrounded in OpenSource programming projects every day. Many of these are produced by teams of one person, who writes programs to satisfy their own needs. That would seem to be a Customer-Programmer combination (and all of the other prohibited combinations as well, for that matter). Of course many of these projects are not ExtremelyProgrammed??.

Warning: I have deliberately written at least one incorrect assertion into this section. Kudos to the person who notices and fixes it. ;-) -- ZygoBlaxell

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006