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.
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…
…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. |