About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Mar.16 Thu
You Can't Change Just One Thing
A paper [pdf] by Glenn Vandenburg entitled "A Simple Model of Agile Software Processes - or - Extreme Programming Annealed" works out why the "interdependencies" of the various XP practices are not necessarily a bad thing. I like this bit:
"...Some process redundancy is invaluable in the face of such flawed workers.
"Many processes try to deal with these problems by ... adding enforcement steps or inspectors, or by adding practices solely for the purpose of redundancy. But such measures are costly in terms of time and effort... One strength of the XP approach is that the practices play multiple roles. In most cases ... the redundant compensation is merely a secondary role of the practice... and has the added benefit of using core team members in enforcement roles without making them seem like 'enforcers.'"
Of course, a drawback of this overloading of a practice, is that when a team "adapts" XP but drops a practice, they're really dropping multiple aspects of that practice. To fully replace that practice could require adding in several other practices.
If the team drops Test Driven Development, they are not only dropping unit tests, with its fast feedback on the quality of your code, but also the designing/refactoring aspect of TDD. They could add back in after-the-fact-unit tests (which provide slower, more difficult-to-implement feedback), but they would also need to add back in more design and refactoring practices as well.
If the team drops Pair Programming, they are not only dropping the fast feedback from pair programming's 'continuous code review', but also they also drop the idea-generation that helps get coding done quicker, and lose opportunities for the 'enforcement' for coding standards, testing and integration processes. Adding in after-the-fact reviews will slow down the feedback and enforcement; and you would also need more brainstorming/design sessions.