This post originated from an RSS feed registered with Agile Buzz
by Jared Richardson.
Original Post: Thoughts on Good and Bad Agile
Feed Title: Jared's Weblog
Feed URL: http://www.jaredrichardson.net/blog/index.rss
Feed Description: Jared's weblog.
The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers.
There have been several recent blogs postings and articles about why Agile is bad and something else is good. In my opinion, this paragraph from Ship It! A Practical Guide to Successful Software Projects provides a huge red flag on a bad process and sums up what I think Agile ~should~ be, but often isn't. Please forgive my obvious bias regarding the source of the quote. ;)
On a practical note, any process that prohibits any other best practices from being introduced is almost certainly a bad process. Beware any process or methodology that claims to be the exclusive solution to every problem for all projects. This magic cure-all is just modern snake oil. Embrace a methodology that encourages periodic reevaluation and inclusion of whatever practices work well on your project. Be sure your process is a flexible one- don't be afraid to change or adjust your process to see if a new, better practice can fit in. If you have a new idea, drop it in for a few weeks. If it works out, great! Make it a permanent addition. Otherwise, revise it or get rid of it. This experimentation is how you'll find out what fits your shop the best. There are no sacred cows in a good process. Anything that works well can stay; anything that isn't working must be removed or revised.
Because every project is different, and every team is unique, you are the only one qualified to judge what works and what doesn't.
There are prominent individuals in several popular processes who are happy to embrace this type of freedom... as long as use everything they tell you to use. How arrogant.
I haven't met anyone yet smart enough to know what every single team in the world should be doing or how every single project should be run. However, you can learn a lot from the experience of others.
So study the popular and successful methodologies. Try them out. And follow Martin Fowler's advice about actually following the rules for a while. Then take what works and use it. Discard the rest.
Your coworkers will enjoy working with you more (as opposed to working with a stiff process snob) and your customers will love getting their stable software on time.
Previous Topic
