What is agile methodology?

Question

Can any one explain about the agile methodology in simple sentences?

Answer 1

I think nothing puts it better than the Agile Manifesto itself:

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 value the items on the left more.

from http://agilemanifesto.org/

Answer 2

Agile is a lot of things and practices, but I think the core of it is just iterative development.

Iterative: Think a bunch of very small waterfalls. That is, the waterfall method (requirements->spec->code->test), but instead of doing it over the course of a year or so, you do it over the course of a few weeks for a manageable chunk of the overall project. At the end of 'iteration/sprint/increment', you have a small but complete and tested set of additional functionality.

This allows you to rapidly change the course of the project if it turns out that what you're doing isn't what the customer wants, or the business needs change, or whatever. Hence the term "agile."

Answer 3

To me the most important idea is this:

Requirements changes are going to happen because we are forced to design software at the nadir of knowledge about what is needed (the start of the project) and requirements will only become clearer over the course of the project.

Traditional (Waterfall) approaches try to mitigate this change by locking everyone into a contract at the start of the project by having them sign off on comprehensive specs. This may work as a CYA, but it doesn't make anyone happy to deliver something that doesn't meet the needs of the users especially if their objections are met with "Well you signed off on it!"

Agile Methods are designed to embrace the inevitable changes instead of shielding the development team from them. It does this in a number of ways, chief among them are iterative development and continual involvement by stakeholders in the process. In my experience it leaves everyone involved happier in the end, although it can be more uncomfortable for some management types who are hardcore planners.

Answer 4

In one sentence this looks like this:

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

This is coming from the wikipedia definition, and I like it very much. I highlighted core principles.

Answer 5

I would like to just also add what Agile is NOT. There are a lot of shops out there who claim to be Agile but in a way that just means they aren't interested in planning their projects and expect things done in an unreasonably short period of time.

Agile!=no project plan. It's tough to handle people who implicitly think that statement is false because they tend to be management types and not always easy to contradict.

Answer 6

Employing an agile methodology comes down to emphasizing the delivery of quality products over other aspects of product development and realizing that feedback from the user community is a vital part of creating quality products.

Contrast that with a traditional/waterfall development approach that emphasizes up-front design, documentation, and interface definition while de-emphasizing implementation and transitioning the product from development to release.

In my opinion there is intrinsic quality that a team can build into a product, I see this taking the form of verifying that a product functions as the development team intended and can reasonably accommodate foreseeable enhancements. There are also quality factors based entirely on perception that measure how well a product meets the needs of its users.

Agile approaches tend to deliver products iteratively, incorporating user feedback and developer feedback into each iteration, and promotes delivering each increment of functionality when it achieves minimum viability as a forcing function to elicit frequent user feedback and counteract the tendency of development activities to go on for extended periods of time without feedback from its users. To my mind, other aspects of an agile approaches tend to support these key tenets.

• Emphasizing frequent customer collaboration generates user feedback while remaining flexible to changes in requirements allows product development to regularly integrate that feedback
• Frequent integration into relevant deployment configurations and environments goes hand-in-hand with ongoing identification of which configurations and environments remain relevant in order to ensure that the product remains valuable and relevant to the users providing feedback
• Self-organization and promoting cross-functional teams speaks to creating personal accountability within the team and empowering the team to determine how best to remove roadblocks in an efficient manner without being held back by preassigned roles and management hierarchy within the team

Answer 7

Andy has already linked to the Agile Manifesto, which I think just about covers it.

I think it's useful to look at where the Agile Manifesto came from as well. There were a number of methodologies out there which had some common elements and a lot of similar motivations: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming (list from Alistair Cockburn). The people proposing those methodologies decided to come up with a marketing term to cover the things which they had in common so that the force of what they were saying would be enhanced.

Interestingly (according to what someone told me) there were a number of names on the shortlist which could have been picked instead of "Agile" - one of which was "Adaptive". I personally think that as a single word that sums up better what agile is really about better than "agile"!