Adapting Agile for AI: Sprints with Research and Nondeterministic Outcomes

The Disconnect Between Traditional Development and Artificial Intelligence

Over the past two decades, Agile methodologies have become the undisputed standard for enterprise software delivery. Frameworks such as Scrum and Kanban were designed around a fundamental premise: although business requirements may change, code behaves predictably and deterministically. If a team implements a specific business rule, that logic will produce precise, repeatable results under the same conditions.

The integration of machine learning models and AI-based systems challenges this assumption. Models are not programmed using static rules; they are trained on data and generate probabilistic inferences. This means that two iterations with similar parameters can produce different results, and improving one component does not guarantee a linear improvement in overall system performance.

For technology and operations leaders at midsize and large companies, this contrast creates friction. Steering committees expect delivery commitments based on fixed estimates, while technical teams face a reality in which preliminary experimentation is essential before writing a single line of production code.

Nondeterministic Behavior and Rethinking the Definition of Done

The traditional Definition of Done typically relies on passing unit tests, test coverage, and deployments with no functional errors in test environments. In an AI environment, however, a function can be technically well written and deployed yet still fail to meet the level of accuracy, consistency, or relevance the business process requires.

Adapting this concept means shifting the focus from simply completing tasks to validating hypotheses against performance thresholds. An acceptance criterion can no longer be as simple as 'the model answers the query'; it must account for statistical tolerance ranges, response stability, and behavior when handling anomalous data.

By redefining these criteria, organizations can maintain technical quality without slowing the team's pace, drawing clear boundaries between analytical progress and a capability that is ready for production.

• Define acceptance criteria based on continuous evaluation metrics, not just code delivery.
• Incorporate data stress testing and semantic consistency checks into sprint validation workflows.
• Accept that an inconclusive research result is also a valid deliverable if it rules out an unviable approach.

Dual-Track Sprints: Integrating Applied Research and Continuous Delivery

The biggest operational risk of applying Scrum rigidly to AI is forcing data scientists to fit uncertain discoveries into two-week time boxes. When this happens, teams tend to compromise experimental rigor, or sprints stretch on indefinitely without delivering measurable value.

A practical solution for midsize and large organizations is to adopt dual-track or parallel workflows. In this model, two synchronized tracks coexist: an applied research track and a software engineering and integration track.

The research track explores technical feasibility, cleans data, and compares model architectures, typically working one or two cycles ahead. The engineering track takes models that have already met the required performance thresholds and packages them into microservices, interfaces, and automation workflows ready for use by enterprise systems.

Progress Metrics: Measuring Value Beyond Sprint Velocity

Team velocity, typically measured in story points completed per sprint, becomes less useful as a primary metric when exploring AI solutions. A team may spend weeks cleaning a dataset or evaluating multiple architectures, only to conclude that the error rate is unacceptable for the use case. In a traditional framework, this would be seen as a failed sprint; in an applied innovation environment, it represents substantial resource savings by avoiding the implementation of an inadequate system.

Mature organizations replace or supplement story points with indicators focused on reducing uncertainty. They assess the rate at which hypotheses are ruled out, the incremental gain in accuracy per training cycle, and the operational resilience of deployed solutions.

This shift in perspective aligns the technical team's objectives with business outcomes, allowing management to assess return on investment based on the solution's actual maturity rather than an artificial tally of completed tasks.

Governance, Compliance, and Managing Business Expectations

At large enterprises and corporations operating in regulated markets in Latin America or the United States, adopting Agile methodologies for AI must go hand in hand with rigorous governance. Unlike traditional software, where audits focus on access controls and security vulnerabilities, intelligent systems require oversight of data bias, decision traceability, and the privacy of the information they process.

Given the rapid evolution of international and local regulatory frameworks governing personal data protection and the responsible use of algorithms, companies must take a proactive approach. It is essential to involve compliance teams and seek qualified legal advice early to ensure that development efforts comply with current regulations in each jurisdiction.

Stakeholder communication also requires ongoing transparency. Project leaders must educate business users about the iterative nature of AI, setting realistic expectations for the learning and tuning phases every system needs before it can operate reliably in day-to-day use.

How 1labs Supports the Transition to Effective Agility in AI

At 1labs, we operate as an independent consultancy, helping business leaders design realistic roadmaps, tailored delivery methodologies, and robust technical architectures for AI adoption.

Our approach avoids overpromising and focuses on technical feasibility, integration with legacy systems, and long-term operational sustainability. We help organizations structure their internal teams, define appropriate evaluation frameworks, and execute projects that balance experimentation and engineering while staying focused on results.

Frequently asked questions