Agile Methodology vs classical development

For the sake of brevity, I am oversimplifying at least half a dozen techniques (such as extreme programming , SCRUM or Feature Driven Development)

Books have been shortened to a bullet point list... This article is more meant as a way to create an interest.

You can read the manifesto in full at http://agilemanifesto.org/ . Traditionally, software was written in a big cycle that started with planning, continued to implementation, testing, deployment of all features at once and then the software development was considered done. The feature set was decided in advance and in that context moving one tiny bit from that feature set was frowned upon.

There was no requirement to have intermediary release and feedback came only after the application was finished. Agile methodology is en vogue and it really offers interesting concepts to programming, namely:

• continuous testing of the application/ automated regression testing
• only implement the features that the client need
• Sprints: work in short monthly cycles
• actual features/working code over documentation
• always have a shippable version (especially at the end of each cycle)
• Prioritized Backlog: always keep a prioritized list of features and implement the first feature on the list
• Reliable planning: develop a reliable method of estimating (like planning games)
• no plan is set in stone, you adapt to the client as you go along.

The idea stems from the fact that often, the developer ends up knows about implementing the product only after having done the whole process a first time and by using this method, you get to optimize what works as you go along. You also have the client more productive immediately by rolling out updates as you go along. Further, you can rectify wrong turns as you go along because you get constant feedback from the customer... indeed, this is a particularly seductive method. Ideally all is well in wonderland. However, keep in mind that with this method, it is very easy to go astray from the original development goals... which is fine as long as the client goes along with the direction the project is taking. It is ideal in case of inhouse development.

Developers must be careful when using Agile methods while on a contract because the client can always go, "this is not what we originally convened".

For these cases, it is good to put in place processes to track the changes and client validation. In my humble opinion, it is also good to have a set of general guidelines, a direction to get to in mind that does stay constant or you may end up with tons of nice features that are fully functional due to the nature of agile method but not necessarily as useful. Further, Agile is criticized by some as a way to simplify programming... it is not if done right. Indeed, by having constant testing, constant shipping versions and progressive deployment, I would argue that more complexity is introduced and in the end it does bring about a positive change...

In Short: better code and avoiding of costly mistakes. One thing is certain, spend time on picking a methodology to formally structure your development, especially in group development. Also one method may work best for one project and slow down the development of another... be agile, even about your development method Happy programming