---
title: 'Agile: Iterative and Feedback-Driven Methods'
url: https://www.emergentmind.com/topics/agile
type: topic
---

# Agile: Iterative and Feedback-Driven Methods

Agile denotes a family of software development approaches oriented toward iterative and incremental development, self-organizing and cross-functional teams, early and continuous delivery of valuable software, close customer collaboration, and responsiveness to changing requirements. In the research literature, however, agility is not reducible to the formal adoption of a named method such as Scrum or Extreme Programming (XP). It is also treated as a perceived degree of agility in how project disciplines are carried out, with many real projects combining agile and traditional elements in hybrid forms rather than operating at either extreme [1709.08439] [2109.11435]. Outside software process research, the term has also been reused as an acronym, most notably for “A Generic Isaac-Lab based Engine,” an end-to-end workflow for humanoid reinforcement learning [2603.20147].

## 1. Conceptual foundations

The canonical value structure associated with Agile is the Agile Manifesto formulation reproduced in the software engineering literature: **Individuals and interactions** over processes and tools, **Working software** over comprehensive documentation, **Customer collaboration** over contract negotiation, and **Responding to change** over following a plan. These values are repeatedly linked to short development cycles, continual refinement, incremental delivery of working software, active customer involvement, and the treatment of requirements as emergent rather than fully knowable up front [1307.3356].

A widely cited formal characterization defines an agile method as one in which software development is **incremental**, **cooperative**, **straightforward**, and **adaptive**. In that formulation, incrementality refers to small software releases with rapid cycles; cooperativeness to constant customer–developer collaboration; straightforwardness to methods that are easy to learn and modify; and adaptiveness to the ability to make late changes [1709.08439]. Related syntheses describe agile development as fundamentally about **“feedback and change,”** with active end-user involvement, tolerance to change, and evolutionary delivery of products [1901.00324].

Research on agility also distinguishes the idea of agility from the label of any specific process. One strand of literature defines agility as the degree to which a team can dynamically adapt the process in response to changes and experience, placing software processes on a spectrum from predictive to agile rather than treating the distinction as binary [1409.6600]. A later empirical study sharpens that view by arguing that agility is better understood as a *perceived degree of agility* in the implementation of project disciplines and is, in the authors’ phrase, “in the eye of the beholder” [2109.11435]. This suggests that agility is simultaneously procedural, organizational, and perceptual.

## 2. Methods, practices, and hybridization

The agile family includes methods and method families with markedly different scopes and emphases. Comparative reviews discuss **Extreme Programming (XP), Scrum, Crystal, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Rational Unified Process (RUP), Agile Modeling (AM), Pragmatic Programming (PP)**, and later **Kanban**, **Lean**, and scaling frameworks such as **SAFe**, **DAD**, **Nexus**, **LeSS**, **Scrum at Scale**, and the **Spotify model** [1709.08439] [1901.00324]. Some are engineering-practice-centric, some are project-management-centric, and some are method families or framework layers rather than single prescriptive processes.

A recurring finding is that method labels are weaker predictors of agility than practice selection. In the HELENA survey study, Kuhrmann et al. analyze **556 data points**, each representing a project or product, across **11 standard project disciplines**, **24 methods**, and **36 practices**. Agility for each discipline is categorized on a Likert-style scale from **fully traditional** to **fully agile**. Only a small minority—**under 15% of the 556 cases**—implement all project disciplines consistently as fully/mainly agile, fully/mainly traditional, or balanced; most projects are hybrids. The same study performs **660 tests**, corresponding to \((24 + 36) \times 11 = 660\) method/practice–discipline combinations, using chi-square tests and Fisher’s exact test with a Bonferroni-corrected threshold of approximately \(p_{corr} \approx 7.57 \times 10^{-5}\). Of these, **146 of 660 cases** show a significant shift in perceived agility, and **88 of 146** shift toward more agile perceptions. The central result is that **the selection of practices has a stronger effect on the degree of agility of a given discipline than the selection of methods**, and **no single method or practice guarantees agility or prevents it** [2109.11435].

Startup research converges on a similar practice-centric picture. In a case survey of **84 start-up cases** and **56 Agile practices**, startups are reported to use Agile practices “however without following any specific methodology.” The most frequently reported practices are **Backlog** (**42 companies**, about **50%**), **Version control** (**39 companies**, about **46%**), **Code refactoring**, and **User stories**. The paper’s interpretation is that start-ups use Agile not as a full methodology but as a selective and evolutionary mix of individual practices [2402.09555]. This is consistent with the broader literature’s rejection of the misconception that “Agile” is simply the correct implementation of Scrum.

## 3. Engineering practices, testing, and quality

Agile’s emphasis on speed and adaptability generates a distinctive testing regime. In contrast to Waterfall, where testing is naturally organized as a distinct phase after development, Agile development is described as **sprint-based**, with continuously changing requirements, frequent builds, less room for comprehensive documentation, and **no separate focused testing phase**. The literature identifies several recurring testing challenges: **infrastructure for testing**, **test documentation**, **insufficient test coverage**, **broken code after frequent builds**, **early defect detection**, **insufficient API testing**, and **lacking focused testing** [2008.13108].

The proposed responses are predominantly lightweight and automation-oriented. Recommended practices include **self-service provisioning and on-demand scalability**, a **library of virtual datacenter templates**, **complex bug capture and reproduction**, a living **test strategy** plus sprint-specific testing plans and **checklists**, **exploratory testing**, **“just-enough” acceptance tests**, automated acceptance tests, **subcutaneous** tests with an **xUnit** framework, **unit tests** for all new code during a sprint, **multiple builds per day**, automated regression testing, **peer code review**, and **static analysis tools**. The same literature names tool support including **N-Unit**, **STAF**, **Smart Bear**, **Cucumber**, **FitNesse**, **Robot Framework**, and continuous integration/build tools such as **Cruise Control**, **Hudson**, and **SmartBear’s Automated Build Studio** [2008.13108].

Practice-level studies associate several of these engineering mechanisms with quality-related outcomes. In startup cases, **Unit tests** are associated with better testing perception \((Cramers'V = 0.391)\), **Card, Conversation, Confirmation (3C’s)** with less dependence on manual testing \((Cramers'V = 0.422)\), **Continuous integration** with better overall product quality \((Cramers'V = 0.368)\), **Automated build** with better source code quality \((Cramers'V = 0.374)\), and **Iterations** with better architecture quality \((Cramers'V = 0.359)\). The same study also reports associations in the opposite direction, including **Collective ownership** with worse overall product quality \((Cramers'V = 0.372)\), which the authors interpret cautiously as either exposure of hidden flaws or introduction of defects when developers lack contextual knowledge [2402.09555]. Because that study explicitly limits itself to associations rather than causal claims, these findings are best read as empirical signals about practice clusters rather than proofs of mechanism.

## 4. Scale, distribution, and organizational context

The original home ground of Agile is repeatedly described as **small, co-located teams**, often **5–9 developers**, with active customer collaboration and lightweight communication structures [1901.00324]. This does not mean that Agile is confined to that setting, but it does mean that much of the literature on limitations and scaling is organized around the consequences of moving beyond it.

One influential limitations analysis identifies common agile assumptions whose failure makes pure agile approaches problematic: co-located and available customers, limited centrality of documentation and software models, experienced developers, incremental development, modest cost of change, and the absence of a need to design extensively for change up front. From these assumptions it derives six recurrent limitation areas: **distributed development environments**, **subcontracting**, **building reusable artifacts**, **large teams**, **safety-critical software**, and **large, complex software** [1409.6600]. The same literature does not reject agility outright in such settings; instead it argues that the appropriate question is not whether a process is agile, but **how much agility is appropriate**.

Scaling studies document the corresponding expansion of agile usage. Methods originally designed for single teams have been adapted to projects with **tens of teams**, **hundreds of developers**, **hundreds of existing system integrations**, and **hundreds of thousands of users**. Large-scale agile development is commonly defined as involving **more than two development teams** and a high number of actors and interfaces with existing systems. The main challenges at this scale include **coordination across teams**, **knowledge sharing**, **customer collaboration**, **decision-making**, **integration complexity**, and governance in **mission-critical systems** [1901.00324].

Distribution sharpens the communication problem. In a survey of a global software development team using **SAFe**, communication emerges as the main challenge. **27 out of 32** participants prioritize **email** and **Skype chat**, yet **phone call** is judged the most efficient channel, with **62%** rating it **extremely efficient**. The most frequently cited barriers to richer synchronous communication are **time-zone constraints: 35%** and **agenda conflicts: 35%**. At the same time, some agile routines remain robust in distribution: **97%** report retrospectives **once per iteration**, and **91%** say retrospectives produce actionable items [1910.09074].

Hybrid work extends the same theme into post-pandemic organizational design. A panel-based report treats Agile organizations as those that adapt both what they build and how they collaborate. It emphasizes that hybrid work makes collaboration more deliberate, communication more tooling-dependent, and innovation harder to sustain remotely. The practical recommendations are team-centered rather than ideology-centered: hybrid arrangements should be a team conversation, trust may require explicit investment such as a **“budget line-item for building trust,”** **pair programming** can sustain engagement, in-person time should be used strategically for design and problem-solving, and organizations should favor **micro-improvements** over waiting for a perfect model [2210.12591].

## 5. Assessment, evidence, and empirical infrastructure

Because agile methods are intentionally tailorable, assessment has become a distinct research problem. One proposed response is the **Objectives, Principles and Practices (OPP) Framework**, which evaluates an agile method in terms of **adequacy**, **organizational capability**, and **effectiveness**. The framework links **objectives** to **principles**, **principles** to **practices**, and practices to observable **indicators** drawn from properties of people, process, project, and product. Adequacy is assessed top-down through linkage coverage, while capability and effectiveness are assessed bottom-up from indicators. The framework also maps linkage coverage to a Likert-style qualitative scale: **Strongly**, **Very well**, **Sufficiently**, **Somewhat**, and **Very little** [1108.0427].

Comparative reviews of agile methods expose why such assessment frameworks are necessary. One review evaluates methods along six perspectives—**project management support**, **software development life-cycle coverage**, **availability of concrete guidance for application**, **adaptability in actual use**, **research objective**, and **empirical evidence**—and concludes that many methods do not provide adequate project management support, cover different life-cycle phases without explaining the rationale, offer abstract principles rather than operational guidance, allow adaptation without enabling it, and remain weakly supported by empirical evidence [1903.10913]. Another comparison argues that no single methodology, agile or waterfall, covers all important aspects of software development and highlights unresolved issues around **technical debt**, **non-functional requirements**, and **large-scale systems** [1704.07469].

Agile research has also developed reusable empirical infrastructure. The **TAWOS** dataset, designed for open-source Agile software projects using Jira, includes **508,963 issues** from **44 projects** contributed by **208,811 users**. Its project corpus is mined from **13 major open-source repositories** and contains **237,594 bugs**, **10,023,871 change-log entries**, **1,612,399 comments**, **5,029 sprints**, **7,885 versions**, **69,724 issues with story points**, and **6,313 developers**. The data are stored as a **relational MySQL database** with tables such as `Issue`, `Comment`, `Change_Log`, `Issue_Links`, `User`, `Sprints`, `Versions`, and `Components`, and include derived fields such as `Resolution_Time_Minutes`, `SP_Estimation_Date`, `Title_Changed_After_Estimation`, and `Description_Changed_After_Estimation` [2202.00979]. This supports reproducible research on effort estimation, issue prioritization, assignment, bug triage, and longitudinal analysis.

Process improvement case work in very small enterprises provides a complementary assessment mode. In one startup case, a pre/post ISO/IEC 29110 assessment combined with the introduction of eight agile practices shows improvement in **13 ISO29110 base practices**, with code metrics indicating trends such as test coverage moving from **2.99%** to **5.21%** [1809.02115]. This does not establish a universal effect size, but it does show how agile practices are used as the “how” in process improvement when a standard such as ISO 29110 defines the “what.”

## 6. Adaptation across domains

Agile is repeatedly adapted rather than merely adopted. A particularly explicit example is the NASA Astrophysics Data System (ADS) team, which describes its process as Agile in principles but deliberately softer than standard Scrum for a team of highly creative and autonomous researchers, curators, and software engineers. The team retains **sprints**, **daily stand-ups**, **retrospectives**, **planning meetings**, a **backlog**, and **regular releases / incremental system updates**, but modifies them through **3-week sprints**, flexible task selection, a non-rigid backlog, and collaborative planning facilitated by a planning facilitator rather than a strict role structure. The claimed benefits are higher professional satisfaction, lower turnover, and continued responsiveness to stakeholders, with the acknowledged cost that work may be “slightly slower” in the narrow sense that not everyone is always assigned to the top-priority item [2009.05048].

Service-oriented architecture research provides domain-specific agile variants. **AM4SC (Agile Model for Service Composition)** combines **Scrum + Extreme Programming (XP)** for **e-service / web service composition**. Its human-centered level is organized into **four main activities**—**Planning process**, **Arrangement process**, **Modeling process**, and **Implementation process**—executed iteratively in **2–4 weeks** per iteration, while its automated level uses six agents: **Feature Selector**, **Unit Test Maker**, **Automated Refactor/Modeler**, **Service Broker**, **Service Creator**, and **Tester** [1203.3085]. A related SOA approach introduces a **five-step approach** before implementation begins: **Prioritization of Business Goals**, **Mapping Business Goals to Business Processes**, **Extraction of Quality Attribute Scenarios related to each Business Goal**, **Determination of CBPs**, and **Selecting Business Processes for Current Release**. Its stated purpose is to determine **Core Business Processes (CBPs)** and establish **Core Architecture** so that SOA development can embrace changes while preserving software quality [1204.0368].

Educational adaptations likewise combine Agile with adjacent disciplines rather than treating it as sufficient on its own. In a UNAM Android/mobile development course, a tailored process combines **Scrum**, **XP**, and **UX / UCD** into a **six-phase** meta-process across **three stages**: **Preproduction** (**Definition**, **Design**), **Production** (**Development**, **Testing and validation**), and **Postproduction** (**Closing**, **Feedback and maintenance**). The course uses real clients, personas, low-fidelity prototyping, Kanban tracking, Git-based collaboration, usability testing, and **System Usability Scale (SUS)** evaluation. Reported project continuations include **Hocus Focus**, with a usability score of **92.86%**, and **Polyx**, with **89.6%** [2311.03361]. Across these examples, Agile functions less as a fixed process template than as a framework for iterative planning, feedback, and adaptation.

## 7. AGILE as a humanoid reinforcement-learning workflow

In a distinct line of work, **AGILE** denotes **“A Generic Isaac-Lab based Engine,”** an end-to-end workflow for humanoid reinforcement learning built on **Isaac Lab** and **RSL-RL**. The paper’s claim is that the primary bottleneck in humanoid RL is often not simulation throughput or algorithm design but the absence of a systematic workflow connecting environment verification, training, evaluation, and deployment [2603.20147].

The workflow is organized into **four stages**: **interactive environment verification**, **reproducible training**, **unified evaluation**, and **descriptor-driven deployment via robot/task configuration descriptors**. Environment verification includes tools such as a **Joint Position GUI**, an **Object Manipulation GUI**, and a **Reward Visualizer** to catch misconfigured joints, collisions, rewards, or observations before expensive training runs. Reproducible training includes Docker-based orchestration, YAML configuration dumps, git snapshots, and structured parameter sweeps, together with training stabilizations such as **L2C2 regularization**, **online reward normalization**, **value-bootstrapped terminations**, **virtual harness**, **velocity profiles**, **symmetry augmentation**, **adaptive command sampling**, **state caching**, and **teacher-student distillation**. Evaluation combines deterministic scenario-based tests and randomized rollouts with shared diagnostics including **RMS acceleration**, **jerk**, and **joint-limit violations**. Deployment exports policies with auto-generated YAML descriptors specifying **joint names**, **observation ordering**, **history buffers**, and **action scaling**, enabling both sim-to-sim and sim-to-real transfer [2603.20147].

The reported validation covers **five representative tasks** on **Unitree G1** and **Booster T1**: **Velocity tracking**, **Height-controlled locomotion**, **Stand-up / fall recovery**, **Motion imitation (“dancing”)**, and **Loco-manipulation with VLA fine-tuning**. In the loco-manipulation case, the RL expert generates **100 successful trajectories**, a **GR00T N1.5 VLA** model is fine-tuned, and the resulting policy achieves a **90% success rate on pick-and-place** in closed-loop simulation [2603.20147]. This use of AGILE is conceptually separate from Agile software development, but the naming convergence is notable: in both cases, the term marks an attempt to replace ad hoc practice with a disciplined, iterative, feedback-rich workflow.

Source: https://www.emergentmind.com/topics/agile