Agile isn't Just About Change

Over the last couple of months several clients of the firm I work for have stated that agile software delivery was not suitable to a particular development project because the need to continually embrace change was not there.

I hear this so often that I feel I need to emphatically point out that agile development practices can provide alot value to "fixed" projects. I have a couple of practices below.

Iterative development: Even if change is not the order of the day breaking up work into small chunks will go along way to mitigating a whole slew of implementation risks.







Test Driven Development: Anyone who has spent serious time practicing TDD can attest to the fact that TDD leads to better design than traditional development. It might not be practical for all situations but where it is TDD lets you safely take a second and third pass at your design.






Behaviour Driven Development: Having a consistent format to describe requirements and test cases in business friendly format that supports automation is just plain common sense, and a great way to specify contracts between teams on large scale projects.

Continous Integration: Code integration is never a fun job and the longer you put it off the harder it is, regardless of how much change is expected in a project.







Planning Poker, Collaborative Modeling, Daily Standups, Retrospectives and Agile Planning Boards: Because "static" projects will also benefit from approaches that increase collaboration, penetrate organizational siloes, and encourage resources who are actually doing the work to partake in the planning process.















Hopefully the point is made, software projects of almost any shape should strive to encorperate as many agile practices as possible.

Practically and common sense should be used to determine which practices should apply, but rate of change should not be the only value driver. Agile practices reduce project risk, increase quality, and reduce churn and rework.