The Crunchberry Project is using agile software development practices as we build a new product for the Cedar Rapids Gazette.  On the team blog, I’ve begun writing a series of pieces detailing our process.

Part one was a brief attempt at defining agile and explaining why it’s important:

What can happen in a year?  Twitter catches on.  The stock market crashes.  Your competitor releases a new product.  A new congress is elected, and they change the laws.  It’s discovered that margarine is healthier than butter.  Your business model becomes obsolete.  And you’ve invested nine months in a product that nobody needs anymore.

And let’s just say that you’re living in a time warp, and the world remains completely static, who’s to say that you even got the requirements right in the first place?  If you’re wrong, you just invested a year of work in a system that doesn’t work for your users.

As a great Chicagoan once said: “Life moves pretty fast. If you don’t stop and look around once and a while, you could miss it.”  Your requirements will change.  Agile teams are prepared for the chaos.

Part two in the series begins to explain how our team is implementing agile processes: how we meet, the weekly atomic work cycle known as an iteration, and why we think meetings are toxic.  Plus, it’s got a great parenthetical reading list:

(… If you want to do this right, read Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin, and The Pragmatic Programmer, by Andy Hunt, and Dave Thomas.  Or even better, go to Ann Arbor and learn it from the badasses at The Menlo Institute.)

(Also, read Getting Real by the folks at 37signals.  Please, just trust me on this one.  It’s important.  Much more important than reading this silly blog post, that’s for sure.)

In the upcoming weeks, I’ll be sharing our design process, task and defect tracking, how we test, and lots more.  Stay tuned!