Agile Software Development

When we first started using Agile, we were amazed by the sheer quickness with which we were able to respond to change-requests and issue-resolutions; we were amazed by the ease with which we could accomodate new requirements; and most of all we were amazed by the way we could focus on the grass-root level ‘real work’, keeping all the mumbo-jumbo around software development aside. It was all about being quick, aggressive and pragmatic as a team. In a very short period of time, I had become a big fan of Agile. I always found myself convinced that Agile would work, and till date my openion has not changed. Let’s examine some of the key differentiators of Agile methodology over conventional practices:

More often than not customers do not completely know what they actually want at the beginning of a project. Generally this is the time when the project contract is signed. Obviously, more often than not the development team ends up providing a solution which partially or not at all solves their problem (even if contract is met completely). This leads to a very high degree of dissatisfaction among the customers. Agile software development methodology answers the problem with a simple, common sense driven approach to software development. It allows the customer to have a direct visibility into the direction in which the project is heading. This allows them to correct and modify an existing requirement or even come up with a brand new one at any point of time in the project. The transparency that Agile provides results in a high level of confidence and satisfaction among the customers.
Agile is about embracing change. It encourages you to accommodate change at any point of time. It even welcomes the new one. These changes are then added to the wish-list (backlog). And the list is prioritized again with the help of customers.
Agile is about delivering continuous stream of value. It breaks down the task in small pieces of deliverable which can be accomplished in a short period of time, say a fortnight (this is called sprint). These task pieces are called backlog items. The list is then prioritized with the help of the customer. Small deliverables are released on a regular basis based on the backlog. The customers play with it and give their invaluable feedback.

Agile encourages not to plan too far ahead. Agile does not bother you about planning for too remote a future. It plans for one sprint at a time. This gives the customer small deliverables on a frequent basis to work and play with. This also ensures a frequent feedback from the customer.
“Business folks must get involved”, is the trick we missed out on in the conventional software development models, so to say. We did not get the customers involved enough. This resulted in the project floating like a boat without sail. Having regular input and feedback ensures that the team is on the right track. Important and critical features (decided by the customers) are built and tested first. It is also comforting for the customer because he or she has a clear visibility of where his or her investment is at any point of time.

Agile encourages regular Face-to-face communication. Agile understands the fact that most effective communication is, in fact, face-to-face communication. Hence it’s a practice that the team must meet at least for five minutes daily and discuss about what did they did yesterday and what they are planning to do today. It is also discussed if there is any impedance. This sort of meeting is called a scrum in the agile world.
Agile is designed for high degree of customer involvement, less up-front planning (as requirements evolve), and high degree of effective communication both within the team as well as with customers. Transparency and clear communication has resulted in an unprecedented level of customer.

I find this idea of Moving with the Cheese behind Agile extremely exiting, how about you?