Extreme Programming (XP) is a very simple and effective discipline of software development based on values of simplicity, communication, feedback, and courage. It includes techniques for programming, and techniques for planning and working with the "customer", the individual or group that has responsibility for making business decisions about the program that is to be written.
While I agree that one can't conclude that they weren't doing XP without more data, we do have this from the OP:
"Basically, everyone walked over everyone else's code, things never once worked properly. Without any sense of forward thought, basically the project went to a standstill."
If the OP means that the code didn't work, that would suggest that they weren't doing the XP testing thing. Can't know for sure, but if you don't release code until all the tests run at 100%, things tend to work properly.
Regarding coming to a standstill, XP teams work in two- or three-week increments, focused entirely on delivering user functionality. Maybe this team wasn't doing that.
I'd sincerely like to know what was going on, because I'd like to know how to improve the XP explanations and process where they need it.
I'd be interested to know what the team really did, i.e. what parts of XP they used and did not use. Were there tests for everything to show that the refactorings worked? Did they pair program, especially with the original authors?
Slashdot Mirror
Extreme Programming (XP) is a very simple and effective discipline of software development based on values of simplicity, communication, feedback, and courage. It includes techniques for programming, and techniques for planning and working with the "customer", the individual or group that has responsibility for making business decisions about the program that is to be written.
Read more about XP at extremeprogramming.org, or on my site, XProgramming.com.
While I agree that one can't conclude that they weren't doing XP without more data, we do have this from the OP: "Basically, everyone walked over everyone else's code, things never once worked properly. Without any sense of forward thought, basically the project went to a standstill." If the OP means that the code didn't work, that would suggest that they weren't doing the XP testing thing. Can't know for sure, but if you don't release code until all the tests run at 100%, things tend to work properly. Regarding coming to a standstill, XP teams work in two- or three-week increments, focused entirely on delivering user functionality. Maybe this team wasn't doing that. I'd sincerely like to know what was going on, because I'd like to know how to improve the XP explanations and process where they need it.
I'd be interested to know what the team really did, i.e. what parts of XP they used and did not use. Were there tests for everything to show that the refactorings worked? Did they pair program, especially with the original authors?
Or did they just run rampant and call it XP?
RonJeffries (XPInstalled author)