When should you Agile?

Agile is an iterative software development paradigm that still scares a lot of clients when we talk to them about it. Strangely so, as it’s supposed to allow for adaptability like changing requirements, which happens pretty much in every project. Why is this the case? We first have to delve into what agile is and what it means for software or web development. Back in 1990s, developers have found that the standard waterfall development methodology was leaving clients with inflexible projects and out-of-date end-products. A multitude of lighter-weight software paradigms began to emerge to meet this need (such as Scrum, Feature Driven Development, Dynamic Systems Development Method, etc). On an evening in February 2001, the Agile Manifesto was born and its core values is as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we increase the value of the items on the left

Agile then took the development world by storm, with Agile development houses starting left, right and center. Surely we should just “Agile” everything possible! However, developers began to realize Agile was not really a “silver bullet”. So what did they find?  

Clients did not feel comfortable with projects with no fixed price

Fixed-price projects of the waterfall model allowed for predictability and planning. Agile, being an iterative model, there was no easy way to estimate cost upfront of the whole development and many resorted to hourly project billing. This meant that there was no incentive for development houses to deliver solutions faster as they would be paid less to do projects quicker. On the other side, if they stuck with fixed-price billing, developers could run out of time and budget whenever new requirements arose. A degree of trading scope would need to be done to keep in budget.  

Skill required for Agile is generally higher

Because of the emphasis of product rather than documentation, a majority of the design decisions are made by the development team. This meant that you had to put full trust in your development team to make the right decisions. This severely restricts pool of the developers you can use for Agile projects, and makes training inexperienced developers very difficult. Furthermore, this may increase the cost of projects in general.

Client interaction may be too demanding

Clients all have their own companies to run and time is always a contentious issue. Agile development requires a lot more client interaction due to it’s iterative nature and may be just “too much”. Agile development works very poorly if the client doesn’t have the time to keep pace with the development at every step. Nor will there be documentation to look at along the way if face-to-face meetings were not possible.

Collaborative approach restricts distributed development

Due to the tight-knit development style of Agile development, having developers not in the same office makes this development style almost impossible. If the development company has developers in different parts of the country, or if the project requires skills not available at the development location, Agile is probably out of the question.

No good for mission-critical projects

For industries such as air traffic control, where failure is not an option at any cost, Agile is just not going to be enough due to the lack of high level planning and documentation. There is no room for iterative development as the product has to be fool-proof right from the start of use. Hopefully this has given you a glimpse of what you should be aware of before trying Agile on your next project. Don’t get me wrong, agile works well in a multitude of projects, especially in web development houses such as ourselves. Just remember to always choose the right methodology and approach for the job at hand.