Software Development Using Agile Methodology

March 15th, 2010 Leave a comment
Like the article?
Agile Tree

We all have lived through the nightmare of a project lacking the process to guide it. The lack of a process usually leads to unpredictability, lots of repeated error, and wasted effort. We end up having disappointed customers who are not happy with growing budgets, slipping delivery schedules and poor software quality. At the same time developers are disheartened by working ever longer hours to produce ever poorer software. Once we have experienced such a fiasco, we become afraid of repeating this experience again which becomes stressful and no longer fun that we thought software development was supposed to be about. We are afraid that the project will not be delivered on time or that we’ll have to sacrifice quality. We are afraid that project will produce an unwanted product. We are afraid that we’ll have to break our commitments or will have to work 80 hours a week. Mostly important, we become afraid that software development is not enjoyable anymore and it is time to change our career!

This frustration may lead many to believe that they do not have enough process, so they make their process even larger. Unfortunately, a big cumbersome process can create the same problems that it was supposed to prevent. It can slow the team to the extent that schedules slip and budgets sky rocket. In fact, for a long time software engineering methodologies have been criticized for not being so much successful, mostly for their bureaucratic approach and slow development pace, involving a lot of overhead.

This has created a lot of discussions in the past few years on a new software methodology, known as Agile Methodology, which brought a lot of interest in the software world. In early 2001, motivated by the observation that software teams in many corporations were stuck with ever increasing process, a group of industry experts met to outline the values and principles that would allow software teams to develop quickly and respond to change. They called themselves the Agile Alliance. Over two days they worked to create a statement of values, that became known as the manifesto of the Agile Alliance:

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.

While there is no agreement between the inventors on what the keyword “Agile” refers to, “Agile” according to the dictionary definition is “quick, light and nimble” software development process that offers answers to the software industry asking for lighter and faster development processes. These new methodologies are inclined to provide just enough process to achieve an incremental payoff without wasting a lot of time on extensive documentation, since the key part of it is already in the code. While some criticize it as a ticket to hacking, by-passing well established process, it is seen by most as the final end to the bureaucratic traditional engineering methodologies, that have too much process in place. Is Agile methodology completely flawless and is it for you? Feel free to share your experience here.

Help us spread the word!
  • Twitter
  • Facebook
  • LinkedIn
  • Pinterest
  • Delicious
  • DZone
  • Reddit
  • Sphinn
  • StumbleUpon
  • Google Plus
  • RSS
  • Email
  • Print
Don't miss another post! Receive updates via email!