This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: You Can't Change Just One Thing
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
"...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.
Previous Topic
