29

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

Improve this question
9
  • 3
    according to my CompSci teacher in college, "waterfall method, just faster"
    – Malfist
    Nov 1, 2010 at 15:49
  • 11
    @Malfist let's hope he/she stays in academia, where the damage is limited to brains ;-)
    – Steven A. Lowe
    Nov 2, 2010 at 1:47
  • @Steven A. Lowe, the sad thing is, the third chapter of our textbook is "Agile Software Development" and he still has no idea what it is.
    – Malfist
    Nov 3, 2010 at 13:39
  • 2
    @Malfist I happened to be on a big college campus in a major city in the mid 1990s, and wandered in to speak with the Dean of CS. He happened to be in and in a chatty mood, so we talked a little bit about the state of the art and how it was reflected in the college curriculum. He told me "object-oriented programming is just a fad, we don't teach it here". Very sad.
    – Steven A. Lowe
    Nov 3, 2010 at 16:09
  • 1
    Agile methodology is like Chinese language - you do not get it until you learn it ;)
    – Job
    Jan 22, 2011 at 15:56

7 Answers 7

Reset to default
24

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."

Improve this answer
1
  • This really isn't the right answer. Agile is not a methodology, it's a philosophy.
    – RibaldEddie
    Mar 14, 2017 at 16:13
33

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/

Improve this answer
3
  • 1
    The only gotcha is that unless you've seen bad process, the manifesto just doesn't do itself justice. It takes comparison with the bad to really get how much the manifesto is saying. Still, +1 because too many people are confusing agile and Scrum these days. And even then, they are confusing SCRUM with Scrum + XP.
    – MIA
    Dec 30, 2010 at 21:43
  • 2
    Agile can contradict itself sometimes, though. Basically "we value flexibility but we devalue the tools and processes necessary to obtain that flexibility". Good, flexible tools are absolutely essential for responding to change. e.g. Ruby-on-Rails migrations vs. somebody's homemade half-baked ORM system that might require a week to make a simple change to the data model.
    – user8865
    Dec 30, 2010 at 23:08
  • 2
    Just wondering how "Individuals and Interactions" could replace "Processes and Tools" or how could "Working software could be against comprehensive documentation"? These are all different things...Never mind, I have not fallen in love with Agile and I guess that I won't.
    – NoChance
    Jul 4, 2012 at 12:40
13

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.

Improve this answer
0
6

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.

Improve this answer
3

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.

Improve this answer
2
  • Since asking the question till date I have been a part of some of such companies and I agree with you.
    – Chankey Pathak
    Sep 16, 2016 at 9:23
  • Agreed. Many people agile is just a cheap way to do things.
    – ABCD
    Feb 2, 2017 at 23:47
2

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"!

Improve this answer
2

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
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.