Here are some roles that are part of XP. Most are assigned: Tracker, Customer, Programmer, Coach, Manager, Tester. Anyone can be Doomsayer.
Tracker (Tracker Role):
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 Xp Immersion Two - but not much on that page.)
Customer (The Customer):
writes User Stories and specifies Functional Tests. Sets priorities, explains stories, views CRC sessions. Corresponds to C3's Goal Donor, may or may not also be the Gold Owner. May or may not be an end-user. Has authority to decide questions about the stories. May have job titles like "Planner", "Analyst", "Project Lead", "Product Lead", "Product Manager", or even "Designer".
Programmer (Extreme Programmer):
estimates stories, defines Engineering Tasks from stories, estimates how long stories and tasks will take, implements stories and Unit Tests.
Coach (The Coach):
watches everything, sends obscure signals, makes sure the project continues to Stay Extreme. Helps with anything. Applies Rolled Up Newspaper as required. See The Coach for some beginning notes on this.
Tester (Functional Tester):
implements and runs Functional Tests. Graphs results, makes sure people know when test results decline. (Note: Programmers do their own Unit Tests.)
Doomsayer (The Doomsayer):
points out when the sky is falling, and when you're in big trouble, guys. (see comments below.)
Manager (Xp Manager?) (It Manager):
schedules meetings (e.g. Iteration Plan, Commitment Schedule), makes sure the meeting process is followed, records results of meeting for future reporting, passes to Tracker. Possibly responsible to the Gold Owner. 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 Iteration Plan do that), when to be done (Commitment Schedule), or check to see how they're doing (Tracker).
Some roles can be combined in the same individual. For example, the same person could have the Manager and Tracker role.
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. Ron Jeffries' 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 Xp Leiden 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 Rolled Up Newspaper, 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 Extreme Anti Roles. See that page for more, but Ron Jeffries' 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. -- Ron Jeffries
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 Extreme Programming attempts to make it OK to tell the truth? -- Joe Bowbeer
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. -- Ron Jeffries
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. -- Robert Di Falco
There's being courageous (as per the Extreme Values), 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 Learning To Drive? 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... -- Robert Watkins
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. -- Lisa Crispin
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 Personality Types? for xp? See also Myers Briggs Types. -- Anthony Baker
No mention of a customer's customer anywhere here. -- Lars Aronsson
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?
From the rest of this page, I get the following minimal XP team, with 4 or 5 members depending on whether you think Coach-Tracker is a good idea (there seems to be support for both opinions above):
Programmer #1, Doomsayer
Programmer #2, Doomsayer
Customer, Tester, Tracker, Doomsayer
Manager, Tracker, Doomsayer
Coach, Doomsayer
Tracker and Doomsayer can be a single person role in any location where they appear above without affecting total headcount. I don't mean to imply two people having the Tracker role or everyone being a Doomsayer. The two Programmers are distinct, since you obviously need a pair for Pair Programming.
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 Open Source 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 Extremely Programmed?.
Warning: I have deliberately written at least one incorrect assertion into this section. Kudos to the person who notices and fixes it. ;-) -- Zygo Blaxell
Manager and Doomsayer in the same person sounds pretty scary for me. Can this work? -- mb
See original on c2.com 