September 1, 20266 MIN READ

Is AI Making Agile Teams More Adaptive, or Quietly Changing What Agile Work Means in Germany?

AI is not just making Agile faster; it is changing how work is divided between humans and machines.

Over the past few years, a lot of my work has sat somewhere between software development, data analysis, and AI. Working in a large German industrial company while also building AI-heavy software projects has made one thing especially noticeable: adopting AI is rarely just a technical decision.

A tool can be useful within minutes. Getting it into an actual organization is another story.

There are questions about which data can be shared, which tools are approved, how generated output should be reviewed, and whether the productivity gain is worth introducing another dependency into an already complicated workflow. In a large organization, even something as simple as using an AI assistant can sit at the intersection of engineering, security, compliance, internal processes, and the way a team actually prefers to work.

That is what made me interested in the relationship between AI and Agile in the first place.

Agile was built for uncertainty. Scrum, Kanban and related methods assume that teams rarely know everything at the start of a project. Requirements change, customers react, technical problems appear, and priorities move. Instead of trying to eliminate that uncertainty, Agile gives teams a way to work through it: short feedback loops, incremental delivery and frequent adjustment.

AI seems to fit naturally into that model. It can summarize customer feedback, draft requirements, help estimate work, generate code, prepare tests and turn meetings into structured notes. Recent research on AI in Agile environments already documents applications across sprint planning, backlog management, risk assessment, documentation and decision support (Ismail, 2026; Neumann et al., 2026).

But after using these tools in real development work, I think the more interesting question is not simply whether they make teams faster.

It is whether they are changing what the team actually does.

If code generation becomes cheaper, more time moves toward review. If project information can be summarized automatically, the value of manually maintaining certain artifacts changes. If an AI system can work through several implementation steps on its own, then even the meaning of assigning a task starts to shift.

This matters everywhere, but Germany is a particularly interesting place to watch it happen. German companies have to combine the pressure to adopt AI with data-protection requirements, internal governance, established engineering practices and very different levels of technical infrastructure across large corporations and the Mittelstand (Felder et al., 2026).

The result is unlikely to be the end of Agile. What seems more plausible is a version of Agile in which planning, implementation and coordination are increasingly divided between people and AI systems.

And that raises a more useful question than whether AI can write a user story:

What happens to Agile when some of the work it was designed to organize is no longer done entirely by humans?

AI is already moving into the planning layer

The easiest place to see the change is project planning.

Agile teams already generate a large amount of structured and semi-structured information: backlog items, story points, sprint histories, defects, customer requests, retrospectives, risk logs and delivery data.

AI can make use of that information.

A 2026 systematic review of 24 studies found that the most common applications of AI in Agile environments were concentrated around sprint planning, backlog management and risk assessment. The review also found repeated claims of efficiency gains and better data-supported decision-making, while noting persistent problems around organizational resistance and data quality (Ismail, 2026).

For a Product Owner, the practical value is easy to imagine.

Instead of manually going through hundreds of support tickets, survey responses or meeting notes, an AI system can group similar complaints, summarize them and suggest possible backlog items. Historical delivery data can also be used to support sprint planning. Research in this area discusses the use of historical velocity, burndown trends, story-point distributions, defect logs and prioritization histories as inputs for forecasting and planning tools (Ismail, 2026).

That does not mean planning becomes automatic.

In fact, one of the biggest problems is that Agile data is often messier than it appears.

Story points are subjective. Different teams estimate differently. Important decisions happen verbally and never make it into Jira. New teams have little historical data. A backlog may reflect what was documented rather than what actually happened.

This matters because AI-assisted planning depends heavily on the quality of that historical data. Inconsistent story-point assignments, sparse records and undocumented decisions can make forecasts less reliable rather than more reliable (Ismail, 2026).

So AI may improve planning, but it may also create something Agile teams have always been suspicious of: false precision.

A system can predict that a sprint has a 72% probability of success. That number looks objective. The assumptions behind it may not be.

The bigger change is happening inside the work itself

The strongest evidence of change is probably not in sprint planning, but in software development.

A recent study of German software engineers found a clear shift from creation to validation. Interviewed developers described moving away from writing everything themselves and toward reviewing and debugging AI-generated output. The researchers describe the developer increasingly acting as a reviewer of generated logic rather than its sole author (Felder et al., 2026).

That sounds like a small workflow change, but it can have a large effect on Agile planning.

A traditional development task might look roughly like this:

understand → implement → test → review

With AI assistance, the flow increasingly becomes:

describe → generate → inspect → correct → test → review

The implementation step may become faster, but the surrounding work does not disappear.

It moves.

The same research describes a "verification tax": when developers do not fully trust AI-generated output, part of the time saved during generation can return as review and validation effort. Limited awareness of the full project context was also one of the most significant barriers reported in the study; more than half of respondents identified difficulty understanding the whole codebase as a serious challenge (Felder et al., 2026).

That is important because it challenges a very simple story about AI productivity.

If coding becomes 30% faster, a sprint does not automatically become 30% faster.

Architecture still needs to be understood. Requirements still need clarification. Generated code still needs to be reviewed. Integration problems still need to be solved.

The bottleneck can simply move.

This also complicates Agile metrics.

If a team's tools change significantly between January and June, comparing velocity between those periods becomes less meaningful. The same number of story points may no longer represent the same amount or type of work.

That creates a strange situation: AI can help teams analyze historical sprint data while simultaneously making that historical data less comparable.

It may also change the value of experience

One of the recurring findings in AI-at-work research is that the productivity effect is not evenly distributed.

A large study of 5,172 customer-support workers found that access to a generative AI assistant increased productivity by about 15% on average. The gains were much larger for less experienced and lower-skilled workers, while the most experienced workers saw much smaller gains. For some less-experienced groups, productivity gains reached roughly 30% (Brynjolfsson, Li & Raymond, 2025).

Those results come from customer support, not software engineering, so they should not be transferred directly to Scrum teams.

But the pattern is worth paying attention to.

German software-engineering research also found that junior and senior developers do not experience AI in the same way. Senior developers often reported less need for assistance because of existing domain knowledge and established workflows, while newer team members and product-oriented roles tended to integrate AI more heavily into their daily work (Felder et al., 2026; Neumann et al., 2026).

This could have consequences for team structure.

A junior developer may be able to produce more output faster than before, but that output may still require review by someone with deeper architectural knowledge.

So AI does not necessarily remove the importance of senior engineers.

It may actually shift more of their time toward review, architecture and judgment.

That is a different kind of leverage.

The Product Owner and Scrum Master probably do not disappear

There is a temptation to look at AI and ask which Agile roles can be automated.

That is probably the wrong question.

The more useful question is: which parts of each role become cheaper?

For a Product Owner, AI can help with:

summarizing feedback
drafting user stories
rewriting acceptance criteria
grouping similar requests
preparing backlog items
analyzing previous decisions

For a Scrum Master or Agile Coach, it can help with:

meeting summaries
action items
retrospective notes
identifying recurring blockers
preparing reports
organizing documentation

Research on LLM use in Scrum management already reports use across artifacts, events and role-specific responsibilities, with perceived benefits in productivity, documentation, communication and decision support. At the same time, practitioners report concerns about unreliable output, confidentiality, trust and organizational resistance (Goldman et al., 2026).

What is harder to automate is the part of Agile that depends on people.

A model can summarize a retrospective.

It cannot reliably tell whether two team members have stopped trusting each other.

It can rank backlog items.

It cannot decide what kind of product a company should become.

It can suggest that a sprint is overloaded.

It cannot negotiate priorities between engineering, sales, management and a major customer.

This probably pushes Agile roles away from administration and further toward judgment.

The Product Owner becomes less of a backlog administrator and more of a decision-maker.

The Scrum Master becomes less of a meeting organizer and more of a facilitator of actual organizational problems.

Germany adds a second problem: using AI is easy, governing it is not

Germany's AI adoption is shaped by factors that do not appear as strongly in many generic discussions about Agile.

Research on German software engineering highlights three particularly important parts of the local context: GDPR and the EU AI Act, the country's Mittelstand-heavy economic structure, and an engineering culture that places significant emphasis on quality, documentation and systematic processes (Felder et al., 2026).

The practical problem is simple.

The best AI assistant is not useful if employees are not allowed to give it the information it needs.

A developer working on a proprietary system cannot necessarily paste source code, customer information or internal architecture into a public AI service. The same applies to Product Owners working with confidential customer requirements or commercially sensitive roadmaps. German practitioners explicitly report concerns around data protection, intellectual property and the use of cloud-based AI systems with sensitive company information (Felder et al., 2026).

This creates a tension between context and compliance.

AI systems become more useful when they receive more context.

Companies become more cautious as that context becomes more sensitive.

German case studies already show what happens when those two pressures are poorly aligned.

In a 2026 multiple-case study of three German organizations, researchers found clear differences between officially approved AI tools and the tools employees actually used. In some cases, ChatGPT was used informally despite not being licensed for work. The authors describe this as a policy-practice gap that could lead to forms of shadow IT when formal rules do not match employees' day-to-day needs (Neumann et al., 2026).

That is probably one of the more useful lessons for German organizations.

The choice is not simply between "allow AI" and "ban AI."

If an approved internal tool is too limited to be useful, employees may look for another way to get the job done.

Good AI governance therefore has to be usable, not just legally defensible.

Employees may already be ahead of their companies

This is not only happening in software teams.

German workplace data from roughly 9,800 socially insured employees shows that more than half of employees already use AI at work, with the majority of that use described as informal. Usage was also strongly related to education and occupation: among employees with university degrees or advanced vocational qualifications such as Meister or Techniker, AI use was close to 80% (Arntz et al., 2025).

This suggests that in many organizations, AI adoption is not really arriving through a top-down "AI transformation."

It is arriving in small pieces.

Someone uses ChatGPT to restructure a requirement.

Someone asks Copilot to generate a test.

Someone summarizes a meeting with an LLM.

Someone uses AI instead of searching through documentation.

Individually, none of these changes looks like a transformation.

Collectively, they change how the organization works.

This may explain why formal processes sometimes lag behind reality.

Large companies and the Mittelstand will not adopt AI in the same way

Germany also has a structural split that matters.

Large corporations can afford internal platforms, security teams, dedicated AI governance and private infrastructure.

Smaller firms usually cannot do all of that.

But smaller organizations also tend to have fewer layers of approval.

The German software-engineering study found that company size affected both tool selection and usage patterns. Smaller companies in the sample used code-generation tools more frequently, while larger organizations shaped adoption more strongly through infrastructure and governance choices (Felder et al., 2026).

Self-hosted AI also showed an uneven pattern. Medium-sized firms and very large corporations in the sample reported similar levels of self-hosted model use, suggesting that the reasons for private deployment may differ by company size. For very large organizations, infrastructure capacity and data-governance requirements can justify private deployments; for smaller firms, the picture is more mixed and resource constraints remain important (Felder et al., 2026).

That makes it difficult to talk about "AI adoption in Germany" as one thing.

A 50-person software company and a global automotive manufacturer may use the same underlying models but operate under completely different constraints.

Agile itself may eventually have to change

So far, most AI adoption fits inside existing Agile structures.

Teams still have a backlog.

They still have sprints.

They still hold retrospectives.

They still have Product Owners and developers.

AI just helps with parts of the work.

The more interesting question is what happens when AI stops being a helper attached to individual tasks and starts handling sequences of tasks.

A developer can already ask an agent to inspect a repository, modify code, write tests and prepare a pull request.

As those systems become more capable, the unit of work changes.

Instead of assigning a person a task and watching them execute it, a person may increasingly supervise several automated workflows.

At that point, Agile is no longer coordinating only human labor.

It is coordinating human judgment and machine execution.

The current research is not yet evidence that Scrum is becoming obsolete. In fact, a recent review of AI in Agile concludes that most current integrations remain relatively shallow: the strongest evidence is still around incremental efficiency gains such as better estimation and planning rather than fundamental changes to team interaction or product design (Ismail, 2026).

That is probably the right way to look at the situation today.

We are still in the phase where AI is being inserted into Agile.

The next phase may be when Agile processes are redesigned around the assumption that AI is always present.

And that could affect some long-standing practices.

Do teams still need the same kind of estimation if AI can continuously update forecasts?

Do two-week sprint boundaries matter as much if implementation agents work continuously?

Does a backlog remain a static list of tickets, or does it become something that is constantly reorganized as new information arrives?

Nobody has a reliable answer yet.

But those questions are more interesting than asking whether ChatGPT can write a user story.

The real issue is not speed

It is easy to frame the effect of AI on Agile as a productivity story.

Developers code faster. Product Owners write requirements faster. Scrum Masters prepare meetings faster.

There is evidence for some of those improvements, but the gains are uneven and highly dependent on task, experience and organizational context (Brynjolfsson, Li & Raymond, 2025; Felder et al., 2026).

But speed alone is not the most important change.

The deeper effect is that the division of work is moving.

Machines increasingly handle first drafts, pattern recognition, information retrieval and routine implementation.

Humans increasingly handle validation, prioritization, architecture, exception handling and accountability.

That also creates new risks.

If developers rely too heavily on AI-generated code, knowledge may become shallower.

If every team member asks an assistant instead of another colleague, informal knowledge sharing may decline.

If AI-generated estimates appear more objective than they really are, teams may trust weak predictions.

And if companies introduce restrictive policies without providing useful alternatives, employees may simply use AI outside the formal process. German case evidence already shows that this policy-practice gap can push AI usage into informal channels rather than eliminate it (Neumann et al., 2026).

Agile was created around the idea that teams should adapt as they learn.

That principle still holds.

The difference is that now the tools themselves are becoming active participants in the work.

The question for German organizations is therefore not whether AI belongs in Agile.

It is already there.

The harder question is how to redesign Agile work so that AI removes unnecessary effort without weakening judgment, team knowledge and accountability.

References

Arntz, M., Baum, M., Brüll, E., Dorau, R., Hartwig, M., Lehmer, F., Matthes, B., Meyer, S.-C., Schlenker, O., Tisch, A., & Wischniewski, S. (2025). Digital Transformation and the Changing World of Work (DiWaBe 2.0): A Data Source for Research on Artificial Intelligence and Other Technologies in the Workplace. Federal Institute for Occupational Safety and Health (BAuA). https://doi.org/10.21934/baua:bericht20250319
Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at Work. The Quarterly Journal of Economics, 140(2), 889–942. https://doi.org/10.1093/qje/qjae044
Felder, L., Eisenreich, T., Fischer, M., Wagner, S., & Chen, C. (2026). Adoption of Generative Artificial Intelligence in the German Software Engineering Industry: An Empirical Study. In 34th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (FSE Companion '26'). ACM. https://doi.org/10.1145/3803437.3805207
Goldman, A., Marczak, S., Tonin, G. S., Bassi, D., Silva da Silva, T., Schön, E.-M., Neumann, M., & Pinna, A. (Eds.). (2026). Agile Processes in Software Engineering and Extreme Programming: XP 2026. Lecture Notes in Business Information Processing, 578. Springer. https://doi.org/10.1007/978-3-032-22375-3
Ismail, K. (2026). Agile practices and AI integration: A systematic literature review. Information and Software Technology, 195, 108119. https://doi.org/10.1016/j.infsof.2026.108119
Neumann, M., Bischof, L., Hinz, N. E., Altun, A., Stockmann, L., Schrader, D., Ahaus, A. C., Demirci, E. C., Gabel, B., Rauschenberger, M., Diebold, P., Fritzemeier, H., & others. (2026). Between Policy and Practice: GenAI Adoption in Agile Software Development Teams. In A. Goldman et al. (Eds.), Agile Processes in Software Engineering and Extreme Programming: XP 2026. Springer. https://doi.org/10.1007/978-3-032-22375-3_18