Xp Is Anarchy

Structure where it is needed, for as long as it is needed. No more and no less. -- RichardHenderson

My version of anarchy is that it is against fixed structure. This provides a balancing force to the relentless accretion of old irrelevant structures. What structure is needed should exist as a dynamic, produced in response to the particular needs of the people, and the particular environment which must satisfy those needs.

That doesn't sound too different from continuous refactoring and YAGNI. Or am I missing something? -- RichardHenderson

Discussion:

The student asks if XP fails when you force it.

Can you elaborate?

I don't believe you. The TrackerRole alone defies this suggestion, let alone the OnsiteCustomer. Perhaps a foray into the complete opposite of anarchy, the military, will explain better than I can. Onwards to ArmCl...

I love ArmCl :). I was thinking more of the system it works on. Do you think XP is structurally fixed? I got the impression that roles were fluid beneath a basic coordinating framework. The ability (and desire) to adapt the structure of both the code and the programming team would place it in the anarchy zone for me. Of course, there are as many definitions of anarchy as there are anarchists. Such is the nature of the beast. Anarchy is not random, though it may be chaotic. -- RichardHenderson

To anyone who suggests that XP is Anarchy, I would ask that he tries to get a development team to adopt it. Issues that I have had include:

TestFirstDesign

: How to get people to write tests and write them before the code.

MercilessRefactoring

: How to get people to incrementally migrate code instead of doing a rewrite.

OnceAndOnlyOnce

: How to get people to use a class written by someone else; they always "can do it better."

PairProgramming

: How to get people to evaluate and trade-off their opinions instead of running to their supervisor to pick a winner and a loser for them.

I see far less anarchy in XP than in the traditional approach, "give us a design specification, close the door, and in 6 - 18 months a program will pop out."

I agree. ExtremeProgramming tells you exactly what to do at every moment

write all production code in pairs;
start with a standup meeting at the beginning of the day;
follow a loop where you write a test, watch it fail, make it pass, and commit;
continually look for code smells and refactor them away.

I would hardly call that anarchy!

XP has everything a project needs, except management. If we define an eXtreme Manager as one manager that allows his team to go eXtreme, then he would need to keep track of what they are actually doing, because they would not report back to him. They tear down cards when finished, so there is no way to keep track of that. Can you plan? Absolutely not, because you can plan only 2 weeks ahead, everything that was not done in an iteration is thrown and must be scheduled *again* from the start for the next iteration. The PM would be exhausted and he would have very little to show, except of course working software that can be validated by the user, but wait, it must be compiled, it must be integrated and you have to keep track on what builds you found the errors. How is going to know how to build, how to install or how to use the software the customer? If they find an error, how are they going to report it? In cards? They are new requirements? How can you keep track of those? Do you have to wait for the next iteration for developers to fix those errors? Is that a joke? If a programmer says he fixed it, how can I verify it?

The first thing the eXtreme Manager must do is to install the software daily in a machine called Staging or something like that where everybody can connect to and test the system. When an error is found, report it immediately using a bug database. When a developer says he is finished, test it in Staging and then close the issue in the bug database. Then you can keep track. Do you think the customer would like to test that every time? Probably a tester would do the job better.

XP is attractive for programmer, but XM is attractive for managers.

I see a lot of fear-based reactions to XP from project managers. They often attack it in the way you have above, but they do so without understanding how XP actually works. It appears you've done the same. For example, how do you reconcile XP's (long-term) release plan with your statement that XP only plans two weeks ahead?

See DoesAgileLeadToAnarchy