This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Agile Practices Considered Harmful?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
In some recent agile newsgroup exchanges I've read, it appears that there is a split in the agile community between what I'll call Rule Followers and Rule Derivers, or just Followers and Derivers for short.
The Follower mantra can be stated as "If I follow all the rules and best practices that I read and hear about, I will be optimally Agile." Taken to the extreme, this mindset implies that there is One True Path(TM) to agility - follow the rules, and you'll get there.
The Deriver says something more like "Given a set of desirable properties for this project, I'll experiment with some possible practices to see how they help us reach those properties." This is more in keeping with agile principles, which are about rapid feedback, inspection, and adaptation. Do the simplest set of things that could work, check to see if it is working, and if not, tweak something.
The main problem with a literal interpretation and application of practices is that if any one of them fails or is unpopular, a Follower has no recourse. It's an all or nothing proposition. In fact, the original XP book (XP Explained) suggested that if you weren't following all of the specific practices, you weren't "doing XP." I think that this is where much of the controversy around XP stemmed from - a seeming lack of flexibility with respect to the practices. In reality this position seemed to be more about protecting XP from bad publicity due to flawed implementations than any resistance to adaptation from the author.
On the Deriver side of the world, the main concern is "reinventing the wheel" in an effort to customize a set of workable practices. It would certainly be easier to take a package of practices, try them all, and only adjust when some aren't working well. What seems to happen in practice is that teams pick and choose the practices they're comfortable with up front. A true Deriver constantly measures and adjusts based on those measurements.
Either approach is a valid way for teams just starting with agile techniques to try, but in the long run, adaptation has a brighter future. Having a clear set of principles, not just practices, can help a team get closer to the Agile ideal - better software, happy customers, and happy developers.
Previous Topic
