We often pitch ourselves as an agile development group, but, sometimes there’s a fundamental misunderstanding of what agile means. And, it’s easy to see why.
We promote the fact that our internal development tools help us build rapidly and change data schemas with minimal impact. And it shows. While we don’t generally condone it, we can build a very custom database-driven Flash application, accompanied with a content management system and some other custom services at a rather relentless pace (on the order of a few weeks) from start to finish. We’ve done it before, and we may well do it again. But, we don’t do it terribly well.
Agile can easily be misconstrued as a change-anything-on-the-fly mentality; Cavalier programmers hacking away at code without a clear understanding of the goal. It’s a dangerous misinterpretation, as it often leads to daisy-chaining functionality at the end of a build because we can. In reality, agile development is a very predictable, rigid way of programming. Iterate, iterate and iterate again. Release, release and release again. Each release is a usable product. Small changes are fine. Large sweeping changes have a signficantly smaller, but still, jarring impact on development timelines as compared to old-school development techniques.
In order for agile to truly succeed, it requires similar buy-in from the client. Clients would have to follow all the rules of the agile process as well (e.g. iterative scheduled builds, a high value on simplicity, continuous re-evaluation of requirements). But, we’re finding out that most of the world simply can’t bend on these rules. Our clients typically have strict deadlines and requirements that don’t adapt well to true agile development. Our clients typically don’t care for a 100% ready product with half the anticipated functionality in 2 weeks. They only care about the full product 4 weeks from now. They can’t stomach a potential shift in the end solution because we discovered something legitimately better as we started writing code. And, that’s completely understandable.
As a necessary compromise, being agile for us means we need the pieces in place- well-thought out concepts, agreed-upon application goals, and a list of functionality at the beginning of a project. We can’t do more without having more time. In our work, we are finding out that agile has to remain strictly internal to us unless clients can bend to the true rules of the game.