Large-scale, offshore and distributed

Agile software development has been widely seen as highly suited to certain types of environments,
including small teams of experts working on greenfield projects,[40][56]: 157  and the challenges and
limitations encountered in the adoption of agile software development methods in a large organization
with legacy infrastructure are well-documented and understood.[57]

In response, a range of strategies and patterns has evolved for overcoming challenges with large-scale
development efforts (>20 developers)[58][59] or distributed (non-colocated) development teams,[60]
[61] amongst other challenges; and there are now several recognised frameworks that seek to mitigate
or avoid these challenges.

Scaled agile framework (SAFe),[62] Dean Leffingwell et al

Disciplined agile delivery (DAD), Scott Ambler et al

Large-scale scrum (LeSS), Craig Larman and Bas Vodde

Nexus (scaled professional Scrum),[63] Ken Schwaber

Scrum at Scale,[64] Jeff Sutherland, Alex Brown

Enterprise Scrum,[65] Mike Beedle

Setchu (Scrum-based lightweight framework),[66] Michael Ebbage

XSCALE[67]

Agile path[68]

Holistic Software Development[69]

There are many conflicting viewpoints on whether all of these are effective or indeed fit the definition of
agile development, and this remains an active and ongoing area of research.[58][70]

When agile software development is applied in a distributed setting (with teams dispersed across
multiple business locations), it is commonly referred to as distributed agile software development. The
goal is to leverage the unique benefits offered by each approach. Distributed development allows
organizations to build software by strategically setting up teams in different parts of the globe, virtually
building software round-the-clock (more commonly referred to as follow-the-sun model). On the other
hand, agile development provides increased transparency, continuous feedback, and more flexibility
when responding to changes.
Regulated domains

Agile software development methods were initially seen as best suitable for non-critical product
developments, thereby excluded from use in regulated domains such as medical devices,
pharmaceutical, financial, nuclear systems, automotive, and avionics sectors, etc. However, in the last
several years, there have been several initiatives for the adaptation of agile methods for these domains.
[71][72][73][74][75]

There are numerous standards that may apply in regulated domains, including ISO 26262, ISO 9000, ISO
9001, and ISO/IEC 15504. A number of key concerns are of particular importance in regulated domains:
[76]

Quality assurance (QA): Systematic and inherent quality management underpinning a controlled
professional process and reliability and correctness of product.

Safety and security: Formal planning and risk management to mitigate safety risks for users and securely
protecting users from unintentional and malicious misuse.

Traceability: Documentation providing auditable evidence of regulatory compliance and facilitating

Verification and validation (V&V): Embedded throughout the software development process (e.g. user
requirements specification, functional specification, design specification, code review, unit tests,
integration tests, system tests).

Experience and adoption

Although agile software development methods can be used with any programming paradigm or
language in practice, they were originally closely associated with object-oriented environments such as
Smalltalk, Lisp and later Java, C#. The initial adopters of agile methods were usually small to medium-
sized teams working on unprecedented systems with requirements that were difficult to finalize and
likely to change as the system was being developed. This section describes common problems that
organizations encounter when they try to adopt agile software development methods as well as various
techniques to measure the quality and performance of agile teams.[77]

Measuring agility

Internal assessments
The Agility measurement index, amongst others, rates developments against five dimensions of product
development (duration, risk, novelty, effort, and interaction).[78]Other techniques are based on
measurable goals[79] and one study suggests that velocity can be used as a metric of agility. There are
also agile self-assessments to determine whether a team is using agile software development practices
(Nokia test,[80] Karlskrona test,[81] 42 points test).[82]

Public surveys

One of the early studies reporting gains in quality, productivity, and business satisfaction by using agile
software developments methods was a survey conducted by Shine Technologies from November 2002 to
January 2003.[83]

A similar survey, the State of Agile, is conducted every year starting in 2006 with thousands of
participants from around the software development community. This tracks trends on the perceived
benefits of agility, lessons learned, and good practices. Each survey has reported increasing numbers
saying that agile software development helps them deliver software faster; improves their ability to
manage changing customer priorities; and increases their productivity.[84] Surveys have also consistently
shown better results with agile product development methods compared to classical project
management.[85][86] In balance, there are reports that some feel that agile development methods are
still too young to enable extensive academic research of their success.[87]

Common agile software development pitfalls

Organizations and teams implementing agile software development often face difficulties transitioning
from more traditional methods such as waterfall development, such as teams having an agile process
forced on them.[88] These are often termed agile anti-patterns or more commonly agile smells. Below
are some common examples:

Lack of overall product design

A goal of agile software development is to focus more on producing working software and less on
documentation. This is in contrast to waterfall models where the process is often highly controlled and
minor changes to the system require significant revision of supporting documentation. However, this
does not justify completely doing without any analysis or design at all. Failure to pay attention to design
can cause a team to proceed rapidly at first but then to have significant rework required as they attempt
to scale up the system. One of the key features of agile software development is that it is iterative. When
done correctly design emerges as the system is developed and commonalities and opportunities for re-
use are discovered.[89]

Adding stories to an iteration in progress

In agile software development, stories (similar to use case descriptions) are typically used to define
requirements and an iteration is a short period of time during which the team commits to specific goals.
[90] Adding stories to an iteration in progress is detrimental to a good flow of work. These should be
added to the product backlog and prioritized for a subsequent iteration or in rare cases the iteration
could be cancelled.[91]

This does not mean that a story cannot expand. Teams must deal with new information, which may
produce additional tasks for a story. If the new information prevents the story from being completed
during the iteration, then it should be carried over to a subsequent iteration. However, it should be
prioritized against all remaining stories, as the new information may have changed the story's original
priority.

Lack of sponsor support

Agile software development is often implemented as a grassroots effort in organizations by software

Insufficient training

A survey performed by VersionOne found respondents cited insufficient training as the most significant
cause for failed agile implementations[94] Teams have fallen into the trap of assuming the reduced
processes of agile software development compared to other methodologies such as waterfall means that
there are no actual rules for agile software development.[citation needed]

Product owner role is not properly filled

The product owner is responsible for representing the business in the development activity and is often
the most demanding role.[95]
A common mistake is to have the product owner role filled by someone from the development team.
This requires the team to make its own decisions on prioritization without real feedback from the
business. They try to solve business issues internally or delay work as they reach outside the team for
direction. This often leads to distraction and a breakdown in collaboration.[96]

Teams are not focused

Agile software development requires teams to meet product commitments, which means they should
focus on work for only that product. However, team members who appear to have spare capacity are
often expected to take on other work, which makes it difficult for them to help complete the work to
which their team had committed.[97]

Excessive preparation/planning

Teams may fall into the trap of spending too much time preparing or planning. This is a common trap for
teams less familiar with agile software development where the teams feel obliged to have a complete
understanding and specification of all stories. Teams should be prepared to move forward with only
those stories in which they have confidence, then during the iteration continue to discover and prepare
work for subsequent iterations (often referred to as backlog refinement or grooming).

Problem-solving in the daily standup

A daily standup should be a focused, timely meeting where all team members disseminate information.
If problem-solving occurs, it often can involve only certain team members and potentially is not the best
use of the entire team's time. If during the daily standup the team starts diving into problem-solving, it
should be set aside until a sub-team can discuss, usually immediately after the standup completes.[98]

Assigning tasks

One of the intended benefits of agile software development is to empower the team to make choices, as
they are closest to the problem. Additionally, they should make choices as close to implementation as
possible, to use more timely information in the decision. If team members are assigned tasks by others
or too early in the process, the benefits of localized and timely decision making can be lost.[99]

Being assigned work also constrains team members into certain roles (for example, team member A
must always do the database work), which limits opportunities for cross-training.[99] Team members
themselves can choose to take on tasks that stretch their abilities and provide cross-training
opportunities.

Scrum master as a contributor

In the Scrum methodology, which is a popular methodology that claims to be consistent with Agile
values and principles, a scrum master is the person accountable for ensuring the scrum process is taking
place, and coaching the scrum team through that process. A common pitfall is for a scrum master to act
as a contributor. While not prohibited by the Scrum methodology, the scrum master needs to ensure
they have the capacity to act in the role of scrum master first and not work on development tasks. A
scrum master's role is to facilitate the process rather than create the product.[100]

Having the scrum master also multitasking may result in too many context switches to be productive.
Additionally, as a scrum master is responsible for ensuring roadblocks are removed so that the team can
make forward progress, the benefit gained by individual tasks moving forward may not outweigh
roadblocks that are deferred due to lack of capacity.[101]