Unit 6: Project methodologies

Waterfall methodology, Agile methodology, Scrum methodology, extreme programming

(XP) methodology, Adaptive project framework (APF) methodology.

# Waterfall methodology
The Waterfall methodology — also known as the Waterfall model — is a sequential
development process that flows like a waterfall through all phases of a project (analysis, design,
development, and testing, for example), with each phase completely wrapping up before the
next phase begins.
It is said that the Waterfall methodology follows the adage to “measure twice, cut once.” The
success of the Waterfall method depends on the amount and quality of the work done on the
front end, documenting everything in advance, including the user interface, user stories, and
all the features’ variations and outcomes.
With the majority of the research done upfront, estimates of the time needed for each
requirement are more accurate, and this can provide a more predictable release date. With a
Waterfall project, if parameters change along the way, it’s harder to change course than it is
with Agile methodology.

What is Waterfall software?

Waterfall software helps project managers handle the task. As Waterfalls are a relatively
complex, phased approach, they require close attention and coordination.
Waterfall software can be desktop or cloud-based. It helps you:
• Structure your processes
• Organize tasks
• Set up Gantt charts and schedules
• Monitor project progress

5 common stages in a Waterfall process.

The Waterfall methodology follows a chronological process and works based on fixed dates,
requirements, and outcomes. With this method, the individual execution teams aren’t required
to be in constant communication and, unless specific integrations are required, are usually self-
contained.
Team members also tend to work independently and aren’t expected to provide status reports as
often as with the Agile approach. Usually, one phase doesn’t begin until the previous one is
finished.
Using a software development project as an example, the Waterfall process usually includes
stages that look like this:
Requirements.
The Waterfall methodology depends on the belief that all project requirements can be gathered
and understood upfront. The project manager does their best to get a detailed understanding of
the project sponsor’s requirements. Written requirements, usually contained in a single
document, are used to describe each stage of the project, including the costs,
assumptions, risks, dependencies, success metrics, and timelines for completion.
Design.
Here, software developers design a technical solution to the problems set out by the product
requirements, including scenarios, layouts, and data models. First, a higher-level or logical
design is created that describes the purpose and scope of the project, the general traffic flow of
each component, and the integration points. Once this is complete, it is transformed into a
physical design using specific hardware and software technologies.
Implementation.
Once the design is complete, technical implementation starts. This might be the shortest phase
of the Waterfall process because painstaking research and design have already been done. In
this phase, programmers code applications based on project requirements and specifications,
with some testing and implementation taking place as well. If significant changes are required
during this stage, this may mean going back to the design phase.
Verification or testing.
Before a product can be released to customers, testing needs to be done to ensure the product
has no errors and all of the requirements have been completed, ensuring a good user experience
with the software. The testing team will turn to the design documents, personas, and user case
scenarios supplied by the product manager to create their test cases.
Deployment and maintenance.
Once the software has been deployed in the market or released to customers, the maintenance
phase begins. As defects are found and change requests come in from users, a team will be
assigned to take care of updates and release new versions of the software.

Advantages of the Waterfall methodology.

The Waterfall methodology is a straightforward, well-defined project management
methodology with a proven track record. Since the requirements are clearly laid out from the
beginning, each contributor knows what must be done when, and they can effectively plan their
time for the duration of the project.
Other benefits of the Waterfall method include:
• Developers can catch design errors during the analysis and design stages, helping them
to avoid writing faulty code during the implementation phase.
• The total cost of the project can be accurately estimated, as can the timeline, after the
requirements have been defined.
• With the structured approach, it is easier to measure progress according to clearly
defined milestones.
• Developers who join the project in progress can easily get up to speed because
everything they need to know should be in the requirements document.
• Customers aren’t always adding new requirements to the project, delaying production.

Disadvantages of the Waterfall methodology.

Like any development process, the strengths in one area might mean weaknesses in the other.
The Waterfall methodology’s insistence on upfront project planning and commitment to a
certain defined progress means that it is less flexible, or agile, later in the game. Changes that
come further in the process can be time-consuming, painful, and costly.
Other reasons the Waterfall methodology may not work include:
• Projects can take longer to deliver with this chronological approach than with an
iterative one, such as the Agile method.
• Clients often don’t fully know what they want at the front end, opening the door to
requests for changes and new features later in the process when they’re harder to
accommodate.
• Clients are not involved in the design and implementation stages.
• Deadline creep — when one phase in the process is delayed, all the other phases are
delayed.

Who uses the Waterfall model?

The Waterfall process is adopted by project managers who are faced with development projects
that:
• Don’t have ambiguous requirements.
• Offer a clear picture of how things will proceed from the outset.
• Have clients who seem unlikely to change the scope of the project once it is underway.
If a project manager prefers clearly defined processes, where cost, design, and time
requirements are known upfront, then the Waterfall method is the way to go, as long as the
project itself is conducive to those constraints.
# 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.

What is Agile?
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.
What is the Agile 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.
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
7. Crystal
8. Scaled Agile Framework (SAFe)

The Agile Development Model was primarily designed to help a project adapt quickly to
change requests. So, the main aim of the Agile model is to facilitate quick project completion.
To accomplish this task, agility is required. Agility is achieved by fitting the process to the
project and removing activities that may not be essential for a specific project. Also, anything
that is a waste of time and effort is avoided. The Agile Model refers to a group of
development processes. These processes share some basic characteristics but do have certain
subtle differences among themselves.

Agile Software Development Methodology in software development is an efficient

methodology that helps teams produce high-quality software quickly and with flexibility. Agile
is not just a methodology; it’s a mindset. At its core, Agile values individuals and interactions,
working solutions, and customer collaboration over strict processes and comprehensive
documentation. It acknowledges that the needs and priorities of a project may change,
emphasizing the importance of adaptability and continuous improvement.

In simple terms, Agile Product Management is a concept and approach that focuses on speed
while taking the demands of customers into account throughout the product development life
cycle. As compared to traditional Waterfall approaches, which follow a ‘linear and sequential’
process, Agile uses iterative cycles of operation; developers can return to customers for
feedback or modifications constantly. That is a mindset that prioritizes people and interactions
over processes and systems, working products over detailed documentation, and customer
collaboration over contract negotiation.

What is Agile Project Management?

Agile Project Management is a revolutionary approach, that is aimed at continuously delivering
solutions for the changing requirements of the project in a spiral way.
1. It was established by the Agile Manifesto’s principles, calling for iterative and
incremental development of the project into manageable sprints that create potentially
shippable increments.
2. Agile Project Management is the concept of being agile and agile method in the new
challenges of advanced projects, concerning its community-oriented spirit, planning
flexibility, and ongoing progress.

Agile Methodology Advantage and Disadvantage

The main advantage and disadvantage of agile methodology are:
• Advantage : Agile methodologies allow for flexibility and adaptability in responding
to changes. Teams can easily adjust their plans and priorities based on evolving
requirements or feedback during the project.
• Disadvantage: The iterative and adaptive nature of agile can sometimes lead to
uncertainty, especially in projects with unclear or rapidly changing requirements. This
may pose challenges in estimating timelines and costs accurately.

Agile vs Waterfall Methodology: Agile is like a good fit for projects that need to be flexible
and change a lot, such as making computer programs. It works well when talking with
customers and making improvements bit by bit are really important. On the other side,
Waterfall is just right for projects that have clear steps and simple, straight-ahead plans. It’s
like following a recipe step by step. So, if your project is all about changes and surprises, go
for Agile. But if it’s more like following a clear plan without many surprises, Waterfall is the
way to go.

Life cycle of Agile Methodology

The Agile software development life cycle helps you break down each project you take on into
six simple stages:
1. Requirement Gathering
• In this stage, the project team identifies and documents the needs and expectations of
various stakeholders, including clients, users, and subject matter experts.
• It involves defining the project’s scope, objectives, and requirements.
• Establishing a budget and schedule.
• Creating a project plan and allocating resources.

2. Design
• Developing a high-level system architecture.
• Creating detailed specifications, which include data structures, algorithms, and
interfaces.
• Planning for the software’s user interface.

3. Development (Coding)
Writing the actual code for the software. Conducting unit testing to verify the functionality of
individual components.

4. Testing
This phase involves several types of testing:
1. Integration Testing: Ensuring that different components work together.
2. System Testing: Testing the entire system as a whole.
3. User Acceptance Testing: Confirming that the software meets user requirements.
4. Performance Testing: Assessing the system’s speed, scalability, and stability.

5. Deployment
1. Deploying the software to a production environment.
2. Put the software into the real world where people can use it.
3. Make sure it works smoothly in the real world.
4. Providing training and support for end-users.

6. Review (Maintenance)
1. Addressing and resolving any issues that may arise after deployment.
2. Releasing updates and patches to enhance the software and address problems.

When to use the Agile Methodology?

It is particularly well-suited for projects and organizations where the following conditions or
needs are present:
1. Unclear or Changing Requirements: Agile is great for projects with requirements
that aren’t well-defined or might change.
2. Complex Projects: It’s good for big, complex projects by breaking them into smaller
pieces.
3. Customer Focus: Use Agile when making customers happy is a priority and you want
to involve them throughout.
4. Quick Time-to-Market: If you need to get your product out fast, Agile can help.
5. Small to Medium Teams: Agile works well for teams of a few to a few dozen people.
6. Team Skills: It’s best when you have a mix of skills in your team, like development,
testing, design, and more.
7. Collaboration: Agile promotes working together and open communication.
8. Regular Updates: If you want to check progress often and make changes as needed.
 9. Transparency: Agile emphasizes being open and clear with everyone involved in the
project.
10. Risk Control: It helps manage risks by tackling issues as they come up.
11. Innovation: If you encourage trying new things and learning from experience, Agile
supports that.
12. Continuous Improvement: Agile fosters a culture of always getting better over time.

Agile Methodologies vs Traditional Approaches

Parameters Agile Methodology Traditional Approach

Definition Agile is like building a Traditional approaches are
flexible and adaptablelike constructing a house
treehouse in stages. with a detailed blueprint.
Chronology of operations Testing and development Testing is done once the
processes are performed development phase is
concurrently. completed.
Organizational structure It follows iterative
It follows linear
organizational structure. organizational structure.
Communication Agile encourages face-to- Traditional approach
face communication. encourages formal
communication.
Number of phases It consists of only three It consists of five phases.
phases.
Development cost Less using this methodology. More using this
methodology.
User requirements Clearly defined user Requires interactive user
requirements before coding. inputs.
Benefits of Agile Methodology
The advantages of the agile model are as follows:
1. Immediate Feedback: It allows immediate feedback, which aids software
improvement in the next increment.
2. Adapts to Changing Requirements: It is a highly adaptable methodology in which
rapidly changing requirements, allowing responsive adjustments.
3. Face-to-Face Communication: Agile methodology encourages effective face-to-face
communication.
4. Time-Efficient: It is well-suited for its time-efficient practices, which help in
delivering software quickly and reducing time-to-market.
5. Frequent Changes: It effectively manages and accommodates frequent changes in
project requirements according to stakeholder convenience.
6. Customer Satisfaction: It prioritizes customer satisfaction.
7. Flexibility and Adaptability: Agile methodologies are known for their flexibility and
adaptability.

Limitations of Agile Methodology

The disadvantages of the agile model are as follows:
1. Less Documentation: Agile methodologies focus on less documentation; it prioritizes
working on projects rather than paperwork.
2. Challenges in Large Organizations: Busy schedule of clients can make daily meetup
and face-to-face communication difficult.
 3. Need for Senior Programmers: It may require experienced programmers to make
critical decisions during the development of software.
4. Limited Scope Control: It has less rigid scope control, which may not be suitable in
certain situations.
5. Predictability: Compared to more structured project management methods, it may lack
predictability.
Popular Agile Tools for Software Development
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.
Some popular agile tools are:
1. Jira
2. ClickUp
3. Mural
4. Kanbanize
5. GitHub
6. Monday.com
7. Jenkins
8. Shortcut
9. Asana
10. Planbox

In conclusion, the Agile model is like building a project in small, flexible steps. It’s about being
quick to adapt, working closely with customers, and delivering value in small doses. This
approach has become popular for many companies because it helps them meet changing needs
and make customers happy.

Use the Agile model when your project needs to be flexible, your customers’ needs might
change, and you want to deliver small parts of your project regularly to make them happy. It’s
like building a puzzle piece by piece, adapting as needed.

# Scrum methodology

The scrum methodology was developed as a response to rigid project management approaches
such as the waterfall method, which didn’t adapt to the needs of agile product and software
development teams. We’ll explore the scrum methodology in-depth, but before that, let’s start
with a simple scrum definition.

What Is Scrum?: Scrum is a project management framework that facilitates team

collaboration on complex product and software development projects. The good news is that
scrum is easy to understand. The bad news? It’s hard to master.

What Is the Scrum Methodology?: The scrum methodology emphasizes teamwork in project
management. It stresses accountability and iterative progress toward a well-defined goal.
Scrum is part of agile software development and teams practice agile. The name comes from
the sport of rugby, where scrum is a formation where everyone plays a specific role, but
everyone is working towards a quick adoption of strategies.

Scrum vs. Agile: Scrum is a part of the agile process, but certainly not the only part. Agile is
a large tent, but scrum is an important pillar. Think of scrum as a framework by which you can
implement agile development. Agile doesn’t have a set of steps to follow, so scrum provides a
means to apply agile to your project. There are many frameworks that you can use in agile
development, such as extreme programming or feature-driven development, but scrum’s
simplicity and autonomy are selling points.

The scrum methodology can also be used as an entry point to other agile practices. It’s also not
solely a framework for software but can benefit many other kinds of projects.

When Should You Use the Scrum Methodology?

Any team that’s working to produce an end product can use scrum methodology, whether it be
a software program, marketing campaign, website or even a new product or building. In reality,
it can be applied to any project in any industry. A good rule of thumb is to use the scrum
methodology if your project requires that you figure out how to do a significant amount of the
work. If you’ve executed many similar projects before and you know how to approach the
project again, you can opt for a waterfall approach.

Scrum in Software Development: Scrum is commonly used in software development as

developers execute the work that’s required to complete each sprint. The framework was
formalized for software development projects. Scrum allows for constant feedback and
flexibility and software developers can focus on developing one or more features within a
particular time frame referred to as a sprint which is usually one month or less. When the
product is finished, it’s ready to be released.

Scrum in Product Development: Product development teams use scrum similarly to software
development teams. When product development teams employ the scrum methodology, they
break down long-term plans into sprints. During this time, they’ll work on only select projects
with the goal of making frequent product updates that hit the marketplace as quickly and
efficiently as possible.

Scrum in Project Management: The scrum process is led by the scrum master who aims to
remove obstacles to the work getting done. Scrum teams meet daily to talk about roadblocks
that could sidetrack projects. It’s ideal for managing projects that require fast development and
testing, especially amongst a small team.

What Are the Artifacts of the Scrum Methodology?

In the scrum methodology, the term artifact refers to key concepts that are used by the scrum
team to develop products in an agile environment. We’ll go through the most critical artifacts
that every scrum team needs: product backlog, sprint backlog and product increment.

• Product backlog: The product owner makes a list of work that needs to be done, and
they’ll place it in order according to priority. This is building your project backlog.
They do this by determining what is a must-have item, which is less critical and those
that don’t fit into the timeframe allotted. That means the value of each item must be
clear. What is their impact, risk and how the item might help in the learning process?
• Sprint backlog: The sprint backlog can be simply defined as the set of user stories in
which the scrum team will be working in a single sprint. It’s important to make sure
that the most critical user stories are always the ones that are being worked on and none
of them fall through the cracks.
 • Product increment: The term product increment refers to all the product backlog items
that have been completed during a sprint. It can also be used to describe the sum of all
the completed backlog items and user stories.

What Are the Scrum Events in the Scrum Process?

These scrum events or scrum ceremonies foster team collaboration and ensure that there’s a
constant line of communication among the scrum team members through the product or
software development life cycle.

• Sprint Planning: Using the product backlog, teams start with the highest priority items
and determine how to achieve this objective. A good tip when sprint planning is to do
the due diligence and only start with items that are ready. Also, remember that planning
is a short process, so don’t get bogged down in the details. Simply get to work on
meeting the objectives and keep the plan collaborative. The team should also ask the
product owner and stakeholder questions.
• Daily Scrum Meeting: These are 15-minute meetings where everybody in the scrum
team talks about the tasks they’ll be working on during the day and share any
roadblocks or difficulties they’re facing. There’s no need to make this daily scrum
meeting longer, as there are other meetings such as sprint reviews and sprint
retrospectives to explore more complex topics.
• Sprint Review: You want to look back on the sprint and see what worked and what
didn’t. You can then take the information and apply it to future sprints to replicate the
positives and reduce the negatives. Begin the sprint review process by thanking
participants, offering short introductions and setting ground rules for the discussion.
• Sprint Retrospective: The sprint retrospective meeting gives the scrum team a space
to reflect on the last sprint and determine what went well and wrong. Stakeholder and
customer feedback are also gathered in order to prioritize user stories and improve
product performance.
• Backlog Grooming: Once through this cycle, it starts over again by going back to the
backlog and taking the next ready item at the top of the priority list. Backlog
grooming consists of improving the scrum process through the prioritization of work
based on prior experience and continuing to refine the work to make it as efficient as
possible.

What Are the Main Roles In a Scrum Team?

As with anything in project management, the scrum methodology needs people to be executed.
For this purpose, it defines three scrum roles, a scrum master, a product owner and a
development team that’s made up of several team members.

• Scrum Master: The scrum master, as his name suggests, is a scrum methodology
expert. He guarantees that everybody in the scrum team understands how the
framework works and helps them adapt to the agile environment. He leads scrum
meetings.
• Scrum Product Owner: The scrum product owner manages the product log and
oversees sprint planning and actively participates in scrum meetings. In a sense, they
act as a project manager because they lead backlog grooming and prioritize user stories
to help the teamwork better.
 • Scrum Development Team: The scrum development team is simply made up of all
the team members who develop software or products. They must work closely with the
product owner and adhere to the scrum master’s suggestions.

What Are Scrum Values in the Scrum Methodology?

Scrum values are the guiding principles of the scrum methodology. They’re simple statements
that work as agile best practices. The agile values come from the Agile Manifesto, a document
with the guiding principles of the agile project management methodology. Let’s quickly
explain what they’re about.

• Individuals and interactions over processes and tools: Processes and tools are
important in software development, but individuals and how they interact with those
processes and tools are more important.
• Working software over comprehensive documentation: Before the Agile Manifesto,
software developers focused heavily on documentation. This value states that while
documentation is important, focusing on developing the software should be the primary
goal of the scrum team.
• Customer collaboration over contract negotiation: This value explains that
collaborating with customers to create a high-quality product is much more important
than drafting a rigid contract that limits product development, as it used to be done in
the old software development days.
• Responding to change over following a plan: This value states that agile is a project
management methodology that seamlessly adapts to change based on an iterative
product development cycle and not a rigid project plan.

Advantages of the Scrum Methodology

There are many unique advantages that scrum offers that can entice you if you’re considering
using scrum for your team.

• Flexibility: If your project undergoes frequent changes, scrum provides adaptability

that other methods don’t. It’s easy to pivot without losing the hard work you’ve already
completed.
• Visibility: Stakeholders feel more involved as they’re able to see progress
incrementally instead of solely during outlined check-in points in the project.
• Efficiency: The goal is to deliver work as efficiently as possible, a goal that’s often
achieved within scrum’s short sprints.

Disadvantages of the Scrum Methodology

There are challenges with any project management methodology and scrum is no exception.

• Scope creep: The lack of a definitive project end date can result in using more
resources than you originally anticipated.
• Requires a small, committed team: It’s challenging to achieve success with scrum if
you have a large team or if team members aren’t committed to project success.
• Not ideal for all projects: If you have a fixed project scope and timeline that cannot
move, it likely isn’t suitable for scrum.
Glossary of Scrum Methodology Terms

Before defining the framework of scrum, here’s a short list of some of the more common terms
used when working within a scrum environment.

• Burndown chart: A burndown chart shows much effort is left compared to time
• Burnup chart: Measures the increase in a measure against time
• Definition of done: The definition of done (DOD) is one of the seven scrum artifacts.
It’s an acceptance criterion agreed upon by the scrum team
• Product backlog: A product backlog is work to be done in a specific order
• Product backlog refinement: When the product owner and team add detail to the
product backlog, also known as backlog grooming
• Scrum board: A scrum board helps scrum teams manage their work
• Scrumban: Scrumban is a hybrid methodology that combines scrum and kanban
project management
• Sprint: Short tasks, one following immediately after the completion of another
• Sprint backlog: What the team needs to complete the sprint
• Sprint goal: The purpose of the sprint
• Sprint planning: Sprint planning is a spring event where scrum teams plan their
upcoming sprint
• Sprint retrospective: Short post-mortem of the sprint
• Sprint review: Short review of the sprint to help add improvements to the next one

# extreme programming (XP) methodology

Extreme Programming (XP) is one of the numerous Agile frameworks applied by IT

companies. But its key feature — emphasis on technical aspects of software development —
distinguishes XP from the other approaches.

Software engineer Ken Beck introduced XP in the 90s with the goal of finding ways to write
high-qualitative software quickly and being able to adapt to customers’ changing
requirements. In 1999, he refined XP approaches in the book . XP is a set of engineering
practices. Developers have to go beyond their capabilities while performing these practices.
That’s where the "extreme" in the framework’s title comes from. To get a better
understanding of these practices, we’ll start with describing XP’s lifecycle and the roles
engaged in the process.

The process and roles of extreme programming

The XP framework normally involves 5 phases or stages of the development process

that iterate continuously:

1. Planning, the first stage, is when the customer meets the development team and
presents the requirements in the form of user stories to describe the desired result. The
team then estimates the stories and creates a release plan broken down into iterations
needed to cover the required functionality part after part. If one or more of the stories
can’t be estimated, so-called spikes can be introduced which means that further
research is needed.
2. Designing is actually a part of the planning process, but can be set apart to emphasize
its importance. It’s related to one of the main XP values that we’ll discuss below --
simplicity. A good design brings logic and structure to the system and allows to avoid
unnecessary complexities and redundancies.
3. Coding is the phase during which the actual code is created by implementing specific
XP practices such as coding standards, pair programming, continuous integration, and
collective code ownership (the entire list is described below).
4. Testing is the core of extreme programming. It is the regular activity that involves both
unit tests (automated testing to determine if the developed feature works properly) and
acceptance tests (customer testing to verify that the overall system is created according
to the initial requirements).
5. Listening is all about constant communication and feedback. The customers and
project managers are involved to describe the business logic and value that is expected.
XP lifecycle in a nutshell

Such a development process entails the cooperation between several participants, each having
his or her own tasks and responsibilities. Extreme programming puts people in the center of
the system, emphasizing the value and importance of such social skills as communication,
cooperation, responsiveness, and feedback. So, these roles are commonly associated with XP:

1. Customers are expected to be heavily engaged in the development process by creating

user stories, providing continuous feedback, and making all the necessary business
decisions related to the project.
2. Programmers or developers are the team members that actually create the product.
They are responsible for implementing user stories and conducting user tests
(sometimes a separate Tester role is set apart). Since XP is usually associated
with cross-functional teams, the skill set of such members can be different.
3. Trackers or managers link customers and developers. It’s not a required role and can
be performed by one of the developers. These people organize the meetups, regulate
discussions, and keep track of important progress KPIs.
4. Coaches can be included in the teams as mentors to help with understanding the XP
practices. It’s usually an outside assistant or external consultant who is not involved in
the development process, but has used XP before and so can help avoid mistakes.

Values and principles of extreme programming

In the late 90s, Ken Beck summarized a set of certain values and principles that describe
extreme programming and lead to more effective cooperation within the team and, ultimately,
higher product quality.
Values and principles of XP

Values of extreme programming

XP has simple rules that are based on 5 values to guide the teamwork:

1. Communication. Everyone on a team works jointly at every stage of the project.

2. Simplicity. Developers strive to write simple code bringing more value to a product, as
it saves time and effort.
3. Feedback. Team members deliver software frequently, get feedback about it, and
improve a product according to the new requirements.
4. Respect. Every person assigned to a project contributes to a common goal.
5. Courage. Programmers objectively evaluate their own results without making excuses
and are always ready to respond to changes.

These values represent a specific mindset of motivated team players who do their best on the
way to achieving a common goal. XP principles derive from these values and reflect them in
more concrete ways.

Principles of extreme programming

1. Rapid feedback. Team members understand the given feedback and react to it right
away.
2. Assumed simplicity. Developers need to focus on the job that is important at the
moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat
Yourself) principles.
3. Incremental changes. Small changes made to a product step by step work better than
big ones made at once.
4. Embracing change. If a client thinks a product needs to be changed, programmers
should support this decision and plan how to implement new requirements.
5. Quality work. A team that works well, makes a valuable product and feels proud of it.

Having discussed the main values and principles of XP, let’s take a closer look at the practices
inherent in this framework.

Extreme programming advantages

So, the XP framework can be beneficial and help reduce development time and costs for the
following reasons:

• Continuous testing and refactoring practices help create stable well-performing

systems with minimal debugging;
• Simplicity value implies creating a clear, concise code that is easy to read and change
in the future if needed;
• The minimalistic iterative approach to development ensures that the workable results
can be delivered very soon and only necessary features are built;
• Documentation is reduced as bulky requirements documents are substituted by user
stories;
• No or very little overtime is practiced;
 • Constant communication provides a high level of visibility and accountability and
allows all team members to keep up with the project progress;
• Pair programming has proven to result in higher-quality products with fewer bugs;
most research participants also reported enjoying such collaboration more and feeling
more confident about their job;
• Customer engagement ensures their satisfaction as their participation in the
development and testing process can directly influence the result, getting them exactly
what they wanted.

Extreme programming disadvantages

On the other hand, XP has a number of disadvantages that have to be considered when deciding
on which framework to choose for your next project:

• In many instances, the customer has no clear picture of the end result, which makes it
almost unrealistic to accurately estimate scope, cost, and time;
• Regular meetings with customers often take a great deal of time that could instead
be spent on actual code writing;
• Documentation can be scarce and lack clear requirements and specifications, leading
to project scope creep;
• The rapid transition from traditional methods of software development to extreme
programming demands significant cultural and structural changes;
• Pair programming takes more time and doesn’t always work right due to the human
factor and character incompatibility;
• XP works best with collocated teams and customers present in person to conduct face-
to-face meetings, limiting its application with distributed teams;
• Sometimes customers have neither the desire, time, nor expertise to participate in
product development. Considering tight deadlines, it can become a source of stress as
either no valuable feedback is provided, or a non-technical representative attempts to
manage tech specialists with little or no knowledge on the process;
• Some authors also mention overfocusing on code over design, lack of quality assurance,
code duplication, and poor results with inexperienced developers.

Any company can apply the XP principles in its projects; however, it’s important to understand
both the good and the bad sides. Read on to find out how XP is different from other
methodologies and when applying its techniques would be the best choice.

Extreme programming vs Scrum: Scrum is commonly associated with self-organizing

teams. It also usually has sprints that are 2 to 4 weeks long, while XP iterations are shorter,
taking 1 to 2 weeks. Besides, XP is much more flexible with possible changes within iterations,
while Scrum doesn’t allow any modifications after the sprint backlog is set. Another difference
is that in XP the customer prioritizes features and decides on the order of their development,
but in Scrum the team itself determines what to work on first.
Scrum’s main roles are Product Owner, Scrum Master, and Scrum Team, which are different
from those in XP.
However, there is no need to choose between XP and Scrum. Incorporating XP practices and
Scrum techniques is considered quite effective with XP focusing on engineering aspects and
Scrum organizing the process.

When to use XP
Now that we discussed the XP methodology pros and cons and identified its place among
other agile frameworks, we can talk about the cases when it’s applicable. It’s important to
make sure a company’s size, structure, and expertise, as well as the staff’s knowledge base
allow for applying XP practices. These are the factors to consider.

Highly-adaptive development. Some systems don’t have constant functionality features and
implies frequent changes. XP was designed to help development teams adapt to fast-changing
requirements.

Risky projects. Teams applying XP practices are more likely to avoid problems connected
with working on a new system, especially when a customer sets strict deadlines for a project.
Additionally, a high level of customer engagement reduces the risk of their not accepting the
end product.

Small teams. XP practices are efficient for teams that don’t exceed 12 people. Managing
such groups is usually easier, communication is more efficient, and it takes less time to
conduct meetings and brainstorming sessions.

Automated testing. Another factor that can influence the choice of XP is the developers’
ability to create and run unit tests, as well as availability of the necessary testing tools.

Readiness to accept new culture and knowledge. XP is different from traditional

approaches to software development, and the way some of its practices should be
implemented might not be obvious. So, it’s important that your organization and team
members are ready to embrace change. It’s also worth inviting an experienced coach if you
don’t have previous involvement with XP.

Customer participation. As XP requires customers, developers and managers to work side-

by-side, make sure your client is always available to provide input until a project ends.

# Adaptive project framework (APF) methodology.

Albert Einstein said, "The measure of intelligence is the ability to change."
Yet, businesses often avoid change is often avoided because traditional project management
relies on adapting goals and outcomes to the process, rather than adapting the process to the
goals. As a result, project plans have little room to adapt to evolving needs or solutions.
In today’s fast-paced business climate, where goals and outcomes are often moving targets,
most teams cannot afford the inflexibility of the past. Businesses need to find the right project
management methodology is crucial to run a team that can be responsive to change, rather than
reactive to it.

Adaptive Project Framework (APF), also known as Adaptive Project Management (APM),
accommodates the unknown factors that can crop up during a project. It prepares teams to
anticipate the unexpected and respond. Think of its core principle as "learning by doing." By
approaching projects with the understanding that key components are constantly in flux, teams
can adopt a flexible mindset to continually learn by re-evaluating results and decisions
throughout a project. This requires regular communication with stakeholders at every level for
the team to effectively adapt.

The 5 phases of Adaptive Project Management

1. Project scope

Develop Conditions of Satisfaction (CoS)- The first step in the scoping phase is to identify
the conditions of satisfaction for the project. In other words, stakeholders need to define what
the project’s goals are and what a successful outcome looks like. Because if you don’t know
where you’re going, you won’t know when you’ve made it there.In fact, executives said
the most common factor behind project failure was a lack of clear goals, according to a 2017
report by PMI Pulse of the Profession. Without clear CoS, your project is essentially rudderless.
Outlining the CoS directs the project and helps project managers keep the project on course
throughout subsequent phases. For best results, have every stakeholder approve the CoS before
proceeding. By including all stakeholders, you can avoid miscommunication on project
expectations and adapt as needed.

Write Project Overview Statement (PoS)- The Project Overview Statement is the deliverable
from the CoS. This document outlines the final approved CoS signed by all stakeholders. Refer
to the PoS throughout the project to evaluate the efficacy of your processes as you go. Although
the PoS is approved at the beginning, it can act as a living document under APF. If the scope
or goals of the project evolve, adjust the PoS to accommodate the changing CoS. Don’t forget
to keep all stakeholders involved in the iteration to ensure everyone is on the same page.

Prioritize requirements- Prioritizing the requirements of the project further defines the scope
of the project and also designates the order of implementation. There are a few ways to
prioritize requirements, but the basic approach is to collaborate with stakeholders to organize
the requirements into weighted designations (high, medium, low) with numerical values.
However, keep in mind that while stakeholders should be involved in this process, the analyst
and project manager should guide the discussion to ensure priorities are realistically assigned.

For instance, it’s common for a stakeholder to list most requirements as critical. To avoid this
pitfall, consider these questions as you go:
• What are the consequences for the business objective if we omit this requirement?
• Is there an existing system or process that could compensate?
• Is there any reason we can't defer this requirement until the next release?
With careful prioritization, your team can focus on the right tasks at the right time.

Develop Work Breakdown Structure (WBS)- A WBS breaks the project components and
processes down further into manageable sections. It provides both the framework for cost
estimating and control as well as guidance for schedule development.
Work Breakdown Structure Template (Click on image to modify online)
Prioritize Scope Triangle- The final step in the scoping phase is to evaluate and prioritize the
“Scope Triangle.” The Scope Triangle is a model of your project’s quality constraints: cost,
schedule, and scope. To prioritize the constraints of your project, classify the limits as
“inflexible,” “adaptable,” or “may concede.” Inflexible constraints are critical to the project
and have little leeway. Adaptable constraints are negotiable and have some flexibility but
should be optimized as a much as possible. And “may concede” indicates an area where trade-
offs are possible to compensate for the other constraints. For instance, Project A might have a
strict timeline but a flexible budget. Or Project B may need certain features (affecting the
scope), but the timeline is adaptable.

2. Cycle plan
With your project scoped out, the next phase is planning. This cycle has four basic steps:
• Define tasks from WBS
• Establish dependencies
• Group and assign tasks
• Schedule work
Your goal during this phase is to further define and plan the tasks you’ll be implementing
during the development phase.
This step includes breaking down individual tasks from the WBS, identifying task
dependencies (or the order in which the tasks need to be completed), assigning out the work to
team members, and scheduling the deadlines and timeframes for each portion of the project.

3. Cycle build
Once your project is scoped and planned, you’re ready to dig in and start developing. There are
several key components to this phase:
• Beginning work
• Monitoring and adjusting the cycle build
• Ending the cycle at planned completion time
• Scheduling incomplete functionalities for the next cycle
• Recording all change requests/ideas for improvement
• Recording and tracking all problems
The key difference between adaptive development methodology versus traditional project
management (TPM) is that the timeline set during the scoping and planning cycles is fixed.
In a TPM project, the scheduled completion date can be moved back to meet a deliverable. But
in adaptive development methodology, if a deadline expires, the deliverable is put aside and
reprioritized for the next cycle.

4. Client checkpoint

The client checkpoint phase is a crucial part of the Adaptive Project Framework. This is the
time to check in with the client to review the quality of the functionality delivered in the build
cycle. Based on this evaluation, the client and project manager will work together to schedule
any adjustments or course corrections needed for the next iteration. At this point, the process
repeats itself until the project budget has been expended. In other words, the team returns to
the planning cycle through the build and checkpoint phases until the project is complete.

5. Final review

At the end of an APF project, managers and stakeholders meet to evaluate the success of the
project, note what was learned, and define any improvements for the process in the future.
Conclusion

Whether APF is the best method for your team depends on the type of work you’re doing, but
the beauty of adopting this approach is that the process is adaptable to the project needs. Like
traditional project management, the scoping and planning phase helps outline and direct the
project. But with an adaptive framework, you can work collaboratively with stakeholders at
every level to determine the goals and success of the project as it evolves, rather than waiting
for the project to end to discover whether it met the client’s needs.

This approach promises flexibility and savings when implemented correctly. But with so many
iterations and collaborations, it’s easy for projects to lose focus fast. That’s why having the
right tools can make all the difference.

Agile Methodology vs Waterfall Methodology in Project Management:

Agile Project Management Waterfall Project Management

Client input is required throughout the Client input is required only after completing
product development. each phase.
Changes can be made at any stage. Changes cannot be made after the
completion of a phase.
Coordination among project teams is Coordination is not needed as one team starts
required to ensure correctness. the work after the finish of another team.
It is really useful in large and complex It is mainly used for small project
projects. development.
The testing part can be started before the Testing can only be performed when the
development of the entire product. complete product is ready.
A Small team is sufficient for Agile project It requires a large team.
management.
The cost of development is less. The cost of development is high.
It completes the project in comparatively less It takes more time compared to Agile.
time.
The Agile Method is known for its flexibility. The waterfall Method is a structured
software development methodology so it is
quite rigid.
After each sprint/cycle test plan is discussed. Hardly any test plan is discussed during a
cycle.