Agile a new methodology

Software has been written for last 30+ years but the story has remained the same for trough out "you write code you create bugs". You deliver but client says its not what is asked for. I am no super coder or a masterful project manager. I have been at the short end of the stick many-a-times. The fact of the matter is that requirements change with time and longer we take to deliver more likely it is client has a change of mind/ or competition came up with better solution before we delivered and now client does not want to be undone by the competition (Fair). The problem lies in the speed at which world is changing, 2 years ago if someone was to take on 2 yr project in ASP.Net 1.1 by the time of the planned release the client would be looking for a solution in ASP.Net 3.5. Now porting it to 3.5 would be a mammoth task (not sure a good example).

For the customers it not only hard to be precise about what's needed, it's also hard to see why it should be difficult to change later. Customers expect software to be soft.Traditional methodologies establish procedures that discourage requirements changes, they resist change. This helps them maintain a predictable schedule, but it does nothing to ensure that the final results meets the customers real, changing needs. While predictability may be very desirable, it can only be achieved by seriously compromising other qualities – particularly the fit of the final result to the real (emerging) requirements.

A typical project plan will indicate that the project requires “three programmers”. Once again, the assumption is that the project can be managed using a defined process, and that the outcome won't depend on the individuals that are assigned. But in our hearts we know that this isn't true – that the outcome depends heavily on the individuals involved. Alistair Cockburn (Author - “Characterizing People as Non-linear, First-Order Components in Software Development”) in particular has presented forceful arguments as to why people need to be considered the most influential factor in project success or failure.

The points above clearly illustrate the failure of earlier methodologies like water fall, spiral etc. one may think why did these why did these work in the past, well the basic reason is that things happen much faster not then it did in the past. MS took years to come up with a new version of office 97 and then 2000 and now they plan to do that practically every year, same is true for many of there products. Customers are now more informative and want to move with the fast paced world.

Agile - Introduction

During the 90s a number of different people realised that things had somehow changed. These people became interested in developing software methodologies that were a better fit with the new business environment – more nimble, easier to manoeuvre through a turbulent business environment. Although the details of these methodologies differ, they all share certain underlying principles, to the extent that these methodologies are often now grouped under the title “agile methodologies”.Given the opportunity to reject the “software engineering” metaphor and start all over again, what would we consider as we were developing a new methodology?·

• Software development is predominantly a design activity·
• Characteristics of individuals are the first-order influence on project activities·
• Modern software development can't rely on individuals – it requires effective teams·
• Customers are unlikely to know what they want in detail before they start·
• Customers need to be able to change requirements without unreasonable penalties·
• The process needs to be flexible·
• Responsibility should be aligned with authority

I am still a student of agile and will be writing more about it in the future.