Agile Is Not Running Faster: It Is Learning First

If you work on a technology team, you have probably heard these words more than once. But do we really know what working with Agile means, or are we just following a recipe? In this post we go over the concepts worth understanding before talking about tools or artificial intelligence.

Agile: learn before you run

When we talk about Agile, words like Sprint, Daily, backlog, Scrum Master or Jira appear quickly. But Agile is not about filling the calendar with meetings or moving cards from one column to another. For me, the idea is much simpler:

Do something small, check whether it delivers value, learn and decide the next step. And repeat.

Now, we also have a tool that can speed up that cycle considerably: artificial intelligence. Not to replace the team, but to reduce mechanical tasks and let us spend more time thinking, collaborating and making decisions.

Agile Is Not Just Scrum

Although we often use Agile and Scrum as if they were the same thing, they are not. Agile is a way of working based on collaboration, frequent delivery of value and the ability to adapt to change. Scrum is one of the frameworks we can use to put those ideas into practice, but it is not the only one:

Approach Main idea
Scrum Working in short cycles called Sprints
Kanban Visualizing and improving the work flow
XP Applying technical practices aimed at quality and frequent delivery
Scrumban Combining elements of Scrum and Kanban

What matters is not following a framework to the millimetre, but managing to deliver, get feedback and adapt.

How Does It Work?

Instead of trying to define a whole product up front, Agile proposes moving forward in small steps: Prioritize → Build → Validate → Learn → Adapt. If we use Scrum, this cycle is organized into Sprints with these moments:

  • Sprint Planning: we decide what we want to achieve.
  • Daily: we review our progress and whether there are blockers.
  • Sprint Review: we show what we built and collect feedback.
  • Retrospective: we analyze how we can work better.

The problem appears when these meetings become a formality. A Daily should not be a meeting to tell a manager what we did yesterday, and a retrospective is of little use if we find the same problems Sprint after Sprint and never do anything about them. Ceremonies make sense when they help us inspect and adapt our way of working.

What Roles Can We Find?

If we are talking about Scrum, we find three main responsibilities:

Role Main responsibility
Product Owner Prioritize and maximize the value of the product
Scrum Master Help the team work correctly with Scrum
Team members Build the product, carry out project tasks and decide how to do the work

But in a real team we can find many more profiles:

Product-oriented profiles: UX/UI Designer — designs the experience. Business Analyst — translates needs into requirements. QA or Tester — guarantees that what is built works.

Technical profiles: Tech Lead — sets the technical direction. DevOps — takes care of infrastructure and deployment. Data Engineer — prepares data and pipelines. AI Engineer — integrates AI models.

Other key roles: Stakeholders — represent business interests. Users — the reason for the product to exist. Their feedback is the main source of the Agile cycle.

An Agile team works better when different specializations work together around a common goal.

Tools Help, but They Do Not Make You Agile

Installing Jira does not automatically turn an organization into Agile. Tools should help us make the work and the information more visible:

Need Some tools
Planning Jira, Azure DevOps, GitHub Projects, Trello
Documentation Confluence, Notion
Communication Microsoft Teams, Slack
Development GitHub, GitLab, Bitbucket
CI/CD GitHub Actions, GitLab CI/CD, Jenkins
Design Figma, Miro
Metrics Grafana, Power BI, dashboards
AI Copilots, assistants and agents

The specific tool is secondary. What matters is avoiding having to know a project’s status by checking five different applications and asking half the organization.

Agile + AI

This is where I think things get especially interesting. On an Agile team there is a lot of work around the work: summarizing meetings, updating tickets, organizing feedback, writing stories, preparing acceptance criteria, creating test cases, searching documentation and generating reports. Many of these tasks can be sped up with artificial intelligence.

For example, tools like GitHub Copilot or Cursor can generate acceptance tests directly from the user story, while an LLM can analyze user comments to group common problems. It can also help us before a Planning by detecting stories that are too large or ambiguous requirements, and in a retrospective it can group similar comments so the team can focus on talking about the problems.

In development it can help us generate code, tests or change proposals. If the team also works with feature flags or short trunk-based branches, the delivery cycle becomes even shorter: less time between writing code and checking whether it works in production.

The cycle could go from something like:

Story → Development → Pull Request → Review

to:

Story → AI proposes → Team reviews → AI executes → Person validates

AI accelerates some parts of the process.

But there is an important difference:

AI can help us produce. It should not decide what is worth producing.

The Risk of Going Faster

This is probably the most important point. If we use AI only to generate more stories, more code, more documentation and more features, we can greatly increase our production capacity. But that does not mean we are building better products.

A common indicator is velocity: how many stories we complete per Sprint. If AI lets us deliver twice as much, velocity goes up. But if those stories do not solve real problems, we are accumulating debt disguised as productivity. We could have a Sprint with 40 stories closed and none of them requested by the user.

We can go very fast…

Velocity as a trap

…in the wrong direction.

And precisely there Agile still makes all the sense.

If developing a feature costs less and less, the important question stops being:

Can we build it?

And starts being:

Is it worth building it?

AI can analyze, summarize, propose and execute.

But we still need people who understand the user, question ideas, prioritize and make decisions.

A Concrete First Step

If you have a Planning or a retrospective tomorrow, try something simple: before estimating or prioritizing, ask the team “why this story and not another?”. You do not need to install anything or change your process. Just a question that forces you to connect the work with real value. If the answer is not clear, perhaps that story should not be in the Sprint.

The Agile to Come

I do not think the future of Agile is about inventing more ceremonies. I think it will be about getting people, tools and agents to share context better: that AI can prepare information before a meeting, that it relates feedback to features, that an agent can execute well-defined tasks. And that people can focus more on discovering which problem truly deserves our attention.

Because Agile was never simply about working faster. It was about reducing the distance between doing something and discovering whether we were doing the right thing. And there AI can become a great ally.

Quick Glossary

If any term in the post is new to you:

Term In one sentence
LLM An AI model trained on text (GPT, Claude, Llama) that generates, summarizes or analyzes content.
Token A unit of processing for the model — a word can take one or several tokens.
Velocity A Scrum metric: stories completed per Sprint. Dangerous if it is the only indicator.
Pull Request A proposed code change for the team to review before merging.
Feature flags Switches to enable/disable features without redeploying.
Trunk-based Working on a main branch with very short branches.
CI/CD Automated and frequent integration and deployment.