Agile Software Development
Agile Methodologies stress responding to change over following plan.
Agile Methodologies can be best understood by explaining what they are not. Agile is not the Waterfall Method, where a plan is created and followed step by step with all members of the project having to wait for a previous step of the process to be completed before they can begin on the next step. Agile is also not a programer creating software as fast as they can by themselves without any documentation.
Agile looks to take process and have it fit the people who are using it rather than forcing people to fit the process. This is usually expressed as creating a plan that is responsive to change, or focusing on people rather than on the plan. A high value is placed on getting feedback as soon as possible and using that to change a project’s course as needed. This allows problems to be caught and addressed early while they are still easy to resolve, rather than allowing them to grow to big problems. This also helps discover problems through seeking out feedback, whereas in a waterfall development model a problem may go unresolved because the individual that discovered the problem does not have a path they can take to quickly adjust the project’s course.
Specific Agile Methodologies are used to address specific types of work environments.
Implementing Kanban is generally used to help organize a large volume of work. Organizing work into tasks helps make the work understandable, a kanban board allows for the quick overview of the status of the work so that bottlenecks can be identified, and moving those tasks towards done helps keep the team on track. Feedback is constantly provided by standups and project manager meetings that are up to the team to schedule.
Scrum is similar, though it tends to focus more on accomplishing very specific goals. Usually a Scrum Master is appointed to help defend the team against other tasks that are looking to take up the team member’s time while the team itself is focused on their sprint. The sprint itself is much like the Kanban board, it is a way to organize the work so that everyone can get an overview of who is working on what. Compared to Kanban, Scrum is more focused on what the next immediate goals are. Feedback is provided by a sprint review at the end of each sprint, where the sprint’s goals are assessed, and the next sprint is created.
Lean methodology is is usually reserved for when a large project does not have the necessary amount of resources to finish in a reasonable timeframe. Here the goal becomes throwing out everything but the absolute essentials. A MVP (Minimum Viable Product) is created as fast as possible so that a review and upgrade process can be established to further grow the base product.
There are many other agile methodologies, including pair programming or even rubber-duck programming, but they are all focused around being adaptive. The goal is to get feedback as soon as possible and use that feedback to improve the project.