PaperlayerView exact revision on arXiv

Source-linked AI summary

Agile Software Development Methods: Review and Analysis

Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Juhani Warsta

arXiv:1709.08439v1cs.SE

TL;DR

Software development faced skepticism toward traditional methodologies, while agile methods attracted interest despite scarce academic evidence and unclear boundaries. The paper systematically reviews agile literature, proposes a definition and classification, analyzes ten methods, and compares their similarities and differences. It finds substantial commonality alongside differences in focus and concreteness, while emphasizing that empirical validation remains limited.

  • Problem

    Academic research on agile methodologies was scarce, hard evidence about organizational payoff was limited, and agreement on agile boundaries had not been achieved.

  • Method

    The publication systematically reviews agile literature, proposes a definition and classification, analyzes methods against criteria, and compares their similarities and differences.

  • Results

    Agile methods share many similarities but differ in focus, coverage of software-product phases, and concreteness; ASD emphasizes guiding principles while XP emphasizes development practices.

  • Takeaways & Limitations

    The review provides a basis for distinguishing, analyzing, and comparing agile software development methods.

  • Takeaways & Limitations

    Very few empirically validated studies support claims about agile methods' effectiveness and suitability, with existing evidence mainly consisting of practitioners' success stories.

Abstract

from arXiv · show

Agile - denoting "the quality of being agile, readiness for motion, nimbleness, activity, dexterity in motion" - software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants. The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile software development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten software development methods that can be characterized as being "agile" against the defined criterion. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.

1. Introduction

Agile methods emerged amid skepticism about traditional methodologies and growing demand for lighter, faster development. This publication addresses limited evidence and unclear boundaries through a systematic review, definition, analysis, and comparison of agile approaches.

  • Traditional methodologies were criticized as mechanistic, unattainable, or primarily symbolic, contributing to skepticism among industrial developers.
  • Hard numbers on the organizational payoff of agile methodologies were scarce despite predominantly positive initial industry reports.
  • Researchers had not reached clear agreement on how to distinguish agile development from traditional approaches or define its boundaries.
  • The publication systematically reviews agile-method literature to propose a definition and classification, analyze methods against criteria, and compare their similarities and differences.
  • The paper reviews existing methods, compares and discusses them, and concludes with final remarks.

characterizations

Agile software development is characterized as a response to demand for lighter, faster, and more adaptable processes. Its descriptions emphasize collaboration, working software, responsiveness to change, and fit between methodology and project context.

  • The publication defines agile methods as addressing demand for lighter, faster, and nimbler development, especially in volatile Internet and emerging mobile environments.
  • Agile methods are contrasted with process-oriented approaches that assume requirements are frozen before design and development begin.
  • Agile values prioritize individuals and interactions, working software, customer collaboration, and responding to change over plans and formal artifacts.
  • Agile practice emphasizes close team relationships, frequent tested releases, customer cooperation, and contracts that permit adjustments during development.
  • No single methodology fits every project, so method selection should reflect the specific nature and setting of the project.
  • Agile processes favor light-but-sufficient rules, human communication, short feedback cycles, automated regression testing, and small teams.

2. Iterative with short cycles enabling fast verifications and corrections

Agile processes use iteration cycles lasting one to six weeks, supporting frequent development and verification.

  • Iteration cycles in agile processes are time-bound and last from one to six weeks.

4. Parsimony in development process removes all unnecessary activities

Agile development reduces process overhead by building functioning applications incrementally, emphasizing people and collaboration, and adapting to changing requirements. Its focus on simplicity and speed supports rapid delivery and feedback, while the paper notes that empirical validation remains limited.

  • Agile methods use incremental development to build functioning applications in small steps and minimize risks through convergent cycles.
  • Agile processes prioritize people, teamwork, collaboration, and communication over processes and technology.
  • Iterative development accommodates requirements that are introduced, modified, or removed in successive cycles.
  • Agile methods encourage simple solutions, continual design improvement, constant testing, and less documentation where possible.
  • Open source software is presented as one variant within the multifaceted agile-method family, positioned between agile and plan-driven approaches.
  • Agile development concentrates on initially needed functions, delivers them quickly, collects feedback, and reacts to the resulting information.

3. Existing agile methods

The review selects agile methods using a defined criterion and examines them systematically across process, roles, practices, adoption, scope, and research. Agile modeling and pragmatic programming receive brief treatment because they are not methods per se but attracted substantial community attention.

  • Eight agile approaches are included in the systematic analysis, including Extreme Programming, Scrum, Crystal, Feature-Driven Development, RUP, DSDM, ASD, and open source development.
  • Each method is reviewed through a common structure covering its life-cycle process, roles, practices, adoption, scope of use, and current research.Process concerns product-life-cycle phases; roles concern responsibility allocation; practices concern defined activities and workproducts.
  • Agile modeling and pragmatic programming are introduced briefly as related approaches rather than methods themselves.They are included because they have gained considerable attention in the agile community.

3.1. Extreme Programming

Extreme Programming combines practices from earlier methodologies into an integrated process with short releases, iterative development, customer-prioritized stories, and defined team roles. The review reports mostly successful experiences but emphasizes that XP must be tailored and is constrained by team size, environment, and organizational conditions.

  • Process: XP proceeds through Exploration, Planning, Iterations to Release, Productionizing, Maintenance, and Death.Exploration develops story cards, tools, technology, and architectural prototypes; planning prioritizes stories and schedules the first release.
  • Roles and responsibilities: XP assigns distinct responsibilities to programmers, customers, testers, trackers, coaches, consultants, and managers.Customers write stories and functional tests and set priorities, while coaches oversee the process and managers make decisions.
  • XP combines practices from earlier methodologies into a novel system whose customer and programmer decision structure separates business from technical decisions.Its roots include Alexander’s decision-making ideas, Scrum’s rapid evolution, Cunningham’s pattern language, and use cases.
  • Scope of use: XP practices should be tailored to individual projects, and reported experience includes partial rather than complete adoption of the method.No experience reports had adopted all XP practices in the cited discussion.
  • Adoption and experiences: 66.3% average increase in new lines of code, 302.1% in new methods, and 282.6% in new classes were reported for one web-development effort using XP.The review notes that these figures come from a specific development effort and that mostly successful XP experiences have been reported.
  • Scope of use: XP targets small and medium-sized teams, with a suggested range of three to twenty project members and strong requirements for communication and coordination.Scattering programmers across two floors is described as intolerable, although limited interaction between related distributed teams may remain within scope.

3.2. Scrum

Scrum is an empirical management approach for complex, changing systems development that emphasizes flexibility, adaptability, and productivity without prescribing specific implementation techniques. Its process moves from planning and architecture through iterative Sprints to release closure, supported by defined roles and management practices.

  • Scrum applies empirical process-control ideas to systems development and focuses on managing how teams work rather than prescribing software implementation techniques.It reintroduces flexibility, adaptability, and productivity while addressing changing environmental and technical variables.
  • Process: Scrum comprises pre-game, development, and post-game phases.Pre-game contains planning and architecture/high-level design; development is the agile game phase; post-game closes the release.
  • Practices: Planning creates a prioritized, continually updated Product Backlog, while architecture develops the high-level system design from current backlog items.Backlog inputs may come from customers, sales and marketing, support, management, or developers.
  • Process: During development, Sprints iteratively produce new increments through requirements, analysis, design, evolution, and delivery.Each Sprint lasts one week to one month, and several Sprints may precede distribution.
  • Roles and responsibilities: Scrum defines six roles: Scrum Master, Product Owner, Scrum Team, Customer, User, and Management.The Scrum Master safeguards Scrum practices and removes impediments; the Product Owner manages the visible Product Backlog.

3.3. Crystal family of methodologies

The Crystal family tailors methodology heaviness to project size and criticality while emphasizing incremental delivery, communication, user involvement, and adaptable practices. Crystal Clear targets small co-located teams, whereas Crystal Orange supports larger multi-team projects but retains important scope limitations.

  • Overview: Crystal selects methodology color according to project size and system criticality, with darker colors indicating heavier methods and greater rigor.Project categories encode team size and potential loss from system failure.
  • Overview: All Crystal methods use incremental development cycles, emphasize communication and cooperation, and permit practices from methods such as XP and Scrum.Increment lengths are at most four months, preferably one to three months.
  • Scope of use: Crystal Clear is designed primarily for projects with up to six developers, while Crystal Orange targets 10 to 40 project members and one- to two-year durations.Crystal Clear assumes shared office space; Crystal Orange divides work among multiple teams.
  • Policy standards: Both Crystal Clear and Crystal Orange require regular incremental delivery, milestone-based progress tracking, direct user involvement, and automated regression testing.Progress is tracked through software deliveries and major decisions rather than written documents.
  • Work products: Crystal Clear uses lighter documentation than Crystal Orange, which requires more extensive requirements, scheduling, design, and inter-team documentation.Clear relies more on annotated use cases, sketches, and notes, while Orange requires formal requirements and design artifacts.
  • Adoption and experiences: In the Winifred project, iterative increments, user viewings, clearer responsibilities, planned communication, deliverable ownership, and management support addressed process problems.The reported success factors were process correction through increments, key individuals, and a team habit of delivering.

3.4. Feature Driven Development

Feature Driven Development focuses on iterative design and building rather than the entire software process, organizing work around client-valued features, defined roles, and short feature iterations. It is presented as adaptable to broader project activities, although reliable experience reports remain scarce.

  • Overview: FDD focuses on system design and building, works alongside other project activities, and does not require a specific overall process model.The approach is described as agile and adaptive but does not cover the entire software development process.
  • Process: FDD comprises five sequential processes: developing an overall model, building a features list, planning by feature, designing by feature, and building by feature.The first processes establish models, features, priorities, ownership, schedules, and milestones.
  • Adoption and experiences: FDD authors present it as suitable for quality, business-critical systems, but reliable experience reports remain difficult to find.The available support includes advocacy by consulting firms, while documented evidence is limited.
  • Process: The design-by-feature and build-by-feature stages iteratively produce selected features, with each iteration lasting from a few days to a maximum of two weeks.Multiple feature teams may design and build their own feature sets concurrently.
  • Roles and responsibilities: FDD defines key, supporting, and additional roles, including project manager, chief architect, development manager, chief programmer, class owner, and domain expert.Chief programmers lead small feature teams, while class owners design, code, test, and document assigned classes.
  • Roles and responsibilities: The project manager controls FDD project scope, schedule, and staffing while protecting the team and providing suitable working conditions.The role is the project’s administrative and financial leadership position.

3.5. The Rational Unified Process

RUP is an iterative, use-case-centered process for object-oriented systems, structured into four phases and parallel workflows. Although widely implemented, it generally requires substantial tailoring to function as an agile approach.

  • Overview: RUP is an iterative approach for object-oriented systems that strongly uses use cases to model requirements and establish the system foundation.Its proposed UML modeling method is particularly suited to object-oriented development.
  • Process: RUP divides a project into Inception, Elaboration, Construction, and Transition phases, each split into iterations producing demonstrable software.Iterations may last from two weeks or less up to six months.
  • Process: The phases address objectives and scope, architectural foundations and planning, component development and testing, and release, user training, and rollout.Transition also incorporates user feedback into subsequent releases.
  • Workflows: Nine workflows run in parallel across the phases, including business modeling, requirements, analysis and design, implementation, testing, configuration management, project management, and environment.Each iteration addresses the workflows to varying extents.
  • Roles and responsibilities: RUP assigns activities to thirty worker roles, with roles varying according to which workflows are implemented.The business-modeling workflow may be omitted when it is not significant to the end product.
  • Adoption and scope: RUP has been implemented in many organizations despite the need for extensive tailoring, but it is not generally considered particularly agile.Making it agile requires screening its more than one hundred artifacts and adopting only essential ones.

3.6. Dynamic Systems Development Method

DSDM is a non-proprietary framework for rapid application development that fixes time and resources while adjusting functionality. Its iterative, incremental timeboxed process emphasizes user involvement, prototyping, and prioritized delivery.

  • Overview: DSDM fixes time and resources rather than functionality, adjusting the delivered functionality to fit those constraints.This is the method’s fundamental approach to rapid application development.
  • Process: DSDM has five phases: feasibility study, business study, functional model iteration, design and build iteration, and implementation.The first two phases occur once, while the final three are iterative and incremental timeboxes.
  • Process: The feasibility and business studies assess suitability, risks, business characteristics, technology, priorities, affected users, architecture, and prototyping plans.Workshops gather customer experts and identify user classes for early involvement.
  • Process: Functional model iterations combine analysis, coding, and prototyping, using user comments and risk analysis to guide subsequent development.Prioritized functions and review documents are produced during the phase.
  • Process: Design and build iterations produce a tested system meeting at least the minimum agreed requirements, with further development based on user reviews.The implementation phase transfers the system to production, trains users, and may itself be iterative.
  • Roles and responsibilities: DSDM relies on distinct user and developer roles, including ambassador users, adviser users, a visionary, executive sponsor, technical coordinator, and developers.The ambassador user brings user-community knowledge into the project and disseminates progress information.
  • Adoption and experiences: Eight documented case studies report that DSDM was a viable alternative for rapid application development in the UK.The method has been in widespread UK use since the mid-1990s.

3.7. Adaptive Software Development

Adaptive Software Development (ASD) uses iterative cycles to manage complex, high-change projects through collaboration, learning, and progressively refined components. Its flexible philosophy supports distributed teamwork but provides limited concrete guidance for adoption and daily practice.

  • Approach: ASD targets complex, large systems through incremental, iterative development and constant prototyping, balancing guidance against emergence and creativity.
  • Process: Each ASD cycle comprises Speculate, Collaborate, and Learn, emphasizing uncertainty, teamwork, and adaptation to mistakes or changing requirements.
  • Process: ASD is component-oriented: concurrent collaboration develops components while iterative planning continuously refines their definitions and requirements.
  • Process: Repeated quality reviews demonstrate cycle functionality and provide the Learning Loop, while customer focus groups and JAD sessions support communication and customer involvement.JAD sessions are especially important at the beginning of a project, although ASD does not prescribe their schedules.
  • Process: ASD ends with Final Q/A and Release and emphasizes capturing lessons learned through project postmortems in high-speed, high-change projects.
  • Assessment: ASD offers few day-to-day practices and little adoption guidance, while allowing distributed teams and suggesting information-sharing and communication techniques.The review reports little significant research on ASD and few experiences using it as-is.

3.8. Open Source Software development

Open Source Software (OSS) development is a globally distributed, collaborative approach built around freely available code, small increments, frequent testing, and volunteer participation. Its success is associated with network effects, customer recognition, and well-known administrators who attract contributors.

  • Characteristics: OSS makes source code freely available for modification and redistribution and produces software through collaborative, widely dispersed individuals working in small, frequent increments.
  • Process: OSS development commonly uses early and frequent releases while omitting project plans, schedules, deliverable lists, and many traditional coordination mechanisms.
  • Organization: Potentially large numbers of volunteers choose their own tasks, with no explicit system-level design and loosely centralized coordination.
  • Organization: OSS projects commonly include project leaders, core and peripheral developers, occasional contributors, testers, bug reporters, and discussion participants.
  • Organization: Modular task division, repository services, and coordination by companies or project leaders help structure distributed OSS development.
  • Outcomes: The network effect is crucial: prototypes attracting customer interest draw more developers, while projects with recognizable customer needs or well-known administrators are reported as more successful.

3.9. Other Agile Methods

The reviewed approaches extend agile ideas into modeling and programming practices rather than presenting complete development processes. Agile Modeling emphasizes lightweight, collaborative modeling, while pragmatic programming offers disciplined, reusable programming guidance.

  • Agile Modeling: Agile Modeling encourages models sufficient for immediate design and documentation needs while minimizing modeling and documentation effort.
  • Agile Modeling: Agile Modeling combines communication, simplicity, feedback, courage, humility, teamwork, and functioning software as the main modeling goal.
  • Agile Modeling: Its eleven practices span iterative and incremental modeling, teamwork, simplicity, and validation, and can be adopted independently.
  • Agile Modeling: Agile Modeling favors customer presence and close communication but covers only modeling, so it requires supporting methods and lacks identifiable research.
  • Pragmatic Programming: Pragmatic programming is a set of practical best practices rather than a process, with no phases, distinct roles, or work products.
  • Pragmatic Programming: Its agile-relevant practices emphasize incremental development, rigorous automated testing, user-centered design, automation, and maintaining reasonable specification detail.
  • Pragmatic Programming: The review characterizes pragmatic programming as simple, responsible, disciplined practice applicable across development phases and useful alongside other methods.

4. Comparison of agile methods

The reviewed agile methods share collaborative values but differ substantially in emphasis, life-cycle coverage, scalability, documentation, and adoption status. The comparison identifies both method-specific strengths and practical boundaries for use.

  • Comparison approach: Quasiformal comparison is used to reduce the subjectivity of comparing software development methodologies.The authors distinguish quasiformal comparison from informal comparison as an approach intended to overcome subjective limitations.
  • Adoption: XP, RUP, OSS, and DSDM are classified as active, Scrum, FDD, Crystal, PP, and ASD as building up, and AM as nascent.The status classification reflects available documentation, experience reports, research, and user communities.
  • General features: Agile methods generally emphasize collaboration, people, useful delivery, technical excellence, and barely sufficient methodology.RUP and OSS are exceptions to the stated chaordic basis shared by the other agile methods.
  • General features: ASD is the most abstract method, AM, XP, and PP are practice-oriented, and Crystal explicitly supports tailoring by project size and criticality.The authors identify translating ASD concepts into practice and achieving scalability as important challenges.
  • Special features: DSDM uses prototyping, FDD follows five feature-centered steps, Scrum manages self-organizing teams in 30-day sprints, and RUP offers a tool-supported development suite.The methods therefore differ in distinctive practices, process scope, and degree of tool support.
  • Adoption: DSDM, RUP, and FDD differ in life-cycle coverage: DSDM and RUP provide full coverage, whereas FDD begins around requirements specification.Most other methods require complementary approaches to varying degrees; DSDM access is restricted to consortium members.
  • Adoption: XP, Scrum, AM, and PP target small teams, while Crystal, FDD, RUP, OSS, ASD, and DSDM claim scalability to 100 developers.Larger teams are expected to require more documentation and explicit communication mechanisms, making projects less agile.
  • Adoption: Agile approaches appear most suitable when future requirements are unknown, while known and specifiable requirements may provide no added value from agility per se.Adoption also requires organizational and cultural change, including greater decision authority for customers and development teams.

5. Conclusions

The paper defines agile development through incremental, cooperative, straightforward, and adaptive practices, then compares methods using these criteria. It concludes that agile methods offer a people-centered approach but remain insufficiently validated and face scalability challenges.

  • 5. Conclusions: The study synthesizes agile literature, analyzes ten methods, and compares their similarities and differences.Methods are reviewed through process, roles and responsibilities, practices, adoption and experiences, and current research.
  • 5. Conclusions: Agile methods are incremental, cooperative, straightforward, and adaptive.They use small releases and rapid cycles, close customer–developer cooperation, methods that are easy to learn and modify, and responsiveness to late changes.
  • 5. Conclusions: Agile methods share core characteristics but differ in supported development phases and concreteness.ASD emphasizes guiding principles, whereas XP emphasizes concrete development practices.
  • 5. Conclusions: Existing support for agile methods consists mainly of professional success stories, while empirically validated studies remain scarce.The paper calls for empirical studies and adoption or selection models to help organizations choose and apply methods appropriately.
  • 5. Conclusions: Agile thinking is people-centric and offers a novel approach to software engineering problems, but it is not exhaustive or universally applicable.The paper notes that many large organizations do not develop software with teams of fewer than ten engineers, creating a scalability boundary.
Loading 1709.08439v1…