1. Introduction

1.1. The context of change

Generative Artificial Intelligence has been at the center of the technology debate for three years. It has brought real changes: coding assistants that shorten cycles, models that allow non-technical profiles to generate functional prototypes, and agents that automate tasks that used to require hours. It has also brought promises that have not been fulfilled at the speed announced. In December 2025, MIT Technology Review described the year as the great correction to AI hype, noting that the technical community was in the middle of revising its expectations. This document starts from there: from reality, not enthusiasm.

What has changed in a verifiable way is where effort is concentrated in development teams. When AI can generate code, tests, and documentation in minutes, the bottleneck stops being engineering and moves somewhere else: deciding what to build, for whom, and why. That is not a technical problem. It is exactly the problem that agile frameworks have spent decades trying to solve.

Scrum emerged in the 1980s as a spontaneous response from communities of practice to the waterfall model, and since then it has kept transforming through the contributions of those same communities. Its principles were not conceived with AI in mind, but neither were they conceived with the cloud, mobile devices, or software as a service in mind. They survived all those changes. The question this document asks is not whether Scrum will survive AI. It is what teams that practice it must change so that this survival generates real value, and does not become yet another case of adoption without impact.

1.2. What this document is

This document is informative, not normative. It does not aim to define a "new Scrum" or to establish rules that replace any existing source. Its purpose is to offer the reader an updated map of the terrain so that each team can make its own informed decisions.

The document starts from a premise that it makes explicit: agile principles remain valid, but many of the concrete practices built on them need to evolve. That evolution has no single form. It depends on each team's context, its maturity, its sector, and the real role AI plays in its work. What you will find here is not a recipe but a set of real tensions, verified evidence, and open questions that can help you chart your own path.

Note for the reader: throughout this document you will find sections on context, industry data, and emerging models. None of them is presented as "the correct answer." Agility, by definition, rejects universal recipes. Use this guide as a starting point for your team's reflection and experimentation.

2. The state of the question: Scrum versus AI

2.1. Scrum as open and emergent knowledge

To understand how Scrum should evolve in the face of AI, it is first necessary to understand what Scrum really is and how it got here. There is a frequent confusion that deserves to be clarified from the start of this guide.

Scrum is not a methodology designed and disseminated vertically by an academic author, a standardization committee, or a group of researchers. Unlike models such as CMMI (created by Carnegie Mellon University) or SAFe (created by Dean Leffingwell), Scrum has no owner who defines it exclusively. Scrum emerged from the bottom up, driven and built horizontally by the professional community. It is an example of open knowledge, in the public domain.

In the 1980s, engineers at companies such as 3M, Fuji, Honda, and HP, dissatisfied with production models based on waterfall cycles, developed an iterative pattern with overlapping phases. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka identified these principles in their article "The New New Product Development Game" in Harvard Business Review, and named them "scrum," borrowed from rugby. It is important to understand that Nonaka and Takeuchi identified, named, and gave visibility to the concept, but did not create it.

Later, various contributions enriched the framework: Peter DeGrace and Leslie Hulet Stahl presented Scrum as an iterative development proposal in 1990; Jeff Sutherland and Ken Schwaber offered their own interpretation in 1995; and since then, the agile community has continued to mature and transform Scrum practices continuously. The reduction of iterations from one or two months to one or two weeks, the incorporation of retrospectives, backlog refinement, estimation practices (or non-estimation), visual management kanban boards... all are examples of how the community has shaped the Scrum we know today.

Thinking of a single author and an exclusive "official guide" is to treat as closed and proprietary a body of knowledge that is collaborative and open. Doing so constrains it and clips the wings of a framework whose strength lies precisely in its capacity for community-driven evolution.

If Scrum were a closed and proprietary model, adapting it to AI would require waiting for "its authors" to update it. But if we understand Scrum as open knowledge, adapting it to AI is exactly what the professional community must do: observe how the context has changed and evolve practices while keeping the principles. That is what this guide proposes.

2.2. The debate in the community: contributions and relevant voices

Faced with the impact of AI, the agile community has not remained silent. In a short time it has produced a notable set of contributions: some propose adapting existing practices, others question whether current frameworks remain valid, and others propose entirely new paradigms. What follows is a map of the most relevant voices, not a verdict on who is right.

The Scrum Guide Expansion Pack (SGEP, 2025)

Published in June 2025 by Jeff Sutherland, John Coleman, and Ralph Jocham, the SGEP is a community supplement presented as an optional companion to the 2020 Scrum Guide. Its most relevant contributions to the AI debate:

• Mutability of Scrum: the SGEP explicitly declares that Scrum is mutable, unlike the 2020 Scrum Guide, which considered it immutable. This is a significant acknowledgment: one of the framework's original co-authors formally admits it needs to change.

• AI as an actor: it recognizes AI as an actor in certain team contexts, including the possibility that "Product Developers can be human or automated," on the condition that at least one of them is human.

• New roles and artifacts: it renames Developers as Product Developers, adds the roles of Stakeholders and Supporters, and introduces the Definition of Outcome Done as a measure of value beyond the technical quality of the increment.

The SGEP has generated mixed reactions. It does not have the endorsement of Scrum.org nor the participation of Ken Schwaber. Its 50 pages compared with the 13 of the Scrum Guide also raise a fundamental question: if Scrum's strength has always resided in its conciseness and in leaving room for each team to complete it, does a supplement that multiplies that length by four evolve the framework or contradict its principle of simplicity? As with any contribution to open knowledge, it deserves to be read with your own judgment.

The AI Teammate Framework (Scrum.org, 2025)

Scrum.org has published a four-step framework for integrating AI into Scrum teams: Model Management, Context Management, Prompt Engineering, and Governance Management. It is a pragmatic approach focused on treating AI as a teammate who is onboarded with context, whose interactions are guided, and over whose outputs governance is established.

The teammate analogy is pedagogically useful, but it has an important limit: unlike a human, AI has no motivation of its own, does not develop relationships of trust, and does not learn from the team in the way a person does. This does not invalidate the framework, but it invites using it with awareness of what the analogy does not capture. AI is an extraordinarily powerful tool; treating it as a teammate may simplify its integration or may generate mistaken expectations about what that integration produces.

The Agile AI Manifesto (Scrum.org, 2025)

An analysis arguing that the principles of the 2001 Agile Manifesto align remarkably well with how generative AI works, and that AI amplifies the value of professionals who contribute judgment and experience while exposing those who performed mechanical work. It is supported by the study The Cybernetic Teammate (Dell'Acqua et al., 2025), a field experiment with 776 professionals at Procter & Gamble.

The thesis is empirically solid. It does, however, deserve a careful reading on one point: that the principles of the Manifesto are compatible with AI does not automatically imply that the usual practices built on them are compatible too. And the claim that AI exposes those who only did mechanical work, although backed by the data, is not a neutral conclusion: it is a narrative that should also be examined from within, asking to what extent agile frameworks themselves have generated mechanical work disguised as iteration.

Critical voices and alternative contributions

Not the whole community starts from the assumption that AI and agility are compatible. Steve Jones, of Capgemini, published in February 2026 in InfoQ a direct argument: agentic development environments are too fast for agility as it is practiced today, and the Agile Manifesto needs to be replaced, not adapted. From the development community, there are voices pointing out that AI accumulates technical debt at unprecedented speeds, which makes specification and documentation regain critical relevance, paradoxically reversing one of agility's historic bets.

Platforms such as GitHub with its Spec Kit and consultancies such as Thoughtworks are exploring paradigms such as Spec-Driven Development and dual-cadence models that do not start from adapting Scrum but from rethinking from scratch how work is organized when a substantial part of execution is carried out by an agent. These practices are developed in section 4.

This document adopts a position of "evolution": agile principles remain valid, but concrete practices need profound transformation. And it does so from the conviction that Scrum, as open and emergent knowledge, has the capacity to evolve. It needs no one's permission to adapt: that is what it has always done.

2.3. The productivity paradox

One of the most documented phenomena of the moment is what McKinsey has called the "generative AI paradox": widespread adoption, scarce impact on results.

McKinsey, in its State of AI 2025 (survey of 1,993 executives in 105 countries), found that 88% of organizations already use AI in at least one business function, but only 39% report any impact on EBIT, and in most of those cases that impact is below 5%. BCG reaches similar conclusions from a different methodology: 60% of organizations do not generate material value despite their AI investments, and only 5% create substantial value at scale. The factor McKinsey identifies as most decisive for being in that 5% is not the tool adopted but having redesigned workflows in depth, not merely having added AI on top of existing processes.

The picture is equally ambivalent among developers themselves. The annual Stack Overflow 2025 survey, with more than 49,000 developers in 177 countries, reports that 84% use or plan to use AI tools, but also that 46% say they do not trust the accuracy of their outputs, compared with 31% the previous year. Favorable views of AI tools have dropped from 70% to 60% in a single year. Adoption grows; trust does not necessarily.

The most widespread explanation for this gap does not point to the technology itself, but to what surrounds its use: teams produce features at greater speed, but without the product guidance, user validation, and strategic vision needed for that speed to generate real value. Product management has displaced engineering as the limiting factor in delivering value. It is a shift that raises uncomfortable questions about how teams are organized, which roles make sense, and which practices remain useful.

3. Agile principles as an invariant compass

There is something the debate on AI and Scrum tends to overlook: agile principles were not conceived with any specific technology in mind. They arose as a response to an organizational problem that AI does not solve but intensifies. The principles do not "survive" AI as if they were an endangered species: they are more necessary than ever.

3.1. The values of the Manifesto

Empiricism over prediction

Scrum rests on three pillars: transparency, inspection, and adaptation. AI does not weaken these pillars; if anything, it tests them. With smarter dashboards and faster feedback cycles, teams today have more technical capacity to inspect and adapt than ever. The risk is the opposite: that AI's speed of generation exceeds the team's capacity to reflect on what it is building, turning empiricism into an empty declaration of intent. Inspecting and adapting requires time to think. AI does not generate that automatically; it must be protected.

Individuals and interactions over processes and tools

This is the principle that most directly challenges AI, because AI is exactly what the Manifesto placed in the column of lesser value: a tool. However sophisticated it is, however much code it generates, tests it writes, or solutions it proposes, AI does not replace human conversation as the mechanism for building shared understanding, managing conflict, or making decisions under uncertainty. What it can do is free up time and cognitive attention so that those conversations are better. That only happens if the team actively decides what to devote the time AI gives back to.

Working software over comprehensive documentation

With AI it is possible to generate functional prototypes in hours. That reinforces the principle of validating with working software rather than with documents. But it introduces a real tension: as section 4 will show, Spec-Driven Development requires detailed specifications to guide AI agents. The distinction this document proposes is that these specifications are not documentation in the sense the Manifesto rejected, bureaucracy that replaces thinking, but the instruction language that makes collaboration between humans and AI possible. The form changes; the principle of prioritizing real validation over paper does not.

Responding to change over following a plan

AI makes operationally viable what used to be costly. Monitoring behavior patterns, analyzing support conversations, or detecting signals of change in real time no longer requires research cycles lasting weeks. What was an ideal becomes a real technical possibility. The challenge is organizational: having decision-making mechanisms agile enough to act on that information when it arrives, not when the next quarter allows it.

3.2. AI as technology, not as a team

There is a confusion worth clearing up before entering the map of concrete tensions. Some recent contributions propose treating AI as one more member of the team. The analogy has pedagogical value for thinking about onboarding, context, and governance. But it obscures something fundamental: AI is technology.

This matters because the first value of the Agile Manifesto is precisely that one: individuals and interactions over processes and tools. AI, however generative it may be, falls in the column of tools. That does not make it less valuable; it places it correctly. A team that treats AI as a powerful technology that amplifies its capacity makes better decisions about when to use it, when not to, and who is accountable for its outputs. A team that treats it as a teammate may end up delegating to it decisions that require human judgment.

3.3. The risk of confusing speed with agility

AI allows teams to go faster. That is a fact. The frequent mistake is assuming that going faster equals being more agile. It does not. Agility is not speed: it is the capacity to respond effectively to change while delivering value. These are different things, and the difference becomes critical when AI accelerates production faster than the organization can validate whether what it produces deserves to be produced.

When that happens, the central question stops being "can AI build it?" and becomes "should we build it, and why?" That second question has no technical answer. It is answered by people with product judgment, knowledge of the user, and the ability to say no. AI does not replace that judgment; it makes it more urgent.

4. Tensions and decisions: the axes of evolution

This section presents the five major axes on which teams are making real decisions right now, without prescribing a single answer. For each axis, options, evidence, and risks are offered. The right answers depend on each team's context.

4.1. Cadence and pace of work

The two-week sprint has become the de facto standard, although it was not always so: the first iterations of Scrum in the 1990s used cycles of one or two months, and it was the community itself that shortened the cadence as the context required. With AI, this cadence is once again under tension: teams can generate product increments, MVPs, or features in a matter of hours or days. What used to take a sprint may now take a morning.

Options teams are exploring

• Sprints with internal micro-iterations: keep the sprint as the container for planning and review, but within it run multiple short cycles of ideation, generation, and validation assisted by AI. It preserves synchronization points without slowing down speed.
• Shorter sprints: reduce to one week or less, bringing the cadence closer to the real speed of delivery. Some teams experiment with three-day sprints for AI-assisted work.
• Continuous flow: abandon the sprint as a time container and adopt continuous flow with work-in-progress (WIP) limits. It requires alternative mechanisms for the moments of inspection and adaptation the sprint used to provide.
• Dual cadence: a fast rhythm for prototyping and experimentation (days) and a slower rhythm for production engineering and strategic validation (weeks). It is developed in detail in section 5.

Risks to consider

Eliminating sprints altogether carries a real risk: losing the moments of structured reflection. The retrospective is precisely the mechanism that allows the team to inspect and adapt how it works with AI. Paradoxically, this is when reflecting on the process is most needed, just when speed invites skipping these moments.

Question for your team: Is our current sprint a useful container that gives us rhythm and moments of reflection, or is it a bottleneck that slows our real delivery capacity?

4.2. Team size and composition

Standard Scrum practices have been optimized for teams of around seven people. The productivity AI enables means modern teams can be significantly smaller. A single business profile can today generate functional prototypes without direct intervention from design or engineering.

This does not mean small teams are always better. It means that team size should respond to the real work, not to an inherited convention. And it raises questions that usual Scrum practices did not address:

• Who is accountable when an AI agent makes a mistake?
• How is AI's context managed so that its outputs are relevant to the team?
• How is AI's contribution measured against the human one?
• Which events still make sense, and in what format?

Scrum.org proposes treating AI as a teammate who is onboarded with context and subject to governance. As argued in section 3, this analogy has a fundamental limit: AI is technology, not a team member. That does not invalidate the practical questions the framework raises, but it invites answering them from a different premise: we are not incorporating a new colleague, we are managing a tool that requires the same rigor as any other architecture or infrastructure decision.

Events in small teams

In teams of two or three people, lengthy ceremonies lose part of their original purpose of complex coordination. That does not mean eliminating them:

• The Daily Scrum can become a brief asynchronous check-in or a weekly sync.
• Sprint Planning can be simplified to a session of prioritization and definition of specifications for AI.
• The Sprint Retrospective remains essential, perhaps more than ever, as a space to evaluate how collaboration with AI works and what to adjust.

Question for your team: if we reduced our team by half with AI assistance, which events would still add value, and which would become meaningless bureaucracy?

4.3. From user stories to specifications: the language of work

User stories were born as a communication tool between humans: "As a [user], I want [action] so that [benefit]." This format is effective for conveying intent between people, but it is not the most precise way to instruct a generative AI. A fundamental tension arises: the language that facilitates human conversation is not the same as the language that effectively guides an agent.

Spec-Driven Development (SDD)

It is one of the most significant paradigms to have emerged in 2025. It uses well-crafted requirement specifications as instructions for coding agents to generate executable code. The specification becomes the source of truth for both the human and the AI. Unlike traditional specifications, SDD specs are executable artifacts: they are run during validation, and the implementation cannot deviate without causing build failures.

Tools such as GitHub Spec Kit have formalized this flow into four phases: Specify (a high-level description of what is to be built and why), Plan (the agent proposes an implementation plan), Tasks (decomposition into small, reviewable tasks), and Implement (the agent executes and the developer reviews focused changes, not massive blocks of code).

Teams adopt SDD at different levels of maturity:

• Spec-first: the entry level. Specifications are written before coding to guide AI-assisted implementation.
• Spec-driven with automated validation: specs include BDD scenarios, API contract tests, or simulations that run automatically.
• Spec-as-source-of-truth: the specification replaces code as the main artifact. Maintaining the software means evolving the specifications.

The risk of regression to Waterfall

If specifications become too rigid, there is a danger of regressing to the waterfall model. Excessively formalized specifications can slow down cycles of change and feedback, exactly as happened in the early stages of waterfall development. The solution is not to choose between user stories and specs, but to find the right coexistence:

• Specs as living documents: specifications must iterate in the same spirit as an agile backlog: they are refined, adapted, and evolve with each learning cycle.
• Not everything needs the same level of specification: a validation prototype can start from a user story; a feature critical for production requires a detailed spec.
• The spec complements, does not replace, the conversation: the Conversation-Card-Confirmation format remains valid; the spec translates that conversation into a language AI can process.

Question for your team: In what proportion of our current work are user stories sufficient to guide AI, and in what proportion do we need more detailed specifications?

4.4. Roles in transformation

The usual roles in Scrum teams do not disappear, but they undergo a deep transformation in their focus, their competencies, and their relative relevance.

The Product Owner as a strategic bottleneck

With AI capable of building features faster than the organization can validate their desirability, the Product Owner becomes the real limiting factor. Their role evolves toward something called the Product Architect: not only prioritizing a backlog, but actively managing what deserves to be built, designing continuous validation experiments, and deciding where AI adds real value versus where it generates noise.

Job postings for these roles multiplied 75 times in two years between 2022 and 2024, according to labor market data that Forrester has also identified as one of the fastest-growing trends in product management. The market has recognized this transformation before most teams have processed it.

The Scrum Master: transformation or extinction

This is the role with the greatest risk of redefinition. If its value is defined as facilitating events, AI makes it dispensable: it can suggest facilitation techniques, generate agendas, take notes, and analyze flow metrics. However, the competencies AI cannot replicate, such as emotional intelligence, systems thinking, team leadership, and ethical decision-making in complex contexts, are precisely what define the value of an evolved agile facilitator. Projections for 2030 place this role as a leader focused on strategy, cultural transformation, and organizational coaching, removed from the team's daily operations.

Developers as Product Builders

The development team transforms into Product Builders: profiles that combine the use of no-code tools, AI-assisted code generation, and a deep understanding of the product. Their value shifts from implementation toward orchestration: designing architectures, writing specifications, reviewing and validating what AI generates, and ensuring the code meets quality and security standards.

Question for your team: for each team member, what proportion of their current work could be assisted or replaced by AI? Toward where should their contribution of value shift?

4.5. Quality and trust: the new QA

Software quality is possibly the area where AI generates the most tension between its promises and its reality.

The silent degradation of code

Analyses of large codebases show worrying patterns as AI assistance becomes widespread:

• Code duplication in AI-assisted projects increased significantly (from ~8% to ~12% of changed lines).
• Refactoring activity dropped sharply: teams produce new code instead of improving the existing one.
• In 2024, for the first time, copied or AI-generated code surpassed refactored code.
• Senior developers experienced a 19% decrease in performance on complex tasks when using AI, due to the time spent reviewing and testing the generated output.

These data suggest that, without deliberate controls, AI accelerates the accumulation of technical debt. The team goes faster, but the code becomes fragile, duplicated, and costly to maintain.

The trust paradox

Developers' trust in the accuracy of AI-generated code fell from 69% in 2024 to 54% in 2025, as use became widespread and teams experienced the limits of the technology more. The most common frustration is getting solutions that are "almost correct but not quite": the output looks plausible but contains subtle errors that generate additional work.

Emerging QA models

• AI supervising AI: using one AI as an automatic reviewer of what another AI generates, establishing "traffic lights" and automated reviews.
• Specification by Example (SbE): creating manual test harnesses with concrete, verifiable specifications. One cannot rely on AI to "grade its own homework"; SbE provides concrete, testable expectations.
• Reinforced Definition of Done: adapting the DoD specifically for AI-generated code, including security reviews, static analysis, and duplication checks.
• Continuous technical debt auditing: actively monitoring code health metrics (duplication, cyclomatic complexity, test coverage) as a counterweight to generation speed.

Question for your team: Have we adapted our Definition of Done to specifically address AI-generated code? Do we have quality metrics that counteract the temptation to prioritize speed over robustness?

5. Emerging working models

The tensions described in section 4 are not resolved in isolation. Teams navigating this moment with the most judgment are not applying one option per axis, but combining options into complete configurations that respond to their context. This section describes the two most relevant models that have emerged. Neither has reached the maturity of consolidated Scrum practices; both are practices in evolution. They are presented so that each team can assess which are relevant to its situation, in the same way that retrospectives or kanban boards were once community innovations that enriched the framework.

5.1. Double Track (Double-Track)

The concept of dual-track agile, discovery plus delivery, has existed for years. AI makes it more explicit and more necessary, because the speed difference between exploring and building for production has become so large that managing both at the same pace generates constant friction.

Vibe coding: the fast track

A flow oriented toward creating prototypes that are not releasable to production. Its purpose is to quickly validate ideas with users, using AI and no-code tools to generate functional artifacts in hours. On this track, code quality is secondary; what matters is the speed of learning. It is the natural space for vibe coding: free interaction with AI to explore possibilities without the rigor of production.

Vibe engineering: the robust track

A flow that ensures minimum standards of engineering, security, and quality so that the product is robust and maintainable. Here the Spec-Driven Development practices described in section 4.3 are applied, the Definition of Done is reinforced, and the QA mechanisms from section 4.5 are executed. It is the space where AI-generated code is subjected to production rigor.

Vibe coding can be 10x to 100x faster than vibe engineering, which requires conscious management of when and how to transition an idea from the fast track to the production track. The decision of when to make that transition is a product decision, not a technical one.

5.2. Hybrid models: combining according to context

In practice, most teams will not adopt a single model in its pure form. They will combine dual cadence with SDD on the robust track, or continuous flow with weekly retrospectives, or short sprints with Byte Coding for discovery. The specific configuration depends on the type of product, team size, technical maturity, and the degree of business uncertainty.

The key is not to choose the right model in advance, but to experiment with discipline: try an approach, measure results, inspect and adapt. That is exactly what the agile community has been doing since the 1980s: evolving its practices in response to context, enriching a body of knowledge that belongs to everyone. The integration of AI is the next chapter of that evolution, not its end.

6. Roadmap for team reflection

Instead of a prescriptive implementation plan, this section offers a self-assessment canvas. It does not say what each team must do; it offers the questions that allow each team to reach its own answers.

It is recommended to use it in a facilitated session, such as a specific retrospective or a team workshop, where all members can contribute. The suggested process is:

1. Assess: each member individually answers the questions under Where are we?
2. Share: the answers are put together and patterns and divergences are identified.
3. Prioritize: one or two dimensions where the friction is most evident are selected.
4. Experiment: a concrete experiment is designed for the next cycle.
5. Inspect and adapt: the results are reviewed and a decision is made to continue, expand, or pivot.

The canvas is neither a definitive diagnosis nor a universal roadmap. It is a starting point for the conversation each team needs to have with itself. The right answers are those that emerge from that process, not those this document prescribes.

7. Conclusion: evolving without losing direction

Generative AI has not killed Scrum. It has done something subtler and deeper: it has tested whether teams truly practice agility or simply execute a set of rituals. It has separated those who contribute strategic judgment from those who perform tasks technology can automate. It has accelerated the capacity to build to the point where deciding what to build has become the main challenge.

From that diagnosis, some ideas follow that this document has tried to support with evidence. Agile principles, empiricism, value delivery, continuous adaptation, and human collaboration, do not merely survive the age of AI: they become more necessary precisely because the speed of construction has ceased to be the constraint. The compass does not change; the terrain does.

Concrete practices, by contrast, need review. Cadences, team composition, artifacts, roles, and quality models need to be rethought, not cosmetically adjusted. And that review has no single answer: Dual Track, Spec-Driven Development, and hybrid models are options, not prescriptions. Disciplined experimentation, which means trying, measuring, inspecting, and adapting, remains the path.

There is something this document cannot resolve for any team: knowing where it stands today and what friction it is feeling. That requires the conversation only the team itself can have. What this document can do is invite that conversation and leave it open.

This is a working document. It is a contribution to a debate that the agile community has been building for decades and that, with the arrival of AI, has become urgent again. The criticisms, corrections, and experiences that arise from reading it are exactly what it needs to improve.

Bibliography

• BCG (2025). AI at Scale: Closing the Value Gap. Boston Consulting Group.
• DeGrace, P. & Hulet Stahl, L. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Engineering Paradigms. Prentice Hall.
• Dell'Acqua, F. et al. (2025). "The Cybernetic Teammate: A Field Experiment on Generative AI Reshaping Teamwork and Expertise". Harvard Business School Working Paper No. 25-043.
• Fernandes, D. [Darrell] (2025). The AI Teammate Framework: A Four-Step Framework for Product Teams. Scrum.org.
• GitHub Blog (2025). "Spec-driven development with AI: Get started with a new open source toolkit". Github.blog.
• Jocham, R., Coleman, J. & Sutherland, J. (2025). Scrum Guide Expansion Pack.
• Jocham, R. & Sutherland, J. (2026). AI and Scrum: An Evidence-Informed Integration Guide.
• Liu Shangqi / Thoughtworks (2025). "Spec-Driven Development: Unpacking 2025's Key New AI-Assisted Engineering Practices". Thoughtworks.com.
• McKinsey & Company (2025). The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey QuantumBlack.
• Schwaber, K. (1997). "SCRUM Development Process". Presented at OOPSLA'95, Austin, Texas. Published in: Sutherland, J. et al. (eds.), Business Object Design and Implementation. Springer, London.
• Schwaber, K. & Sutherland, J. (2020). The Scrum Guide.
• Stack Overflow (2025). Developer Survey.
• Takeuchi, H. & Nonaka, I. (1986). "The New New Product Development Game". Harvard Business Review, vol. 64, pp. 137-146.
• Wolpers, S. (2025). "The Agile AI Manifesto". Scrum.org Blog.
• Xebia Academy (2025). "Scrum Teams In 2030: The Future Of Agile With AI". Academy.xebia.com.

You can download it as a PDF (you can also access it in the resources section of our website).