The Agile Manifesto Made Easy
The Agile Manifesto Made Easy
The agile approach brought about a systemic change in the very evolution of software development; meeting requirements and creating solutions through collaborative effort of self organized, cross functional teams along with their customers and/or end users. Since agile approaches promote evolutionary development, adaptive planning and ongoing enhancements, this has helped accelerate deliveries and has made processes more flexible and responsive to changing requirements.
The agile manifesto
The agile software development manifesto was formulated by 17 signatories – self confessed organizational anarchists – at a ski resort lodge in Utah in 2001. The group of independent thinkers, many whose work put them in direct competition with each other, wanted to encourage professionals to think of “software development, methodologies, and organizations, in new– more agile – ways” and it was this common aim that gave rise to the agile manifesto.
The agile approach is predicated on sustainability in terms of the product’s global applicability and responsiveness to change of requirements. The accent is on adaptability, flexibility and team interaction to achieve better productivity. This approach is responsive to change and is quick to welcome the opportunity to evolve in order to remain competitive. Agile software is predicated upon 12 principles and 4 values or foundational beliefs for all agile processes:
1.Individuals and interactions over processes and tools
Interaction such as pair programming and co-location, motivation, self organization and effective communications are fundamentally important. Hence the manifesto envisages valuing individuals and the interactions between people rather than processes and tools. It is people who create requirements and it is also people who respond to those requirements. In the event, a people centered approach is more responsive and better able to meet those requirements than a tools and processes driven approach. When people are prioritized over tools and processes, communications become need based and fluid and no longer remain rigid or limited in terms of content and scheduling.
2.Working software over comprehensive documentation
Heavy documentation is effort intensive and quickly outdated; with limited usability. The agile approach envisages streamlining of the entire documentation process and eliminating superfluous or time consuming aspects of the documentation required for product development and delivery. Typically, the documentation needed for technical specs, interface design, the technical prospectus, test plans and the approvals required for each would be voluminous and would take up significant amounts of resource expenditure and time. The agile approach values working software more than documentation and views this is more important. In a nutshell, the focus should be on executing over planning
3.Customer collaboration over contract negotiation
It is important to involve the paying customer and/ or the end user into the process of the software development cycle right from the initiation. User feedback can help to create a more faithful and user friendly product and specific requirements can be incorporated at each stage of development. Agile advantages continuing collaboration over negotiations at the contract stage. The key difference between earlier approaches and the agile approach is the involvement of customer feedback and communication of detailed requirements incorporated at each stage of development and not just at the initial negotiation stages. The engaged, involved customer makes for a more effective creation process and a more user friendly product.
4.Responding to change over following a plan
Agile is a much more responsive and intuitive method of functioning as compared to traditional processes that closely focused on following a preset plan. Agile envisages a more ‘agile’, nimble approach where priorities and plans can be altered to improve and add value to both the process of development as well as the final product. The idea is to modify processes to dovetail with changing requirements rather than tweaking or limiting requirements to continue to correspond with the initial assessments.