Agile software development

Agile software development is an approach to software development under which requirements

and solutions evolve through the collaborative effort of self-organizing and cross-functional teams
and their customer(s)/end user(s).[1] It advocates adaptive planning, evolutionary development, early
delivery, and continual improvement, and it encourages rapid and flexible response to change.[2][further
explanation needed]

The term agile (sometimes written Agile)[3] was popularized, in this context, by the Manifesto for Agile
Software Development.[4] The values and principles espoused in this manifesto were derived from
and underpin a broad range of software development frameworks, including Scrum and Kanban.[5][6]
There is significant anecdotal evidence that adopting agile practices and values improves the agility
of software professionals, teams and organizations; however, some empirical studies have found no
scientific evidence.[7][8]

History
Iterative and incremental development methods can be traced back as early as 1957,[9] with
evolutionary project management[10][11] and adaptive software development[12] emerging in the early
1970s.[citation needed]
During the 1990s, a number of lightweight software development methods evolved in reaction to the
prevailing heavyweight methods that critics described as overly regulated, planned, and micro-
managed. These included: rapid application development (RAD), from 1991;[13][14] the unified
process (UP) and dynamic systems development method (DSDM), both from 1994; Scrum, from
1995; Crystal Clear and extreme programming (XP), both from 1996; and feature-driven
development, from 1997. Although these all originated before the publication of the Agile Manifesto,
they are now collectively referred to as agile software development methods.[6] At the same time,
similar changes were underway in manufacturing[15] and aerospace.[16]
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these
lightweight development methods, including among others Kent Beck, Ward Cunningham, Dave
Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Robert C. Martin.
Together they published the Manifesto for Agile Software Development.[4]
In 2005, a group headed by Cockburn and Highsmith wrote an addendum of project
management principles, the PM Declaration of Interdependence,[17] to guide software project
management according to agile software development methods.
In 2009, a group working with Martin wrote an extension of software development principles,
the Software Craftsmanship Manifesto, to guide agile software development according
to professional conduct and mastery.
In 2011, the Agile Alliance created the Guide to Agile Practices (renamed the Agile Glossary in
2016),[18] an evolving open-source compendium of the working definitions of agile practices, terms,
and elements, along with interpretations and experience guidelines from the worldwide community of
agile practitioners.

The Manifesto for Agile Software Development[edit]

Agile software development values[edit]
Based on their combined experience of developing software and helping others do that, the
seventeen signatories to the manifesto proclaimed that they value:[4]

 Individuals and Interactions over processes and tools

 Working Software over comprehensive documentation
 Customer Collaboration over contract negotiation
 Responding to Change over following a plan
That is to say, the items on the left are valued more than the items on the right.
As Scott Ambler elucidated:[19]

 Tools and processes are important, but it is more important to have competent people working
together effectively.
 Good documentation is useful in helping people to understand how the software is built and how
to use it, but the main point of development is to create software, not documentation.
 A contract is important but is no substitute for working closely with customers to discover what
they need.
 A project plan is important, but it must not be too rigid to accommodate changes in technology or
the environment, stakeholders' priorities, and people's understanding of the problem and its
solution.
Some of the authors formed the Agile Alliance, a non-profit organization that promotes software
development according to the manifesto's values and principles. Introducing the manifesto on behalf
of the Agile Alliance, Jim Highsmith said,
The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the
word methodology. We want to restore a balance. We embrace modeling, but not in order to file
some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of
pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a
turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other
Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition
of the term hacker.

— Jim Highsmith, History: The Agile Manifesto[20]

Agile software development principles[edit]

The Manifesto for Agile Software Development is based on twelve principles:[21]

1. Customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Overview
Pair programming, an agile development technique used by XP.

Iterative, incremental and evolutionary

Most agile development methods break product development work into small increments that
minimize the amount of up-front planning and design. Iterations, or sprints, are short time frames
(timeboxes) that typically last from one to four weeks. Each iteration involves a cross-functional
team working in all functions: planning, analysis, design, coding, unit testing, and acceptance
testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes
overall risk and allows the product to adapt to changes quickly.[22] An iteration might not add enough
functionality to warrant a market release, but the goal is to have an available release (with
minimal bugs) at the end of each iteration.[23] Multiple iterations might be required to release a
product or new features. Working software is the primary measure of progress.[21]
Efficient and face-to-face communication
The principle of co-location is that co-workers on the same team should be situated together to
better establish the identity as a team and to improve communication.[24]This enables face-to-face
interaction, ideally in front of a whiteboard, that reduces the cycle time typically taken when
questions and answers are mediated through phone, persistent chat, wiki, or email.[25]
No matter which development method is followed, every team should include a customer
representative ("Product Owner" in Scrum). This person is agreed by stakeholders to act on their
behalf and makes a personal commitment to being available for developers to answer questions
throughout the iteration. At the end of each iteration, stakeholders and the customer representative
review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI)
and ensuring alignment with customer needs and company goals.
In agile software development, an information radiator is a (normally large) physical display
located prominently near the development team, where passers-by can see it. It presents an up-to-
date summary of the product development status.[26][27] A build light indicator may also be used to
inform a team about the current status of their product development.
Very short feedback loop and adaptation cycle
A common characteristic in agile software development is the daily stand-up (also known as
the daily scrum). In a brief session, team members report to each other what they did the previous
day toward their team's iteration goal, what they intend to do today toward the goal, and any
roadblocks or impediments they can see to the goal.[28]
Quality focus[edit]
Specific tools and techniques, such as continuous integration, automated unit testing, pair
programming, test-driven development, design patterns, behavior-driven development, domain-
driven design, code refactoring and other techniques are often used to improve quality and enhance
product development agility.[29] This is predicated on designing and building quality in from the
beginning and being able to demonstrate software for customers at any point, or at least at the end
of every iteration.[30]
Philosophy[edit]
Compared to traditional software engineering, agile software development mainly targets complex
systems and product development with dynamic, non-deterministic and non-linear characteristics.
Accurate estimates, stable plans, and predictions are often hard to get in early stages, and
confidence in them is likely to be low. Agile practitioners will seek to reduce the leap-of-faith that is
needed before any evidence of value can be obtained.[31] Requirements and design are held to be
emergent. Big up-front specifications would probably cause a lot of waste in such cases, i.e., are not
economically sound. These basic arguments and previous industry experiences, learned from years
of successes and failures, have helped shape agile development's favor of adaptive, iterative and
evolutionary development.[32]
Adaptive vs. predictive[edit]
Development methods exist on a continuum from adaptive to predictive.[33] Agile software
development methods lie on the adaptive side of this continuum. One key of adaptive development
methods is a rolling wave approach to schedule planning, which identifies milestones but leaves
flexibility in the path to reach them, and also allows for the milestones themselves to change.[34]
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project
change, an adaptive team changes as well. An adaptive team has difficulty describing exactly what
will happen in the future. The further away a date is, the more vague an adaptive method is about
what will happen on that date. An adaptive team cannot report exactly what tasks they will do next
week, but only which features they plan for next month. When asked about a release six months
from now, an adaptive team might be able to report only the mission statement for the release, or a
statement of expected value vs. cost.
Predictive methods, in contrast, focus on analysing and planning the future in detail and cater for
known risks. In the extremes, a predictive team can report exactly what features and tasks are
planned for the entire length of the development process. Predictive methods rely on effective early
phase analysis and if this goes very wrong, the project may have difficulty changing direction.
Predictive teams often institute a change control board to ensure they consider only the most
valuable changes.
Risk analysis can be used to choose between adaptive (agile or value-driven) and predictive (plan-
driven) methods.[35] Barry Boehm and Richard Turner suggest that each side of the continuum has its
own home ground, as follows:[36]