What is Agile Methodology?

The Agile methodology is a project management and software development approach

that emphasizes flexibility, collaboration, and customer-centricity.
It is the latest model used by major companies today like Facebook, google, amazon,
etc. It follows the iterative as well as incremental approach that emphasizes the
importance of delivering of working product very quickly.

Agile is a project management and software development approach that aims to be

more effective.
1. It focuses on delivering smaller pieces of work regularly instead of one big
launch.
2. This allows teams to adapt to changes quickly and provide customer value faster.

Agile is not just a methodology; it’s a mindset. Agile isn't about following specific
rituals or techniques.
Instead, it's a bunch of methods that show a dedication to quick feedback and always
getting better.

Methodology-
Agile methodologies are iterative and incremental, which means it's known for
breaking a project into smaller parts and adjusting to changing requirements.
1. They prioritize flexibility, collaboration, and customer satisfaction.
2. Major companies like Facebook, Google, and Amazon use Agile because of its
adaptability and customer-focused approach.

History of Agile
 In 1957, people started figuring out new ways to build computer programs. They
wanted to make the process better over time, so they came up with iterative
and incremental methods.
  In the 1970s, people started using adaptive software development and
evolutionary project management. This means they were adjusting and evolving
how they built software.
 In 1990s, there was a big change. Some people didn't like the strict and super-
planned ways of doing things in software development. They called these old
ways "waterfall." So, in response, lighter and more flexible methods showed up.
These included:
o Rapid Application Development (RAD) in 1991.
o Unified Process (UP), Dynamic Systems Development Method (DSDM) in
1994.
o Scrum in 1995.
o Extreme Programming (XP) in 1996.
o Feature-Driven Development (FDD) in 1997.
 In 2011, the Agile Alliance, a group of agile enthusiasts, made the Guide to Agile Practices
(later called Agile Glossary). This was like a shared document where agile people from
around the world put down their ideas, terms, and guidelines. It's a bit like a dictionary for
how to do agile things.

Life cycle of Agile Methodology

The Agile software development life cycle helps you break down each project you take
on into six simple stages:
Steps -

Manifesto for Agile Software Development

The Manifesto for Agile Software Development is a document produced by 17
developers at Snowbird, Utah in 2001. This document consists of 4 Agile Values and
12 Agile Principles. These 12 principals and 4 agile values provide a guide to Software
Developers. The Manifesto for Agile Software Development emerged as a
transformative guide to Software Development.

Agile Software Development -

Frameworks -
Types of Agile Frameworks
1. Kanban
2. Scrum
3. Lean
4. DSDM or Dynamic Systems Development Method ·
5. XP or Extreme Programming
6. FDD or Feature Driven Development

What is the Agile Process?

The Agile process is a way of developing software (or completing projects) by
breaking them into smaller parts called iterations or sprints.
 Instead of trying to plan everything in detail from the beginning, Agile focuses on
flexibility, continuous improvement, and delivering small but functional pieces of the
project quickly.
The meaning of Agile is swift or versatile."Agile process model" refers to a software
development approach based on iterative development.
Agile methods break tasks into smaller iterations, or parts do not directly involve long
term planning.
The project scope and requirements are laid down at the beginning of the
development process.
Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks.
The division of the entire project into smaller parts helps to minimize the project risk
and to reduce the overall project delivery time requirements.
Each iteration involves a team working through a full software development life cycle
including planning, requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.
Phases of Agile Model:
Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

Key Features of the Agile Process:

1. Iterative Development: Work is done in short cycles (1–4 weeks) called sprints,
allowing teams to review progress regularly.
2. Customer Collaboration: Customers or stakeholders are involved throughout
the project to provide feedback and ensure the final product meets their needs.
3. Flexibility: Changes in requirements are welcome, even late in the process.
4. Frequent Delivery: Deliver small, working versions of the software regularly, not
just at the end of the project.
5. Teamwork: Everyone, including developers, testers, and business stakeholders,
works together closely.

Principles of Agile (in Simple Terms):

1. Customer Satisfaction First: The highest priority is to satisfy the customer by
delivering valuable software quickly and regularly.
2. Welcome Changes: Be ready to adjust to new requirements, even late in the
project, to keep improving the product.
3. Frequent Deliveries: Deliver working software frequently, typically in weeks
rather than months.
 4. Teamwork with Stakeholders: Work together with customers and stakeholders
throughout the project.
5. Build Trust: Build projects around motivated team members. Provide them with
the tools and support they need and trust them to do their work.
6. Face-to-Face Communication: The best way to share information within the
team is through direct communication.
7. Working Software as Progress: Progress is measured by working software, not
by how much documentation or planning has been done.
8. Technical Excellence: Focus on good design and technical practices to improve
quality and flexibility.
9. Continuous Attention to Technical Excellence and Good Design
10. Simplicity: Do only what’s necessary; avoid unnecessary complexity.
11. Self-Organizing Teams: Allow teams to make decisions and organize themselves.
This often leads to the best results.
12. Reflection and Improvement: At regular intervals, reflect on what went well
and what didn’t, and make changes to improve.

Challenges in Agile Methodology

1. Balancing Flexibility and Stability:
o Ensuring the system can adapt without compromising performance or
stability.
2. Communication:
o Coordinating architectural decisions across teams, especially in large or
distributed organizations.
3. Technical Debt: Continuous iteration can lead to accumulating shortcuts or

inefficiencies if not managed.

4. Scalability:
o Designing an architecture that can scale while still being developed
incrementally.
Why Agile?
• Faster Delivery: Smaller deliverables reach the customer more quickly.
• Better Quality: Continuous testing and feedback improve quality.
• Happy Customers: Regular involvement ensures the product matches their
needs.
• Reduced Risk: Frequent deliveries help detect issues earlier.

Working principle of agile –

1. Customer Satisfaction Through Early and Continuous Delivery
 Deliver valuable software to customers frequently.
 Prioritize customer needs by ensuring functionality is provided early and
updated often.
2. Welcome Changing Requirements
 Embrace changes, even late in development, as they can lead to competitive
advantage.
 Agile processes are designed to accommodate evolving business needs.
3. Frequent Delivery of Working Software
 Deliver functional software in short, regular iterations (e.g., every 2-4 weeks).
 Focus on completing small, incremental features.
4. Collaboration Between Business Stakeholders and Developers
 Maintain close, daily interaction between developers and business teams.
  Ensure all parties understand and contribute to the goals of the project.
5. Support and Trust Motivated Individuals
 Build projects around motivated individuals and trust them to do their work.
 Provide the necessary support and environment for success.
6. Face-to-Face Communication
 Promote direct communication as the most efficient way to convey information.
 Use tools like video calls, stand-up meetings, or in-person discussions.
7. Working Software as the Primary Measure of Progress
 Focus on producing software that works and delivers value, rather than just
meeting deadlines or documenting processes.
8. Sustainable Development
 Maintain a constant pace of development that can be sustained indefinitely.
 Avoid burnout by balancing workloads.
9. Continuous Attention to Technical Excellence and Good Design
 Focus on high-quality code and architecture to make changes easier.
 Emphasize simplicity in design and execution.
10. Simplicity
 Maximize work not done by eliminating unnecessary complexity.
 Deliver only what's required and valuable.
11. Self-Organizing Teams
 Empower teams to make decisions and determine how to accomplish their
work.
 Leverage the collective intelligence of team members.
12. Regular Reflection and Adaptation
 Conduct retrospectives to assess performance and identify areas for
improvement.
 Continuously refine processes to enhance efficiency and collaboration.
What is Scrum?
Scrum is a framework within the Agile methodology used for managing and
completing complex projects.
It is especially popular for software development but can be applied to other fields as
well.
Scrum focuses on delivering value in small, iterative cycles called sprints, which
typically last 1–4 weeks.
The framework emphasizes team collaboration, transparency, and adaptability,
enabling teams to respond quickly to changes.
Scrum is a management framework that teams use to self-organize tasks and work
towards a common goal.
It is a framework within which people can address complex adaptive problems while
the productivity and creativity of delivering products are at the highest possible
value.
Scrum is a management framework that teams use to self-organize and work towards
a common goal.
Silent features of Scrum
 Scrum is a light-weighted framework
 Scrum emphasizes self-organization
 Scrum is simple to understand
 Scrum framework helps the team to work together
 Lifecycle of Scrum

 Sprint: A Sprint is a time box of one month or less. A new Sprint starts
immediately after the completion of the previous Sprint.
 Release: When the product is completed, it goes to the Release stage.
 Sprint Review: If the product still has some non-achievable features, it will be
checked in this stage and then passed to the Sprint Retrospective stage.
 Sprint Retrospective: In this stage quality or status of the product is checked.
 Product Backlog: According to the prioritize features the product is
organized.
  Sprint Backlog: Sprint Backlog is divided into two parts Product assigned
features to sprint and Sprint planning meeting.

Key Elements of Scrum:

1. Roles:
o Product Owner: Defines the vision, manages the product backlog, and
ensures the team delivers value to the customer.
o Scrum Master: Facilitates the process, removes obstacles, and ensures
adherence to Scrum principles.
o Development Team: Cross-functional group responsible for delivering the
product increment.
2. Artifacts:
o Product Backlog: A prioritized list of features, enhancements, and fixes
required in the product.
o Sprint Backlog: A subset of items from the product backlog that the team
commits to completing in a sprint.
o Increment: The working product or feature completed during the sprint.

Advantage of Scrum framework

 Scrum framework is fast moving and money efficient.
 Scrum framework works by dividing the large product into small sub-products.
It’s like a divide and conquer strategy
 In Scrum customer satisfaction is very important.
 Scrum is adaptive in nature because it have short sprint.
 As Scrum framework rely on constant feedback therefore the quality of product
increases in less amount of time
Disadvantage of Scrum framework
  Scrum framework do not allow changes into their sprint.
 Scrum framework is not fully described model. If you wanna adopt it you need
to fill in the framework with your own details like Extreme
Programming(XP), Kanban, Dynamic Systems Development Method (DSDM).
 It can be difficult for the Scrum to plan, structure and organize a project that
lacks a clear definition.
 The daily Scrum meetings and frequent reviews require substantial resources.
The six Scrum principles
1. Empirical Process Control (no clear solution) - This principle emphasizes the
core philosophy of Scrum based on the three main ideas of transparency,
inspection, and adaptation.
Empirical process control aids learning through experimentation, especially
when the problem is not well defined or when there are no clear
solutions. More
2. Self-organization - This principle focuses on today’s workers, who deliver
significantly greater value when self-organized, and this results in better team
buy-in and shared ownership and an innovative and creative environment which
is more conducive for growth. More
3. Collaboration - This principle focuses on the three core dimensions related to
collaborative work: awareness, articulation, and appropriation.
It also advocates project delivery as a shared value-creation process with teams
working and interacting together, as well as with the customer and other
business stakeholders, to deliver the greatest value. More
4. Value Based Prioritization - This principle highlights the focus of Scrum to
deliver maximum business value, from early in the project and continuing
throughout. More
5. Time-boxing - This principle describes how time is considered a limiting
constraint in Scrum and used to help effectively manage project planning and
execution.
 Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint
Planning Meetings, Sprint Review Meetings, and Retrospect Sprint
Meetings. More
6. Iterative Development - This principle defines iterative development and
emphasizes how to better manage changes and build products that satisfy
customer needs. It also delineates the Product Owner’s and organization’s
responsibilities related to iterative development

What is Extreme Programming?

eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands
or requirements, or when they are not sure about the system's performance.

Extreme programming (XP) is one of the most important software development

frameworks of Agile models.
It is used to improve software quality and responsiveness to customer requirements.
Extreme Programming (XP) is an Agile software development methodology that
focuses on delivering high-quality software through frequent and continuous
feedback, collaboration, and adaptation.
XP emphasizes a close working relationship between the development team, the
customer, and stakeholders, with an emphasis on rapid, iterative development and
deployment.
Extreme programming is one of the most popular and well-known approaches in the
family of agile methods.
an XP project starts with user stories which are short descriptions of what scenarios
the customers and users would like the system to support.
Each story is written on a separate card, so they can be flexibly grouped.

 Code Review: Code review detects and corrects errors efficiently. It suggests pair
programming as coding and reviewing of written code carried out by a pair of
programmers who switch their work between them every hour.
 Testing: Testing code helps to remove errors and improves its reliability.
XP suggests test-driven development (TDD) to continually write and execute test
cases. In the TDD approach, test cases are written even before any code is
written.
 Incremental development: Incremental development is very good because
customer feedback is gained and based on this development team comes up
with new increments every few days after each iteration.
 Simplicity: Simplicity makes it easier to develop good-quality code as well as to
test and debug it.
  Design: Good quality design is important to develop good quality software. So,
everybody should design daily.
 Integration testing: Integration Testing helps to identify bugs at the interfaces of
different functionalities. Extreme programming suggests that the developers
should achieve continuous integration by building and performing integration
testing several times a day.

ROLES OF EXTREME PROGRAMMING –

The Whole Team
Like the Scrum team, the XP Team is also self-organized, cross-functional, and co-
located and also does ceremonies like planning meetings, daily standup meetings,
review meetings, and retrospective meetings in each iteration.

XP Coach
Since the team is self-organized and cross-functional, a management layer or explicit
leadership role is often found not useful.
Instead of traditional management roles, the XP Coach plays a supporting role in the
team’s success.
A coach helps a team follow the process and helps the team to learn discipline and
make sure that XP Principles are followed well by the team.

On-Site Customers
As the Product Owner role in the scrum, in XP - the On-Site Customer role is
responsible for maximizing the product value and defining the features and stories
with acceptance criteria.

Programmer
The XP team has 4-10 developers who can work together practicing XP core values like
pair programming, practice test-driven development, continuous integration,
automation testing, and reducing technical debt by refactoring the code as required.

Testers
Tester is also one of the important roles and a rule of thumb is to have one tester per
four programmers. in some cases, XP team members play the role of testers and there
aren't any dedicated testers, the programmers and the on-site customers are
expected to fill the role by using strategies like Test-Driven Development, automated
regression testing, or exploratory testing.

XP Tracker
XP Tracker is the role to keep track of the team's progress at an iteration level.

Sponsor
The sponsor is the person who is funding the project and is a very important
stakeholder of the project. A team must interact with sponsors regularly to provide
demos and get valuable feedback.

Advantages of Extreme Programming

1. High Software Quality:
o Continuous testing and refactoring improve the quality of the code.
 2. Fast Feedback Loops:
o Customers can see progress quickly and provide input to ensure the
software meets their needs.
3. Reduced Risks:
o Small releases and frequent feedback reduce the chances of project
failure.
4. Enhanced Collaboration:
o Pair programming and collective code ownership foster teamwork and
knowledge sharing.
5. Flexibility:
o Easily adapts to changing customer requirements.

Principles-
1.coding –
The concept of coding which is used in the XP model is slightly different from
traditional coding. Here, the coding activity includes drawing diagrams (modeling)
that will be transformed into code, scripting a web-based system, and choosing
among several alternative solutions.
2.testing
3.listening –
The developers need to carefully listen to the customers if they have to develop good
quality software. Sometimes programmers may not have the depth knowledge of the
system to be developed. So, the programmers should understand properly the
functionality of the system and they have to listen to the customers.

4. Designing-
Without a proper design, a system implementation becomes too complex, and very
difficult to understand the solution, thus making maintenance expensive.
5.Pair Programming –
 XP encourages pair programming where two developers work together at the
same workstation.
This approach helps in knowledge sharing, reduces errors, and improves code
quality.
6. Refactoring –
XP encourages refactoring, which is the process of restructuring existing code to
make it more efficient and maintainable.

Challenges of Extreme Programming

1. Requires Discipline:
o Teams need to strictly follow practices like TDD and pair programming,
which can be challenging for inexperienced teams.
2. Customer Availability:
o Having an on-site customer is not always feasible for every project.
3. Not Suitable for All Projects:
o Works best for small to medium-sized projects where requirements are
likely to change frequently.
4. Overhead Costs:
o Practices like pair programming may increase initial costs and time
investment.
When to Use Extreme Programming
• Projects with rapidly changing requirements.
• Teams that can work in close collaboration with customers.
• Environments, where delivering high-quality software quickly is critical.
User Stories
User stories are a key component of agile software development.
They are short, simple descriptions of a feature or functionality from the perspective
of a user.
User stories are used to capture requirements in an agile project and help the
development team understand the needs and expectations of the users.

In agile software development, user stories are typically written on index cards or in a
digital format, and are used to drive the development process.
The development team uses user stories to plan and prioritize work, estimate the
effort required for implementation, and track progress towards completing the user
stories.
By using user stories in agile software development, teams can ensure that they are
building software that meets the needs of the users and delivers value to the
business.

Here are some key characteristics of user stories:

1. User-centric: User stories focus on the needs of the user and what they want to
achieve with the software.
2. Simple: User stories are short and simple descriptions of a feature or
functionality.
3. Independent: User stories can stand on their own and do not depend on other
user stories.
4. Negotiable: User stories are open to discussion and can be refined and modified
based on feedback from stakeholders.
5. Valuable: User stories provide value to the user and the business.
6. Estimable: User stories can be estimated in terms of time and effort required
for implementation.
 7. Testable: User stories can be tested to ensure they meet the needs of the user.
8. Prioritized: User stories are prioritized based on their importance to the user
and the business goals.
9. Iterative: User stories are developed iteratively, allowing for feedback and
changes throughout the development process.
10. Consistent: User stories follow a consistent format, making them easy to
understand and work with.
11. Contextual: User stories are written in a way that provides context to the
development team, helping them understand the user’s needs and goals.
12. Acceptance criteria: User stories have clear and specific acceptance
criteria that define when the story is considered “done” and ready for release.
13. Role-based: User stories are written from the perspective of a specific
user role, helping to ensure that the development team is building features that
are relevant and useful to that user.
14. Traceable: User stories are tracked and linked to specific features and
functionality in the software, making it easy to trace back to the original user
need.

Example:
• As a customer, I want to view my order history so that I can track my purchases.
• As an administrator, I want to manage user accounts so that I can ensure system
security.
Key Elements of a User Story:
1. Title: A concise summary of the story.
o Example: "View Order History"
2. Description: Details the goal of the story using the format above.
3. Acceptance Criteria: Defines the conditions that must be met for the story to be
considered complete.
o Example:
 Users can view a list of their past orders.
  Users can filter orders by date.
4. Story Points (Optional): A measure of effort or complexity assigned by the
team.
5. Priority: Helps determine the importance and sequencing of the story.

Working with User Stories :

1. Once the user story is fully written then it undergoes review and verification.
2. In project workflow meetings it is reviewed and verified then added to the
actual workflow.
3. Actual requirements and functionality are decided based on the stories.
4. User stories are scored based on their complexity and the team starts work
based on user stories.

Advantages of User Stories:

1. User stories help to keep the focus on the user’s needs and expectations, which
leads to better customer satisfaction.
2. User stories are easy to understand and can be created quickly, which speeds up
the requirements gathering process.
3. User stories are flexible and can be refined and modified easily as requirements
change.
4. User stories are independent, which makes it easier to prioritize and plan the
work.
5. User stories are small and manageable, which makes it easier to estimate effort
and track progress.
 6. User stories promote collaboration between stakeholders, which leads to better
communication and understanding.

Agile Software Development Tools

An Agile Tool for software development is a software application or a platform that
enables the teams to manage and track the Agile project more efficiently.
These Agile methodologies are increasing day by day in project management due to
their flexibility and ability to adapt to the changes in the requirements of the
projects.
Therefore, these agile tools provide a digital workspace where the teams can plan,
collaborate, and execute their projects by using the principles of Agile.

An Agile Tool for software development is a software application or a platform that

enables the teams to manage and track the Agile project more efficiently.

1. Jira: An Agile Tool

Jira is the most widely used Agile tool which is mainly used for issue tracking, bug
tracking and agile project management, it is also used by a large number of clients
and the users all over the world.
 Jira tool is also used for backlog tracking and release planning , CI/CD and developer
tools integrations.
Features:
 Jira offers multiple features such as project tracking, reporting, tracking and
collaborating with the team.
 Jira mainly offers issue prioritization and also allows the software testers to
point out the major issues in the software development and products.

2. GitHub: An Agile Tool

GitHub is another widely used web based platform ideal for project management
as it allows the software development teams to perform the tasks effectively and
track the progress of the task at one place.
GitHub allows sharing the tasks and it also allows collaboration with the other
team members.
Features
 GitHub helps in safely managing the templates and also repositories of the
codes.
 GitHub improves the code writing and increases the safety of the code.
 With the help of GitHub easy code hosting and effective team management is
possible.

7. Jenkins: An Agile Tool

Jenkins is an open source and free automation server ideal for creating, testing and
deploying the software applications, it is one of the most popular automation servers
which is used in the DevOps community.
Jenkins is used for automatically building, testing and deploying the applications
whenever the codebase is modified.
Features:
  Jenkins allows the distributed builds to various computers for increase in the
performance.
 Jenkins integrates with the different tools used throughout the lifecycle of
software development.

4. Planbox: An Agile Tool

Planbox is a type of cloud based

Test Driven Development TDD -

Test Driven Development (TDD) is a software development methodology that
emphasizes writing tests before writing the actual code.
It ensures that code is always tested and functional, reducing bugs and improving
code quality.
In TDD, developers write small, focused tests that define the desired functionality,
then write the minimum code necessary to pass these tests, and finally, refactor the
code to improve structure and performance.
This cyclic process helps in creating reliable, maintainable, and efficient software.
By following TDD, teams can enhance code reliability, accelerate development cycles,
and maintain high standards of software quality.

Test-driven development (TDD) is a method of coding in which you first write a test
and it fails, then write the code to pass the test of development, and clean up the
code.
This process recycled for one new feature or change.
In other methods in which you write either all the code or all the tests first, TDD will
combine and write tests and code together into one.
Test-Driven Development (TDD) is a method in software development where the
focus is on writing tests before writing the actual code for a feature.
This approach uses short development cycles that repeat to ensure quality and
correctness.

Process of Test-Driven Development (TDD)

It is the process in which test driven are written before the code that validates those
cases. It depends on the repetition of a concise development cycle.
Test-driven Development is a technique in which automated Unit tests are used to
drive the design and free decoupling of dependencies.
The following sequence of steps is generally followed:
Test Driven Development (TDD)
• Run all the test cases and make sure that the
new test case fails.
• Red – Create a test case and make it fail, Run the
test cases
• Green – Make the test case pass by any
means.
• Refactor – Change the code to remove duplicate/redundancy.
• Refactor code – This is done to remove duplication of code.
• Repeat the above-mentioned steps again and again
Advantages of Test-Driven Development (TDD)
• Unit test provides constant feedback about the functions.
• Quality of design increases which further helps in proper maintenance.
• Test driven development act as a safety net against the bugs.
 • TDD ensures that your application actually meets requirements defined for it.
• TDD have very short development lifecycle.

Disadvantages of Test-Driven Development (TDD)

• Increased Code Volume: Using TDD means writing extra code for tests cases,
which can make the overall codebase larger and more Unstructured.
• False Security from Tests: Passing tests will make the developers think the code
is safer only for assuming purpose.
• Maintenance Overheads: Keeping a lot of tests up-to-date can be difficult to
maintain the information and it is also time-consuming process.
• Time-Consuming Test Processes: Writing and maintaining the tests can take a
long time.
• Testing Environment Set-Up: TDD needs to be a proper testing environment in
which it will make effort to set up and maintain the codes and data.

Pair Programming-

Pair programming is a software development practice where two programmers work

together on one computer.
It involves one programmer, the driver, writing code while the other, the observer or
navigator, reviews each line of code as it’s typed.
This real-time collaboration helps catch errors early, improves code quality through
constant feedback, and ensures better design decisions.
It also facilitates knowledge sharing and reduces the likelihood of bugs, leading to
more efficient problem-solving and enhanced productivity within the development
team.
Pair programming is a development technique in which two programmers work
together at a single workstation.
A person who writes code is called a driver and a person who observes and
navigates each line of the code is called a navigator.
They may switch their role frequently. Sometimes pair programming is also known
as pairing.
Pairing Variations: There are three pairing variations –
• Newbie-newbie pairing can sometimes give a great result because it is better
than one solo newbie. But generally, this pair is rarely practiced.
• Expert–newbie pairing gives significant results. In this pairing, a newbie can
learn many things from an expert, and an expert gets a chance to share his
knowledge with a newbie.
• Expert–expert pairing is a good choice for higher productivity as both would be
experts, so they can work very efficiently.

How does pair programming work?

Pair programming is a collaborative software development technique where two
programmers work together at one workstation.
One assumes the role of the driver, actively typing code, while the other acts as
the navigator, reviewing each line for strategic direction, potential issues, and
improvements.
They frequently switch roles to maintain engagement and share knowledge
effectively.
This method enhances code quality through immediate error detection and fosters
communication, speeding up problem-solving and reducing knowledge silos within
the team.
Pair programming can occur in various forms, including remote setups using
collaborative tools or as part of mob programming with larger teams tackling complex
challenges together.
Advantages of Pair Programming
 Two brains are always better than one -
If driver encounters a problem with code, there will be two of them who’ll solve
problem

 Detection of coding mistakes becomes easier –

Navigator is observing each and every line of code written by driver.

 Mutual Learning –
Both of them can share their knowledge with each other and can learn many
new things together.

 Team Develops better communication skills

 Better Designs
 Team Bonding:
 High Quality Code
Disadvantages of Pair Programming
 Team Fit
 Newbie-newbie pairing problem
 Individual Productivity Concerns
 Skill and Personality Compatibility
 Dependency Risk

Techniques
Pair programming is more than just putting two developers together.
Over time, experts have developed and improved different ways to
make it work for different situations
Driver-Navigator: In this method, one programmer (the driver) actively
writes code, while the other (the navigator) reviews each line and provides
guidance

Ping-pong: In Ping-Pong method, programmers switch roles rapidly, with

each taking turns to write failing tests and then writing code to pass those
tests.

Unstructured style: The unstructured style of pair programming is informal

and lacks a defined process or guidance. Typically, two programmers with
similar skill levels work together in an ad hoc manner, without strict rules or
frameworks

Continuous Integration (CI)

Continuous Integration, also known or called as CI in short.
It is a part of the software development process generally used in DevOps practices
where users/teams can collaborate and seamlessly work together to integrate new
code changes or add new features into the existing codebase using a version control
system.

Continuous Integration (CI) is a software development practice where developers

frequently integrate their code changes into a shared repository, typically multiple
times a day.
Each integration triggers an automated build and testing process to ensure the new
code works with the existing codebase without introducing errors.
The goal of CI is to detect and fix integration issues early, improve collaboration, and
maintain a working version of the software at all times.

Key Steps in Continuous Integration

1. Code Commit:
Developers write and commit small chunks of code to a version control system
(e.g., Git).
2. Automated Build:
When code is pushed to the repository, an automated process compiles the
code, assembles dependencies, and prepares the application for testing.
3. Automated Testing:
Automated tests (unit, integration, and sometimes functional tests) are
executed to verify the correctness of the code.
4. Feedback:
The CI system provides immediate feedback on the success or failure of the
build and tests. Developers can quickly address any issues.
 Collaboration:
CI encourages collaboration among developers by making code changes visible
to the team and promoting frequent code reviews.

Why Continuous Integration is Important

1. Early Detection of Bugs:
CI helps identify and fix issues early in the development cycle, reducing the cost
and effort of fixing bugs later.
2. Improved Collaboration:
Teams work on the same codebase and integrate changes frequently, reducing
integration conflicts and silos.
3. Faster Delivery:
Automating builds and tests speeds up the development process, allowing
teams to deliver features faster.
 4. Higher Code Quality:
Automated tests ensure that only tested and reliable code is integrated into the
main branch.
5. Reduced Risk:
Frequent testing and integration minimize the risk of major failures when
merging large chunks of code.
6. Continuous Feedback:
Developers get instant feedback on their code, allowing them to fix errors
before moving on to new tasks.
7. Stable Codebase:
A properly implemented CI process ensures that the main branch is always
stable and deployable.

Best Practices for Continuous Integration

1. Commit Code Frequently:
Commit small, incremental changes to avoid large, error-prone integrations.
2. Automate Testing:
Use automated tests (unit, integration, and regression) to catch issues early.
3. Maintain a Single Source of Truth:
Use a version control system (e.g., Git) for all code and configurations.
4. Build Fast:
Optimize the build process to provide feedback to developers as quickly as
possible.
5. Fix Build Failures Immediately:
Treat build failures as high-priority issues to maintain a healthy codebase.
6. Use a CI Server:
Tools like Jenkins, Travis CI, Circle-CI, or GitLab CI/CD can automate the CI
process.

Popular CI Tools
• Jenkins: Open-source and highly customizable.
 • GitHub Actions: CI/CD directly integrated with GitHub repositories.
• GitLab CI/CD: Built into GitLab, supports CI/CD pipelines.
• Circle-CI: Simplifies CI/CD with pre-configured pipelines.
• Azure DevOps: Comprehensive tool for CI/CD and project management.

Challenges in Continuous Integration

1. Slow Build Times:
Complex projects may lead to long build times, slowing down feedback.
Solution: Optimize tests and use parallel testing.
2. Flaky Tests:
Unreliable tests can create false positives or negatives, reducing trust in CI.
Solution: Identify and fix or remove flaky tests.
3. Cultural Shift:
Teams unfamiliar with CI may resist adopting it due to the required discipline
and changes in workflow.
Solution: Provide training and highlight the benefits.

Agile Release Planning:

Consider agile launches with the aid of making plans and organizing the journey to
release new features. It's a different part from the Instead, you ruin it down into
chew-sized chunks known as sprints or iterations.

The primary purpose of release planning is to make a plan to deliver an increment to

the product.
It is done in the interval of every 2 to 3 months.
Following person are involved in product releasing plan-
Scrum Master, Product Owner, Agile Development Team, Stakeholders.
  Scrum Master: The Scrum Master is a team leader and facility provider who
helps the team member to follow agile practices so that they can meet their
commitments and customers’ requirements.
 Product Owner: The Product Owner is one who runs the product from a
business perspective. He defines the requirements and prioritizes their values.
 Agile Development Team: Agile development team provides the judgment on
the technical feasibilities or any dependencies.
 Stakeholders: Stakeholders are the customers, subject matter, program
manager act as advisers in decisions which are made around the release
planning.

Steps –
1. Determine your Product Vision

Creative strategy –
Start by defining the massive image of your product. Consider market tendencies,
client profiles, and advertising agency goals to decide the direction of your group’s
adventure.

Focus on what matters -

Identify key abilities and features so that you can still offer the most value to your
customers.

Innovation and predictability: -

Find the proper balance between innovation and predictability in your product
layout. Innovation creates opposition, and predictability guarantees that your clients
are balanced and dependable.

2. Review your Product Backlog and Rank the Features

 Background Optimization –
Dive into your product backlog, prioritizing products primarily based on
their strategic significance and potential impact.

Prioritize
 Scripting the backlog: Create purchaser proofs and recognition criteria for each
object backlog, making sure requirements and validating assumptions.

3. Host a Scrum Release Planning Meeting-

Film Goals –
Set easy and measurable dreams, and begin by placing targeted and
predictable manufacturing facility dreams to your product.

Tactical Credentials: Break down removal requests into actionable

obligations and deliverables, assign administrative responsibilities based
on their good judgment and availability

Integrated release

4. Finalize and release the Planning Schedule

Sprint Storytelling –
Execute the release procedure in repetitive sprints, mostly shifting highly-priced
features and activities
Memory Lane Sprints –
Bold Plot Twist- Include the twists of the longer drainage system. Be open to
changing priorities.

Important

1. Methods and frequency:

In a slow global software system development process, implementing an agile
methodology for incremental improvement is like keeping a dynamic dance
It ensures that the product is developed at just the right speed, enabling teams to
respond quickly to changes in consumer preferences and market growth. Looking
ahead to greater exposure, an Agile launch-making process encourages a daily
demonstration of product innovation, keeping customers more engaged and happy.

2. Status and Impact:

Imagine building a residential brick at a time. By breaking down product development
into logical increments, Agile release processes provide consistent and continuous
improvement across all versions of the product Each product introduction comes at a
cost including, accurately meeting customer preferences and expectations.
This approach not only creates customer pride but also strengthens the overall
reputation of the product in the market.

3. Risk Reduction:
In the unpredictable international environment of software development, surprises
are inevitable. However, an agile release tool acts as a safeguard, enabling teams to
create and address issues earlier in the development cycle. By repeatedly releasing
low-level updates, teams can gather valuable feedback, iterate their responses, and
evolve quickly if desired.
This proactive approach to risk management reduces costly mistakes ensures smooth
sailing at some point in the development journey requirements and validates
assumptions.

4. Stakeholder Alignment:
When it comes to a clean startup plan, the purpose is to get everybody on the same
page.
 The platform brings stakeholders together, from product proprietors to development
teams and advertising and marketing organization leaders.

Prerequisites of Planning:
• A Product Owner manages the ranked product backlog. While releasing the
product, the Product owner feels to include five to ten features at the period of
product release.
• High- level vision
• Market and Business objective
• Team's input according to capabilities, known velocity, or about any technical
challenge.
• Acknowledged about the new product backlog items are needed Material
Required:

 Flip charts, markers, whiteboards

 Posted agenda, purpose
 Projector for sharing the data/tools of computers required during a
planning meeting
 Planning data (The list of data needed during release planning are as
follow
Output:
• Release plan
• Commitment
• Issues, dependencies, concerns, and assumptions which are to be monitored
• It suggests improving future release planning
Burn Down Charts:
As we know most IT companies are using the Agile software development approach
for software development, in that we have many facilities to keep track of the
complete development process.
One of them is a burn-down chart. This chart helps to determine work done in each
iteration, how much work is remaining, how much work has been completed till now,
and what is the expected deadline the remaining portion will be completed.
Burndown chart is a major parameter used in agile software development and
scrum to detect how much work remains to be completed.
It is the graphical representation of showing the left-out portion of the task versus
time.
Generally, time is taken on the abscissa and left out work on ordinates. It is highly
used when a project is going to be done.

The company gets the knowledge of ‘How the team members are working”, and
“Can determine the accomplishment of the task”.
From the burn-down chart graph, we can estimate when the project is going to be
complete. It is generally useful when a team does not make any progress in the
project in the middle may be due to any reason, at that time they take the help of it
and plan accordingly to complete the project within the given time.
It checks the productivity of the work. It is widely used in agile and scrum project
management.
As from above, we got an idea that it is the graphical representation of work done,
work to be done, and the time required for pending work done.
So, these are the main components that are involved during the burndown chart
scrum creation steps. Let’s know the steps individually.

• Estimating Work:
Estimating work means from the backlog deciding what tasks need to be done
and how much time is required to complete these tasks.
More specifically how many user stories in how many days?
• Estimating Time: Estimating remaining time means how much time is left for a
sprint.
• Estimating Effort:
Estimating effort means managing effort accordingly looking at the work left and
time left and tracking the burndown slope (means work completion track).
In Y-axis a point (work needs to be done) and in X-axis a point (time remaining),
the straight line from the Y-point to the X-point is the burn downslope.
• Tracking Progress:
 Tracking daily progress includes comparing the actual daily progress with the
expected progress as per effort estimation.
So, if the daily progress line is below the burndown slope, then the team is
ahead of schedule, if the daily progress line is above the burndown slope, then
the team is far behind the target and if the daily progress line and burndown
slope are lined up then it is in the right track.

Advantages of Burndown Chart:

• We can see the total efforts a team puts against the given task from the graph.
• Burndown chart guides them to manage their tasks according to the time.
• Generally, software developers need a burn-down chart to estimate their efforts
and pending works.
• It is useful as it provides insight into how the members are busy doing the work.
• Thus, every owner uses it to check the progress of the process of making a
product.
• It works as a reminder and pokes the members if any project is delayed.
• It describes the period required to achieve the goal.
• It is a simple and easy way to check the progress of a project in scrum and agile
management.
• Progress updates will keep the workers dedicated to their given tasks.
Agile Design -
Agile Design is a dynamic and iterative approach rooted in the
principles of the Agile methodology, reshaping traditional design
practices to enhance collaboration, adaptability, and continuous
improvement.
Unlike linear processes, Agile Design embraces flexibility, concurrent
development, and user-centricity, aiming to deliver efficient and
customer-focused solutions in a rapidly changing environment.
1. It breaks away from traditional, linear design processes by
emphasizing flexibility, collaboration, and a user-centric
mindset.
2. Unlike sequential methods, Agile Design allows for concurrent
development, feedback loops, and integration of user insights
throughout the entire design process.
3. The core principles include adaptability to change, faster time-
to-market, user-centric solutions, reduced risks and costs, and
enhanced collaboration among cross-functional teams.

Important of agile design –

1. Adaptability to Change:
2. Faster Time-to-Market –
One of the primary advantages of Agile Design is its capability
to boost the improvement and launch of products.
By breaking down the design manner into iterative cycles,
groups can deliver incremental updates greater often. This
outcome in a faster time-to-market
3. User-Centric Solutions
4. Reduced Risks and Costs
5. Enhanced Collaboration

Characteristics –
 1. Iterative and Incremental: Agile design follows an iterative and
incremental method, wherein the layout process is broken
down into smaller chunks referred to as sprints. Each sprint
specializes in delivering a working product or layout that may
be tested and evaluated.
2. Collaborative: Agile layout emphasizes collaboration between designers, builders, and
stakeholders during the design manner. This facilitates making certain that everyone is
aligned and operating toward the same goal.
3. Flexibility and Adaptability: Agile design permits flexibility and adaptability because the
layout system is not rigidly described. It allows for adjustments and modifications to be
made as wished, primarily based on comments and evolving necessities.
4. User-Centric: Agile design places the consumer in the center of the layout manner. It
entails non-stop checking out and feedback from users to make certain that the very last
product meets their desires and expectations.
5. Continuous Improvement: Agile design is focused on continuous improvement, with each
iteration building upon the previous one. This facilitates refining and improving the design
primarily based on personal comments and converting requirements.
6. Cross-Functional Teams: Agile layout involves cross-purposeful groups, in which designers,
builders, and stakeholders with one-of-a-kind talent sets and perspectives work together
to create the finest possible design.

Principles –
There are 7 different Agile Design Principles
1. Executives are Geared up to Aid UX Designers
This precept highlights the significance of government buy-in and
consumer support (UX) designers. When executives apprehend
the price of consumer-centered design and actively aid the efforts
of UX teams, it creates surroundings wherein user desires and
layout concerns are given due significance in selection-making
procedures.
2. Teams must be Cross-functional
Cross-functional teams are the ones composed of members with
diverse talents vital to finishing an assignment. In an Agile context,
this indicates having people with a whole lot of information (layout,
improvement, checking out, and so on.) running collectively. Cross-
functional groups foster collaboration, lessen dependencies, and
enable faster decision-making.

3. Good Product Backlog Management and Assignment Planning

are Essential
Effective backlog control includes maintaining a prioritized listing of
capabilities and obligations that need to be addressed in the task.
Agile emphasizes flexibility, so the backlog can be adjusted based on
comments and converting priorities. Project planning involves
breaking down paintings into practicable responsibilities, estimating
effort, and placing practical timelines.

4. There are Correct Estimations of the Time to Subsequent Launch

Agile encourages the use of timeboxed iterations or sprints.
Accurate estimation of the time to the subsequent release is crucial
for making plans and coping with expectations.

5. Research and Checking out are Baked into the Layout Technique
Integrating user research and trying out for the duration of the
design system guarantees that the product aligns with consumer
needs.

6. Design and Development are Iterative

The iterative nature of the Agile layout and development approach
is that paintings are completed in small, incremental cycles. Each
new release consequences in a probably shippable product
increment. This iterative technique helps flexibility, adaptability, and
the potential to respond speedily to converting necessities or
personal remarks.

7. Constant Communication is the Prime Key

Effective verbal exchange is a cornerstone of Agile methodologies.
Teams collaborate regularly through ceremonies like each day stand-
ups, sprint planning, and evaluation meetings.
Constant communication increases a shared understanding of
projects, progress, and demanding situations, promoting a
collaborative and transparent work environment.

Advantages of Agile Design –

4. Flexibility and Adaptability
5. Continuous User Feedback
6. Faster Time-to-Market
7. Reduced Risks and Costs
8. Enhanced Communication

Disadvantages of Agile Design-

1. Dependency on User Availability
2. Initial Learning Curve
3. Documentation Challenges
4. Resource Intensive
5. Need for Experienced Facilitation

Timeboxing-
Timeboxing in Agile software development is a key practice that
involves setting fixed, limited durations for specific tasks, activities,
or iterations.
The goal is to focus efforts within a defined timeframe, ensuring
that work progresses steadily without unnecessary delays.
Timeboxing helps manage scope, prioritize effectively, and deliver
value incrementally.

Key Features of Timeboxing

1. Fixed Timeframe:
o A predefined duration is assigned to complete a specific
task or activity, such as a sprint in Scrum (e.g., 2 weeks).
2. Prioritization of Work:
o Teams focus on completing the most important tasks
within the given timebox, reducing scope creep.
3. Focused Effort:
o Encourages teams to concentrate on a specific goal
without distractions.
4. Review and Feedback:
o At the end of the timebox, the team evaluates progress,
gathers feedback, and decides next steps.
5. Continuous Improvement:
o Timeboxing allows for regular opportunities to reflect on
processes and improve efficiency.

Applications of Timeboxing in Agile

1. Sprints (Scrum):
 o A timeboxed iteration, typically lasting 1-4 weeks, during
which a set of user stories or tasks is completed.
2. Daily Stand-ups:
o Short, timeboxed meetings (usually 15 minutes) for team
members to share progress, plans, and blockers.
3. Timeboxed Planning:
o Activities like sprint planning, backlog refinement, or
retrospectives are constrained to a specific time limit to
prevent over-analysis.
4. Spikes:
o Timeboxed research or exploratory tasks aimed at
reducing uncertainty or testing a concept.
5. Task Execution:
o Developers may timebox their work on specific tasks to
prevent over-engineering or spending too much time on
a single feature.

Benefits of Timeboxing
1. Promotes Efficiency:
o Forces teams to focus on essentials and deliver results
within constraints.
2. Prevents Overcommitment:
o Ensures that work is manageable within the allocated
time.
3. Encourages Iterative Progress:
o Facilitates regular, incremental delivery of value.
4. Clear plan:
o Makes it easier to plan and manage work by setting clear
deadlines.
 5. Clear goals:
o Teams are more likely to stay on track with clear, time-
based goals.

COLLABORATION –
1. Pair programming
2. Collective ownership
3. Stand up meeting
4. Continuous integration

Technical Debt and refactoring –

Refactoring is modifying the internal structure of code without

changing its behaviour. All functional tests should pass with the
same results after the code has been refactored. But if it behaves
the same, why do we need to do it?
Refactoring is important to maintain the long-term quality of the
code and platform of which the code is a part. If the developers
don’t do some refactoring on a regular basis, “technical debt” will
creep into the system.
It will continue growing to the point where new development
becomes difficult if not impossible. The “cost of change” curve will
become impossibly high

Technical debt is the concept of delaying or omitting work to

complete a project or reach a goal, but it also causes more rework in
the end.
It’s like building a house without a complete set of blueprints.
Construction might finish sooner, but the house will have significant
structural issues that will take more time and more money to fix
later.

challenges -
 Time Constraint: Time is the biggest challenge for doing
refactoring in Agile projects as the Sprints are time-boxed with
a defined set of deliverables.
Reluctance: If the code is working fine without any refactoring done,
there will be an inclination towards not revisiting the code.

Fear factor - Developer often fears that refactoring will introduce

bugs and break the existing functionality which is working fine

Re-Testing

 Backward Compatibility: Backward compatibility often

prevents developers from starting refactoring efforts.

Motivation For Refactoring:

 It becomes easier to add new code
 The existing code’s design is improved.
  Helps to gain a better understanding of code
 Makes coding less annoying

Technical debt is generally identified in the Software

development domain when the developers make sacrifices in
system design and jump right into coding.
It refers to a variety of bugs, missing documentation, or simply
outdated legacy code. Just like financial debt, technical debt accrues
interest, the longer the debt or backlog of ignored issues builds up,
the more costly it becomes to rectify
But perfect project design and implementation with no elements of
technical debt are rare, even when doing everything right.

Types of Technical debt

1. Planned Technical debt
Planned technical debt occurs when teams knowingly want a fast
but imperfect implementation, either to build a presence in the
rapidly developing market or collect customer feedback. However,
teams hardly have the time to go back and redesign how they
planned earlier.
2. Unintentional Technical debt
Unintentional technical debt happens by accident usually
occurs when developers don’t understand market
requirements or how to design an architecture to meet market
requirements.

Poor management can also cause debt. For instance, if

inexperienced team members are given complex tasks, and
management doesn’t conduct reviews that might catch
problems.
 Training, static analysis, and reviews are some good
engineering practices to prevent unintentional technical debt.
3. Unavoidable Technical debt
There are situations in which technical debt is not within the
control of the development teams and organization as a
whole. It usually covers changes in the industry or broad
technology shifts.

How to manage Technical Debt -

1. Identify and Prioritize Technical Debt

 Track Technical Debt: Maintain a list of known technical
debt items in your backlog or a dedicated "Tech Debt
Register."
 Prioritize Debt: Use metrics like impact on
performance, maintainability, and team productivity to
prioritize technical debt items. High-impact debts
should take precedence.
2. Integrate into Agile Workflow
 Allocate Time in Sprints: Dedicate a fixed percentage
(e.g., 10-20%) of each sprint for addressing technical
debt.
 Create User Stories for Debt: Write user stories for
technical debt items, specifying the problem and
expected outcome.
 Combine Debt Fixes with Features: Address technical
debt as part of feature development to minimize
disruption.
3. Use Continuous Integration and Automation

Productive ways to manage Technical Debt -

 Calculate Technical Debt
 change Developers
 Improve data
 Employ Resources
 Reframe Software Development strategy

Product Backlog :
Product backlog is compiled of all the things that must be
done to complete the whole project.
But it’s not an easy task. Product backlog breaks down each
of the items on the record into a series of steps that helps
the development team.
So, the team knows when to start the work and how long
they have until they must finish it by the time given to them.
With the help of task management software, this process
can be accelerated.
The product backlog is shrinking because it should be
removed from the product backlog list once a task is
completed. Sometimes, however, new items are added, as
the project grows.

What is an Effective Product Backlog ?

1. The product backlog concept is simple enough, it can be
clumsy, as it’s composed of all things that must be
complete to bring in a successful project.
2. Skill set required to break each of those individual tasks
into a series of steps, One must know the project inside
and outside that can then be appointed to the team,
who not only complete it but must understand it.

Sprint Backlog :
The product backlog is like a superset of the sprint backlog.
The sprint backlog evolves from the product backlog, but it
holds less items, that can be completed within each agile
sprint. Like in each sprint some features needs to be
developed which comes under sprint backlog.
The sprint backlog will determine by the difficulty of the
project, but overall the knowledge is to dedicate the team
only to those tasks that can be completed within the sprint.
Naturally, it is a complex project that sprint backlog can also
develop in complexity and length.

Disparate the product backlog, however, the sprint backlog

is unchanged during the period of the sprint. Only during the
sprint planning meeting, it can also be changed. They will be
added again to the product backlog and addressed during
the next sprint if there are items left incomplete by the end
of the sprint.

What is an Effective Sprint Backlog ?

1. The sprint backlog is easier to create by definition. It’s
shorter, more absorbable, but that doesn’t mean it can
be grown without thinking strategically about the
ability of the team and the resources at hand.
2. An expert in scrum methodology who guides through
experience and skill so it’s up to the development team
and the scrum master to know what the team can do by
having a good estimation of their ability.

Working of Product Backlog and the Sprint Backlog

Together :
 To work effectively, the difference between a product
backlog and a sprint backlog and interaction between
both must be understood to move the project forward.
 During the plan meeting, everyone on the development
team should discuss how it will be completed and what
must be done.
 The product backlog list objects are moved to a sprint
backlog list.
 Then each object on the sprint backlog is divided into
steps, that will be taken to complete the object.
  Once started there can not be changed to the steps
needed to complete them.

monitoring and adapting agile project-

Monitoring and Adapting Agile Projects is essential to ensure
successful delivery and alignment with project goals.
In Agile methodology, monitoring and adaptation happen
continuously through iterative processes and feedback mechanisms.
Here's a detailed breakdown of how it works:

1. Monitoring in Agile Projects

Monitoring involves keeping track of progress, performance, and
quality to ensure the project stays on course. Key practices include:
a. Regular Progress Reviews
 Daily Standups (Scrum Meetings): Short meetings to discuss
progress, impediments, and plans for the day.
 Sprint Reviews: End-of-sprint meetings to showcase the
completed work to stakeholders and gather feedback.
b. Tracking Tools
 Burndown Charts: Visualize work remaining versus time
available.
 Velocity Tracking: Measures the amount of work completed in
each sprint to predict future performance.
 Kanban Boards: Track work items through different stages (To
Do, In Progress, Done).
c. Quality Assurance
  Continuous integration and testing to ensure deliverables
meet quality standards.
 Code reviews and pair programming to identify and resolve
issues early.
d. Feedback Mechanisms
 Gathering feedback from stakeholders, team members, and
customers through regular reviews and demos.
 Retrospectives to discuss what went well, what didn’t, and
areas for improvement.

2. Adapting in Agile Projects

Adaptation involves responding to change based on monitoring
insights, customer feedback, or unforeseen challenges.
a. Iterative Improvements
 Adjust the product backlog based on feedback and evolving
priorities.
 Refine user stories or add/remove features to align with
customer needs.
b. Addressing Blockers
 Quickly resolving impediments identified during standups or
retrospectives.
 Adjusting team roles or workflows if inefficiencies are
detected.
c. Scope and Timeline Adjustments
 Using velocity data to recalibrate scope or deadlines as
necessary.
  Flexibly reprioritizing work to focus on high-value features.
d. Continuous Learning
 Implementing lessons learned from retrospectives in
subsequent sprints.
 Encouraging team members to acquire new skills or tools to
adapt to project demands.

3. Tools and Techniques for Monitoring and Adapting

 JIRA/Trello/Asana: Tools for tracking tasks, progress, and
backlog items.
 CI/CD Pipelines: Ensure code is always in a deployable state.
 Retrospective Tools: Tools like FunRetro or Miro to facilitate
reflection and improvement.
 Customer Feedback Platforms: Tools like UserVoice or
SurveyMonkey to gather direct feedback.

Lean Software Development -

Lean Software Development (LSD) is an agile framework used to
streamline and optimize the software development process
It may also be referred to as the Minimum Viable Product (MVP)
strategy as these ways of thinking are very similar since both intend
to speed up development by focusing on new deliverables.
Lean is an agile methodology that improves product delivery by
reducing wastes.
Sometimes it sounds awkward but is very effective. The definition of
waste is quite different in lean terms, so that anything that does not
add any new functionality to the final product is known as waste in
it.
Hence this approach makes lean agile because there is a needed
iterative structure of the projects. It is much easier to remove waste
during an iterative cycle than to remove it when the product is
ready.

1. Prevent Defects: It integrates quality assurance throughout

the development process to prevent defects.
2. Eliminate Waste: It focuses on activities that add value to the
customer and eliminates those activities that do not add value.
3. Fast Delivery: Reduces cycle time to deliver software quickly
and respond to feedback and changing requirements rapidly.
4. Delay Decisions: Delay decisions until they can be made based
on facts.

Necessary procedure in Lean methodology:

1. Testing is an essential procedure in this agile methodology.
We all know that there cannot be a project which has no bugs.
Fixing bugs is needed.
The iteration cycle detects the bugs in each loop which is then
removed as soon as it arises.
2. It is a necessity that the communication inside a lean team
should be strong. All the project issues must be discussed
when needed, and solving bugs follow a hierarchical structure.
Furthermore, the developers contact clients constantly during
the project. This improves the customer and user acceptance
of the product.
Structure:
1. The structure of the lean team is similar to the scrum team.
2. Small and self-managing.
 3. The three primary roles:
Product owner, team members, and team lead.
4. People in a team are interchangeable.

Seven Principles of LSD

1. Eliminating the Waste
To identify and eliminate wastes e.g. unnecessary code, delay in
processes, inefficient communication, issues with quality, data
duplication, more tasks in the log than completed, etc. regular
meetings are held by Project Managers. This allows team members
to point out faults and suggest changes in the next turn.
2. Fast Delivery
Previously long-time planning used to be the key to success in
business, but with time, it has been found that engineers spend too
much time on building complex systems with unwanted features. So
they came up with an MVP strategy which resulted in building
products quickly that included a little functionality and launching
the product to market and seeing the reaction. Such an approach
allows them to enhance the product based on customer feedback.
3. Amplify Learning
Learning is improved through ample code reviewing and meetings
that are cross-team applicable. It is also ensured that particular
knowledge isn’t accumulated by one engineer who’s writing a
particular piece of code so paired programming is used.
4. Builds Quality
LSD is all about preventing waste and keeping an eye on not
sacrificing quality. Developers often apply test-driven programming
to examine the code before it is written. Quality can also be gained
by getting constant feedback from team members and project
managers.
5. Respect Teamwork
LSD focuses on empowering team members, rather than controlling
them. Setting up a collaborative atmosphere, keeping perfect
balance when there are short deadlines and immense workload.
This method becomes very important when new members join a
well-established team.
6. Delay the Commitment
In traditional project management, it often happens when you make
your application and it turns out to be completely unfit for the
market. LSD method recognizes this threat and makes room for
improvement by postponing irreversible decisions until all
experiment is done. This methodology always constructs software
as flexible, so new knowledge is available and engineers can make
improvements.
7. Optimizing the Whole System
Lean’s principle allows managers to break an issue into small
constituent parts to optimize the team’s workflow, create unity
among members, and inspire a sense of shared responsibility which
results in enhancing the team’s performance.

Kanban -
Kanban is a popular Agile Software Development Methodology. It is
a signaling device that instructs the moving of parts in a ‘pull’
production system, developed as part of the TPS (Toyota Production
System).
Kanban is about en-visioning the existing workflow in terms of steps.
These steps can be created on the whiteboard.
The main aim of Kanban is to reduce WIP (Work-In-Progress), or
inventory, between processes by ensuring the upstream process
creates parts as long as its downstream process needs it.
The goal of the Kanban execution is to ensure work items move to
the next steps quickly to realize business value faster.
Kanban Board/Card
It is critical to understand the visualization of workflow stages in the
task execution pipeline. Kanban board provides a simple way to
understand the process.
1. Every request received is put on the Kanban board.
2. A column on the board represents a stage (these stages are
termed as the Work stage) during the lifecycle of bugs/
tickets.
3. The received stage could be called a “Backlog” also.
4. Kanban board could be a simple whiteboard on which sticky
notes
5. ALM tools like Rally/ Jira could be configured to use the Kanban board.

APPLICATION ON KANBAN –
 frequent changing requirements which need to be delivered
faster.
 In case of changing priorities, the team can pull the prioritized
work as soon as the WIP limit drops.
 Frequent releases are there (Periodically).
 When incoming work is continuous.
 Where task priority needs to be decided dynamically based on
task nature and type.
 Kanban could be used by any function of an organization

Principles of Kanban:
o Start with what you are doing now: The Kanban does not
believe in making the changes to the setup or the continuing
process. It is mainly applied to the current workflow. Any
changes that occur gradually over a while at a pace when the
team is comfortable with.
o Agree to pursue incremental, evolutionary change: Kanban
believes in making small steps rather than making big changes.
 If significant changes are made, it may be led to substantial
resistance between the team and the organization.
o Initially, respect current roles, responsibilities, and job titles:
o No organizational changes are made by Kanban.
o So it is not mandatory to change the existing parts which might
be performing well because the team will collaboratively
identify and implements whenever the changes are
demanded.
o leadership at all levels:
o Kanban encourages the team members by continuously
encouraging them.
o It is because it believes that leadership does not come from
senior managers only.
o Peoples at any level can present their ideas and show
leadership whenever it is required to implement changes so
that they can deliver their products and services continuously.

Agile Stakeholders-
Stakeholders in Agile projects are individuals or groups with an
interest in or influence over the project.
They play a crucial role in ensuring the project's success by
providing requirements, feedback, and support.
Stakeholders in an Agile project can be either internal or external.
Internal stakeholders are those whose interest in your project
comes from a direct relationship. External stakeholders don’t work
with you directly, don’t necessarily know you’re building a product,
but will be affected by it in the future.

Common stakeholders include:

1. project sponsors – people funding the project,
 2. product owners – often core stakeholders from the client’s
side,
3. project managers-handle everything
4. business managers and business architects,
5. account and sales managers,
6. development team including engineers, designers, business
analysts,
7. end users.

Identify the ones applicable for your case

Stakeholders differ from case to case – especially key ones – so you
need to perform stakeholder analysis to select yours.
Step 1: Identify. To identify your project’s stakeholders, start with
listing every individual and group who is impacted by your project’s
outcome and has an interest in its success.
Step 2: Analyze. Name your stakeholders’ needs and goals, and
identify what brings business value to each of them.
Step 3. Prioritize. Create a stakeholder map to pick the ones who
have the biggest interest and influence.
Step 4: Plan communication. A stakeholder map will help you
distinguish those who just need to be informed about the progress
from active meeting participants. Build a plan of meetings, name
channels, and establish the frequency of communication for each
individual and group.
Step 5: Engage effectively. Your development team can engage key
stakeholders by encouraging them to actively participate in
meetings, like sprint reviews or retrospectives, and appreciating
their feedback

Common Agile stakeholders

Examples of internal stakeholders:
 Project Managers,
 business managers and business architects,
 account and sales managers,
 development team including engineers, designers, business
analysts,
 different departments,
 marketing and sales personnel,
 management teams (CXOs),
 testing and quality assurance,
  legal and compliance,
 DevOps teams,
 client,
 project sponsors,
 Product Owners.
Examples of external stakeholders
 users,
 customers,
 suppliers,
 community,
 shareholders.

Requirements Engineering –
Requirements Engineering is the process of identifying, eliciting,
analyzing, specifying, validating, and managing the needs and
expectations of stakeholders for a software system.
A systematic and strict approach to the definition, creation, and
verification of requirements for a software system is known as
requirements engineering.

To guarantee the effective creation of a software product, the

requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of
stakeholders.
1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned
areas below. Among these Economic Feasibility Study is the most
important part of the feasibility analysis and the Legal Feasibility
Study is less considered feasibility analysis.

a.Technical Feasibility: In Technical Feasibility current esources both

hardware software along required technology are
analyzed/assessed to develop the project. This technical feasibility
study reports whether there are correct required resources and
technologies that will be used for project development.

b.Operational Feasibility: In Operational Feasibility degree of

providing service to requirements is analyzed along with how easy
the product will be to operate and maintain after deployment.
c.Economic Feasibility: In the Economic Feasibility study cost and
benefit of the project are analyzed. This means under this feasibility
study a detailed analysis is carried out will be cost of the project for
development which includes all required costs for final development
hardware and software resources required, design and development
costs operational costs, and so on.

After that, it is analyzed whether the project will be beneficial in

terms of finance for the organization or not.

d.Legal Feasibility: In legal feasibility, the project is ensured to

comply with all relevant laws, regulations, and standards. It
identifies any legal constraints that could impact the project and
reviews existing contracts and agreements to assess their effect on
the project’s execution

2. 2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the
project domain and requirements.
The various sources of domain knowledge include customers,
business manuals, the existing software of the same type,
standards, and other stakeholders of the project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc.
Elicitation does not produce formal models of the requirements
understood. Instead, it widens the domain knowledge of the analyst
and thus helps in providing input to the next stage.
Requirements elicitation is the process of gathering information
about the needs and expectations of stakeholders for a software
system.
This is the first step in the requirements engineering process and it
is critical to the success of the software development project.
The goal of this step is to understand the problem that the software
system is intended to solve and the needs and expectations of the
stakeholders who will use the system.

 Interviews: These are one-on-one conversations with

stakeholders to gather information about their needs and
expectations.
 Surveys: These are questionnaires that are distributed to
stakeholders to gather information about their needs and
expectations.
 Focus Groups: These are small groups of stakeholders who are
brought together to discuss their needs and expectations for
the software system.
 Observation: This technique involves observing the
stakeholders in their work environment to gather information
about their needs and expectations.
 Prototyping: This technique involves creating a working model
of the software system, which can be used to gather feedback
from stakeholders and to validate requirements.

3. Requirements Specification
This activity is used to produce formal software requirement
models. All the requirements including the functional as well as the
non-functional requirements and the constraints are specified by
these models in totality.
During specification, more knowledge about the problem may be
required which can again trigger the elicitation process. The models
used at this stage include ER diagrams, data flow diagrams(DFDs),
function decomposition diagrams(FDDs), data dictionaries, etc.

Requirements specification is the process of documenting the

requirements identified in the analysis step in a clear, consistent,
and unambiguous manner.
This step also involves prioritizing and grouping the requirements
into manageable chunks.

Several types of requirements

1. Functional Requirements: These describe what the software
system should do. They specify the functionality that the
system must provide, such as input validation, data storage,
and user interface.
2. Non-Functional Requirements: These describe how well the
software system should do it. They specify the quality
attributes of the system, such as performance, reliability,
usability, and security.
3. Constraints: These describe any limitations or restrictions that
must be considered when developing the software system.
4. Acceptance Criteria: These describe the conditions that must
be met for the software system to be considered complete and
ready for release.

Requirements Verification and Validation

Verification: It refers to the set of tasks that ensures that the
software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement
definitions would propagate to the successive stages resulting in a
lot of modification and rework

1. The requirements should be consistent with all the other

requirements i.e. no two requirements should conflict with
each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.

. Requirements Management
Requirement management is the process of analyzing,
documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant
stakeholders.
This stage takes care of the changing nature of requirements. It
should be ensured that the SRS is as modifiable as possible to
incorporate changes in requirements

1. Tracking and controlling changes:

2. Version control:
3. Traceability
4. Communication
5. Monitoring and reporting

Tools Involved in Requirement Engineering

 Observation report
 Use cases
 User stories
  Mind mapping
 Prototyping

DSDM
DSDM Atern is a vendor-independent implementation of the agile
project delivery framework Dynamic Systems Development Method
(DSDM). It is a generic approach to agile project management rather
than solely focused on software delivery.

DSDM differs from many agile approaches in that it retains a role for
a project manager and considers itself compatible with other
project management approaches such as PRINCE2 and PMI.
The DSDM approach is scalable from small teams to-large scale,
across many teams. There are many roles defined, which may be
shared or combined.

Phases
The DSDM project process has 6 phases:
1. Pre-project. Helps start the project correctly and prevents
poor projects beginning.
2. Feasibility. Check the project is technically feasible, and the
business case is viable.
3. Foundations. Teams spend a few weeks establishing the
business rationale, the technical solution and approach.
4. Evolutionary development. Teams build increments of
prioritised features in iterations of the system.
5. Bring the system into operational use.
6. Post-project. Quantify the benefits delivered by the project.
Principles
To get the full benefit of the DSDM framework, teams must adopt a
mindset that focuses on the following principles:
1. Focus on the business need. Make all decisions with the
overriding project goal in mind.
2. Deliver on time. The most critical success factor is on-time
delivery.
3. Collaborate. Collaborative teams always outperform those
that don’t.
4. Never compromise quality. The quality of the system must be
good enough.
5. Build incrementally from firm foundations. Perform sufficient
analysis and design upfront.
6. Develop iteratively. At the end of each iteration, work is
reviewed and feedback is received.
7. Communicate continuously and clearly. The most significant
cause of project failure is poor communication.
8. Demonstrate control. Proactive management of plans to
ensure the project remains in control at all times.

Core techniques
At the core of DSDM are a collection of techniques:
 Timeboxing. Creates motivation and pressure to achieve an
objective in a fixed period.
 deadline. Understanding the relative priority of requirements
helps the team make progress and hit deadlines.
 Decision. Facilitated workshops are a proven practice for
driving rapid high-quality decision making and buy-in.