Agile Software Development

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

The term of ‘Agile’ was coined in 2001 when 17 practitioners of lighter software development methods met at a ski resort in Snowbird, Utah to discuss better ways of delivering. They produced the Agile Manifesto to describe the key differences between the Agile way of working in comparison to more traditional ways of working.

http://agilemanifesto.org/

Individuals and Interactions: The point is that the most important factors that you need to consider are the people and how they work together, because if you don’t get that right the best tools and processes won’t be of any use. Tools and processes are important, don’t get me wrong, it’s just that they’re not as important as working together effectively.

Working Deliverables: Documentation has its place; written properly it is a valuable guide for people’s understanding of how and why a something is produced. However, never forget that the primary goal of delivery is to create working solutions, not paper.

Customer Collaboration: Only your customer can tell you what they want. Working together with your customers is hard, but that’s the reality of the job. Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication.

Responding to Change: People change their priorities for a variety of reasons. As work progresses on your solution, your projects stakeholder’s understanding of the problem domain and of what you are building changes. The business environment changes. There is nothing wrong with having a project plan, in fact I would be worried any project that din’t have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

Misreadings of the Agile Manifesto has resulted in many myths about Agile, ranging from ‘Agile is a chaotic way of working because there is no process’ to ‘Nothing is documented because Agile doesn’t believe in documentation’. If you re-read the manifesto and experience Agile done correctly for yourself, it is clear that such myths are founded on ignorance rather than fact.