Ok. So having a team of empowered individuals, driven by a consensus around the customer is great. But what about when ordinary everyday office politics rears its head? When:

	1. Someone on the team is just not willing to change their class, even if it doesn't fit what others are doing in the system (''and'' they are somewhat revered as a "good designer", so nobody wants to tick them off)
	1. The lack of leadership means the team goes around in circles (perhaps because the customer is also uncertain)
	1. There is a designated project leader, but s/he does more meddling than managing.
	1. The project manager gives lip service to XP, but turns around and defeats its principles in practice.
	1. You've pleaded with the manager above the project manager to change leaders, but they are reluctant because the leader is a senior member of the staff and, besides, they were "promised" the leadership of this version after they were unceremoniously taken off the last one!
	1. Managers and teams are so used to playing communication games with each other, that when a method comes along that requires openness, honesty and cooperation, it's alien to them.
	1. Example: Programmers automatically double any estimate they give management, and management just mentally divides it in half again.
	1. Another example: Management is always going after this thing or that thing - maybe because they're getting heat from above, or they read it in an article, or they just felt like it.  The team members just nod, and go do whatever they were doing anyway because they've learned to ignore these things.
	1. The situation of BenignNeglect, where the IS department is left to graze in the pastures of their own strategic technology initiatives until one day they are actually called on to do something productive (like e-business).

Is XP self-correcting in these cases?  Or is something outside of XP required to step in and set things aright?  And what is "aright"?

How well does XP fare when the crucial method expert/coach is not influential enough to make a change in the organization's practices?

----

''Take it from me - office politics affect XP or XP-aware teams with results just as ugly as anywhere else. I'm asserting this mostly because I'm currently embroiled in "office politics" of the worst sort, which unfortunately I couldn't ethically stay out of; with the most disastrous effects on a process of MigrationToXp that had fared rather well before.''

''I would guess that XP is vulnerable to outside influences in this respect rather than "self-correcting", but I would also hazard that no methodology can be less vulnerable.''

Absolutely. I've certainly seen cases 4-5 (about project managers) defeat an otherwise promising XP project.

''I disagree that XP is no more vulnerable than other methods to office politics.  This is because XP is usually something new.  Switching methodologies in a project getting battered about by political forces gives the politicians a scapegoat.  Then again, if XP is standard procedure in your shop, then it is the safest route. -- RobMandeville''
----

''The fact that some XP practices appear unconventional and controversial may possibly increase the risk of "outside influences" from management. That risk may be lower if you're following AnAcceptableWayOfFailing instead.''

XP has nothing to do with office politics. XP is a software development process, not a breakfast cereal.

''I disagree. Software development processes have a '''lot''' to do with the personalities, styles and interactions of the people involved.  Look at the beginning of AlistairCockburn's manifesto, for example, especially the "cooperative" part:''

	 :	"Software development is a cooperative game, in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game..." [cf. SoftwareDevelopmentAsaCooperativeGame]

''also, his paper at http://members.aol.com/acockburn/papers/adchange.htm''

Politics do affect your job, but XP has nothing to say about that. It is merely a bunch of methods for the process of developing software. Politics may affect XP only in the sense that XP is part of your job. But XP won't help you deal with the political situation. More UnitTest''''''ing does not deal with obnoxious individuals. Politics are outside the scope of XP.

Actually, I lied. XP has some political tools. The PlanningGame for instance. But more index cards won't tell you how to deal with racism in the workplace.

''Well, the ''official'' XP writings don't cover office politics (are there any methods that ''do''?)''

Yes, but they aren't normally software methods. Do you understand what I mean here? The scope of XP is developing software. Office politics require other methods. There are some of those patterns here, like ParkingLotTherapy.

	 :	There is a large push by people to extend XP out of scope, from ExtremeProgrammingForOne, ExtremeProgrammingInEnemyTerritory, to XpAndOfficePolitics. XP has a limited scope. I don't think that XP advocates (any of them) know what that scope is. This makes extensions to XP dubious. XP is not a Hollywood movie. It is not supposed to everywhere. It is not a breakfast cereal. Don't make it one. -- SunirShah

Well, the way I see it is like PushingTheEnvelope, and I don't see anything wrong with that. It's necessary to explore all the nooks and crannies of any theory. Sure it doesn't apply everywhere, but does anybody really know for sure where it ''doesn't''? Maybe a page listing XpFailures would be enlightening.

	 :	Even better. How about a page called DealingWithOfficePolitics, or even extend the OrgPatterns. Create a pattern language. You don't need to involve XP in that, nor could you seriously. It's ok to ''not'' say "XP" on every page. Note that office politics affects lawyers too. So, I'm sure you could find a way of talking about office politics that didn't involve software methodology. -- SunirShah

''How about some real world examples of XP mixing (or clashing) with office politics?''

CthreeProjectTerminated.

----

Maybe we can change the focus of this page and move the generic office politics stuff elsewhere. Important XP specific questions that need to be answered:

	* Since XP is so radically different from WaterfallMethodology, XP usually gets a large backlash. ExtremeProgrammingExplainedEmbraceChange has some rebuttals to common reactions, like PairProgramming is expensive. However, SteveMcConnell goes way further in CodeComplete with actual data, studies, results, and suggestions. XP lacks empirical validity. Q: ''How do you deal with common negative reactions?'' Hand waving, mostly, unfortunately. Can you do better?

	* XP removes people from positions of power, like architects. They will not appreciate this. Q: ''How do you deal with power redistribution?''

	* XP moves faster than some other methods, and is often seen as loose. Q: ''How do you show that moving faster doesn't penalize your quality?''

	* XP moves slower than some other methods. Q: ''How do you show that XP is worth the overhead?''

	* DontCallItExtreme.

-- SunirShah

Good points and questions Sunir. I can say that I have encountered every one of your points in trying Xp.

-- sg

''Second that. This is kind of what I was getting at. Thanks!''

The first point is important. I mentioned in another topic that I had written a very extensive pro-XP letter to SteveMcConnell at IEEE Software and he basically said that I had to PresentEmpiricalData to back up my claims and so did XP. In presenting this to people, that's the first thing that they ask. The power redistribution thing is *very* real. At a major software vendor where I only introduced UnitTest''''''s there was already a power distribution thing and conflict going on among the Architects and QA. These are points that worth addressing.

-- sg

----

I suspect the OfficePolitics to which the page title refers is in fact "petty politics", power plays and so on. As far as I can tell XP makes no particular effort to be resistant specifically to such things, and I think it would not be proper of XP to aim at being, generally, a program for reforming OfficePolitics.

''I called it "OfficePolitics" to distinguish it from national politics, but it's not limited to "petty" politics; it's about the normal (possibly pathological, but normal) ways people interact at the office.'' 

That last (anonymous?) comment notwithstanding, I think that in part, but in an important sense, XP '''is''' office politics; at least insofar as we adhere to the nobler meaning of "politics" as that method which societies adopt to ensure that their collective efforts yield better results than could be expected from their members acting severally as individuals.

This is evident in the notion associated with XP of a BillOfRights - two of them in fact, one applying to Development and a complementary one applying to Business. See PlanningExtremeProgramming. In particular, the notion of XP as these complementary "bills of rights" is liable to clash with certain (sadly more common) conceptions of how IT businesses should be operated; any such clash and its resolution involves "office politics" in a sense relevant to XP.

I certainly would agree with Sunir on scope, and say that XP is, and should remain, neutral with respect to the broader aspects of the social organization of businesses. XP is intended as applying to the interactions of specific parts of organizations - programming teams and their management. (Which, naturally, restricts it to those organizations that ''have'' programming teams.) -- LaurentBossavit

''How about a page called DealingWithOfficePolitics, or even extend the OrgPatterns. Create a pattern language.''

I seem to recall KentBeck is doing just that - ReluctantLeadership. ''ReluctantLeadership touches on tangentially on office politics, although the patterns could be used for leading higher and peer managers instead of inside the team''

----
Politics are simply people trying to make things how they feel most comfortable with them. What XP seems to promise is that the system benefits everyone. In which case it should just be slapped into place wholesale. This is of course assuming everyone has movies that are inkling with the success of the software project and they can clearly see all the ways in which XP can be implemented.

Now, last time I was at the dentist and he told me this was for my own good, I don't recall being to happy about it at all.

This is the problem. The value of XP has to be shown. How do you show it with out implementing it first? Paradox. So to apply XP to the XP process (I love recursion) do the DoTheSimplestThingThatCouldPossiblyWork. Implement first the small acceptable pieces. Change slowly. 

Imagine Office Politics like a ship. The more politics there are, the bigger the ship is..the harder it is to turn. And certainly if you run up to the helm, grab the wheel while no one is looking and yank it hard to port, you will find your only popular with the rats in the brig.

Suggest small changes that you feel the management are already willing to accept. Ask question to find out in which ways they'd like to see the project change. Make small suggestions by doing things like brining index cards to a meeting, or writing your own Unit tests. Once your pushing the cards around, maybe you could begin asking other people for help on specific parts of the project. Ask them if they would be willing to help you write a section of code. Appeal to the ego. Use unit testing during the process, or maybe even write the test before you get their help. (gee, that process was really easy once the tests were written.) Start talking in Refactoring speak while at the same time explain the individual concepts.

I did this with a project and slowly but surely the ship was turned. Unfortunately, it was clear at that point that we were going to run aground no matter what changes were made, but at least it became apparent. It could have gone on for months before anyone saw what was happening. And I guess that is the down side. You can't be too afraid of what will happen when you know the truth about your software.  ---Todd Edman