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:
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:
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 UnitTesting 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.
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:
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 UnitTests 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