Agile Development

There is a controversy when it comes to defining what exactly agile methodology is. If you were to ask most people, especially the development community, would refer to Agile methodology as a software development method where:

• The value of individuals and interactions is favored over processes and tools.*
• The value of working software [or any product] is favored over comprehensive documentation.*
• The value of customer collaboration is favored over contract negotiation.*
• The value of responding to change is favored as opposed to simply following a plan.*

When we are talking about agile methodology, we also think of an umbrella of different methodologies that are utilized to develop software.  Some of the better known methodologies under Agile are Lean Development, Scrum, Kanban and Extreme Programming.

Even though each of these methods is distinctive, they all have at least one similar characteristic: they are much more lightweight in comparison to the common waterfall methodology.
 

The History of Agile Methodology

Methodology for incremental software development has been around since 1957.  In 1974, a paper by E. A. Edmonds introduced an adaptive software development process.  In addition, during the early 1970’s, Tom Gilb published the principles of Evolutionary Project Management (EVO), which transformed into Competitive Engineering.

These so-called “lightweight software development” methods expanded in the mid-1990s as a reaction and solution to the heavyweight waterfall method. At that time, Agile development meant to many going back to the very beginning of software development.

Agile Methodology Today

Scrum, Extreme Programming and Kanban are the main Agile methodologies that are used these days.  Some of the other lesser-known methodologies are DSDM, Crystal and FDD.

Also, these days, Agile Methodology has created a lot of debate within the software industry.  This is because some companies are able to successfully utilize Agile while other companies have tried and failed.

Many of these failed tries can be tracked back to organizations that already had significant internal problems.  What we have learned from this phenomenon is that Agile is not right for every organization; it is absolutely not a silver bullet that will solve internal dysfunctions or problems. In fact, if your organization is already struggling, trying to change to an Agile methodology without addressing organizational and staff problems might make things worse.

However, when implemented in the appropriate environment, agile methodologies will provide more flexibility to organizations in comparison to waterfall methods.

It is also important to note that for many, Agile has transformed into more than just the concepts for Software Development.  

Reference

* Agile Manifesto