Team Crunchberry has adopted an agile software development process. I’ll be writing about our process and sharing the outputs here on the Crunchberry blog every week. But before I get down to business, let’s talk about agile.
How we did things back in the day
Traditionally, the software development process looked something like this:
After realizing that you need some new software, a team of ambitious people spend a long time, say, 6 months, writing a functional specification. That is, a fat, three ring binder describing exactly what the software should do.
Then they hand the binder to another team, the developers. (They’re the unusual chaps who don’t leave their caves much, but who hold the magic keys to make the computers work.) They spend a long time, say 6 months, translating the functional specification into a piece of software.
They then hand the software back, a year after it was first conceived.
“Life moves pretty fast. If you don’t stop and look around once and a while, you could miss it.”
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.
What is agile?
Agile software development is about accepting that it’s impossible to design up front. It’s a tough idea to shake, but by embracing the chaos, you save yourself from perfectionism. You’ll never get it perfect.
A common misconception is that agile is a free-for-all, anarchy even. How can you develop without a plan? Oh, there’s a plan. Agile development is very strict. Everything but the requirements is super tight. Only with discipline, can you become free.
With agile you plan less up front, and correct your course along the way. You design a little bit, build a little bit, test a little bit, and then look up. Are we still on course?
(Though when a team tries to do a few things agile and skip the hard stuff, you gain little, and often get anarchy. For instance, if you design and build in short cycles, but don’t ever ask a user what she thinks, how do you know if you need to correct your course? It’s no better than the old way.)
There are many schools of thought on the correct rules for an agile team, but they’re all based on a basic set of principles. In my next post, I’ll describe what we’re doing to be agile. (And if you’re dying for more reading, the wikipedia (of course) has much much more.)