Introduction to AGILE Methodology
What is AGILE Methodology?
AGILE software development lifecycle is a practice which means ‘the ability to move quickly & easily’. It promotes continuous iterations/sprints of development and testing throughout the software development lifecycle. AGILE focuses on process adaptability and customer satisfaction by rapid delivery of working software products/modules. Every iteration involves cross-functional departments/teams working concurrently on various areas like planning, requirements analysis, designing, development, unit level, and acceptance testing unlike waterfall model of development.
Brief about AGILE methodology:
1. In traditional models of software development like waterfall model, a project can take several months or years to complete and the customer may not be able to see the progress of the project until the completion of the project.
2. If we talk about high level, Non-AGILE projects may take a lot of time in requirement gathering, finalization of the requirements, designing, development, testing, & before the final deployment of the end product.
3. In contrast to all these points, AGILE methodology allows the projects to split up into sprints during which the pre-determined features are developed, tested & delivered. These sprints/iterations may vary from 1-2 weeks to 2 months based on the size or the module which is getting developed.
4. AGILE products may have 1 or more iterations/sprints to complete the requirement of the customer and deliver the final bug-free product.
The 4 Core values of AGILE methodology are:
1. Individual & team interactions over processes & tools:
The first core value in AGILE is “Individual & team interactions over processes & tools” which emphasis on valuing people & communications over tools and processes because it’s the people who respond back to business need and drive the development process by interacting with other teams.
Example: Just think of some developers sitting in the same room without interacting with each other, they have tools with them but if they are not interacting with each other then just recall one proverb “Fool with a tool is still a Fool”.
2. Working software over comprehensive documentation:
3. Customer collaboration over contract negotiation:
Negotiation is that period when the end customer/client and the product manager work out on the points of delivery, where the renegotiation of the details may be there. But if you want to have the results far better, then only your customer can let you know what he exactly needs to have. Working closing with the customers and communicating with them frequently and have feedback is the reason for the successful development teams.
4. Responding to change over following a plan:
The reality about the software development is “change”. Change may occur in anything like technology change, requirement change, or customer change. There should be some space to allow for a change and respond back to it otherwise, you project plan will become obsolete.
Example: If the customer is asking for some change, then the developers are the first who come to now about these changes and testers are the last if there isn’t any proper communication between the teams and this will make the testers under pressure. So while responding back for changes, the development team must keep first core value in mind to have proper communication in order to have smooth workflow without any chaos.