Introduction

"Agility" refers to the capacity to move quickly and fluidly. It also refers to flexibility, as well as the ability and willingness to adjust. The iterative technique used by agile project management means that project procedures are repeated several times throughout the project's life cycle. The team works in iterations in this case, which are shorter spans of time. Individual iterations may be repeated based on the feedback received. The team selects a subset of the project's activities each iteration and completes all work required to complete that subset. Consider each action as a sequence of little waterfalls. With this iterative process, the project can move forward.

Agile seeks to address this issue by receiving more frequent client feedback to guarantee that the team is developing exactly what the customer wants. Working with an Agile mindset necessitates a constant search for ways to enhance efficiency. This is performed by finding procedures that may be streamlined while retaining product quality and value. Unnecessary paperwork, for example, is a type of waste. Another example of squandering time is spending weeks or months developing a feature only to discover that the customers, who might also be users or stakeholders, dislike it. Customer satisfaction is the primary priority in Agile projects when it comes to creating a high-quality and value product. After all, if it isn't beneficial to the customer, there isn't much purpose in having it.

The problem with traditional approaches to Software Engineering

Traditional software development approaches are based on the software development lifecycle's pre-organized phases and stages. The development flow is unidirectional here, with requirements leading to design, development, testing, and maintenance. Each phase of a traditional technique, such as the Waterfall model, has precise deliverables and detailed documentation that has gone through a thorough review process.

When criteria are well understood — for example, in industries like building, where everyone understands the ultimate output - traditional procedures are appropriate. Traditional development techniques, on the other hand, may fail to meet project goals in fast changing industries such as IT. The key drawbacks of traditional SDLC methodologies are listed below.

• The problem statement/business need must be defined ahead of time. In addition, the solution must be determined ahead of time and cannot be amended or modified.

• The whole set of requirements must be provided at the outset of the project development process, with no opportunity of amending or modifying them afterwards.

For example, the user may have specified preliminary requirements for analyzing their items' sales potential. If the user wants to amend the need and examine the data on product movement by region after the project has started, the user can either wait until the initial requirements are completed or start a new project.

• The user is unable to perform intermediate evaluations to ensure that product development is aligned with the business requirement and that the finished result meets the business requirement.

• The user receives a system that is based on the developer's understanding, which may or may not meet the customer's requirements.

• Documentation becomes a high priority, and its creation becomes costly and time intensive.

• Reusable components are less likely to be created/implemented.

These disadvantages hinder project delivery in terms of cost, effort, time and end up having a major impact on customer relationships.

• Only once the development phase is completed can testing begin. It is not possible to go back and alter anything once the application is in the testing stage, which could have a negative influence on delivery timelines and project costs.

• Projects are occasionally shelved, resulting in an appearance of inefficiency and a loss of time and money.

Traditional development methodologies are only appropriate when the requirements are explicit, that is, when the customer knows exactly what they want and can confidently state that the project's scope will not change significantly throughout development. When the needs are modest and there is a lot of space for modification, it is not ideal for huge projects like maintenance projects.

What is the Agile Methodology?

Agile technique avoids sequential phases in favor of concurrent, incremental work across multiple departments. Teams operate in sprints, which are often divided into two-week chunks of time. Several checkpoints during the project allow the team to pivot if necessary. You can deliver a better end product by constantly monitoring the project's temperature throughout the process.

What is the Agile Manifesto?

The Agile Manifesto is a declaration of software development's essential ideals and concepts. The Agile Manifesto for software development was established in 2001 and is a declaration of four important rules and twelve concepts that serve as a guide for individuals working on agile software. It was developed by a group of 17 experts who had previously used agile methods and were assembled by Kent Beck in the icy mountains of Utah, USA.

The 4 core values of Agile Manifesto are:

• Individuals and interactions over processes and tools. This value emphasizes people communicating with one another above the use of several processes and technologies to force things to happen in a certain way. With a quick dialogue, you could have been able to get the same information in less time.

• Working software over comprehensive documentation. It prioritizes working software over extensive documentation, implying that teams should spend more time working on things that add value than than debating, writing, and revising manuals.

• Customer collaboration over contract negotiation. Customer satisfaction is the primary priority in Agile projects when it comes to creating a high-quality and value product. After all, there's no point in spending time on something that isn't valuable to the consumer. Agile emphasizes the importance of being able to collaborate with customers early and regularly. Instead of waiting for contract conditions to be negotiated before making a few adjustments or requesting resources, teams can swiftly react and adapt to what consumers require.

• Responding to change over following a plan. As I mentioned in the history summary, Agile arose from a world that was changing at such a rapid pace that organizations were unable to adapt and battled to exist. As a result, this value emphasizes the importance of every Agile team accepting change as a given. The more unpredictable a project is, the larger, longer, and more complex it is. For many projects, finalizing a well-established plan from the start will almost certainly result in on-time delivery under budget, but it may also result in the project failing to meet client needs or adding maximum value.

The 12 core principles of Agile Manifesto are:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Whether you're working on a product for your firm or a consumer, there's a good probability that someone is waiting for it to arrive. If that delivery is delayed, the customer, user, or organization will be left waiting for that extra value to be delivered to their lives and processes. Agile emphasizes the need of providing value to users early and often in order to establish a consistent value stream that will benefit both you and your customers. Continuous feedback and early business value realization will help to create trust and confidence.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. It's critical to be agile when working with Agile. That implies being able to move quickly and change directions as needed. That also implies that you and your team are continually scanning your surroundings to ensure that any essential modifications are accounted for in the plans. Recognizing and accepting that your plans may alter (once, twice, or multiple times) helps that you and your customers get the most out of your time together.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Delivering your product in small, frequent increments is critical because it gives stakeholders including customers time and regular opportunity to provide input on its progress. This ensures that the team does not waste time travelling in the wrong direction.

• Business people and developers must work together daily throughout the project. Removing boundaries between developers and people working on the business side of the project fosters trust and understanding, as well as ensuring that developers, or those working on the solution, are aware of the needs of the consumers.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. A successful Agile team consists of people who not only trust each other to complete tasks, but also trust their sponsors and executives to complete tasks. When teams are empowered and motivated to complete difficult initiatives, they provide superior results.

• The most efficient and effective method of information to and within a development is face-to-face conversation. There isn’t anything quite like face-to-face communication. Face-to-face communication allows us to catch certain cues, body language, and facial expressions that are sometimes lost when using forms of communication like email, chat, or the phone. However, we can’t always be face-to-face. Establishing effective communication norms no matter the formats essential to effective teams.

• Working software is the primary measure of progress. The most common technique for Agile teams to demonstrate meaningful work completion is to exhibit a working component of the solution. That might be a working piece of software in a software team. In non-software teams, this could signify a critical component of the solution that is ready to be shown to users or their representatives in order to get feedback. This is in contrast to classic or Waterfall projects, when project document completion might be utilized to track progress. If there is no working, demonstrable item ready to review, it is not adequate to state that the team is 80% done with an activity in Agile project management.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Maintaining a steady yet cautious pace will help you avoid making mistakes. You also don't want your workforce to be overworked or stressed. On the other hand, an under utilized team may become bored and lose its ability to innovate. The Agile aim is to keep the team's effort at a consistent level, avoiding overtime and fatigue.

• Continuous attention to technical excellence and good design enhances agility. This idea states that just because a team is working quickly does not indicate that quality is being sacrificed. The team's agility, efficiency, and speed will be improved by prioritizing quality and design throughout the project development phase. A well-built solution allows a team to respond swiftly to user comments and new information. If the product is of poor quality, however, making modifications can be difficult, time-consuming, and slow down the entire team.

• Simplicity—the art of maximizing the amount of work not done—is essential. Extra features that were not explicitly requested by the user or product owner should not be implemented into the solution by the team. This includes getting rid of procedures that are no longer needed and cutting down on paperwork.

• The best architectures, requirements, and designs emerge from self-organizing teams. Without a management dictating how they operate, team members should be able to get their work done by creating their own work methods and practices. Members of the team should also feel free to ask questions, express concerns, or provide comments.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. It's critical in Agile to recognize that learning from triumphs and errors is a continual process. There is no such thing as an ideal team. Mistakes, obstacles, trials, and victories will all occur. Teams should consider all of these distinct aspects of their activity so that required adjustments can be made.

Extreme Programming

Extreme Programming (XP) encourages constant communication between the client and development teams, as well as fluid communication among all participants, simplicity in implemented solutions, and adaptability to change. XP is particularly well suited to projects with ambiguous and rapidly changing requirements, as well as significant technical risk.

Scrum Methodology

Projects in Scrum are broken into Sprints, which are typically two or three weeks long. A Sprint is a set of features that must be produced within a certain amount of time. Multiple sprints may be merged to make a Release, which is the formal delivery of software/product to the customer/market.

Kanban Method

Kanban is a visual management approach for tracking work as it progresses through a process. Kanban depicts both the process (workflow) and the actual work that passes through it. The purpose of Kanban is to identify and eliminate possible bottlenecks in your process so that work can flow through it at a cost-effective rate.

Dynamic Software Development Method (DSDM)

With the Dynamic Software Development Method (DSDM), you may create a project plan that includes early and continuous delivery, deploying an incremental solution, responding to input received along the way, and ensuring that the promised benefits are reached.

REFERENCES

https://www.digite.com/agile/agile-methodology/

https://www.inflectra.com/ideas/whitepaper/introduction%20to%20agile%20development%20methods.aspx

https://monday.com/blog/project-management/introduction-to-agile/

https://www.coursera.org/learn/agile-project-management/lecture/H5lKZ/introduction-to-course-5