Unit-1

Agile software development

Agile software development refers to a group of software development

methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-functional
teams.
Agile methods or Agile processes generally promote a disciplined project
management process that encourages frequent inspection and adaptation, a
leadership philosophy that encourages teamwork, self-organization and
accountability, a set of engineering best practices intended to allow for rapid
delivery of high-quality software, and a business approach that aligns
development with customer needs and company goals.

Agile is a type of software development methodology that anticipates the need

for flexibility and applies a level of pragmatism to the delivery of the finished
product. Agile software development requires a cultural shift in many
companies because it focuses on the clean delivery of individual pieces or parts
of the software and not on the entire application. 

Benefits of Agile include its ability to help teams in an evolving landscape

while maintaining a focus on the efficient delivery of business value. The
collaborative culture facilitated by Agile also improves efficiency throughout
the organization as teams work together and understand their specific roles in
the process. Finally, companies using Agile software development can feel
confident that they are releasing a high-quality product because testing is
performed throughout development. This provides the opportunity to make
changes as needed and alert teams to any potential issues.

Agile has largely replaced waterfall as the most popular development

methodology in most companies, but is itself at risk of being eclipsed or
consumed by the growing popularity of DevOps.
The four values of Agile
In 2001, 17 software development professionals gathered to discuss concepts
around the idea of lightweight software development and ended up creating
the Agile Manifesto. The Manifesto outlines the four core values of Agile, and
although there has been debate about whether the Manifesto has outlived its
usefulness, it remains at the core of the Agile movement.

The four core values outlined in the Agile Manifesto are as follows:

Individual interactions are more important than processes and tools. People

drive the development process and respond to business needs. They are the most
important part of development and should be valued above processes and tools.
If the processes or tools drive development, then the team will be less likely to
respond and adapt to change and, therefore, less likely to meet customer needs.

A focus on working software rather than thorough documentation. Before

Agile, a large amount of time was spent documenting the product throughout
development for delivery. The list of documented requirements was lengthy and
would cause long delays in the development process. While Agile does not
eliminate the use of documentation, it streamlines it in a way that provides the
developer with only the information that is needed to do the work -- such
as user stories. The Agile Manifesto continues to place value on the process of
documentation, but it places higher value on working software.

Collaboration instead of contract negotiations. Agile focuses on

collaboration between the customer and project manager, rather than
negotiations between the two, to work out the details of delivery. Collaborating
with the customer means that they are included throughout the entire
development process, not just at the beginning and end, thus making it easier for
teams to meet the needs of their customers. For example, in Agile, the customer
can be included at different intervals for demos of the product. However, the
customer could also be present and interact with the teams daily, attend all
meetings and ensure the product meets their desires.
A focus on responding to change. Traditional software development used to
avoid change because it was considered an undesired expense. Agile eliminates
this idea. The short iterations in the Agile cycle allow changes to easily be
made, helping the team modify the process to best fit their needs rather than the
other way around. Overall, Agile software development believes change is
always a way to improve the project and provide additional value.

The 12 principles of Agile

The Agile Manifesto also outlined 12 core principles for the development
process. They are as follows:

1. Satisfy customers through early and continuous delivery of valuable work.

2. Break big work down into smaller tasks that can be completed quickly.
3. Recognize that the best work emerges from self-organized teams.
4. Provide motivated individuals with the environment and support they need
and trust them to get the job done.
5. Create processes that promote sustainable efforts.
6. Maintain a constant pace for completed work.
7. Welcome changing requirements, even late in a project.
8. Assemble the project team and business owners on a daily basis throughout
the project.
9. Have the team reflect at regular intervals on how to become more effective,
then tune and adjust behavior accordingly.
10.Measure progress by the amount of completed work.
11.Continually seek excellence.
12.Harness change for a competitive advantage.
The Agile software development cycle
The Agile software development cycle can be broken down into the following
six steps:

 concept
 inception
 iteration/construction
 release
 production
 retirement

The first step, concept, involves the identification of business opportunities in

each potential project as well as an estimation of the time and work that will be
required to complete the project. This information can then be used to prioritize
projects and discern which ones are worth pursuing based on technical and
economic feasibility.

During the second step, inception, team members are identified, funding is

established and the initial requirements are discussed with the customer. A
timeline should also be created that outlines the various responsibilities of teams
and clearly defines when work is expected to be completed for each sprint. A
sprint is a set period of time during which specific work has to be completed
and made ready for review.

A
visualization of the Agile software development cycle
The third step, iteration/construction, is when teams start creating working
software based on requirements and continuous feedback. The Agile software
development cycle relies on iterations -- or single development cycles -- that
build upon each other and lead into the next step of the overall development
process until the project is completed. Each iteration typically lasts between two
to four weeks, with a set completion date. The goal is to have a working product
to launch at the end of each iteration.

Multiple iterations occur throughout the development cycle and they each
possess their own workflow. A typical iteration flow consists of the following:

 defining requirements based on the product backlog, sprint backlog and

customer and stakeholder feedback;
 developing software based on the set requirements;
 conducting QA testing, internal and external training and documentation;
 delivering and integrating the working product into production; and
 gathering customer and stakeholder feedback on the iteration in order to
define new requirements for the next sprint.

The fourth step, release, involves final QA testing, resolution of any remaining

defects, finalization of the system and user documentation and, at the end,
release of the final iteration into production.

After the release, the fifth step, production, focuses on the ongoing support
necessary to maintain the software. The development teams must keep the
software running smoothly while also teaching users exactly how to use it. The
production phase continues until the support has ended or the product is planned
for retirement.

The final step, retirement, incorporates all end-of-life activities, such as

notifying customers and final migration. The system release must be removed
from production. This is usually done when a system needs to be replaced by a
new release or if the system becomes outdated, unnecessary or starts to go
against the business model.

Throughout the Agile cycle, different features can be added to the product
backlog, but the entire process should consist of repeating each step over and
over until every item in the backlog has been satisfied. This makes the Agile
cycle more of a loop than a linear process. At any time, an enterprise can have
multiple projects occurring simultaneously with iterations that are logged on
different product lines and a variety of internal and external customers
providing different business needs.

Types of Agile methodologies

The goal of every Agile methodology is to embrace and adapt to change while
delivering working software as efficiently as possible. However, each method
varies in the way it defines the steps of software development. The most widely
used Agile methods include the following:

 Scrum
 Lean software development
 Extreme programming
 Crystal
 Kanban
 Dynamic systems development method
 Feature-driven development

Scrum is a lightweight Agile framework that can be used by project managers

to control all types of iterative and incremental projects. In Scrum, the product
owner creates a product backlog that allows them to work with their team to
identify and prioritize system functionality. The product backlog is a list of
everything that needs to be accomplished to deliver a successful, working
software system -- this includes bug fixes, features and non-functional
requirements. Once the product backlog is defined, no additional functionality
can be added except by the corresponding team.

Once the team and the product owner have established the priorities, cross-
functional teams step in and agree to deliver working increments of software
during each sprint -- often within 30 days. After each sprint, the product
backlog is reevaluated, analyzed and reprioritized in order to select a new set of
deliverable functions for the next sprint. Scrum has gained popularity over the
years since it is simple, has proven to be productive and can incorporate the
various overarching practices promoted by the other Agile methods.

Scrum is the type of Agile framework. It is a framework within which people

can address complex adaptive problem while productivity and creativity of
delivering product is at highest possible values. Scrum uses Iterative
process. Silent features of Scrum are:
 Scrum is light-weighted framework
 Scrum emphasizes self-organization
 Scrum is simple to understand
 Scrum framework help 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.
 Advantage of using 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 using 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, 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.

Lean software development is another iterative method that places a focus on

using effective value stream mapping to ensure the team delivers value to the
customer. It is flexible and evolving; it does not have rigid guidelines or rules.
The Lean method uses the following primary principles:

 Increasing learning
 Empowering the team
 Fostering integrity
 Removing waste
 Understanding the whole
 Making decisions as late as possible
 Delivering the product as fast as possible
The Lean method relies on fast and reliable feedback between the customers
and programmers in order to provide fast and efficient development workflows.
To accomplish this, it provides individuals and small teams with decision-
making authority instead of relying on a hierarchical flow of control. To
eliminate waste, the Lean method asks users to only select truly valuable
features for their system, prioritize these chosen features and then deliver them
in small batches. Lean software development also encourages automated unit
tests to be written simultaneously with the code and concentrates on ensuring
every member of the team is as productive as possible.

The extreme programming (XP) method is a disciplined approach that focuses

on speed and continuous delivery. It promotes increased customer involvement,
fast feedback loops, continuous planning and testing and close teamwork.
Software is delivered at frequent intervals -- usually every one to three weeks.
The goal is to improve software quality and responsiveness when faced with
changing customer requirements.

The XP method is based on the values of communication, feedback, simplicity

and courage. Customers work closely with their development team to define and
prioritize their requested user stories. However, it is up to the team to deliver the
highest priority user stories in the form of working software that has been tested
at each iteration. To maximize productivity, the XP method provides users with
a supportive, lightweight framework that guides them and helps ensure the
release of high-quality enterprise software.

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.
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 higher product quality.

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.

Principles of extreme programming

Most researchers denote 5 XP principles as:

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.
Advantages and disadvantages of XP
XP practices have been debated upon for decades, as its approach and methods
are rather controversial in a number of aspects and can’t be applied in just any
project. Here, we’ll try to define the pros and cons of XP methodology.
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.

Comparison of XP to other frameworks

As we mentioned above, XP is part of the agile methodology. It shares the main
agile principles, i.e., frequent releases, short development cycles, constant
communication with the customer, cross-functional teams, and so on. For this
reason, XP is often confused with other popular Agile frameworks such as
Scrum, Kanban, and Lean. Check our detailed whitepaper to get more in-depth
information or the infographics for a quick summary of the main agile methods.
Here, we’ll briefly compare them and see what the main differences are.

But before we dive in, it’s important to note that XP is not really a project
management framework, even though a lot of its practices overlap with those
from the project management domain. So, its primary focus is on the technical
aspects of development and the implementation of specific practices rather than
the management and organizational sides.
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.

Extreme programming vs Kanban

Kanban puts a lot of focus on visualizing the development process and strictly
limits the number of features developed at a time. It’s also characterized by a
continuous workflow while XP has separate iterations, even though both
suggest small frequent releases and a high level of flexibility and adaptiveness
to the changing requirements.

The roles in Kanban are not strictly defined.

Extreme programming vs Lean

It’s hard to actually compare XP and Lean because the latter is more of a
philosophy or approach to the development process and bringing value to the
customer. Its core principles include eliminating waste, deciding as late as
possible, delivering as early as possible, and so on. So, Lean’s main focus is not
on time-boxed iterations or specific engineering practices as in XP, but largely
on a fast MVP delivery and reducing time waste.

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.

Agility principles are becoming increasingly popular as they prove their

effectiveness. Even though extreme programming is not the most widespread
methodology, it offers a lot of sensible practices that can benefit software
development and are worth considering for implementation in your projects.

Crystal is the most lightweight and adaptable methodology. It focuses on

people and the interactions that occur while working on an Agile project as well
as business-criticality and priority of the system under development. The
Crystal method works off the realization that every project possesses unique
characteristics that require a slightly tailored set of policies, practices and
processes. As a result, it is made up of a collection of Agile process models,
such as Crystal Orange, Crystal Clear and Crystal Yellow. Each model has its
own unique characteristics that are driven by different factors, including project
priorities, team size and system criticality. 

Like other Agile methodologies, Crystal emphasizes frequent delivery of

working software with high customer involvement, adaptability and the
elimination of bureaucracy and distractions. Its key principles include
communication, teamwork and simplicity.

Kanban uses a highly visual workflow management method that allows teams

to actively manage product creation -- emphasizing continuous delivery --
without creating more stress in the software development lifecycle (SDLC). It
has become popular among teams also practicing Lean software development.

Kanban uses three basic principles: visualize the workflow; limit the amount of
work in progress; and improve the flow of work. Like the Scrum, the Kanban
method is designed to help teams work more efficiently with each other. It
encourages continuous collaboration and attempts to define the best possible
workflow in order to promote an environment with active and ongoing learning
and improvement.

The dynamic systems development method (DSDM) is a response to the need

for a common industry framework for rapid software delivery. The DSDM is
based on eight key principles; failing to abide by any one of the principles
introduces risk to successful completion of the project. The eight principles are
as follows:

1. Collaboration
2. On-time delivery
3. Demonstrated control
4. Continuous, clear communication
5. A constant focus on the business need
6. Iterative development
7. Creation in increments from firm foundations
8. Refusal to compromise quality

In the DSDM, rework is built into the process and all changes must be
reversible. System requirements are prioritized using MoSCoW Rules, which
ranks priority as follows:

 M -- must have
 S -- should have
 C -- could have, but not critical
 W -- won't have now, but could have later

It's important in DSDM that not every requirement is considered critical. Each
iteration should include less critical items which can be removed so higher
priority requirements are not impacted.

Finally, feature-driven development (FDD) blends software engineering best

practices -- such as developing by feature, code ownership and domain object
modeling -- to create a cohesive, model-driven, short-iteration process. FFD
begins by defining an overall model shape, which in turn creates a feature list.
The method then proceeds with iterations that last two weeks and focus on
planning by feature, designing by feature and building by feature. If a feature
takes more than two weeks to build, then it should be broken down into smaller
features. The primary advantage of FDD is that it is scalable -- even to large
teams -- since it uses the concept of "just enough design initially," or JEDI.

Advantages and disadvantages of Agile

Much has been compared over the years with Agile vs. Waterfall approaches.

In the Waterfall era of software development, coders worked alone, with little to
no input before handing the software to testers and then on to production. Bugs,
complications and feature changes either weren't handled well, or were dealt
with so late in the process that projects were seriously delayed or even scrapped.
The idea behind the Agile model, in which everyone -- including the business
side -- stayed involved and informed in the development process, represented a
profound change in both company culture and the ability to get better software
to market more quickly.

Collaboration and communication became as important as technology, and

because the Agile Manifesto is open to interpretation, Agile has been adapted
and modified to fit organizations of all sizes and types. The Agile cultural shift
also paved the way for the latest software development evolution, DevOps.

On the other hand, many would say the biggest disadvantage of Agile is the fact
it has been modified -- some would say diluted -- by many organizations. This
phenomenon is so widespread that the "Agile my way" practitioners are known
as "ScrumButs," as in, "We do Scrum in our organization, but …."

Although Agile opens the lines of communication between developers and the
business side, it's been less successful bringing testing and operations into that
mix -- an omission that may have helped the idea of DevOps gain traction.

Another potential concern about Agile is its lack of emphasis on technology,

which can make it difficult to sell the concept to upper managers who don't
understand the role that culture plays in software development. Furthermore, the
necessity of completing sprints on time can create a stressful work environment
for software developers. They may be forced to work extra hours and stay late
in order to meet deadlines.

DSDM: A Hybrid Approach to Promote Agility while Delivering Business

Value
Dynamic System Development Method or DSDM is a long-standing approach
that’s been used successfully since 1994 for rapid software development and
delivery.
With its iterative and incremental approach it was agile well before the Agile
Manifesto was written and went a lot further than the team level, making it an
agile scaling methodology (not just a framework) long before the term ‘scaling
agile’ was coined.
Like SAFe, it gives you a lot of guidance, much more than other scaling
frameworks. That’s a huge advantage when you’re still finding your agile feet
— you’ll have a lot more to hold on to.
So, read on to get a firm grounding in its philosophy, principles, roles, and focus
on successfully delivering value to your business quickly.
Brief Overview
DSDM considers the need to react quickly throughout the development of the
product while incorporating the constraints often imposed by corporate cultures
and processes.
Managing projects using DSDM helps resolve many of the problems we face
when running projects more traditionally.
For example, DSDM uses regular facilitated workshops and encourages the
team to interact, which helps resolve the natural communication problems faced
by many projects.
DSDM focuses on delivering on time because delivering 80% of the features
working and on time is better than trying to deliver everything late.
Customers are human. As their knowledge of the product increases throughout
the development phase, they tend to change their mind. Therefore, DSDM’s
approach to understanding customer requirements is to involve a customer in
the solution development.
Early customer involvement helps avoid problems, stop unwanted features from
being built, and ensure the business gets what it needs. It also helps to prevent
over-engineering or gold plating the output.
All of these positive impacts ensure the customer gets a return on its investment
as soon as possible.
Brief History
DSDM is an iterative and incremental approach that embraces Agile
development principles, including continuous user/customer involvement.
DSDM was first released in 1994. And it was created to provide some discipline
to what was at that time the rapid application development method(RAD),
another method in use.
The first DSDM practitioners recognized that sequential development models
like a waterfall and rapid application development had strengths and areas to
improve.
They aimed to combine RAD’s ability to develop valuable solutions quickly
with an understanding of the broader project context and the need for
stakeholder engagement.
In 2007, the DSDM project framework was revised. It became a more generic
approach to project management and solution delivery rather than explicitly
focused on software development and code creation.
In 2014, DSDM released the latest version. The new DSDM manual recognized
the need for DSDM to work alongside other frameworks used for service
delivery like ITIL, PRINCE2, and the Project Management Institute’s Body of
Knowledge (PMI-BOK).
The DSDM Philosophy, Principles, and Project Variables
The DSDM Philosophy
The DSDM philosophy is that any project must be aligned to clearly defined
strategic goals and focus upon early delivery of real benefits to the business.
This is achieved when all stakeholders:
 Understand and buy into the business vision and objectives
 Are empowered to make decisions within their area of expertise
 Collaborate to deliver a fit for purpose business solution
 Collaborate to deliver to agreed timescales in accordance with business
priorities
 Accept that change is inevitable as the understanding of the solution grows
over time
The DSDM philosophy is supported by eight principles that build the
mindset and behaviors necessary to bring the philosophy alive.
The principles are themselves supported by four Ps:
 people (with defined roles and responsibilities),
 an agile process (enabling an iterative and incremental life cycle to shape
development and delivery),
 clearly described products,
 and recommended practices to help achieve the optimum results.

The DSDM Principles

The eight principles of DSDM bring the agile values to life by guiding the team
in the attitude it must take and the mindset it must adopt in order to deliver
consistently whilst still remaining flexible.

Principle 1 – Focus on the Business Need

Every decision taken during a project should be viewed in the light of the
overarching project goal – to deliver what the business needs to be delivered,
when it needs to be delivered.
 

Principle 2 – Deliver on Time

Delivering a solution on time is a very desirable outcome for a project and is
quite often the single most important success factor.
 

Principle 3 – Collaborate
Collaboration encourages increased understanding, greater speed and shared
ownership, which enable teams to perform at a level that exceeds the sum of
their parts.
 

Principle 4 – Never Compromise Quality

In DSDM, the level of quality to be delivered is agreed at the start. All work
should aim to achieve that level of quality – no more and no less.
 

Principle 5 – Build Incrementally from Firm Foundations

DSDM advocates understanding the scope of the business problem to be solved
and the proposed solution first, but not in such detail that the project becomes
paralysed by overly detailed analysis of requirements.
 

Principle 6 – Develop Iteratively

DSDM uses a combination of Iterative and Incremental Development, frequent
demonstrations and comprehensive review to encourage timely feedback.
Embracing change as part of this evolutionary process allows the team to
converge on an accurate business solution.
 

Principle 7 – Communicate Continuously and Clearly

Poor communication is often cited as the biggest single cause of project failure.
DSDM practices are specifically designed to improve communication
effectiveness for both teams and individuals.
 

Principle 8 – Demonstrate Control

The use of well-defined Timeboxes, with constant review points, and the
preparation of the Management Foundations and Timebox Plans, are designed
to assist the Project Manager and the rest of the project team to follow this
principle.
The eight principles of DSDM bring the agile values to life by guiding the team
in the attitude it must take and the mindset it must adopt in order to deliver
consistently whilst still remaining flexible.

The Project Variables

In the traditional approach to managing a project (left-hand diagram), the
features content of the solution is fixed whilst time and cost are subject to
variation. If the project goes off track, more resources are often added (which
varies the cost), and the delivery date is extended (which changes the time).
However, adding resources to a late project often makes it even later, and a
missed deadline can be disastrous from a business perspective and often
damages credibility. Under such pressure, quality often becomes a variable due
to introducing compromises that have not been thought through, reducing
essential quality control steps, or cutting back on testing.

The Project Variables

In the traditional approach to managing a project (left-hand diagram), the
features content of the solution is fixed whilst time and cost are subject to
variation. If the project goes off track, more resources are often added (which
varies the cost), and the delivery date is extended (which changes the time).
However, adding resources to a late project often makes it even later, and a
missed deadline can be disastrous from a business perspective and often
damages credibility. Under such pressure, quality often becomes a variable due
to introducing compromises that have not been thought through, reducing
essential quality control steps, or cutting back on testing.DSDM’s approach to
managing the project (right-hand diagram) fixes time, cost, and quality at the
end of the Foundations phase. At the same time, contingency is controlled by
varying the features (the requirements) to be delivered. As and when the
contingency is required, lower priority requirements are dropped or deferred,
with the full agreement of the business stakeholders following MoSCoW
priorities.

The DSDM Process Model

The DSDM has a five-phase life cycle as shown below.
The Feasibility and Business Study
In the feasibility and study phase, the problem is defined and technical
feasibility of the desired application is verified. It is also checked whether the
application is suitable for the Rapid Application Development (RAD) approach
or not.
Only if the RAD is found as a justified approach for the desired system, the
development continues.
Functional Model Iteration
The main focus in this phase is on building the prototype iteratively and getting
it reviewed by the users to bring out the requirements of the desired system.
The prototype is improved through demonstration to the user, taking the
feedback, and incorporating the changes. This cycle is repeated generally twice
or thrice until a part of the functional model is agreed upon.
The end product of this phase is a functional model consisting of an analysis
model and some software components containing significant functionality.
Design and Build Iteration
This phase ensures that the prototypes are satisfactorily and properly engineered
to suit their operational environment.
The software components designed during the functional modeling are further
refined till they achieve a satisfactory standard.
The two phases, as a result, may simultaneously continue. The product of this
phase is a tested system ready for implementation.
Implementation
Implementation is the last and final development stage in this methodology.
In this phase, the users are trained, and the system is put into the operational
environment.
At the end of this phase, there are four possibilities, as depicted:
 Everything was delivered as per the user demand, so no further
development is required.
 A new functional area was discovered, so return to the business study phase
and repeat the whole process.
 A less essential part of the project was missed out due to time constraints.
So development returns to the functional model iteration.
 Some non-functional requirements were not satisfied, so the development
returns to the design and build phase.
Products Produced in the DSDM Process and Their Purpose
The DSDM Agile Project Framework describes a set of products to be
considered as the project proceeds. These products describe the solution itself
(the main deliverable of the project) and anything created to help with the
process of evolving it, and anything that is required to help with project
governance and control.
DSDM identifies two distinct types of product:
 Evolutionary products evolve over time. They typically, but not always,
span a number of project phases and may be baselined more than once
during that time.
 Milestone products are created in a phase and typically fulfil a specific
purpose within that phase as a checkpoint or to facilitate governance
processes
Product Key:

Type of
Product Description
Product

It is a high-level definition of the overarching

Terms of business driver for, and top-level objectives of, the
Milestone
Reference project. ToR scopes and justifies the Feasibility
phase.

Feasibility It provides a snapshot of the evolving business,

Milestone
Assessment solution and management products.

It provides a vision and a justification for the project

Business Case Evolutionary
from a business perspective.

Benefits It describes how the benefits have actually accrued,

Milestone
Assessment following a period of use in live operation.

The Prioritised
It describes, at a high level, the requirements that the
Requirement Evolutionary
project needs to address and indicates their priority.
List
 Type of
Product Description
Product

It reflects the management approach of the project as

Management a whole. For instance, how the project will be
Approach Evolutionary organised and planned, how stakeholders will be
Definition engaged in the project and how progress will be
demonstrated and, if necessary, reported.

It provides a high-level schedule of Project

Delivery Plan Evolutionary Increments and, at least for the first/imminent
Increment, Timeboxes that make up that Increment.

It provides depth and detail for each Timebox

Timebox Plan Evolutionary
identified in the Delivery Plan.

Timebox It captures the feedback from each review that takes

Evolutionary
Review Record place during a Timebox.

It is typically a single document that is updated,

Project Review incrementally, at the end of each Project Increment by
Milestone
Report the addition of new sections pertinent to that
Increment.
 Type of
Product Description
Product

It provides a high-level design framework for the

solution. It covers both business and technical aspects of
Solution
Evolutionary the solution to a level of detail that makes the scope of
Foundations
the solution clear but does not constrain evolutionary
development.

Solution Evolutionary It provides a high-level definition of the tools,

Assurance techniques, customs, practices and standards that will be
Pack applied to the evolutionary development of the solution.
Importantly it describes how the quality of the solution
 will be assured.

It is made up of all appropriate components of the final

Evolving solution together with any intermediate deliverables
Evolutionary
Solution necessary to explore the detail of requirements and the
solution under construction.

This is a baseline of the Evolving Solution, which is

Deployed deployed into live use at the end of each Project
Evolutionary
Solution Increment.

Feature-Driven Development (FDD)

Feature-Driven Development (FDD) is a client-centric, architecture-centric,
and pragmatic software process. The term “client” in FDD is used to
represent what Agile Modeling (AM) refers to asstakeholders  or eXtreme
Programming (XP)  calls customers. FDD was first introduced to the world in
1999 via the book
Java Modeling In Color with UML , a combination of the software process
followed by Jeff DeLuca’s company and Peter Coad’s concept of features.
FDD was first applied on a 15 month, 50-person team for a large Singapore
bank in 1997, which was immediately followed by a second, 18-month long
250-person initiative. A more substantial description is published in the
book A Practical Guide to Feature-Driven Development  as well as
the Feature Driven Development  web site.
As the name implies, features are an important aspect of FDD. A feature is a
small, client-valued function expressed in the form “Action result object”.
For example, “Calculate the total of a sale”, “Validate the password of a
user”, and”Authorize the sales transaction of a customer”. Features are to
FDD asuser stories  are to Scrum – they’re a primary source of requirements
and the primary input into your planning efforts.As you see in Figure 1 there
are five main activities in FDD that are performed iteratively. The first is
Develop AnOverall Model, the initial result being a high-level object model
and notes. At the start of an initiative  your goal is to identify and understand
the fundamentals of the domain that your system is addressing, and
throughout the initiative you will flesh this model out to reflect what you’re
building. The second step is Build A Features List , grouping them
into related sets and subject areas .These first two steps map to the initial
envisioning effort of AMDD  (seeFigure 2). Next you Plan By Feature, the
end result being a development, the identification of class owners (more on
this in a minute), and the identification of feature set owners. The majority
of the effort on an FDD team, roughly 75%, is comprised of the fourth and
fifth steps: Design ByFeature and Build By Feature. These two activities are
exactly what you’d expect, they include tasks such as detailed modeling,
programming, testing, and packaging of the system.
Figure 1. The FDD lifecycle.

Figure 2. The lifecycle of AMDD.

An FDD initiative starts by performing the first three steps in the equivalent
of the DAD’s Inception phase or XP’s “iteration 0”, the goal being to
identify the scope of the effort, the initial architecture , and the initial high-
level plan. Construction efforts occur in two-week (or less) iterations,
similar to XP or DAD teams, with the team iteratively working through all
five steps as needed. As with other agile software development processes,
systems are delivered incrementally by FDD teams.There are six primary
roles on an FDD team: Project Manager, Chief Architect, Development
Manager, ChiefProgrammer, Class Owner, and Domain Expert. An
individual will take on one or more roles on a team as you would expect.
The concept of a class owner is where FDD differs from XP. XP includes a
practice called Collective Ownership  the idea of which is that any developer
can update any artifact, including source code, as required. FDD takes a
different approach in that it assigns classes to individual developers, so if a
feature requires changes to several classes then the owners of those classes
must work together as a feature team to implement it. Just like programming
pairs will model storm to think something through before they code it, so
will feature teams.FDD also defines a collection of supporting roles,
including:
o Domain Manager
o Release Manager
o Language Guru
o Build Engineer
o Toolsmith
 o System Administrator
o Tester
o Deployer
o Technical Writer
FDD’s five steps are supported by several practices. The first is domain
object modeling, the creation of a high-level class diagram and supporting
artifacts that describes the problem domain. Developing by feature and
individual class ownership are also good practices, as is having developers
work together in feature teams.Inspections are an important aspect of FDD.
FDD also insists on regular builds, similar to XP, and configuration
management. Finally, FDD promotes a best practice called
reporting/visibility of results, similar to XP and AM’sphilosophy of open
and honest communication .How would Agile Modeling (AM) be applied on
an FDD team? The principles and practices can be clearly appliedto FDD’s
two modeling-oriented steps – develop an overall model and design by
feature. The only apparent mismatch between the two processes is FDD’s
practice of class ownership and AM’s practice of collective ownership , but I
would argue that this isn’t the case. FDD’s practice pertains to coding but
does not to modeling, on a FDD team people work together in teams to
model, along the lines of AM’s model with otherspractice, and therefore
several people will be working on your shared collection of modeling
artifacts.

MODELING MISCONCEPTIONS

Common Misconceptions about Agile Technology

The use of agile methodology is a popular topic in many industries. As a result,
there is often a lot of buzz about it, which leads to many misconceptions. Below
are 10 widespread misconceptions regarding Agile software development that
we’ve run into.

1. Agile is a brand-new idea

The vast majority of people believe this to be true. The Agile Manifesto has
been in effect since 2001, while the Scrum Pattern language was initially
presented in 1995. Agile may be new in comparison to time-tested techniques
such as waterfall, but Agile practice is nothing new, having been in use for more
than two decades. Some authorities assert that Professor Alan Perlis coined the
word “agile” for the first time when he spoke on sequential recurrence,
integrated testing, and design at the 1968 NATO Conference on Software
Engineering.

2. Agile requires no documentation

People often make this incorrect assumption about Agile. The myth comes from
one of the four Agile Manifesto principles, which asserts that you should
emphasize the working software before detailed documentation. However, this
does not imply that you don’t need any documentation for the activity.
According to the guiding concept, the team should prioritize producing a usable
software product above spending time on documentation. Agile advocates
avoiding needless paperwork while completing the needful.

You should thoroughly document the project to carry everyone along, keep
track of all decisions, learn from errors, and report on the project’s progress

3. Agile entails no planning

. Agile development projects need some planning, which should cover specifics
like development priorities, an assessment of the work and responsibilities
involved, objectives, and an entire budget to serve as a guide for choices
throughout development. The fact that this is a “guide” and not a set course of
action is crucial. Planning is a continuous process that involves all parties
throughout development and monitoring progress.

4. Agile models are incompatible with other models

Another misconception about Agile is that its approach is incompatible with the
process models from other models. The Agile approach, on the other hand,
gives customers more freedom to incorporate different elements of conventional
techniques into it. Although the phases in the agile method’s product
development cycles are shorter and more numerous, they are nevertheless
complete, like those in the other traditional approaches. Agile techniques are
incredibly compatible with conventional methods’ procedures in this way.

Also, one way to integrate the agile approach with a conventional plan-driven
model, such as the waterfall approach, is to employ its sprints within the
waterfall model’s linear structure to begin work on the subsequent stage without
finishing the preceding stage’s work first. Ultimately, it is up to the project
manager to decide whether and how to integrate agile approaches with other
methodologies.

5. The agile technique eliminates the management role

Due to the great flexibility, it offers in contrast with conventional plan-driven
techniques, another common misconception about agile methodology holds that
it does away with the need to precisely define the sequence and roles. It is false
once more since agile defines each person’s function, and the project manager
doubles as the owner of the product. The product owner is accountable for
product management, including setting the project team’s priorities and goals,
as well as motivating them to complete their assigned tasks.

A Scrum Master, who works in tandem with the product owner on agile
projects, is in charge of ensuring that the project’s development teams perform
at their highest level throughout each sprint. The project’s whole team,
including those accountable for achieving the project’s objectives through
continuous work on it, is a part of the agile product development team. The
development teams collaborate with the product owner to determine the number
of tasks to complete in each sprint and how to arrange them to complete the
project as quickly as feasible.

6. Agile technique is mostly used in software development

Another popular misconception about agile methodology is that it was created

exclusively for software development. Although agile project management
started with software development, it has developed into a comprehensive
method that applies to other kinds of projects where there is a higher likelihood
of change and continuation and shorter feedback cycles.

Agile Modeling (AM) is a collection of values, principles, and practices for

modeling software that can be applied on a software development project in an
effective and lightweight manner.”

The modeling adds to existing Agile methodologies such as the Rational

Unified Process (RUP) or extreme programming (XP). Agile modeling helps
developers create a customized software development process that fulfills their
development needs yet is flexible enough to adjust to future situations.

Agile Modeling Embraces Five Values:

 Communication.

Agile modeling fosters communication between team members, developers, and

stakeholders.
 Simplicity.

Models help simplify both the software and the software development process.

Drawing a diagram that illustrates a concept or plan and the related growth can
eliminate hours of unnecessary work and manual coding.

 Feedback.

Similar to the “communication” step, team members who use diagrams to

communicate their ideas enable stakeholders to give fast feedback, which then
cuts the project turnaround time.

 Courage.

Fortune favors the bold, and you need the courage to make the difficult
decisions and change course, even if your team has already spent much time and
resources on the work.

 Humility.

Although some iterations of Agile modeling values stop at four, other models
include this fifth one. Humility shows that everyone on the team is essential and
has equal value. Sometimes we can even be wrong! Humility, in this case,
means respect for others’ ideas and suggestions and acknowledging the value of
others’ contributions.

The modeling embraces 11 core principles. You will notice many of the

principles reference the five values we previously discussed.

1. Model With a Purpose.

Ask why you’re developing the models and who you are developing them for.

2. Adopt Simplicity.

Keep the models as straightforward and uncomplicated as possible, and believe

the simplest solution is also the best solution. Remember Occam's Razor, which
tells us that the solution with the fewest unknowns (e.g., the easiest answer) is
usually the correct one. Only model what you need right now.
3. Embrace Change.

The more your understanding of a project grows, the more likely it will change.
Instead of fighting change, accept them and have the courage to readjust and
rebuild.

4. Your Secondary Goal is Enabling the Next Effort.

Your successors might have to improve or enhance your project after you
depart. Leave them enough documentation and models to expedite possible
changes or improvements.

5. Incremental Change.

It’s rare for a model to be complete on the first try. Models evolve as the project
grows and develops. You can cushion against the shock of change by making
minor changes to the models as needed.

6. Maximize Stakeholder Investment.

The team must make the best effort to develop software that meets the
stakeholder’s needs. Bear in mind, the whole purpose of producing the software
is to maximize the return for the client.

7. Remember the Existence of Multiple Models.

There are many modeling solutions available, so pick the ones that fit the
current situation best. Additionally, there are many different methods of
software delivery.

8. Produce Quality Work.

Nobody wants careless, rushed work. The developer doesn't like it because they
know it's not something they can be proud of deep down. The teams that come
later to check the work don't like it because sloppy work is challenging to
understand and means more hours spent fixing it. And finally, the end-users
won't like the sub-par work because it most likely won’t function properly or
doesn't meet their expectations.
9. Provide Rapid Feedback.

Receiving timely feedback on the model closes the model’s loop of

understanding. Model a small portion—show it to the appropriate parties for
review—then model again.

10. Make Working Software Your Primary Goal.

Models are just a means to the end, which is building great software for your
customer. Make sure that documentation and modeling directly support the goal
of your software development project.

11. Travel Light.

Traveling light is another way of saying that you have sufficient documentation
about the models you’re developing, but no more than that. If you have too little
documentation, the developing team might lose its way—if you have too much,
the development team may forget that the primary goal is not writing
documentation but instead building software and the right models!

Phases of the Agile Model

The Agile breaks down tasks into smaller iterations, each of which lasts for a
short time frame (one to four weeks) in the overall process model. As in the
case of the core values of Agile, there are several versions of the model and its
phases
 Requirements Gathering:

Here is where you define the project’s requirements. This phase includes
explaining business opportunities and planning the time and effort required for
the project. Once you quantify this information, you can evaluate the technical
and economic feasibility of your project

 Design the Requirements:

Once you’ve identified the project parameters, work with the stakeholders to
define the requirements.

 Construction/Iteration:

After the team defines and designs the requirements, the real work begins.
Product, design, and developer teams start working on related projects,
ultimately deploying a product or service that is not static.

 Testing:

The quality assurance (QA) team examines and evaluates the product's
performance, looking for bugs and other flaws.
 Deployment:

The team deploys the product in a working environment.

 Feedback:

Once the product is released, the team receives feedback about the product and
handles any issues that may have arisen.