Hello, welcome back. This module we will have an introduction to the Agile software development. In the traditional waterfall approach, the software development is done in a sequence of phases. First, there will be a detailed requirement phase in this phase, the complete set of requirements are captured. Then we will move to a design phase we will complete the high level design, low level design etc. Then we will start with the development followed by testing and then user acceptance and release.
This looks fine as a solid framework. But here we are dealing with human beings, not machines. mistakes can creep in For example, requirements may keep changing. As development progresses, development may take too long or at the end. To keep the schedule, we may have to skip some tests knowingly or by mistake. It is a long time period from the requirements to the delivery.
We don't realize any value until the end of the project. And when we realize it, the customer needs may not remain the same. This approach leave the testing until the end, mistakes are detected late and it will be costlier to fix. We don't seek approval from the stakeholders until late. There is no frequent interaction with the customer. And when we show them the product, it might not be the right product for them.
The planning is done and fixed early in the project and we are managing the project to the plan. There is a heavy dependency on the plan. This traditional approach is heavily reliant upon a project manager driving the way. If we go for a definition from Wikipedia, it says Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self organizing cross functional teams. It promotes adaptive planning, evolutionary development and delivery, a time boxed iterative approach and encourages rapid and flexible responses to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
There are a few key words highlighted here. We will discuss them one by one in the coming slides. agile methods are based on an iterative and incremental development approach, where requirements and solutions evolve through collaboration between self organizing and cross functional teams. It promotes adaptive planning, evolutionary development and delivery, a time boxed iterative approach and encourages rapid and flexible response to change. Agile is an umbrella term for different methods such as XP, Scrum, and dsdm. Agile is much more than a new process is a culturally different way of building products compared to the traditional methods.
In iterative model, the entire development is split into a number of parts. Instead of having a long single phase, the development happens in different smaller iterations. A writ of development is a way of breaking down the software development of a large application into smaller chunks. iterative development software is designed, developed and tested in repeated cycles. As the name suggests, in the incremental model, the development happens in an incremental way. Instead of delivering all at once, we start with an initial one, and keep adding increments to it.
The incremental build model is a method of software development, where the product is designed, implemented and tested incrementally. That is, a little more is added each time until the product is finished. self organizing teams plan and manage their own work on their own. They are not directed by someone outside the team self organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Teams are structured and empowered by the organization to organize and manage their own work. A cross functional team has the right mix of capabilities, they have all the required skills to successfully complete their work.
A cross functional team is a group of people with different functional expertise working towards a common goal. In other words, the team will have all capabilities to accomplish the task assigned to them. In traditional software development planning is predictive. The plan is defined at the beginning of a project and then managing the project to the plan. In adaptive planning, we define an overall plan at the start, but it is not frozen. Once again work starts the plan may change to adapt to the new learnings and changes around us.
Plans for an agile team will be adapted based on the delivery and changes in the requirements each iteration. Benefits of Agile include not limited to accelerate time to market. Agile delivers the right scope at the right time, not all at once. The most important features are delivered earlier than later. It increases project transparency and visibility by having multiple iterations of the end to end development cycle rather than one iteration. agile methods welcome changing requirements.
It addresses evolving requirements and reprioritize. This as needed. reduce risk and overall cost with short delivery cycles and testing. And often to identify potential issues early in the project. Business and developers work together throughout the project. It's improved collaboration and alignment with business organization.
In traditional approach, plan is a one time activity. But in Agile planning is done at different levels. We will have an initial upfront planning at the start and just in time planning iterations introduced traditional approach, the project manager plans for the team, but an agile team is empowered and participates in planning. In traditional approach, detailed requirements are captured and frozen upfront. But in Agile, we have high level requirements to start with. Requirements evolves as project progresses.
In traditional approach, we have huge requirements, documentation, a lot of text and different levels. But an agile requirements are captured in the form of user stories or use cases in a simple way. In traditional approach, limited client collaboration after requirements definition, an agile we collaborate with client throughout the project lifecycle. A recent survey lists down many benefits as listed here. You can visit the website given below for more details. A few of the drivers our ability to manage changing requirements, more visibility, more productivity at a time to market Better Business alignment, etc.
These are mainly due to the issues with the understanding of agile, and issues with its implementations may not be problems with agile. There are situations where documentation is ignored completely. Agile demands more time and energy from everyone. Because developers and customers must constantly interact with each other. At times, it is difficult to ensure this involvement. As agile welcomes change in new requirements, the project can become everlasting because there's no clear end and scope creep may happen.
At times an overall plan in the beginning may not be enough for the clients who work on a specific budget or schedule. They can't predict how much the project will actually cost Teams can get focused into delivering new functionality at the expense of technical debt, which increases the amount of unplanned work. When should we use waterfall over Scrum? You might not have come across this so far, but we can try answering from our understanding. This can be an imaginary answer for an ideal situation. We may prefer a waterfall if the requirements are very clear and frozen.
The customer won't demand any changes. The customer is not ready for frequent interactions. The project is small. Time to market is not important. These can be a few scenarios ajar reduces time to market by delivering the right scope at the right time, not all at once. It is better aligned with business priorities.
It follows short delivery cycles and incremental way of delivery. agile methodologies inherently reduce risk in product development. They do it by using many approaches including short delivery cycles, early testing and early customer feedback, continuous delivery, prioritization, influenced by risk and value, high visibility, risk identification JRT stands for just in time. In this approach, we have a high level plan for long duration a detailed plan for a short duration. detailed plans are created at the time they are needed, not months in advance. Decisions are made at the last responsible moment.
This reduces rework and replan