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:
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:
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