Agile: Iterative and Feedback-Driven Methods
- Agile is a family of software development methods emphasizing iterative delivery, adaptive planning, and close customer collaboration.
- Agile methodologies blend practices from frameworks like Scrum and XP with hybrid approaches to enhance testing, quality, and rapid prototyping.
- Agile principles extend across domains, including adaptations for large-scale projects and workflows for humanoid reinforcement learning.
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 (Abrahamsson et al., 2017, Kuhrmann et al., 2021). 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 (Zhao et al., 20 Mar 2026).
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 (Moniruzzaman et al., 2013).
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 (Abrahamsson et al., 2017). Related syntheses describe agile development as fundamentally about “feedback and change,” with active end-user involvement, tolerance to change, and evolutionary delivery of products (Dingsøyr et al., 2019).
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 (Turk et al., 2014). 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” (Kuhrmann et al., 2021). 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 (Abrahamsson et al., 2017, Dingsøyr et al., 2019). 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 method/practice–discipline combinations, using chi-square tests and Fisher’s exact test with a Bonferroni-corrected threshold of approximately . 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 (Kuhrmann et al., 2021).
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 (Klotins et al., 2024). 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 (Rehman et al., 2020).
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 (Rehman et al., 2020).
Practice-level studies associate several of these engineering mechanisms with quality-related outcomes. In startup cases, Unit tests are associated with better testing perception , Card, Conversation, Confirmation (3C’s) with less dependence on manual testing , Continuous integration with better overall product quality , Automated build with better source code quality , and Iterations with better architecture quality . The same study also reports associations in the opposite direction, including Collective ownership with worse overall product quality , which the authors interpret cautiously as either exposure of hidden flaws or introduction of defects when developers lack contextual knowledge (Klotins et al., 2024). 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 (Dingsøyr et al., 2019). 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 (Turk et al., 2014). 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 (Dingsøyr et al., 2019).
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 (Lautert et al., 2019).
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 (Mancl et al., 2022).
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 (Soundararajan, 2011).
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 (Abrahamsson et al., 2019). 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 (Shaydulin et al., 2017).
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 (Tawosi et al., 2022). 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% (Diebold et al., 2018). 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 (Blanco-Cuaresma et al., 2020).
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 (Fatehi et al., 2012). 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 (Shahrbanoo et al., 2012).
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% (López et al., 2023). 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 (Zhao et al., 20 Mar 2026).
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 (Zhao et al., 20 Mar 2026).
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 (Zhao et al., 20 Mar 2026). 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.