The real meaning of agile

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.

2 responses to “The real meaning of agile

  1. Well said, I agree completely.

    I think that client’s may begin to see the benefits of agile development once they realize the benefits it tangibly creates for their timelines and budget. The onus is on the client to know what they want in their application before any work has been done on the development group’s side, or at least what the main support column of their goal application are. On the development side, this provides many benefits including being able to build these foundations elegantly and intelligently, making the ancillary development that much easier and more efficient. This translates to happier developers and other team members, as nobody will have to scramble in the final days before a launch to fundamentally rebuild any of these columns. Each development cycle can dress up the columns in any way the client sees fit with no real negative effects, this way.

    On the flip side, there is a mirrored responsibility on the side of the development team and the related managers to make it known to clients that “this is the way we operate”. This means streamlining how the client interacts with the development team and providing the client with a constrained set of actions that they can request. These actions can change the behavior of applications in a seemingly infinite amount of ways, but can never knock out any of the columns that were designed and built at the start.

  2. I see it the other way around. When agile really proves useful is when dealing with the client, because he (often) doesn’t have a clue, and you have to guide him.
    For internal development (I’ve done it), I don’t see the point.
    At the end, both parties should take advantage of agile. Of course the client only cares about the final product to be available on a given deadline. But he must be aware of the advantages, and be willing to pay the price (more involvement).
    For me, real agile means that the customer is present on your standup meetings, and you get payed at the end of the iteration for the work you’ve done those 2 weeks.

Comments are closed.